Disinfecting for WPYII2 – the #fakeplugin invading WP and how to kill it #wpyii2 #killwpyii2

I’ve just spent a week disinfecting my server from this pernicious bit of ruskyhack. Not only has it completely derailed my working week, its meant that my team have had very little work over that period as my websites have been unable to process orders. Whoever the surnames Skorobogatov, Serebryakov and Biryukov refer to, well, they should be ashamed of themselves.

The context is this. On a server (not the one this blog is hosted on) I have c. twenty installs of WordPress, plus several apps which are collected in three or four directories. I’ve got a variety of domains and subdomains, as well as password-protected directories for particularly sensitive work apps.

Now if I say that some of these apps take data from my WP install DB repackage it and spit it out via the Royal Mail API into their Click and Drop app, you will get why this fake plugin has completely disrupted that workflow. And of course the problem with some of the WP installs I am using is that, because of its wide integration into our production systems, I cannot upgrade either the WordPress version or the plugins associated with it.

WPYII2 found its way onto the server mid-week last week and the first I knew about it was some code appearing at the top of the homepage of several of my sites.

The damage was extensive. I lost three separate bespoke apps we use regularly for business because the fake plugin deletes top level ‘index.php’ files when they are not associated with a WP install. Luckily I had different earlier iterations available on the server so I could cobble together replacements – which ended up improving on the earlier versions.

As for the WP installs, well, they all fell over, repeatedly. I ended up playing whack-a-mole for a couple of days while trying to understand what the hell was going on. It didn’t help that there were plenty of posts from security firms saying, yes, this is a thing, and we’re here to help you get rid of it, but very few saying this is how you do it. I *think* I have done it, and the solution has ended up being cobbled together through trial and error and some helpful non-specific security posts from a variety of sources [for example]

So how to rid your WP install of this vicious fakery?

1. Open top-level index.php and delete the machine code sitting in lines 1-3
2. Delete any ‘new’ files at top-level that you don’t expect to see.
3. In cpanel use phpmanager to flip between php version to disable the fake plugins chron jobs
4. Replace the .htaccess file text with the single or multiple install vanilla code from here: https://wordpress.org/support/article/htaccess/
5. Delete all .htaccess files below the top level on the WP install.
6. Delete any folder in plugins which isn’t something you have installed eg. the folder called “wpyii2”
7. Look for any folders / files which have a recent ‘last modified’ date which you don’t recognise as being something you did.
8. Repeat 1 through 4 if at anytime the website won’t display / shows the code at the top of the page again.
9. Check 5-7 if you have to repeat 1 through 4
10. Once you have a clean install, or at least as clean as you can make it, and you don’t have to maintain an outdated version of WP, upgrade to the latest version of WP.
11. Upgrade all your plugins and themes. If you have made bespoke versions of themes by changing the code, I’d recommend trying to find a different way of creating the same effect through the customization options for that theme rather than altering the php.
12. Protect the ‘wp-admin’ directory with a password (check to see whether this works for your install of WP – I’ve had mixed results)
13. Install a firewall plugin – eg. BBQ Pro or similar
14. Install a 2FA plugin
15. Install captcha on login plugin.
16. Install a SSL/HTTPS force plugin – assuming you have a live SSL certificate for the relevant domain.
17. For 13-15 remember to do this for all iterations of a multisite – although BBQ Pro will activate across the network without further configuration (which I like).
18. With your wp-config.php file, add the following code before the ‘Happy Blogging’ message –> “define( ‘DISALLOW_FILE_EDIT’, true );” – this stops all editing of php / css / html within the WP environment (see note 11 re: editing themes etc.)
19. Consider moving the config file to the top level of your server, ie. above the ‘public_html’ directory, using the php code ‘require_once ‘/home/username/wp-config.php’;’ on the ‘wp-config.php’ file within the WP install directory.

As of 15th June 2022 I seem to have reached a stable environment with the fake plugin effectively being locked out by the abovenoted steps. However, I continue to monitor the server, and use downnotifier.com to give me immediate intel if things go awry. Any recommendations on other steps to keep this stuff away, let me know!

The cost of all of this to my business? Who knows? My time / stress? The lost orders? The lost IP? Those who black hat hack should reflect on their lives and wonder whether their skills could be better used elsewhere.