BMOW title
Floppy Emu banner

Web Site Hacked


Web Site Hacked
Web Hack Analysis Part 2
Web Hack Analysis Part 3

It’s Monday morning, and the BMOW web site has been hacked. In fact all six of my web sites at my shared hosting service have been hacked. Yuck! I think I’ve cleaned up the mess successfully, but I wasn’t able to determine how the hack originally occurred, so I’m not sure it won’t happen again.

Google Site Verification

I discovered the hack this morning, when I received an email notifying me that some email address I’d never heard of had been added as an owner of the Google Search Console account for Google Search Console is a developer tool that enables the owner of a web site to see how Google’s web crawler views it, and learn about potential problems with the site. At first I thought this might be a clever phishing scam – click the link in the email to be directed to a web site with some kind of drive-by download attack – but after closer inspection the email looked legitimate.

I logged in to the Google Search Console (by navigating there directly, instead of the email’s link), and sure enough (not the real address) had been added as an owner about 4 hours before. That shouldn’t be possible – to add yourself as the owner of a web site, Google Search Console requires you to prove your ownership by placing a specially-named file on the site. In this case, the hacker was required to place a file called google1a74e5bf969ded17.html on the site, with the contents “google-site-verification: googlea174e5bf969ded17.html” Google would then attempt to access the file and check its contents to verify the new owner. So I logged in to my server with ssh and checked the directory contents, and there was no file named google1a74e5bf969ded17.html. But when I pointed my web browser to /google1a74e5bf969ded17.html, the expected contents somehow magically appeared!

How can a request for a non-existent file on the web server return a seemingly valid file with the expected contents? Lots of ways. After doing a bit of experimenting, I discovered that any request for /googleNNNNNNNN.html would return a fake file with the contents “google-site-verification: googleNNNNNNNN.html” Something was procedurally generating valid-looking site verifications for any token ID, enabling anyone who wanted to to add themselves as an owner of my site with Google Search Console.

When you visit, a file on the server named index.php gets executed, and it generates the HTML content that’s ultimately displayed in your web browser. This index.php file is part of WordPress, the software I use to maintain the site. But when I opened index.php in an editor, I discovered that some new and evil-looking PHP code had been inserted at the top, in front of the regular WordPress code:


Welcome to code obfuscation city. I don’t know what all that code does, but I’m betting part of it is to recognize any Google site verification requests, and auto-generate a valid-looking response. And that check for “undermomocontrol” doesn’t look good.

After deleting the evil code at the top of index.php, I was able to remove the hacker’s email from the list of Google Search Console owners. It’s not clear to me why he bothered to add himself as an owner there, since I don’t think there’s anything you can actually change about the site or its search settings through that interface. Maybe he somehow redirected all BMOW search traffic to a site about Gucci handbags? I hope there wasn’t some hidden damage performed through the search console that I overlooked.

Incidentally, while I was poking around the Google Search Console site, I discovered that Google had sent me an email on May 8 about suspected hacking activity on my site. But my email client identified it as junk and sent it to the trash. 🙁

Examining the Hack

By checking the modification times on the files in each web directory, I was able to determine which files had been compromised. Here’s another of my web sites, that formerly contained only a static index.html file and a few zip files:


The hacker added new files named your.php, book.php, and clsssica.php. These contained more obfuscated PHP code. He also renamed my former index.html to index.php, and inserted the same evil header code as seen on the BMOW web site. And lastly, he added a .htaccess file, which controls how the Apache web server handles requests:


I’m not an Apache guru, but I think the two RewriteConds and the final RewriteRule are what’s important here. If Apache receives a request where the requested filename is neither a real file nor a real directory on the server, then the request will be remapped to index.php. This enables the evil code to run that auto-generates Google site verification responses.

The pattern of hacking was identical in all six web sites that I checked, all of which are subdirectories owned by my same Linux user account on the shared hosting server. In every case, the three files your.php, book.php, and clsssica.php were added. If index.php already existed, evil code was added to it. If only an index.html previously existed, it was renamed to index.php and the evil code was added. Then the .htaccess file was modified with the new rewrite rules, or the file was created if no .htaccess existed before.

I did some searching to see if these filenames and pattern of hacking are part of any known PHP or WordPress vulnerability, but I found nothing. As far as I can tell, this is a new hack.

Cleanup and Prevention

I deleted all the evil files from all the web directories, and removed the evil code from index.php, and the unwanted rewrite rules from .htaccess. Then I removed write permissions from index.php, .htaccess, and the root directory of each web site, to make them more difficult to reinfect. I also changed the admin password for each WordPress installation, and made sure each was upgraded to the latest version of WordPress. And I changed my password for the shared hosting account.

Steps to Take When your PHP Site has been Hacked contained a lot of useful suggestions for finding and cleaning up parts of the infection. Using the methods described there, I recursively checked all the subdirectories on each web site for potentially infected files, including PHP code hidden inside of image uploads and other sneaky things. I didn’t find anything – as far as I can tell, the files I mentioned previously were the only ones modified on each site.

So how did this happen? It appears that the original infection occurred on May 2, which is when your.php, book.php, and clsssica.php appeared on each site. But activity continued for some time after that. Index.php was modified just a couple of days ago. My web host only maintains a single week’s worth of server logs, so I don’t have any way of seeing what happened on May 2.

Did the infection occur through a WordPress vulnerability? Possibly, but only two of the six infected web sites were running WordPress. Given the way the sites are configured on the shared hosting server, though, it might be possible for an evil PHP script running as part of one web site to modify files in my other web sites. All six web sites exist as subdirectories in the home directory of my Linux user account on the server. If a PHP script that was launched due to a request for can do

<?php fopen("../", "w"); ?>

then the infection can easily spread from one site to another. I don’t know if PHP is configured this way by my hosting provider, but I suspect it is. There was a seventh defunct web site in my account, which was also infected. This was a subdirectory that contained all the files for a web site, but there was no hosting provided for that web site, and no way to access it through the web server. The fact that it got infected anyway means that the infection didn’t come from a direct web attack on that site. Hmmm.

It’s also possible that someone guessed my password for the shared hosting account, or sniffed it with a keylogger or some other tool. Or maybe the shared hosting server itself was compromised, through some vector exposed by another customer on that server, or a vulnerability in the server itself as configured by my hosting provider. It seems unlikely that I’ll ever know the true answer.

Read 10 comments and join the conversation 

10 Comments so far

  1. Keith M - July 13th, 2015 6:46 pm

    Hey Steve,

    My wordpress site fell victim to being hacked by pharma-spam hackers a year or so ago. It was a royal pain in the butt to fix everything, and I think I ended up needing to do a reinstall. It took hours to fix, partially because I only know about 1/2 of what I’m doing….

    Google was reporting on all searches that returned my website as a result that my “site may be compromised.” and sure enough, it was.

    I switched off of GoDaddy shared linux hosting for a variety of reasons, one of which was really really poor performance.

    I am now with wpengine, which is managed hosting. It’s $29/month. They worry about the security details, and there’s a ton of nice features. For instance, they back my database and site contents up every day, and you can arbitrarily backup the site whenever you want. So, for instance, before you upgrade plugins, then you can take a snapshot, and if things go awry, then you just push the old snapshot back into place. They also do it automatically before version upgrades.

    The performance rocks, too.

    I’m just a happy customer, no vested interests…..

  2. Erik Petrich - July 14th, 2015 10:03 am

    (disclaimer: I’m not a PHP expert)

    $e is base64 encoded PHP, which gets decoded and executed with @$d($f) ($e has been embedded within $f)

    This defines the vspider_get() function, which seems to do a basic http GET, although interestingly it does set the accept-language to “momo”. It also sets $ref to the referring URI and $agent to a string that contains the user’s IP address, the server’s name, the user’s agent (web browse ID info), the requested URI, the referring URI, and finally “2v”; all of these fields are delimited with a “|”.

    Then it uses vspider_get() to fetch, but passes $agent as the user agent. It base64 decodes the file it gets back and if it contains undermomocontrol it executes it as PHP as well. So presumably, has been hacked and has the code that’s generating the Google site verification file, based on all the data packed into the $agent. The user agent data is usually saved in the web server logs, so all this information about who has been visiting your web site is probably now also packed into the site logs.

  3. Steve Chamberlin - July 14th, 2015 6:58 pm

    Good analysis, thanks. The code seems to be going to some trouble to avoid having “eval” or “base64_decode” appear in plain text, building those strings up letter by letter, concatenating $g (an empty string) between each letter. But then at least base64_decode appears in plain text anyway, so all that trickery seems to be of questionable value.

    I saved the hacked version of the index.php file with the evil code, as well as the book.php, your.php, and clsssica.php files, if anyone wants to look at them.

  4. Steve Chamberlin - July 15th, 2015 8:30 am

    My hosting provider confirmed what I suspected: if one of my sites gets infected, all of my sites under the same Linux user can be infected.

    “You should check any other domains (if applicable) for vulnerable software as well, as one domain being exploited could result in all domains under that user being exploited due to the shared permissions and home directory.”

  5. Jody - July 17th, 2015 3:59 am

    @Keith M, your comment isn’t of no value since this post is all about technical details.

  6. Gregg C Levine - July 17th, 2015 6:30 am

    You dodged a big one there. Good going. I strongly suggest you check to see further how that exploiter got in. If he used SSH, then you need to check to see how he got in. If it was user level, and then use the Sudo series of commands to elevate the shell, then change your user password to something so obscure its not at all known to any of us.
    Do not use the name(s) of your offspring.
    When I got started with Linux and DSL in a big way at the beginning of this century, I saw and stopped a series of interesting hacks.

    @Jody, Keith M, was only giving our host some good advice.

  7. Jay Ferrando - July 17th, 2015 8:23 am

    Are you positive that your server/site is clear of any further infiltration?

    It seems to me the http request being made is likely pulling in a second code payload. There could be any number of remote access tools still on the machine. It would also be prudent to check for other back doors the attacker may have left open, Additional FTP/SSH users, etc.

  8. makerimages - August 25th, 2015 1:30 am

    for me, the frontpage doesnt completely load and f5 renders the site ERR_CONN_REFUSED for the rest of the day. I’m not sure everything is cleaned up…

  9. SeannyFunco - October 27th, 2015 7:36 am

    Thanks for posting this info Steve. Just recently got hit by this too and your site helped tremendously!

  10. dharma - February 28th, 2016 7:28 pm

    does adding a SSL to my website solve this issue.? or what can i do to solve this issue.

Leave a reply. For customer support issues, please use the Customer Support link instead of writing comments.