Presentation slides from Vladimir Lasky's talk "Tips for Fixing a Hacked WordPress Site", presented on Sunday 25th September at WordCamp Sydney 2016.

1. 1
Tips For Fixing a Hacked WordPress Site
Vladimir Lasky
http://wpexpert.com.au/
WordCamp Sydney 2016

2. 2
Bring Back Memories?

3. 3
Wordfence’s 2016 Survey on How Sites Were Compromised

4. 4
7-Step Recovery Strategy
1. Assess The Damage
2. Identify Sources of Replacement Data
3. Remove Infected Data and Restore from
Replacement Sources
4. Disinfect What Cannot Be Replaced
5. Reconstruct What Cannot Be Disinfected
6. Harden the Security of the Website
7. Repair Damage to Reputation

5. 5
Common Hurdles that Delay Repairs
 Obtaining SSH/FTP Access to Client’s Hosting
Server
– Especially when client is not owner/administrator of
their hosting service
 Obtaining Original Installation packages for
Premium Themes and Plugins
– Especially when site was built by someone else
– Often cheaper & faster to re-purchase plugins or
themes. Usually ensures renewed support & upgrades

6. 6
The Goal
 Ensuring complete disinfection
– There can be no remaining malicious scripts or
exploits that can be used to easily compromise the
site again

7. 7
1 - Assessing The Damage

8. 8
Identifying The Infection
 Sucuri Site Check
– https://sitecheck.sucuri.net/
 Google Webmaster Tools
– https://www.google.com/webmasters
 If WordPress admin is still accessible,
vulnerability scanning plugins like Wordfence
– https://wordpress.org/plugins/wordfence/

9. 9
Sucuri Site Check Example

10. 10
Wordfence Scan Functionality

11. 11
Wordfence Scan Settings

12. 12
2 - Identifying Sources of Replacement Data

13. 13
Recovering Website Content & Stylesheets
 Past Website Backups (Files and Database)
 Cached Version of the Website in Google Search
– E.g. to see the most recently cached version of
website.com, visit google.com and perform the
following query:
• site:websitehostname.com
 Archive.org (also called Internet Archive or
Wayback Machine)

14. 14
Example - Accessing Google’s Cache

15. 15
Example - Wayback Machine

16. 16
Recovering WordPress Itself
 The latest version of WordPress can always be
downloaded from this URL:
– https://wordpress.org/latest.tar.gz
 Previous versions can be found here:
– https://wordpress.org/download/release-archive/

17. 17
Recovering Website Themes & Plugins
 Common Download Locations for Free Plugins:
– WordPress.org Theme and Plugin Repositories
– GitHub
– Theme/Plugin Author’s home page
 Premium Themes/Plugins
– Ask clients to search their emails for
• original theme/plugin installation packages
• login details for theme/plugin marketplaces i.e. Envato
– Sometimes original theme/plugin packages have been left
on the server by a previous developer

18. 18
Disinfection

19. 19
What is Secure Shell (SSH)?
 Allows you to access a UNIX (Linux) shell on your
hosting server - similar to the Command Prompt
under Windows
 SSH access must be enabled by your web host
 Some hosts enable by default, others require a
special request, a minority forbid it 
 Recommended Windows SSH Client is PuTTY
– http://www.chiark.greenend.org.uk/~sgtatham/putty/

20. 20

21. 21
Why use SSH?
 Saves time spent in uploading/downloading files
to/from the web host
 Lets you run many useful UNIX/Linux shell
commands to help quickly locate and repair
damage
 Avoids triggering infected PHP code within your
WordPress installation

22. 22
Common Infectious Payloads:
 Shell code (a back door for the hacker)
– Often appears as strangely-named PHP files with
obfuscated content
 JavaScript code to run in the visitor’s browser that:
– retrieves content from external sites (often spam or spam
links)
– attempts to trigger vulnerabilities in the visitor’s web
browser
 The attacker boasting about their achievement

23. 23
Precautions When Making Changes
 Backup the site files and database before making
any changes
– cp –pa public_html prev
OR
– tar zpcvf prev.tar.gz public_html
 Also make backups during each step of disinfection
process just in case you make a mistake and have to
revert

24. 24
WordPress Files That Are Often Infected:
 Root Folder
– wp-config.php
– wp-load.php
 Anywhere within the installation:
– .htaccess
– index.php
– index.html
 Within directory /wp-content/
– Theme templates
– Plugin Files

25. 25
Disinfecting with Wordfence
 Wordfence has the ability to compare and replace
WordPress core files, theme files and plugin files
with official repository versions
 Powerful, but still often misses things
 Cannot help with custom/premium themes and
plugins
 Should always be followed up with manual
disinfection procedures

26. 26
Replace WordPress Core Files
 Move WordPress core files/folders within the
website’s root folder to a quarantined location
– Folder wp-includes
– Folder wp-admin
– Files matching wp-*.php (except wp-config.php), index.php,
xmlrpc.php
 Download the latest WordPress into a temporary
folder and move the new copies of the core
files/folders into the website’s root folder

27. 27
Inspect Site Content Folders
 Any remaining issues are likely to be contained within the folder /wp-
content
 Be suspicious of:
– .php files with unusual names
– ANY .php files within wp-content/uploads (should not normally be there)
 Index.php outside of the root folder files should normally only have
something like:
– <?php
// Silence is golden.
?>
– Their purpose is to prevent users from being able to list the directory
contents

28. 28
Finding Files Modified Between Two Dates
 Between two dates:
– find . -type f -newermt 2010-10-07 ! -newermt 2014-10-08
 Between two dates & times:
– find . -type f -newermt "2014-10-08 10:17:00" ! -newermt
"2014-10-08 10:53:00"
 This command will find and move the files to
“destdir”:
– find srcdir -type f -newermt 2014-08-31 ! -newermt 2014-09-
30 -exec mv -i {} destdir/ ;

29. 29
Comparing Site Files With A Good Version
 The utility diff compares two files/directories and
displays lines of text that differ between them.
 Comparing with a good version from a backup or
installation package may reveal the infection,
allowing it to be manually removed with a text editor
– E.g. comparing the theme folder with one from a backup
• diff –qr mybackup/wp-content/themes/mytheme public_html/wp-
content/themes/mytheme
– E.g. Comparing an installed plugin with a downloaded package
• diff –qr downloads/myplugin public_html/wp-content/myplugin

30. 30
Searching Contents of Files for Infections
 To search within a directory for files containing a
search string (regular expression):
– fgrep –R foldername “searchstring”
 These PHP functions are often present in
obfuscated code, so searching for them by name
can identify its presence:
– base64_decode
– gzinflate
– eval

31. 31
Infected Widgets
 On occasion, some attacks may result in
malicious JavaScript code is inserted into text
widgets
 Look through your widgets for anything that
should not be there

32. 32
Disinfecting .htaccess
 .htaccess contains settings that override the default
behaviour of the Apache web server
 Malware often overrides the web server’s error handler
with its own actions
 Detailed topic, but you can delete the .htaccess file in the
root folder and recreate it by going to Settings-
>Permalinks and selecting “Save Permalinks”
 If you are using a page caching plugin that modifies
.htaccess, you may need to reconfigure or save its
settings again.

33. 33
Example of Obfuscated PHP Code

34. 34
Failsafe Disinfection (Last Resort)
 Record the installed plugins & themes by:
– Accessing WordPress admin or
– By inspecting contents of /wp-content/plugins and /wp-
content/themes
 Use the WordPress Exporter plugin to export page, post and
menu content into an export file
– https://en-au.wordpress.org/plugins/wp-exporter/
 Quarantine the entire WordPress root folder
 Setup WordPress from scratch, install the required plugins and
themes, import content from the previous export file
– https://codex.wordpress.org/Importing_Content

35. 35
Common Disinfection Hurdles
 A theme/plugin with a security vulnerability is no
longer maintained
– Hire a developer to audit the code and fix its security
weaknesses
– Replace with a newer theme/plugin that provides
similar functionality

36. 36
Reconstruction
 Common Reconstruction Tasks
– Reconfiguring Off-the-shelf Plugins & Themes
– Rewriting Theme stylesheets and re-uploading
graphics
– Reconfiguring widgets
– Reposting content

37. 37
Security (Re)Hardening
 Reset users’ passwords
 Change the MySQL database password
 Update WordPress, Themes and Plugins to latest
versions
– May require renewal of support for Premium themes/plugins

38. 38
Beware of UTF-7 Encoding
 From WordPress Admin go to Settings->Reading
 Is this visible?
 An attack has weakened WordPress’s character
encoding settings to facilitate future XSS (Cross-
Site Scripting) attacks.
 Change this setting back to UTF-8

39. 39
Repairing Damage to Reputation
 Remove Google warnings by submitting a
reconsideration request in Google Webmaster
Tools that outlines:
– That you have disinfected your site
– What you have done to prevent a recurrence, e.g.
Updated software to address security vulnerabilities,
installed a Web Application Firewall (WAF)
 Inform users & readers of your site

40. 40
More Information
 Wordfence’s article “How Attackers Gain Access to WordPress Sites”
– https://www.wordfence.com/blog/2016/03/attackers-gain-access-wordpress-sites/
 Google Webmaster’s help for hacked sites:
– https://www.google.com/intl/en/webmasters/hacked/
 Slides from My Previous Security Talks. Old but good 
– Wordcamp GC 2011:
• http://slidesha.re/tr2XA5
• Covers the “Three Pillars of Security”, the aims of attackers and other WordPress security plugins
– WordCamp Sydney 2012:
• http://www.slideshare.net/wordcampsyd/securing-your-wordpress-website-vlad-lasky-wordcamp-
sydney-2012
 Questions and Comments:
– http://wpexpert.com.au/contact-us/