Part of the problem is that these compromised sites often use the WordPress publishing platform, which is infamous for the great number of security bugs that make it such a preferred target.
This fact has been proven once again by security researcher Denis Sinegubko, who has pinpointed 4,358 WordPress blogs hijacked by unknown attackers and pumped full with popular search keywords and images, which redirect users to sites that try to scare them into buying a fake AV solution.
Each compromised site usually contains over 100 different doorway pages whose URLs follow a simple pattern: "hxxp://
The final destination of the scam are a number of .in domains that are changed every so often but mostly point to the same IP address of a server in the UK.
The served malicious executable is a bogus solution names Security Scanner and the file is repackaged every day in order to elude real AV solutions.
“The doorway pages rank quite well for some keywords both in Google web search and Google Images search (especially when you are searching for exact phrases),” said Sinegubko. “However the malicious redirects occur only when you click on Google Images search results, which proves that Google Images poisoning is the main goal of this black-hat SEO campaign.”
He can't yet explain how the sites get compromised in the first place, since they have different owners and are hosted by different hosting providers. They only thing they have in common is that they are all WordPress blogs.
"Many of them are up-to-date (run the latest version of WordPress). So it’s neither a server-wide hack, nor an intrusion via stolen site credentials (otherwise we’d see many non-WP sites). At the same time, it is not a core WP hack. In my experience, this usually means that hackers used some backdoor script," he concludes, pointing out that many of the sites also use the timthumb.php script, which has been recently discovered to contain a bug that allows attackers to upload content onto the sites using it.
Webmasters of compromised blogs are advised to check site statistics for suspicious requests, sift through access logs and scan files present on the server on a regular basis and, in this case, to search for rogue rules in .htaccess files in the site root and above the site root directory - evidence of the compromise.