Gumblar Q&A
What is happening?
A multi-stage series of compromises is delivering malware that attempts to redirect Google search engine results (SERPs). Visitors who encounter the compromised websites risk having their subsequent Google search results replaced with links that point to malicious and fraudulent websites.
The malcode also steals FTP credentials (if found) from the victims’ computers. These stolen FTP credentials are then used to further compromise any websites owned or operated by the victim. As a result, there is exponential growth of these compromises – as more victims are infected by encountering a compromised site, the number of compromised sites also increases and thus more visitors are exposed.
Is this a cross-site scripting (XSS) attack?
No. The compromises appear to be the result of stolen FTP credentials and direct manipulation of files on the Web server.
When did ScanSafe first detect this?
There are two stages in the attack. The first stage compromised websites in order to distribute malcode from 94.247.2.195. OI made the first block on March 23rd. Signature scanners began detecting on March 27th. The compromises were reported to Google on April 13th after an investigation revealed the malware was redirecting Google searches.
Reference blog post: Malware Manipulating Google SERPs
What happened next?
As Google began delisting the compromised websites, those site owners began cleaning up the mal-scripts pointing to 94.247.2.195. Likely as a defensive maneuver, in early May the attackers began replacing the mal-scripts pointing to 94.247.2.195 with dynamically generated and heavily obfuscated mal-scripts pointing to gumblar.cn. Blacklisting based on the original mal-script would thus be defeated, allowing the compromised sites to once again be listed by search engines.
What is the intent of the malware distributed through the Gumblar compromised websites?
The malcode distributed via the compromised websites attempts to exploit PDF and Flash exploits in order to deliver malware that redirects infected users’ search engine results. In these particular attacks, the malcode appears to be targeting Internet Explorer users and Google search. In addition, the gumblar.cn malcode installs a backdoor that connects to 78.109.29.112 – an IP address of a known botnet command and control that has historically been associated with malware engaged in malicious redirections.
Reference blog post: Google SERPs Redirections Turn to Bots
How do these malicious redirections work?
Similar to a man-in-the-middle attack, these redirections occur as a result of a man-in-the-browser attack. The malcode injects itself into the browser process, monitors the requests processed by the browser, and injects fraudulent traffic. In the case of the Google SERPs redirects, the malcode replaces legitimate Google SERPs results with links pointing to malicious or fraudulent websites.
Is this a problem on Google’s end?
No. As mentioned, this is a man-in-the-browser attack. The injection and redirection occurs locally, on the compromised PC.
Millions of websites have been compromised over the past year; what makes these particular compromises unique?
A typical series of website compromises reaches peak within the first week or so and subsequently begins declining in intensity as detection is added by signature vendors, user awareness increases, and website operators begin cleaning the affected sites. (This is why attackers are constantly pushing new waves of compromise).
In the gumblar.cn attacks, the opposite is occurring. As website operators attempt to clean up the original compromise or otherwise make changes to the original source code of the .htm, .php, and .asp pages on their sites, the gumblar.cn compromise is injected. The gumblar.cn mal-script appears to be dynamically generated and thus varies not only from site to site, but also from page to page on the same site. In addition, the resulting mal-script is heavily obfuscated, further hampering signature detection methods. As a result, the gumblar.cn compromises are increasing – up 188% from last week and a 61% increase from yesterday.

Mary Landesman
Reader Comments (5)
hello!, i have seen your post, and foundout this is quite common, many people got infected
i have made a simple bash script that will find if sites on a server were infected, my script refers to /home/$USER/public_html , as the default location of the html files, but can be changed to fit your needs.
http://www.blog.isra3l.net/?p=184 <- this will help you find out if you are infected
you must run this as root.
Sorry, but your links to the other blog posts are broken.
We've been seeing this evolution over the past few weeks. I blogged about how to clean up and get your site out of Google's blacklist. In the cases we looked into, the exploit was changing FTP passwords.
We've advised our clients to stop using FTP (as we've done for years) and use SFTP. Most FTP clients support secure FTP protocols or you can grab the very useful Winscp (www.winscp.net).
During the early infections, I noticed that several AV software tools did not detect the exploit.
Steps to remove it;
1. Download all folders and files from remote server.
2. Search for "iframe" in all the files using any mass text find and replacer utility. Text editor "EditPlus" can also be used to search text in files.
3. Shortlist those files which has undesired code starting with "iframe" and remove those lines from code.
4. Search for "unescape" and remove any undesired javascript code which involve "unescape" and "function()".
5. Search for "base64_eval". These are the files which are created by the virus itself. These are particularly named as images.php or gifimg.php and are placed in images folder. Remove these files completely.
6. Upload the cleaned files back to server.
Mohan, this will not fix your problem, it will only treat the current symptoms. Your computer (not your server) has a virus on it that's reading your FTP details from FileZilla or whatever FTP program you're using. You need to setup an ip tables rule (firewall) on your server to prevent all FTP file transfers, and stop using FTP to do file transfers to your server. You need to use SSH instead. Additionally, you need to remove the virus from your own computer. So far, I have not found any software which correctly finds it.