Lastline Labs

Analyzing a banking Trojan

Posted by Sebastian Poeplau LinkedIn on Apr 17, 2014 6:00:00 AM

In our effort to detect threats to the users of Android devices, we analyze a lot of malicious apps. This post exemplifies the analysis of such malware, more specifically a banking Trojan that we came across recently. It pretends to generate one-time authentication codes for online banking, but its real purpose is to steal the users' banking credentials and to intercept incoming SMS (possibly containing Transaction Numbers). Also, it tries to evade analysis by checking its runtime environment.

We have seen different versions of the app, but this post is based on samples with SHA1 hashes e370ab3f1fbecfc77bdc238591d85882923ed37e and 698a1c5574fbe8ea1103619d81fdd4e8afa85bd5.

The user's perspective

Let's start with observing how the app under analysis presents itself to the user. It disguises itself as an app provided by the user's bank and pretends to help with the generation of one-time secrets for online banking. We have seen versions that target the Swiss ZKB and the Austrian Erste Bank. Note, however, that it will be easy for the malware's author to adapt the Trojan to other banks.

loginThe app's login screen.

On startup, the app displays the impersonated bank's logo and asks for the user's password. After users enter their data, they are presented with a "security code", which is supposed to be used with their online banking account.

The app imitates the behavior of legitimate applications for two-factor authentication. A benign app would generate authentication codes as a second proof of identity for the user when banking online, in addition to the usual user name and password. By imitating this behavior known to the users, the Trojan attempts to gain their trust.

fake_codeThe fake security code presented to the user.

Going deeper

Now let's take a look at what happens behind the scenes. Since the app does not use any code obfuscation, we can decompile it, producing Java-like code that is more easily readable than the Dalvik bytecode that we would normally be looking at. Thus, for this blog post, we employ the freely available tools dex2jar and jd-gui to create a pretty readable Java representation of the app's code.

decompilationOur decompilation using jd-gui.

The interesting functionality is located in packages named com.gmail.*. We will not go into too much detail on the code itself but rather sum up our findings.

Stealing information

Looking at the app from the user's perspective, we have seen that it asks for credentials. As expected, whatever the user enters is sent out to the malware's author. Also, the app monitors incoming SMS and forwards them to the attacker (potentially to capture Transaction Numbers for online banking). Along with the stolen data, the Trojan reports various details of the victim's phone, such as the version of the operating system, the phone number, carrier and country code.

Let's focus a little more on how the stolen data is transferred from the victims' phones to the attacker. Apparently, the author of this Trojan has gained unauthorized access to a number of legitimate web servers that now act as intermediaries between infected phones and the attacker's server. The infected phones only know the URLs of the compromised web servers, so that the destination of the exfiltrated data remains hidden even when the Trojan app is analyzed. Tracing the data further would require access to one of the intermediaries. This is a common, very basic strategy for attackers to hide and stay flexible.

We have informed the administrators of the compromised web servers that we learned about when analyzing our samples. Unfortunately, none of them has provided us with additional information about the attack so far.

Configuration

The remote addresses that the Trojan contacts to upload stolen information are configurable. The app comes with a basic initial configuration, and it regularly tries to retrieve updated versions (potentially tailored to the victim's phone) from the Command-and-Control servers. The configuration files are encrypted using the Blowfish algorithm.

This is the (anonymized) initial configuration of one of our samples:

<config>
    <data rid="25"
        shnum10="" shtext10="" shnum5="" shtext5="" shnum3="" shtext3="" shnum1="" shtext1=""
        del_dev="0" 
        url_main="http://[removed]/gallery/3.php;http://[removed]/images/3.php"
        url_data="http://[removed]/gallery/1.php;http://[removed]/images/1.php"
        url_sms="http://[removed]/gallery/2.php;http://[removed]/images/2.php"
        url_log="http://[removed]/gallery/4.php;http://[removed]/images/4.php"
        download_domain="[removed]"
        ready_to_bind="0" />
</config>

The various url_* parameters specify the targets of the Trojan's exfiltration and update activity.

Runtime checks

The malware conducts some simple checks to thwart dynamic analysis. We found a function isEmulator that tries to detect if the app is executed in the standard Android emulator, a common technique for basic analysis. Essentially, it compares some properties of the potentially emulated phone with the known default values used in the emulator.

emulator_detectionThe function isEmulator.

 

Furthermore, there is a location check in one of our samples: The app obtains the SIM's country code and asserts that it is either Austria, Switzerland or Russia. While the first two countries align well with the area of operation of the targeted banks, the last one feels somewhat out of place. It may or may not hint at a Russian developer - always bear in mind that the criminals who develop such malware might deliberately place such details to set us on the wrong track.

SMS commands

As a last feature, we discuss the Trojan's ability to receive commands via SMS. We identified the commands START, STOP and DEL. The first two start and stop an SMS forwarding service, respectively: When the service is active, it forwards every incoming SMS to a number specified in the START command.

The last command, DEL, triggers removal of the Trojan app. Android apps need the user's approval to uninstall themselves or other apps, so the malware applies a trick to get the user's consent: It displays a message announcing the availability of an update; the user is told that a new version is installed after removing the current one. When they press the "update" button, the app initiates the removal process, to which the user will likely consent after having been informed about the alleged update. The removal mechanism allows the malware to cover its traces after having stolen all the information that the attacker was interested in.

Lastline analysis report

Below, you see a screenshot of how our analysis engine presents the results of its automated analysis. The details are very similar to what we have discussed in this post: The system detects the encrypted configuration file, and it finds that the app sends out data, in SMS as well as encrypted over the Internet. All in all, the app's threat potential is scored at 100 out of 100, yielding the final verdict "High Risk - Malicious behavior detected."

our_analysisResults of the Lastline Analyst.

 

Conclusion

We have looked at the functionality of a typical Android banking Trojan, both from the user's perspective and from the view of an analyst. Our analysis usually centers around the technical side of things and, in particular, the question how to detect such threats automatically. However, we also believe that it is important to raise awareness with the users and to caution them to maintain a healthy measure of skepticism when it comes to giving apps access to their phones and even entering data as important as banking credentials.

Looking for protection against advanced malware?

Lastline Enterprise provides premier malware protection for web, e-mail, content, and mobile applications, deployed anywhere on your physical or virtual network. Learn more here:

Topics: Android Security, Bank Malware

Subscribe to Email Updates