Dealing with a hack

Hello loyal readers.  A couple of days ago, this blog got hacked.  Instead of the usual “Ant-Like Persistence” page, it was a mostly blank page asking the visitor to type in a password.

Several nice people dropped emails to me to let me know they had noticed the problem.

I will describe what had gone wrong and what I did to fix the hack. 

The blog is, of course, hosted with WordPress.  I have the blog hosted on a fairly robust hosting platform and the WordPress instance is set up in a fairly robust way.  Nonetheless, a bad person managed to hack it.

I will start with the answer.  The answer is that the bad person created a folder called “mu-plugins” in the main folder for this blog.  “Mu-plugins” is a very odd place.  It means that whatever is located in this folder is a “must-use” plugin.  In the world of WordPress, it means the plugin is absolutely required to load and run no matter what else happens.  It is very difficult for the administrator of the WordPress site to even learn that the “mu-plugins” folder has been created, and it is very difficult for the administrator of the WordPress site to learn what, if anything, is located in that folder.  Basically you need to get out of the normal environment of a WordPress administrator and you need to get into the higher-level environment of the world in which WordPress is executing, to learn that this hack has happened.

If the WordPress instance is in a cPanel environment then it means you must get into the cPanel administration environment. If the WordPress instance is in a Synology environment then it means you must get into the Synology administration environment.   Maybe the WordPress instance is on an ordinary Linux box.  In that case, you must get into the Linux root administration environment.

How did the bad person somehow create the “mu-plugins” folder and how did the bad person somehow load a very evil “index.php” file into that folder?  I cannot be very certain, but I think the bad person somehow compromised one of the plugins that I had installed in my WP environment.  The evil “index.php” file had a file creation date and time that matched the date and time that the blog got hacked.

The corrective steps included:

    • delete the”mu-plugins” folder
    • reinstall WordPress from the top to the bottom
    • delete all of the themes that I was not actually using
    • delete all of the plugins that I did not absolutely need (this included deleting a couple of plugins that I suspected of having been compromised)
    • reinstall the theme that I was actually using
    • carefully inspect my wp-config.php file (it was intact)
    • reinstall each of the plugins that I was actually using
    • run a linux virus scan in my hosting environment
    • run a WordPress malware scan in my WordPress hosting environment
    • change several passwords
    • change several 2FA shared secrets
    • do several other things that I will not detail here

One of the learning opportunities here is to be vigilant about any possible “mu-plugins” files.

Leave a Reply

Your email address will not be published. Required fields are marked *