Zitmo has been used by the ZeuS gang to defeat SMS-based banking two-factor authentication on Symbian, BlackBerry and Windows Mobile for a several months (see my ShmooCon slides).

Lately, there’s been an active discussion on technical forums regarding ZeuS targetting Android users. We finally managed to get our hands on the mobile sample the ZeuS PC trojans are propagating.
Actually, it is not a new sample and has been detected under several names (Android.Trojan.SmsSpy.B, Trojan-Spy.AndroidOS.Smser.a, Andr/SMSRep-B), but it is far more scary when propagated by the ZeuS gang.

The malware poses as a banking activation application:

Zitmo trojan spyware for Android

In the background, it listens to all incoming SMS messages and forwards them to a remote web server. It’s simple, but just enough for the ZeuS gang to grab your banking mTANs…

Wireshark capture of Zitmo forwarding an incoming SMS (on the infected phone) to a remote web server

We’ll keep you posted on this one.

– the Crypto Girl

PS. F-Secure, s21sec and Kaspersky contributed to finding this sample. Thanks for their cooperation.

Android devices continue to be the target of malware authors with Android/Fake10086.A!tr. AegisLab spotted this malicious Trojan in the wild in China and posted an interesting write-up on the matter.

In brief, Android/Fake10086.A!tr looks like a handy hotel reservation application (e.g com.hotel apk), but in the background it communicates with a remote web server and blocks some incoming SMS messages. Most noticeably, Fake10086 blocks SMS messages coming from 10086, the customer service portal of a leading chinese telecom operator – presumably to prevent them from warning the victim. How does it do that? This is what we are going to focus on in this post.

The AndroidManifest.xml shows a class FakeLanucherActivity (misspelt as in the sample) is started:

Part of the trojan's AndroidManifest.xml

This calls the onCreate() method of FakeLanucherActivity, which, in turn, instantiates a SettingManager object via the getInstance() method:

SettingManager.getInstance(this).log("FakeLanucherActivity::onCreate");

The constructor of SettingManager creates a private settings file for the application (named setting.xml in the shared_prefs private directory of the application)

SettingManager constructor - creating the settings file (setting.xml)

Later (we skip all parts which do not relate to SMS blocking) this settings file is edited by calling setSMSTempBlockNumAndTimes() with
10086 as first parameter, and 1 as second parameter:

Default values for setting.xml

From the name of the method, we guess the first parameter is the SMS number to block and the second parameter is the number of times such messages should be blocked.
The setSMSTempBlockNumAndTimes method does no more than writing the configuration in a sms_temp_block_num_and_times XML tag of the setting.xml file:

Writting SMS Block Number and Times to setting.xml

A typical setting.xml file looks as follows:

Sample setting.xml file

Note a function to read sms_temp_block_num_and_times also exists, and is named getSMSTempBlockNumAndTimes().
The SettingManager class does not have anything more regarding blocking SMS. So, how are SMS blocked?

Each time an SMS message is received, it is processed by the onReceive() method in PrivilegedSmsReceiver class which is registered as an SMS receiver by the trojan. The relevant parts of this method are pasted below (smali disassembly output):

Smali disassembly for the onReceive() method of PrivilegedSmsReceiver

So, the onReceive() method retrieves the sms_temp_block_num_and_times (and logs it to an internal debug file), gets the phone number from which the incoming SMS comes (getDisplayOriginatingAddress()), checks whether it ends with the number to block (10086), decrements the “times” counter and checks it is positive. Probably due to a bug, it does not update the setting.xml file with the decremented value, so 10086 is blocked forever. See below the logs of the trojan when the device receives an SMS from 10086:

[[2011,Mar,08,12:59PM]]: com.mms.bg.transaction.PrivilegedSmsReceiver::onReceive::Line=48
  PrivilegedSmsReceiver::onReceive
[[2011,Mar,08,12:59PM]]: com.mms.bg.transaction.PrivilegedSmsReceiver::onReceive::Line=66
The temp block info = 10086;1
[[2011,Mar,08,12:59PM]]: com.mms.bg.transaction.PrivilegedSmsReceiver::onReceive::Line=78
block the sms because it contain the temp block num : 10086 for once

– the Crypto Girl

Update: Mario Bellano found the corresponding source code. You can download it and compare…

Zitmo is a mobile malware Fortinet has particularly been focusing on since the beginning (see our first blog post and my presentation at ShmooCon 2011) as it is one of the first palpable signs organized criminals show interest in infecting mobile phones. As you may know (see F-Secure and Kaspersky‘s blog posts), it is unfortunately back, with a new version.

So, technically speaking, what’s new?

• it now supports Windows Mobile phones too. Not only Symbian (there was rumors concerning a BlackBerry version – never confirmed).
• the default phone number it sends intercepted SMS to has changed, though it is still a mobile phone number, in the UK and probably from the same operator.
• it intercepts both incoming and outgoing SMS. The previous version only intercepted incoming SMS and did not care about outgoing ones. It is possible this feature isn’t actually used by the gang, but has just been put back in the executable from “SMS Monitor”, the trojan spyware Zitmo is highly inspired from.
• it sends an SMS (to the UK number by default) with the text “app installed ok” each time a SET ADMIN command is processed. In the previous version, this SMS was only sent at the first install of the trojan.
• it features a new command “UNINSTALL”… which actually installs a new package (see Figure below). Zitmo searches on the mobile phone for a file named c:\system\apps\u.dat (note the file is not downloaded from the web – Zitmo does not connect to Internet). The extension of this file is intentionally misleading, it is actually a Symbian package. Zitmo renames it u.sisx and silently installs it on the phone (no prompt, no warning whatsoever).

So far, this variant has been found in the wild in different European countries, albeit in low volumes. In Poland, in particular, it has been reported to be used by the PC component of ZeuS to target ING Poland and mBank. Note that Zitmo itself (aka the mobile component of the ZeuS toolkit) works for any target: as it simply forward the one-time passwords, it is bank agnostic.  Thus, the target is solely determined by the PC component, and is found in an encrypted configuration file, fed to it by the cyber-criminals from the command and control center.

Finally, Fortinet detects those trojans as SymbOS/Zitmo.B!tr and WinCE/Zitmo.B!tr.

– the Crypto Girl

In prevision of the anticipated merge between the two infamous banking malware ZeuS and SpyEye, our Threat Analyst Kyle Yang spent some time dissecting the most current version of SpyEye we could get our hands on (W32/SpyEye.C!tr.spy).

While SpyEye shares some similarities with ZeuS (encrypted/compressed configuration file, updateable injection scripts, drop zones, update zones for binary and config update, etc …), an extra feature quickly caught our attention: SpyEye connects to a “log server” that is different than the server where it fetches updates from, where fraudulent transactions done by the trojan are logged:

Of course, because most banks today won’t allow transactions initiated online to be transnational, the recipients of such transfers are what we call “mules” (in the money laundering jargon) or “drops” (in the jargon used by cybercriminals themselves) – intermediaries between the victim and the cyber criminals, living in the victim’s country.

Unsurprisingly, the drops are not hardcoded in the trojan’s binary, but simply configured in the log server itself:

Note that the names and account numbers were modified to dumb values for the screenshot. However, the rest of the drop info was untouched, which prompts comments on two items:

• Transfer limits: Those are relatively low, possibly to stay “under the radar.” Transferring a large sum of money “by small chunks” in order to avoid the new anti-laundering legislation (where mandatory records and reports are needed for large sums, etc…) is called “smurfing”. While the chunk limit in the USA is $10,000, thus well above the ~1000  upper limit used by SpyEye, we are not sure these are dollars. They could be British Pounds, and in UK there is no chunk limit: any suspicious transaction must be reported. Or… the SpyEye upper limit may simply reflect the amount of trust the cybercriminals have in each particular drop.

• A percentage: It very likely represents the share taken by each of the two parties (the mule and the cybercriminal) on the transfers. Now, given the unbalance (90% – 10%) it creates, the question is: who gets 10%, and who gets 90%? Some years ago, the question would have been quickly resolved, with the cybercriminals usually taking the bigger piece of cake – which would seem normal, as he/she was the one putting the most effort into the whole operation. But with the large “mule busting” operations conducted in UK and US lately, it is fairly possible that the odds got inverted,which would seem… normal – given the risks now involved for each party. That would at least indicate that while mule busting operations lead by law enforcement do not catch the bigger fishes, warmly sheltered under the complexities of transnational judiciary operations, it does contribute to make them less rich.

Kyle will address some technical points in an upcoming post.

Last week, a lady from the sales department dropped in to see me for some help with her iPhone. She was worried because she had “suddenly” lost all of her contacts, music and emails. She had turned to a neighbor of hers, an “expert” who had told her she had “a Trojan on her iPhone”.

Whaow. A Trojan on an iPhone: that was definitely very interesting, as I know of none yet. I know a worm (Eeki) and a couple of spyware (Trapsms, MobileSpy) or other questionable software, but no real Trojan.

But, I’m sure you’ve guessed I am being slightly sarcastic and, of course, there was no Trojan at all on her iPhone (which is, altogether, good news anyway). Indeed, it turned out that she had had problems syncing with two different computers and had accidentally erased all her data. Now, I do sympathize because, personally, I have so many difficulties understanding how to use iTunes myself…

Reciprocally, I recall a while ago I scanned my dad’s USB key, although he told me it was certainly virus free because he was “very cautious”. That time, I was right to be suspicious, I had hardly started scanning it that the AV software started blinking in excitement, having found three different samples…

My point here is that end users obviously have difficulties identifying whether they are infected or not: the lady told me her iPhone was infected though it was not, and my dad told me he wasn’t although he was…

If you are in the same case, I would like to help you out with a very simple statement:

if you notice any damage (hard/ soft/) on your phone (or computer), it is unlikely to be infected

(but of course, there might be a hardware or a software failure – which is different).

On the other hand, if you start noticing problems on your bank account, then, be alarmed

(check with your kids or spouse first ;)).

Of course, this is not a 100% guarantee; a few mobile malware do actually cause malfunction, but it’s a general idea to keep in mind: nowadays, malware authors try to make money (or silently grab private data they re-use later), not to misconfigure your phone. Why would they? This would only cause you to notice it’s infected and possibly perform a hardware reset, thereby depriving the malware authors or cybercriminals from a source of revenue.

The graph below shows the number of mobile malware families per threat category. Note there hasn’t been any new annoyware (i.e malware whose main goal is to annoy/cause malfunction) created since 2008. New mobile malware try to make money, or target your privacy, much like desktop computer malware.

– the Crypto Girl