The malicious code that gets injected into these webpages is the following:
Which deobfuscates to:
What was interesting is that we had to use a valid browser user agent to obtain the in.php file. We used: Mozilla/5.0 (compatible; MSIE 7.0; Windows NT 6.0) as our user-agent string. Other similar user-agents worked as well, but they had to be MSIE and Windows compatible so we knew it had to be a Microsoft specific exploit they (the hackers) were attempting on unsuspecting visitors.
You’ll see from the above iframe that the file it references is in.php. Here is the code for in.php:
Which deobfuscates to:
As you can see, there are 2 other files that this malscript tries to load:
load.php (which is actually a Windows executable)
pdf.php (which is an actual PDF file that uses ActionScript to try and infect the visitor’s PC).
At the time of our investigation, the malware load.php was only detectable by 2 out of 41 anti-virus companies. Here is the VirusTotal report on that little gem:
And pdf.php was detectable by 11 out of 41 anti-virus programs. Here is the Virus Total report on that file:
Inspecting the FTP log files for the infected website we found that the majority of the FTP traffic on the day the infected files were modified was from the following IP addresses:
The interesting thing about this FTP traffic from various places around the world is that the exact same FTP username and password were used. There weren’t any failed login attempts with this username for the prior 6 months so we didn’t feel it was a brute force or dictionary attack on a weak password. This leads us to believe that this infection is another case of compromised FTP credentials.
Another interesting point is that the FTP traffic from these various IP addresses happened within minutes of each other and the number of files transferred from each IP address was 2. It appears from this information that the attackers were using a distributed network of compromised PCs (read botnet) to send the modified files to the website server.
This could be for a number of reasons.
But the one reason that seems most obvious is that the attackers know many people try to block their IP addresses. By using a botnet of remotely controlled PCs a website owner would have to block dynamic IP addresses. Would you block a range of IP addresses from a DSL connection in the United States? Probably not.
Having a website means handling traffic from visitors all over the world. If you’re going to start blocking groups of IP addresses, how will you know when you’re blocking innocent visitors? Wouldn’t that hurt your business?
The IP address that d0lpin.biz is hosted on show this for their whois:
The whois on the domain d0lphin.bz is:
Google’s report on the network hosting d0lphin.biz shows: