Welcome to WebmasterWorld Guest from

Message Too Old, No Replies

How Hacked Servers Can Hurt Your Traffic

2:44 am on Dec 8, 2008 (gmt 0)

Senior Member

WebmasterWorld Senior Member tedster is a WebmasterWorld Top Contributor of All Time 10+ Year Member

joined:May 26, 2000
votes: 0

Unfortunately there are all kinds of devious server hacks making the rounds these days. They usually depend on two factors: sites that use a common CMS (such as Wordpress) and site owners who do not update their software to keep security solid.

But the average site owner may not have the resources or understanding to investigate thoroughly. All they know is that their Google traffic went away.

But if you can discover that you've been hacked, the fix is straightforward:

  1. fix the security problem
  2. restore a clean version of the site
  3. request reconsideration

One thing that hackers do is find sites to help distribute malware. This one should be easy to detect, because Google will post a warning notice in the SERPs "This site may harm your computer." This discussion [webmasterworld.com] covers the details of how to handle a malware hack.

One common footprint for a malware hack is an iframe that doesn't belong in your code - especially one with a lot of hex coding.

Defacement Hacks
These are really "old school" - they're more like online graffiti than anything else. The hacker usually just wants to brag that they got you, and they put up a message on your pages for all to see. Well, that's easily detected because you just go to your pages and there it is!

But as I said, this is old school and many hackers are looking for something with some financial value these days.

Robots.txt Hacks
This one is either done for sheer malicious delight, or perhaps for competitive disruption. How often do you check your robots.txt file? If someone replaced the first line and disallowed all indexing, how fast could you catch that?

In addition to visually inspecting your robots.txt file on a regular basis (and especially if your urls start disappearing from the Google index) you can also set up a Webmaster Tools account and check it regularly. Google will report to you when urls get blocked by robots.txt.

Parasite Hosting
This one is sneakier and depends on the value of backlinks, either for PageRank or for the traffic itself. The hacker places links on your pages (they may be hidden through various means) and you may not be inspecting your content close enough to see those links.

The tool you need is a link checker, such as Xenu LinkSleuth, that can give you a report on all your external links. You are careful about who you link out ot, right? So anything really bogus is going to jump out at you from that list. Running a link checker on a regular basis has many other benefits as well, such as keeping those accidental 404s out of your site. So I consider it to be something like getting a regular physical (but I recommend doing it more often.)

Cloaked Hacks
Now we're really getting devious. Over the past year or more, hacks have been showing up that cloak their parasite content so that only googlebot sees it. If you visit with a regular browser (user agent) you only see what you expected to see.

Your main tool here is a user-agent spoofer of your own, such as the User Agent Switcher extension for Firefox. Just fire it up with a googlebot user agent string and see if your page content changes.

Complex Cloaking - using IP and cookies
This is getting deep - and it's also not so common, but it is out there "in the wild." The hacker in this case paces complex scripting on your site so that not only do they cloak for googlebot by user agent, they also cloak by IP address. In some cases the script also places a cookie so you get only one chance to see what they're doing.

And your tools here are 1) learning how to browse your site with coolies turned off and 2) studying your server logs for what your server replies to googlebot.

Cloaked Redirects - .htaccess hacks
Google's John Mueller (JohnMu) has just made an excellent blog post about this. I'll refer you to him:

The first symptom that you would see is hard to interpret: URLs from the website are just not indexed anymore...

When you submit a Sitemap file, Google will show warnings for URLs that redirect. By design, you should be listing the final URL in your Sitemap file, so if the URL is redirecting for our crawlers (as in this case), we’ll show a warning in your account.

I urge you to read JohnMu's entire article [johnmu.com]. He's offering a lot of help here.

DNS Troubles
Some of the sneakiest hackers have used various kinds of DNS tricks. Over two years ago we discussed this rare but still possible problem in this thread [webmasterworld.com].

If your traffic totally dries up, you would hit the panic button pretty quickly - so these hackers have been more clever than that. With DNS tricks they might syphon off only 20% of your traffic. One thing you would see was a traffic drop with no corresponding drop in rankings.

There's been some good effort here on the part of the DNS servers to get more secure from this type of thing, but it's still worth mentioning as a potential. The moral is to check your DNS settings and fix any warnings you get. It might seem like a foregin language to you if you never waded into these waters before, but it's worth climbing the learning curve - especially if your traffic is evaporating. However, it's something that I wouldn't suspect until I ruled out all the rest of the hacks I listed above.

It might be an employee, too
Sorry to say, it's not always an external hacker. Sometimes a person your trusted with server access gets greedy and places parasite links to earn some csh on the side. We've had such reports here, and it even happened at Google a few years back.

Don't get crazy about this possibility, but if you do find junk on your server and there's no real sign of an external hack - then consider who you might have given server access to. This is one solid reason always to changes passwords (strong ones) when anyone leaves the company, or when your contract is over with anyone who had access. Even great companies sometimes hire a bad apple.

7:34 pm on May 9, 2009 (gmt 0)

Senior Member

WebmasterWorld Senior Member tedster is a WebmasterWorld Top Contributor of All Time 10+ Year Member

joined:May 26, 2000
votes: 0

There has been some question about whether various hosting automation apps -- cPanel, Vdeck, Plesk and the like -- are a source of vulnerability. The answer is YES, hosting automation is a major target used by various botnets to increase their "member" domains, as a couple quick searches will show you.

As with any server software, these applications need continual patching and upgrading. Here's some recent documentation:

  1. HostGator says hackers compromised its servers using a previously unknown security hole in cPanel [news.netcraft.com]

  2. Secunia's Vulnerability Report for Plesk [secunia.com]

  3. StopBadware's vulnerability report on Vdeck [stopbadware.org], which is Ipower's offering for automated web hosting.
This thread should not turn into a review of various hosting services. But because questions have been raised in this area, here's the documentation about some vulnerabilities involved with these applications. They are in wide use by hosting services for small to medium enterprises, so do not be naive.

If you use any third party services at all (and who doesn't?) then be an informed consumer. There is no such thing as a 100% secure server.

6:00 pm on Sept 3, 2009 (gmt 0)

Junior Member

5+ Year Member

joined:Jan 3, 2008
posts: 42
votes: 0

Here's a solid analysis of a particularly devious hack - offered by Google's John Mueller (JohnMu):

Let's discuss the specifics of that hack in the linked thread, rather than here - thanks.

I missed this thread and the one you pointed about John.

But still would like to contribute if possible...

That site John talked about belonged to me. If it helps, here is some information. The server got hacked, not the website. It happened in August 2006. Within 1 week Google completely de-indexed the entire site. De-indexing is really nasty as you see your site disappearing from DCs one at a time and you hurry to check another one only to see live the site disappearing in front of your very own eyes (as you do site:--- you see less and less pages by the hour). Noone from Google would give the slighest hint of the problem. Complete silence. Six months into the problem, John (pre-Google) finally spotted what was happening. He was able to replicate calling the urls of the site *as if* from a Google serp and indeed only the 1st hit produced that redirect when clicking the results (I had to clean my temp, flush dns and repair IP to be able to see the redirect again). The redirect was to a site selling none other than anti-virus software. I believe a site in Russia. Pressumably, this was done so that the owner of the site would think it was just a temporary malfunction. Astute hacking is an understatement.

The real problem had been that some binaries from Apache had been changed and went undetected. Upon contacting the hosting company -they wouldn't even apologize- they said they forgot to upgrade Apache on that particular server, so as Tedster mentioned, patches and regular upgrades/updates are essential. Hacks of this nature are very damaging. Only 1 individual was able to detect it. After 2 trips to Chicago and personally meeting with Google's spam team, the site would not come back. So if you are a victim of this you are in trouble. Google may still have doubts about who you really are. This hack would in essence steal Google's traffic and mess up with the user. I wouldn't be surprised if this would cause the people at Google to hate you for eternity.

When all was said and done, after moving to another hosting and upgrading the site from plain vanilla to something as close as possible to a web 2.0 website with custom scripts and custom content, the site got back in the index. But it still remains a lackluster and to this day it has only gain a small fraction of the traffic it had when it was deindexed. Perhaps, there are some penalties that never go away -I think Brett Tabke mentioned something like this regarding banned sites- or it may just be that Google is not ready to believe your story and doubts linger on. So, in cases this problematic the best may just be to start a new site from scratch and move on. As quickly as you can!

On hindsight, that would have been the cleverest decision. As time passes by and when finally your site comes back most likely it is a dinosaur. A Rip Van Winkle that wakes up in another era. So now you have a new, different problem which is that Google doesn't like you and considers you obsolete. Another reason to quickly begin anew with a vision into the future.

8:39 pm on Sept 3, 2009 (gmt 0)

Senior Member

WebmasterWorld Senior Member tedster is a WebmasterWorld Top Contributor of All Time 10+ Year Member

joined:May 26, 2000
votes: 0

The server got hacked, not the website.

Please give some details about this. I understand that the vulnerability must be a server vulnerability, but the server then responds differently to requests for website URLs in some way, correct?

10:34 pm on Sept 3, 2009 (gmt 0)

Junior Member

5+ Year Member

joined:Jan 3, 2008
posts: 42
votes: 0

That is my understanding, Tedster.

A hacked server with partial or 1 domain affected. I put it that way to eliminate the possibility of me uploading a corrupted/infected file or the attacker changing files within the site. After auditing the site line by line at least two times it came out crispy clean. Proof of this was that uploading those same files to a new server would yield no redirects. John also tested it and confirmed, to the best of his ability. This particular site had had many #1 positions spread out to many areas of its field of interest for an extended period of time. It was just too visible and perhaps someone decided it was time... My mistake: falling asleep at the wheel.

Unfortunately, the hosting company wasn't too communicative about the problem. All I got was that binaries had been compromised and that they "patched it up". It was explained to me that the core of the software running the server had been changed and that the problem wouldn't have happened if Apache had been up to date with the latest updates.

This was a shared hosting account, not a dedicated nor a semi neither a VPS. In other words, no access to root from my account. At the time John suggested to track other domains also hosted in that same server but I personally couldn't replicate the problem in the domains I tested. Which gives more credence to the idea that the attacker could hack the server and alter how specific pages would be served according to specific requests. A cyber-sniper, so to speak.

This 34 message thread spans 2 pages: 34

Join The Conversation

Moderators and Top Contributors

Hot Threads This Week

Featured Threads

Free SEO Tools

Hire Expert Members