“Why does our website seem so sluggish?” A client recently asked.
Much like the slow infected walkers on The Walking Dead, a hacked website can have a dramatically reduced loading speed. I set out to rid their website of it’s Walkers, Rick Grimes style.
First: Always CYA
I started by making a backup of their database. I never skip this step! If something goes wrong, your ass is covered.
[hr type=”single” margin_top=”40″ margin_bottom=”40″]
Lock It Down
[list type=”check”]
- CHANGE THE SALT KEY. The SALT key lives in the wp-config.php file. Doing this will log out any users currently logged into the WordPress install on the website. *Zap* Mutha F*ckers!
[/list]
[list type=”check”]
- CREATE ALL NEW PASSWORDS. This cannot be stressed enough. There are a number of passwords you will have to change, including the WordPress users, FTP, and the database password. Remove any unnecessary users and/or make sure anyone with administrator privileges should have them.
[/list]
[hr type=”single” margin_top=”40″ margin_bottom=”40″]
Assess The Situation
One handy tool I use to scan for malicious files in WordPress is WordFence.
During a Wordfence scan, it will compare your WordPress core files with the repository for any differences. The same goes for your plugin files, and optionally, your theme files. I use the free version of the plugin, but there are many more options available in the paid version.
The results of the scan showed me a long list of malicious files that were placed inside of plugins, themes, upload folders, and the core files of WordPress itself.
[hr type=”single” margin_top=”40″ margin_bottom=”40″]
Clear The Room
I went through the list of files, and via FTP, deleted the ones that were not supposed to be there. Then, using the Wordfence plugin, chose to restore the modified files that are supposed to be there back to their original versions.
[accordion]
[accordion_section title=”List of Files Caught By WordFence”]
Injected Malicious Files:
wp-includes/js/swfupload/alias.php
wp-includes/js/tinymce/plugins/directionality/start.php
wp-includes/js/tinymce/plugins/wpautoresize/javascript.php
wp-includes/js/tinymce/plugins/wpdialogs/sql.php
wp-includes/ID3/dump.php
wp-content/uploads/2014/11/css.php
wp-content/uploads/2014/09/info.php
wp-content/themes/Avada/archive.php
wp-content/themes/Avada/css/skins/page.php
wp-content/themes/Avada/style_selector.php
wp-content/uploads/2013/02/dirs.php
wp-content/uploads/2013/05/system.php
wp-content/plugins/wp-firewall/config.php
wp-content/plugins/w3-total-cache/pub/js/functions.php
wp-content/plugins/w3-total-cache/pub/files.php
wp-content/plugins/w3-total-cache/lib/W3/ObjectCache.php
wp-content/plugins/w3-total-cache/lib/SNS/sdk.class.php
wp-content/plugins/w3-total-cache/lib/CSSTidy/utf.php
wp-content/plugins/revslider/views/templates/slider_css_js.php
wp-content/plugins/backwpup/vendor/Guzzle/list.php
wp-content/plugins/backwpup/vendor/PEAR/Net/include.php
wp-content/plugins/revslider/css/font/view.php
wp-content/plugins/backwpup/inc/class-mysqldump.php
wp-content/plugins/backwpup/vendor/Aws/Common/Enum/option.php
wp-content/plugins/backwpup/vendor/Guzzle/Inflection/defines.php
wp-content/plugins/backwpup/vendor/Guzzle/Stream/stats.php
test_framework.php
Modified Existing Files:
wp-content/plugins/w3-total-cache/readme.txt
wp-content/plugins/google-sitemap-generator/readme.txt
wp-content/plugins/backwpup/readme.txt
[/accordion_section]
[/accordion]
Once the files were either cleared out and/or restored, I checked all pages and posts for any injected code. In this instance, I was lucky. It was clean. However, I have come across pages/posts with injected code before. One thing to look for is malicious code wrapped in a div with it’s opacity set to 0. Tricky!
Don’t forget to check inside the .htaccess file. Depending on your hosting setup, you have an .htaccess file that sits in the root directory, and inside other directories as well. Make sure there isn’t any malicious code in them. For this project, there wasn’t any, but the .htaccess file is a popular place for hackers to add code. If you do find malicious code, delete it.
[hr type=”single” margin_top=”40″ margin_bottom=”40″]
Update Your Weaponry
Next I made sure all the software was up to date.
Updating all of the plugins that were installed, even the the ones that are deactivated, is very important. Deactivated plugins are still vulnerable to attack. Personally, I like to remove any plugin that is not active.
Next update all of the WordPress themes. Yes, even though you can only activate one theme at a time, any installed theme is vulnerable to hacking.
**Tip: I like to keep the most recent of the default WordPress themes installed and updated just in case I need to switch themes for troubleshooting purposes.
[hr type=”single” margin_top=”40″ margin_bottom=”40″]
CYA 2
At this point, I make a new ‘clean’ backup of the database.
[hr type=”single” margin_top=”40″ margin_bottom=”40″]
Beef Up Security
To help ward off getting hacked again – or so easily at least, I added a few snippets of code the the .htaccess file.
This snippet protects both the wp-includes and admin/includes directories:
# Block the include-only files. <IfModule mod_rewrite.c> RewriteEngine On RewriteBase / RewriteRule ^wp-admin/includes/ - [F,L] RewriteRule !^wp-includes/ - [S=3] RewriteRule ^wp-includes/[^/]+\.php$ - [F,L] RewriteRule ^wp-includes/js/tinymce/langs/.+\.php - [F,L] RewriteRule ^wp-includes/theme-compat/ - [F,L] </IfModule>
This snippet protects the wp-config.php file:
# protect wpconfig.php <files wp-config.php> order allow,deny deny from all </files>
Additionally, I added a snippet to the wp-config.php file to disallow file editing in the WordPress backend. So if somebody does get into your WordPress backend, they cannot edit any theme or plugin files through the built in file editor.
define('DISALLOW_FILE_EDIT', true);
Once you have cleaned up the files, you can go back and set up some configurations for WordFence. On this website I temporarily configured it to alert me when anyone logs in or when a file is modified. This will allow me to see if my work here is done. Ideally, I will only see the legitimate users logging in.
Additionally, I set it to immediately lock out any user who tries to log in with a username that is NOT currently being used, and that includes the default ‘admin’ username. After a couple of weeks of normal interaction, I will turn off those notifications.
** On a side note: Here is an article on WHY you shouldn’t be using “admin” as a username.
[hr type=”single” margin_top=”40″ margin_bottom=”40″]
Have you been $%^*?! HACKED?
You will never stop the flood of Walkers trying to get into your site. But just like Rick and Daryl, you can make it much harder for them.
If you find yourself swallowed up by a sluggish website riddled with malicious code, I hope this post helps you out. Additionally, you can also hire me to clean it up for you. I like this type of stuff.
Share your experience & tips in the comments.
Leave a Reply