My site was hacked this morning – something I discovered by visiting my site, only to be greeted by Google’s genuinely frightening “WARNING: VISITING THIS SITE MAY HARM YOUR COMPUTER” screen.
The culprits altered every file ending in “.html”, as well as every file beginning with “index.”, to add a hidden IFRAME element to the page. That, in turn, would quietly load a web page from a third-party site that attempts to install malware onto visiting computers.
Nasty. And not uncommon for WordPress users.
Fortunately, I was able to track down and wipe out the infection in short order. Here’s how:
- I looked at the timestamp on the hacked files. Each had been changed at 5:13 am today.
- A quick trip to my server logs revealed that at 5:13 am, a file called “cache.php” was accessed using POST.
- A peek at the file, a little Googling, and a look at a default WordPress installation, confirmed for me that cache.php a) didn’t belong, and b) was a very likely culprit. Backed up, and then deleted it.
- This left me with the challenge of restoring all of the files that had been hacked (there were more than you might think). I didn’t relish the thought of doing it one by one. Fortunately, Dreamhost has a “Restore” command for domains that can let you roll a site back to a snapshot from a few days or weeks ago.
- Unfortunately, it didn’t work. Fortunately, Dreamhost lets me use SSH to access the server.
- I found a code snippet from this helpful guy on WordPress.org’s support forum that let me run a search-and-replace operation from the command line. I just replaced his search string with mine (the URL his iframe pointed to was different from the one my hackers used), being careful to put a backslash before every forward slash in the URL.
- Then I went to Google’s Webmaster Tools home page, and requested a review of my site, letting them know I’d removed the nasty bits. That should soon mean you can visit this site without having to click past dire warnings of impending doom.
I’ll be checking even more regularly for rogue PHP files like cache.php – especially now that I know what to look for. And I’ve saved that search string for future use; with any luck, it will only be useful for helping others who’ve run into this.
You’re investigative skills are remarkable!
It’s nice to see someone who share their experience with their readers. Often times many just want to forget it ever happened.
However, you have one last step, you need to find out how that cache.php file got there in the first place. If one hacker/cybercriminal found a way in, others will as well.
Often times, these files are placed there with stolen FTP login credentials. These credentials are stolen by a virus on a PC with FTP access to the infected website. Typically the hackers replace legitimate files with infected files. In your case they put a file that provided them with remote access to your site and possibly sent the modified files through their file.
What I’ve been recommending on sites like http://www.badwarebusters.org is to install a new anti-virus program. The reason is that the viruses learn how to avoid detection of the currently installed anti-virus program. Otherwise, the current anti-virus program would have detected the virus and removed it.
Many have had good success with AVG, Avast or Avira. Select one of these and also use Malwarebytes. This combination should find and remove any viruses/trojans on the PC.
Then change all FTP passwords and you should be safe from any future hackings.
Nice job on the investigation and the reporting. If you care to share the cache.php file, I would like to see what it does and how it does it. I can report back to you with my findings. Please share the file.
Thank you.
Thomas, thanks for the solid advice on checking for malware. In my case, I’m on a Mac with decent protection (hello, ClamXav!) so I’m not as worried about my laptop having been compromised – but I don’t want to be complacent.
That said, I don’t think malware protection and changing my FTP password alone will leave me save from future hacks, because those measures don’t address the server end of the situation. And there, I have a likely suspect: WordPress itself. I was late to the party in upgrading to version 2.8.4, and there were some crucial exploits in earlier versions. Given how many WordPress users have had similar attacks on their sites, I’m guessing that’s how my hacker got in.
Nonetheless, I’ve changed the FTP password, disabled a few plugins that were on the strictly optional end of the Spectrum of Essentialness, and done a little extra site hardening (am I the only one who thinks that sounds rude?) with the help of WP Exploit Scanner and WP Security Scan.
Hi Rob, yeah the WP Exploit Scanner is your friend.
In the spring I wrote up my advice for dehacking your WordPress site.