ZitMo (ZeuS-in-the-Mobile) is one of the oldest and most notorious mobile Trojan. It is installed (or suggested for installation) on mobile devices by ZeuS-infected computers. After the installation, ZitMo and ZeuS work alongside in order to steal money from victims' bank accounts. Practically, ZitMo is used to intercept all incoming SMS messages and to forward them to a C&C Server, in order to defeat the SMS-based two-factor authentication. This is a classic example of Man-in-the-Mobile attack.

In the table below are listed some of the analyzed samples that correspond to some of the various ZitMo variants.

MD5	PACKAGE	APP NAME	ICON
ECBBCE17053D6EAF9BF9CB7C71D0AF8D	com.systemsecurity6.gms	Truesteer Rapport
B1AE0D9A2792193BFF8C129C80180AB0	com.android.security	Android Security Suite Premium
E98791DFFCC0A8579AE875149E3C8E5E	com.android.security	Zertifikat

In all its variants, ZitMo presents itself with (kind of) different skins in which it always pretends to be a security- or certificate-related app, but it actually steals incoming SMS messages. Indeed, in almost all its Android variants, it always requires at least the following two permissions:

• android.permission.RECEIVE_SMS
• android.permission.SEND_SMS

The first one is used to monitor/record incoming SMS messages, while the second one is used to send SMS messages.

Remind that it is highly recommended to READ the permissions that an app requires CAREFULLY before installing it!

As shown in the precedent table, all the ZitMo samples we have analyzed use always one of the following two package names:

• com.systemsecurity6.gms
• com.android.security

And one of the three following app names:

• Trusteer Rapport
• Android Security Suite Premium
• Zertifikat

As already said, once launched, all the ZitMo variants show a pretty similar UI in which, in order to seem a security- or certificate-related app, an "activation code" is displayed. In all its variants but the last one analyzed, ZitMo uses the device ID (i.e. the IMEI for GSM phone and the MEID or ESN for CDMA phones), with proper translations and alterations in order to disguise it, as "activation code".
All the ZitMo variants but the last one analyzed attempt to connect and send the stolen SMS to one the following URLs, using HTTP POST requests:

• http://android2update.com/aapl.php
• http://android2update.com/biwdr.php
• http://androidversion.net/2/biwdr.php
• http://androidssafe.com/biwdr.php
• http://getupdateandroid.com/biwdr.php
• http://updateandroid.biz/update/biwdr.php
• http://softthrifty.com/security.jsp

[Please, note that all those domains are not active anymore.]

The last ZitMo variant analyzed, detected by Vir.IT eXplorer has Android.Zitmo.H, uses an hard-coded string as "activation code" and does not connect to an URL at all.

Finally, most of the ZitMo variants present typical botnet capabilities, in particular the ability to receive commands from a C&C Server (usually via SMS). Usually, at least the command to enable/disable the malware and the one to change the C&C Server phone number are implemented.

Now, let's have a deeper look to some of the ZitMo variant!

Android.Zitmo.A

In this variant of ZitMo, detected by Vir.IT eXplorer has Android.Zitmo.A, the displayed "activation code" is nothing else but the device ID (i.e. the IMEI for GSM phone and the MEID or ESN for CDMA phones), retrieved through the TelephonyManager's getDeviceId() method, with the addition of a "-" every 4 characters.
Furthermore, in background, the SmsReceiver BroadcastReceiver intercepts all the received SMS messages (through the android.provider.Telephony.SMS_RECEIVED action) and, for each SMS message intercepted, the MainService Service is launched.
For every SMS message received, MainService launches a new thread (SmsBlockerThread) in which it extracts the sender and the body of the message. If the extracted values are consistent (not null), then, they are listed in a list of key-value pairs with a specific format ("f" followed by the counter of the current PDU as key for the sender and "b" followed by the counter of the current PDU as key for the body). After it has listed all the incoming PDUs, also the pair formed by "pid" as key and the device ID as value is stored in the list. Finally, the entire list is sended using HTTP POST request, through the ServerSession's postRequest() method, to the URL (hard-coded in a "crypted" string): http://softthrifty.com/security.jsp.

If a ClassCastException exception occurs while sending the data, then the thread goes to sleep for 15 seconds (15000 milliseconds) and, then, tries again.

Android.Zitmo.B

Also in this variant of ZitMo, detected by Vir.IT eXplorer has Android.Zitmo.B, the displayed "activation code" uses the device ID (i.e. the IMEI for GSM phone and the MEID or ESN for CDMA phones), retrieved through the TelephonyManager's getDeviceId() method. However, in this variant, ZitMo tries to disguise it by adding "1" in the head, taking only 7 digits of the device ID (the ones from the position 8 till the end) and, finally, adding a "3" in the foot.
Furthermore, in background, the SecurityReceiver BroadcastReceiver intercepts all the received SMS messages (through the android.provider.Telephony.SMS_RECEIVED action). The same BroadcastReceiver intercepts also the Operating System boot and all the new outgoing call.
For every SMS message received, SecurityReceiver extracts the related information and, if the malware is enabled ("AntivirusEnabled" value of the "secsuite" SharedPreferences file), then these information are sended to the URL (hard-coded in a "crypted" string): http://updateandroid.biz/update/biwdr.php&from=[...]&text=[...]. Where in the "text" field there will be the string "LocalTime: " followed by the timestamp of the SMS arrival (retrieved through the Calendar.getInstance().getTime() method) and by the message body.
All the message information are also stored in an internal SQLite database.

This variant of ZitMo is really more advanced then the first one presented and it shows typical botnet capabilities. Indeed, through the SecurityReceiver's AlternativeControl() method, this variant is able to receive commands from a C&C Server via SMS.
The names of the commands change for almost all the analyzed samples of this variant of ZitMo but, essentialy, the malware has the ability to:

• Send private user information (e.g. the device model, manufacturer, version, etc...);
• Set/unset an alternative C&C Server phone number (stored in the "AlternativeNumber" value of the "secsuite" SharedPreferences file);
• Enable/disable the malware itself (through the "AntivirusUninstallReq", "AntivirusEnabled" and "AntivirusUninstallComplete" values of the "secsuite" SharedPreferences file).

Android.Zitmo.H

In this last variant of ZitMo, detected by Vir.IT eXplorer has Android.Zitmo.H, the displayed "activation code" is nothing else but a string hard-coded in the malware itself (that is: "7725486193").
As usual, the SmsReceiver BroadcastReceiver intercepts all the received SMS messages (through the android.provider.Telephony.SMS_RECEIVED action).
Also this variant of ZitMo shows botnets capabilities. Indeed, through the SmsReceiver's onReceive() method, it is able to receive commands from a C&C Server via SMS.
Essentialy, the malware has the ability to:

• Forward all the SMS received to the C&C Server phone number (saved in the "adminNumber" value of the "SecurityService" SharedPreferences file). The SMS messages are forwarded with the message body composed by the original message body, followed by ". F:" and by the message sender.
• Change the C&C Server phone number through the "set adminn" command.
• Enable/disable the malware itself (through the "serviceStatus" value of the "SecurityService" SharedPreferences file) through the "on"/"off" commands.

Moreover, for every command sended, the C&C Server will receive in response an SMS of confirmation with different codes ("ONOK" if the malware was correctly enabled in the device, "OFOK" if the malware was correctly disabled in the device and "SAOK" if the C&C Server phone number has been correctly changed). Finally, another message ("INOK") is sent to confirm the correct infection of the new device.
The default C&C Server phone number is hard-coded into the malware itself (that is: "+46769436094").

---------------------------------
Paolo Rovelli
Mobile Developer & Malware Analyst
CRAM (Anti-Malware Research Center) of TG Soft