h1. Unhacking a WordPress site This is an INCOMPLETE guide, but a good starting point! It doesn't cover removing malicious code inserted into the database, for instance. WordPress gets hacked - a lot. And the correct solution is to restore your database and filesystem from backup. However, sometimes we deal with sites that weren't responsibly managed, and that's not an option. Here's a guide on what to do. First - if it IS an option, delete your WordPress filesystem and restore from known good files. There's just too many ways to obfuscate a hack, so these approaches are necessarily incomplete. * Search for suspicious PHP commands:
grep -r gzuncompress * grep -r base64_decode * grep -r eval( * grep -r str_rev *Not every instance of these commands is malicious! However, a hacked site will often use these, so look at what comes after them. If it's a long base64 block, that's bad news. Note that there are MANY ways to obscure the commands above. Here are some example strings you can also search for
"base" . "64_decode" eval/*That last one's tricky. It found this command: @eval/*boguscomment*/('malicious_command')@. * Check for this:
That evaluates to:
This indicates that there's malicious code in your database, and this minimal change allows the code to render. Here's the commands I used to remove that from my entire codebase:
find -name \*php -exec sed -i 's///g' {} \; find -name \*.html -exec sed -i 's///g' {} \;* Look for function names you discovered with the last command and grep for those. I found commands like "ruburat" and "ukonabuh" which I then searched for. * Use @git reset --hard HEAD@, if you're using git. * Don't assume git will remove everything! I found php files in places not checked by git. E.g. in the .git folder, to wp-config.php and civicrm.settings.php, wp-content/uploads. Here are some commands to help you find php files where they don't belong (run from webroot):
find .git -name \*php find wp-content/uploads -name \*phpFrom when Highlander was hacked: _*If the site is hacked*_ (note that I wrote these fast and before my vacation... they should probably be updated and my guess is this process can be refined) # Confirm that the site is hacked or being actively attacked ** This "flow chart":https://drive.google.com/file/d/1Z3u9hyVwIzyhY4EJKp6ixBMEX47P9mBZ/view?usp=drive_link might be of assistance # If the site is compromised, ssh into the site # Go to the web root directory and vim .htaccess # uncomment line 94 and change it with your ip so it should like this.
Require ip your.ip.goes.here another.ip.goes.here** Note that if it's a DOS or DDOS you'll need to set up some sort of firewall at the server level. # Save the htaccess file and confirm that only the required ips can access the site. # Login into the site; you should be able to find login information via bitwarden. # Goto plugins # activate Wordfence Security and run the malware scan ## this may take some time to complete. ## there will be some red herrings, such as un updated files. # If you find something confirm that the it's a hacked file... ## When you ssh into the root directory, run git status to see if any files have been changed. ## If the same file pops up, the site might be compromised. # If the site is indeed compromised. clean up up the bad files. # Check the database for compromised data. # First check if there were new users created:
wp user list --role=administrator --format=table** The above command produces a table that you can review and look for out of the ordinary users with wired emails and recent user_registered time stamps # If there bogus users, you'll need to delete them either through the wp cli or through web admin panel. # Check for bogus post data **
wp db query 'SELECT * FROM `wp1_posts` ORDER BY `wp1_posts`.`post_date_gmt` DESC LIMIT 10;' >> ~/last_post.txt** I use the above command to see if the last 10 post entires seem out of the ordinary. I then save it to a file. ** If it's a different website you'll need to make sure table names match. # If there is bogus data it's best to go into updraft plus and revert to the last clean back-up # You may want to change passwords at this point for users. # If that worked you can change the .htaccess file back by commenting out line 94 # Confirm that the site is working for all. # Continue to monitor the site for a few days