PT Commons

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:

<pre>

grep -r gzuncompress *

grep -r base64_decode *

grep -r eval( *

grep -r str_rev *

</pre>

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

<pre>

"base" . "64_decode"

eval/*

</pre>

That last one's tricky.  It found this command: @eval/*boguscomment*/('malicious_command')@.

* Check for this:

<pre>

<?php eval(get_option("\x72\x65\x6e\x64\x65\x72")); ?>

</pre>

That evaluates to:

<pre>

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

</pre>

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:

<pre>

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' {} \;

</pre>

* 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):

<pre>

find .git -name \*php

find wp-content/uploads -name \*php

</pre>

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)

# 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.

<pre>Require ip your.ip.goes.here  another.ip.goes.here</pre>

** 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:

<pre>  wp user list --role=administrator --format=table </pre>

** 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 

** <pre>  wp db query 'SELECT * FROM `wp1_posts` ORDER BY `wp1_posts`.`post_date_gmt` DESC LIMIT 10;'  >> ~/last_post.txt </pre> 

** 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