In this Blog we're going to take a look at the mass compromise we alerted on, which we named Beladen.
And those sites are injected with...
The malicious code injected in the Beladen attacks uses an obfuscation method that starts with the initialization of a long, obfuscated string parameter. This gets de-obfuscated and then executed by the browser. This kind of obfuscation can employ many levels of obfuscation - where obfuscated code leads to more obfuscated code, and so on. Here is an example of the injected code and the steps it takes to de-obfuscate it:
The example above de-obfuscates a function call. Now that the function code is available, the code calls it with another obfuscated variable. The variable is de-obfuscated to step 3, which in turn executes the redirect to the malicious site.
Notice how the referrer and current date & time are passed as part of the parameter values of '__utm.gif'. These will probably be parsed by the server to collect traffic statistics. The referrer value is designed to collect information about where the user browsed to get to the compromised site (if available).
Ironically, the malicious URL name redirects to a site with a name very similar to the Google Analytics service (this service exists at 'google-analytics.com'). Once redirection occurs, the user is redirected again to the exploits payload site, Beladen. Beladen uses wildcarded subdomains, so each time Beladen is used by the intermediate redirecting site, a different subdomain is used. Here is what the redirection looks like:
Beladen is the exploit site where several exploits try to compromise the redirected browser. Beladen means loaded in German - a suitable name because the site is loaded with exploits. Once the browser is redirected to Beladen, there is another internal redirect check that verifies the referrer, to subvert any direct mining attempts to the site's obfuscated exploit code. Here is part of the obfuscated exploit code:
Here is part of the de-obfuscated exploit code:
I was interested to see how well other security companies are doing in detecting this malicious, obfuscated exploit code, so I uploaded the full code to Virustotal. These are the results I got. Another interesting fact is that when you do an NSlookup on Beladen, the address of 127.0.0.1 is returned. However, DNS requests on any sub domain of Beladen return a valid IP address - as mentioned, those are wildcarded and host the obfuscated exploit code.
AS48031 NOVIKOV-AS IP Novikov Aleksandr Leonidovich (or: Where is this menace coming from?)
Some string checks on the intermediate Web site name, which has been injected in the mass compromise, reveal that other typosquatts of the legitimate site Google-Analytics.com had been injected near the end of 2008 and early 2009. There are distinct similarities between the current attack and the attack that occured back then; we believe it's the same group behind both attacks. At that time, the hosting malicious site was located at the IP subnet block of 184.108.40.206/24, which was part of the Russian Business Network (RBN). The threat this time comes from the IP block of 220.127.116.11/24, which is part of AS48031 NOVIKOV located in the Ukraine. According to our log data, this autonomous system has been quite busy spreading malicious code using Scareware, Rogue Antivirus software, and exploit sites (including the latest PDF exploits).
The IP address hosting the specific attack we described holds yet another typosquatt Google-like domain. Here is a screenshot of the sites hosted on the malicious IP address:
Following the recent Gumblar attack, we know that mass injections are nothing new, but these are becoming more popular and more common. We notice that as Websense routinely follows mass injection attacks, the attackers are up for the challenge to create more automated tools to help them succeed in their mission, and to come up with more obfuscation algorithms to evade scanning engines. Because major 'bullet-proof' autonomous systems such as Atrivo and McColo did go down, attackers always manage to find new 'homes' for their operations. We'll continue to monitor and protect against this threat and will update you on major developments.
Security Researcher: Elad Sharf