Earlier this week, in the security researcher forums there have been a round of discussions regarding Zbot attacking Android users and today fellow researchers from Fortinet have managed to find a sample that actually does it.
Though this sample has been in the wild for some time, it was found now that it is actually the one that Zbot uses to target its victims.
In this blog, we will demonstrate how the sample actually works to target the mTAN based authentication scheme.
Overview of the main payload:
1. The sample installs a receiver and a SMS blocker thread that gets triggered upon receiving every SMS.
2. When the user (victim) receives an SMS from the Bank, the SMS blocker thread blocks the SMS and reads the body of the SMS and posts it to a URL which is previously known to be associated with Zbot malware. (hxxp://softthrifty.com)
Fig.1: Code that intercepts the SMS to post to the webserver.
Fig.1 shows the code that is part of the SMS Blocker thread that intercepts the incoming messages and reads the content of the incoming message to post to the website.
To demonstrate this from a dynamic analysis perspective, we will be using two mobile phone emulators running Android 2.2 in a controlled environment. Along with the two emulators, we will use a FakeDNS server to resolve all the DNS queries to a local HTTP server. Also, we will run a very simple webserver by running netcat to listen on port 80 (http port)
Fig.2: Two emulators running in a controlled and simulated internet environment.
The emulators are assigned the following mobile numbers:
Victim mobile : 15555215554 [LabMobi]
Banker of victim : 15555215556 [LabClient]
Once the environment is ready, we will install the sample in the victim mobile emulator.
Fig.3: shows the sample installed in the device
Now, to see the payload in action, we will simulate a real world scenario. To do that we need to send an SMS (supposedly containing the mTAN) to the victim's mobile.
Fig.4: A message is ready to be sent from the banker device to the victim device.
Fig.4 illustrates a simulated setup created to demonstrate the payload. We have two mobile phones (LabMobi is the victim infected by Zitmo and Labclient is the Banker's device) and we also have a minimalistic "webserver" created using netcat to tap the information that is being sent from the victim's mobile.
Now, we will click on the send button to trigger the payload. When we click the payload, the SMS will be sent to victim. However, as explained above the Zitmo SMS blocker thread running in the victim phone will maliciously read the SMS and send it to the webserver in the following format (as shown in Fig.5)
Fig.5: Message format
The Fig.6 shows the message trapped in the "webserver" we have created using netcat.
Fig.6: Message posted by the Zitmo SMS blocker
Fig.7 shows the infographic of the profiled data of methods getting triggered upon everytime a SMS is received.
Fig.7: Profiled data about methods getting triggered for each incoming SMS
In the real world scenario, if an unsuspecting user's android mobile device is infected by this Trojan, the SMS messages sent to the user from his bank would be hijacked and posted to the server accessible to the malware author thereby putting the victim at risk.
We believe this is a very keen development in the context of the mobile malware and we will continue to monitor this threat very closely and update as and when new development happens.