Book Sale! Save 20% on all books w/ code: WP2024
Web Dev + WordPress + Security

Tale of a Hacked Website

[ Prise de la Bastille, by Jean-Pierre-Louis-Laurent Houel (Detail) ] I love a good story. Almost as much as I enjoy securing websites. Put them together and you’ve got suspense, intrigue, and plenty of encoded gibberish. But no happy ending this time, in this case the smartest decision was to “pull it” and rebuild. The site was just wasted — completely riddled with malicious code. Without current backup data, it would’ve been “game over” for the site, and possibly the business.

There are several lessons in this sordid tale of hack-recovery, including a reminder of perhaps the most important of all: backup thy data. Without a good backup policy, you’re just begging for data loss.

Act I: The Warning

It’s always first thing in the morning. Out of bed, sit in chair, check email. Uh-oh, what’s this.. someone needs help with a hacked website. Thankfully it’s not anything of mine (just sayin’). So I jump up out of Mail and scramble to the Chrome-mobile. Immediately I’m stopped by the worst:

[ Google warning: visiting this site may harm your computer ]

Ugh.. that’s no good, but don’t panic, let’s take a closer look and gather any clues:

Diagnostic page: “ contains malware”:

  • Site is listed as suspicious – visiting this web site may harm your computer.
  • Part of this site was listed for suspicious activity 28 time(s) over the past 90 days.

Of the 39 pages we tested on the site over the past 90 days, 16 page(s) resulted in malicious software being downloaded and installed without user consent. The last time Google visited this site was on 2012-06-02, and the last time suspicious content was found on this site was on 2012-05-21.

  • Malicious software is hosted on 2 domain(s), including ayy.bee.cee/, dee.eee.eff/.
  • This site was hosted on 1 network(s) including 1234567 (CODENAME).

If you are the owner of this web site, you can request a review of your site using Google Webmaster Tools. More information about the review process is available in Google’s Webmaster Help Center.

This is your basic intercept page from Google, designed to alert visitors to potential danger. It does in fact offer some clues about the situation, including:

  • Number of reports of malicious activity
  • Number of pages tested, number of malicious events
  • Date of most recent visit, date of recent malicious activity
  • Location of any externally hosted malicious software
  • Where to find more information and help

Fortunately it’s not always as bad as it looks. Unfortunately, this time it was..

Act II: The Diagnosis

[ Paratroopers of the 50’s @ ] Upon connecting to the hacked server via SFTP, it’s time to search for hacked files, beginning with one of the most widely used obfuscation methods: eval(base64_decode.

So I download the current theme directory, make a backup, and begin scanning.. almost immediately hundreds of results fill the screen — and the count:

504 items found in 848 documents.

Ewwww… that’s a lot, by any measure. Looking at the code was like watching one of those bloody scenes from an old gangster movie.. in the theme’s archive.php file, for example, there were 24 instances of malicious code — literally packed into a file that’s normally a mere 50 lines tall. And with the red syntax highlighting for all the encoded gibberish, it just looked like a bloody mess. Essentially DOA. Here is a screenshot to help visualize the situation:

[ Screenshot of encoded gibberish (obfuscated payload) ]
The site was riddled with hundreds of instances of this obfuscated PHP code.

Act III: The Payload

When successfully introduced into its target, malicious code is often referred to as “payload”, referring to both manner of delivery and potential of production. Once payload is discovered, understanding its purpose reveals useful information regarding:

  • the severity and scope of the attack
  • additional files and/or code involved
  • the method or point of entry of the attack
  • clues to the identity/location of the attacker

[ SPACE ART: Space Shuttle Payload Bay Concept @ ] Whatever the payload, it behooves the investigator to examine it thoroughly. In this case, most of the code had been obfuscated using a common method, eval(base64_decode(. There are numerous ways to decode encrypted PHP code, but the easiest is to copy/paste the encoded string into your favorite online PHP decoder. It’s like, “click, click, and done.”

I can’t display the actual code here on this web page because search engines and anti-virus software will flag my site as “suspiciously malicious” or something equally scary. But it is safe to share the code via external text files; so in the name of “peace and safety,” here is the principle payload, in both encoded and decoded flavours:

Throughout the site, hundreds of instances of this malicious code were discovered. And not entirely in WordPress core and theme files — many of the client’s custom/3rd-party scripts were also infected. Indeed the situation was grim, so time to clean up the mess, lock things down, and back in time for lunch..

Act IV: The Verdict

[ Scene from ‘The Verdict’ ] After assessing the severity of the damage, the verdict was to nuke the site and restore from backups. This is a prime example of why backing up your data is so important. If the client had not a recent set of backups, it would’ve been game over. It’s easy enough to delete everything and reinstall WordPress (or whatever other software), but with many custom/3rd-party scripts and files, rebuilding from scratch takes WAY more time than re-uploading from a recent, complete set of backup files.

Another option might have been to try “cleaning” the infected files with a plugin, script, or even manually. There are several good reasons why cleaning is ineffective:

  • No guarantees. Unless you’re using a script or service that scans files and compares against originals, you can’t be sure that all traces have been removed completely.
  • Malfunction. Payload could disrupt/alter functionality of plugins or other auto-scanning services, and make things worse.
  • Waste of time. It’s just waay faster and more convenient to restore from backup rather than clean.

Regardless of whether you clean or restore, the most important thing is to patch any security holes. How did the attacker get in? Were there multiple points of entry? You’ve got to scan the logs, follow the tracks, and ultimately lock things down. Here is my basic process:

  1. Put client site in maintenance mode if necessary
  2. Duplicate hacked site locally and investigate offline
  3. Restore clean site from most recent working backup
  4. Patch any/all security vulnerabilities
  5. Test thoroughly

I go further into depth on this process of cleaning up a hacked website, so give it a read for more information and tips.

Act V: Epilogue

So case closed. After the diagnosis, there were plenty of details to work out. How to improve security, for example. Should the client find a new host, like maybe something that is not on a shared server. A private or virtual private server would lower the chances of another attack. And becuase you’re already starting over with a restore, what better time to find better hosting. And you know that there’s better hosting out there. And more than anything else you do online, finding reliable & secure hosting is worth your time and money. A more secure server gives you a better foundation for securing your online assets.

Lessons learned from this sordid tale of virtual intrigue:

  • Always keep dependable recent backups — files, database, email, etc.
  • Don’t try “cleaning” a hacked site — restore from recent backup instead
  • There’s always better hosting — and it’s your mission to find it

While I’m on the soapbox: take the time to test that your backups actually work. It’s pretty easy to know that files will work, but database imports fail frequently enough to be concerned, so you want to check that your exports are solid, otherwise what’s the point? Might as well not even bother with backups at all. Perhaps a career in the service industry..?

Act VI: Encore (Log Analysis & Security Tips)

Alas, the missing chapter — thanks to Vladimir for furthering the story with some excellent insight and advice into the better securing of your site, particularly those of the WordPress variety :)

Jeff Starr
About the Author
Jeff Starr = Web Developer. Security Specialist. WordPress Buff.
.htaccess made easy: Improve site performance and security.

22 responses to “Tale of a Hacked Website”

  1. Lisa Webb 2012/07/11 8:06 pm

    I have recently had many of my sites hacked and a massive “eval” code placed in ALL of the .php files of the affected sites.
    There was a log file in the public_html that showed a list of 10 sites.

    I was only aware that these sites had been attempted by getting warning of blocked attacked by WP Firewall – I probably not have known anything was happening without this plugin – as the sites all still function as normal. It didn’t stop them actually getting in – in the end, but at least it let me know something was going on.

    I only found the eval code when I changed a theme and was editing the header file to use SEO by Yoast and I noticed the code in there.

    I used site checker and got the dreaded “infected”. I then used Sucuri’s’ rrnuVaccine.php file, which is uploaded to the root and run. It takes about 5 seconds to delete the code from all the php files – most sites had over 800 infected files.

    I then went into the sites via ftp and deleted the log file, and any extra, odd files I could find. There were things such as a “default” page which went to Hostgator (I wasn’t using Hostgator), and other files I knew didn’t belong there.
    I then used (again) Sucuri’s .htaccess code to deny access to the list of 10 sites. Running the site checker again, the sites came up clean.

    So far this has all worked and my sites are not getting infected again, but I am still getting WP Firewall warnings of deflected attacks. AND I can see that someone is still poking around trying to get in again.

    I have just added your 5G to my .htaccess files and will see if that stops them accessing my sites.

    Can you please advise if this is OK to add to my .htaccess ALONG WITH the Sucuri code to deny access to those 10 sites?

    As someone who is not knowledgeable in any of this sort of thing it has been very trying and I am hoping that it will stop.
    I also think that there must be a massive amount of WP blogs that have this infection and the owners do not even know it.

  2. Lisa Webb 2012/07/11 8:12 pm

    Just subscribed so I can keep up to date :-)

  3. Can you please advise if this is OK to add to my .htaccess ALONG WITH the Sucuri code to deny access to those 10 sites?

    .htaccess is used to block access FROM specific address(es), not TO.

    Thus if you added something like

    deny from

    this will mean that will get 403 Forbidden error when trying to access your site, but this does not stop the code on your site to access

  4. Lisa Webb 2012/07/12 5:29 pm

    Thank your for the reply. I am just not sure “how much” I should be adding to the .htaccess. Wanted to know if it is OK to add the 5G as above when I already have this (plus the ordinary WP stuff and W3 Total cache stuff:
    Options All -Indexes
    RewriteEngine on
    # Options +FollowSymlinks
    RewriteCond %{HTTP_REFERER} [NC,OR]
    RewriteCond %{HTTP_REFERER} [NC,OR]
    RewriteCond %{HTTP_REFERER}
    RewriteRule .* – [F]

    I have actually 20 domains in that list, that I saw had accessed my sites. The above code came from and seems to have stopped the hackers in the meantime, however the domains will most likely change …

  5. Great article! Two of my sites was hacked three months ago and the hackers used them to sale google ads (adsense).
    The interesting part was that i did not saw the ads on my desktop, i discovered the ads viewing the sites on my iphone.
    First thing i did was to loggin in my wp-admin and search for the code that generated the ads, it was nothing there so on my usual ip adress i got a “mirror” of my site with no ads on it.
    It took me two days to find the code on the server. Both sites was hosted on the same shared server so just as you posted: “There’s always better hosting — and it’s your mission to find it”.

Comments are closed for this post. Something to add? Let me know.
Perishable Press is operated by Jeff Starr, a professional web developer and book author with two decades of experience. Here you will find posts about web development, WordPress, security, and more »
Blackhole Pro: Trap bad bots in a virtual black hole.
Note to self: encrypting 500 GB of data on my iMac takes around 8 hours.
Getting back into things after a bit of a break. Currently 7° F outside. Chillz.
2024 is going to make 2020 look like a vacation. Prepare accordingly.
First snow of the year :)
BF Sale! Save 40% on all Pro WordPress plugins and books w/ code FRIDAY23
Sincerely trying to engage more on social media. I love the people not the platforms.
All free and pro WordPress plugins updated and ready for WP version 6.4!
Get news, updates, deals & tips via email.
Email kept private. Easy unsubscribe anytime.