Project

General

Profile

Actions

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:
    <?php eval(get_option("\x72\x65\x6e\x64\x65\x72")); ?>
    

That evaluates to:

<?php eval(get_option("render")); ?>

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/<?php eval(get_option("\\x72\\x65\\x6e\\x64\\x65\\x72")); ?>//g' {} \;
find -name \*.html -exec sed -i 's/<?php eval(get_option("\\x72\\x65\\x6e\\x64\\x65\\x72")); ?>//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 \*php
    

From 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)

  1. Confirm that the site is hacked or being actively attacked
  2. If the site is compromised, ssh into the site
  3. Go to the web root directory and vim .htaccess
  4. 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.
  5. Save the htaccess file and confirm that only the required ips can access the site.
  6. Login into the site; you should be able to find login information via bitwarden.
  7. Goto plugins
  8. activate Wordfence Security and run the malware scan
    1. this may take some time to complete.
    2. there will be some red herrings, such as un updated files.
  9. If you find something confirm that the it's a hacked file...
    1. When you ssh into the root directory, run git status to see if any files have been changed.
    2. If the same file pops up, the site might be compromised.
  10. If the site is indeed compromised. clean up up the bad files.
  11. Check the database for compromised data.
  12. 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
  13. If there bogus users, you'll need to delete them either through the wp cli or through web admin panel.
  14. 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.
  15. If there is bogus data it's best to go into updraft plus and revert to the last clean back-up
  16. You may want to change passwords at this point for users.
  17. If that worked you can change the .htaccess file back by commenting out line 94
  18. Confirm that the site is working for all.
  19. Continue to monitor the site for a few days

Updated by Manu Mei-Singh about 1 month ago · 3 revisions

Also available in: PDF HTML TXT

Go to top