Zeus for Android and fake Kaspersky Antivirus 2011

Android shotOver the weekend I wrote about the discovery of the potential Android component of the Zeus information-stealing toolkit (also known as Zitmo).

I wanted to share an update as there are further developments which have been uncovered about the relationship between the Zeus toolkit and Andr/SMSRep-B.

Thanks to Denis from Kaspersky Labs we can now confirm that the fake Trusteer Rapport application is related to malicious websites set up as command-and-control servers for several Zeus/Zbot botnets.

The server-side Zeus application checks for the User-Agent string of the HTTP requests and delivers the malicious payload based on the browser type.

In the case of Android. the default browser User-Agent string will be similar to "Mozilla/5.0 (Linux; U; Android 2.2)..." and from there the operating system can be easily determined.

On a separate note, it seems that the tradition of malware pretending to be legitimate anti-virus software for Android is extending.

After Trusteer, the next target is Kaspersky Labs. Yesterday, I had a chance to analyse a sample of Android malware which attempts to fool the user into installing the package by looking like a legitimate Kaspersky Antivirus 2011 product.

The application package uses an icon similar to the Kaspersky Lab icon, but the actual functionality is far less useful than the functionality of the legitimate product.

When the package is launched the malware attempts to get the unique device id number and transform it into an "activation code". The fake activation code is then displayed in a standard Android view.

Fake Kaspersky Antivirus 2011

In the background, the application installs a broadcast receiver that attempts to intercept SMS messages and send them to a web server set up by the attacker.

Luckily, in the case of this malware (which Sophos detects as Andr/SMSRep-C), the command-and-control web server IP address is 127.0.0.1 (localhost), which does not make the malware very useful.

Clearly, this is just an early test build and we will have to be on watch for the next version which will be connected with a real malicious server.

Although the functionality of Andr/SMSRep-B and Andr/SMSRep-C is quite similar, the code does not indicate that they have been developed by the same author.


Compromised ads leading to TDSS rootkit infections

As we all know, compromised sites play an important role in web distributed malware, acting as the conduit, guiding user traffic to further malicious content. Sometimes, the attackers get lucky, and succeed in compromising a high profile, popular site. Another way to increase the number of users exposed to the attack is to compromise advertising content, thereby exposing all users of any 3rd party sites that happen to load the ads.

Late yesterday evening, we started to see evidence of such an attack - Sophos products were blocking certain ad content as Mal/Iframe-U.

Knowing that detection and what it looked for, I was pretty sure that the ad server of Campus Party was compromised.

Sure enough, I could see that in addition to the desired ads (for the July Campus Party event in Valencia), the content also contained malicious JavaScript (highlighted in yellow):

Not the first time I have seen an OpenX ad-server getting compromised, and I suspect it won't be the last.

Deobfuscating the JavaScript reveals the payload. As our Mal/Iframe-U detection name suggests, it is an iframe to load further malicious content from a remote server.

This initiates the attack, triggering a chain of events summarised below:

  • ad content (pro-actively blocked as Mal/Iframe-U) silently loads content from the attack site.
  • user's browser and browser plug-ins are inspected to determine most appropriate exploit content to load. For this a legitimate library is used.
  • exploit content (e.g. Mal/HcpExpl-A, Troj/Lifsect-A, Mal/ExpJS-M) is loaded in order to infect the user with malware. At the time of writing, the exploit site is currently serving up a rootkit which Sophos products detect as Mal/TDSSPack-AX.

As is typically the case for today's web attacks, all of the script components used are heavily obfuscated in an attempt to thwart detection efforts and hinder analysis.

We have already informed those at Campus Party about this issue in order that they can get the malvertising attack cleaned up as soon as possible. In fact as I type, I can see that the ad server is already offline, presumably whilst they resolve the issue. Kudos to them for actioning this quickly!

As to the root cause of the compromise, I do not know exactly how the server was compromised. However, given history, my money would be on an out of date or unpatched version of OpenX.