Recently one of my clients received a warning notice via Google Webmaster Tools that one of our sites was the target of a phishing hack. I checked it out and sure enough, if you copied the long URL it provided into your browser bar, it displayed the dreaded red warning page:
When you clicked past the warning, it showed a phishing page that looked like this:
I’ve put a big emphasis on WordPress security for all of my clients in 2015 after going through a couple of hacked site ordeals. I currently use the iThemes and Sucuri security plugins, but have been using WordFence more recently because of it’s terrific deep scanning capabilities. (More on that later). So I was pretty miffed that we had been hacked again.
I ran Sucuri and Wordfence scans and they came up with nothing.
I manually checked a handful of areas to see if I could spot the hack: header.php, functions.php, looking for weird plugin directories, looking for weird files in the root directory and other places. I couldn’t find anything. That doesn’t mean malicious code wasn’t hidden somewhere, so I went through the process of completely reloading WordPress, site content files, and the database from backups. Note, I always do manual checks first to see if I can find the code because I want to learn more about where malware can show up.
After a full reload, I still got the hacked page. Obviously, if the hack was removed, we should have been getting our normal 404 page when typing in the long, suspicious URL. I couldn’t figure out what was going on.
I put in a ticket with Hostgator, our hosting company, and with Sitelock, a security service we purchased as an add-on in the past. The Sitelock Basic scan only scans 25 pages deep and is extremely limited, IMO, in what it can do. It came up negative as well. After speaking with Sitelock customer service, they wanted to charge us $179/hour for dehacking services. We declined, and my client ended up canceling their service. WordFence scanning is much more comprehensive and totally free, so we opted to trust their service over Sitelock.
After a ton of research, I theorized the hack was actually a symlink hack on the Hostgator shared server at the root level. My theory was our site wasn’t exploited, but the server was, and we as customers had no access to fix the hack. My problem was that I know almost nothing about Linux servers and symlink, so at the time I didn’t even know what keywords to search on to read more about this type of attack.
I ended up putting in three different tickets with Hostgator and all three were dismissed by Hostgator as being a “normal” part of the system. WTF, right!?
After gathering all of my evidence, I called their customer service line, and after a 45′ wait, I got a rep on the line who I walked through everything I had found. The total call took 3 hours, as the rep had to put me on hold several times to consult with engineers on his team. They finally came to the same conclusion as I did, and made a fix on our account that removed the symlink hack within a couple of hours. Note, I’ve been a Hostgator customer for many years and many of my clients use Hostgator. The rep I worked with was super professional and respectful, but had no knowledge of this type of hack.
One tool that was very helpful was URLQuery.net, basically a reverse IP lookup with malware warnings, and showed me other sites on the same shared served that had the same hack! That’s what clinched in my mind that this was a symlink hack, as every website on the server was showing the same hack. If you’re a website owner on shared servers, I highly recommend running a search on URLQuery.net to see if anything shows up.
Here is a screenshot of my first search that showed several sites with the same hack:
The hack is actually still present on the Hostgator server and can be viewed live here on one other site:
I presented all of my findings in my ticket (and on the phone) so I don’t understand why Hostgator hasn’t closed this hole on the server, but it’s still there. Scary question: Is every Hostgator shared server susceptible to the same attack? That would be thousands of sites that could be susceptible to the same exploits, right?
The way the hack works, if I’m describing this correctly, is that symlink is used to append malicious content to some or all of the sites on a particular server via an alias. So the malware isn’t actually in your directories, but rather it’s hosted somewhere else. It still triggers Google warnings and obviously isn’t good for business.
Anyone have anything to add to this? Like I said, I’m no Linux engineer, so I don’t completely understand how the hack works, but if you do a search on “symlink hack” you can read tons of blog posts about it. This article – Symlink Bypass Explained – even does a blow-by-blow of how it’s accomplished.
It’s also extremely hard to find and doesn’t show up in malware scans. Make sure you have Webmaster Tools linked to your site. Feel free to contact me if you suspect a symlink hack and you need help.
Also, be sure to see my other article on preventing hacker attacks on WordPress sites for more tips.