The curious case of banking trojans
Banking trojans are a class of trojans that target financial apps to steal user’s credentials to commit some kind of banking fraud. Different trojans employ different kinds of techniques to trick users into providing their credentials.
These range from simple impersonation to complex vulnerability exploitation. In this article, I will discuss these techniques and analyze over 2000+ banking trojans for possible similarities.
Techniques
Most techniques revolve around tricking the user to provide his/her banking login password or steal two factor authentication tokens. Most trojans misuse/abuse features provided by the operating system to their advantage. Over the years, the Android OS has been cracking down on framework APIs & features that can potentially expose sensitive information. It has implemented hurdles that include protecting sensitive actions with permission, depreciate dangerous APIs, apps that utilize private APIs, etc. These measures have obviously reduced the attack surface but haven’t completely eliminated them. Moreover, attackers keep coming up with workarounds to bypass restrictions imposed by the OS & Google Play store.
Exploiting accessibility permission
Most operating systems provide some kind of accessibility feature that allows disabled users to use their operating system. Voice narration is a good example. An artificially sensitized voice reads what’s currently shown on the screen. The platform exposes APIs for developers to build features for addressing accessibility gaps within the OS. Unfortunately, this has allowed attackers to misuse it for malicious intent
<service android:name=".service.AppAccessibilityService"
android:permission="android.permission.BIND_ACCESSIBILITY_SERVICE"
android:label="@string/accessibility_service_label">
<intent-filter>
<action android:name="android.accessibilityservice.AccessibilityService" />
</intent-filter>
<meta-data
android:name="android.accessibilityservice"
android:resource="@xml/accessibility_service_config" />
</service>
Notification permission
This permission allows developers to get notified when app notifications are posted to the system tray. This lets malicious actors snoop on users by reading any messages that are visible on the tray. Notification messages can hold very sensitive infos including second-factor auth tokens, private chat messages, authenticator tokens, etc. Additionally, attackers use such events as a signal to launch actual attacks. Recently, a new wormhole was found by CheckPoint that auto replies to whatsapp messages with phishing websites
Credit. You can read more about this here
Privilege Escalation
There is a class of apps that exploit system vulnerability to gain root access. Such access will allow the app to have unlimited access to all sensitive information. Both system & user data will be compromised. This is especially true on older versions of Android. It is increasingly difficult to find these exploits and if found they are used for targeting individuals (state actors) than for the masses (bank users or mid-sized companies)
Overlay
Application overlay permits an attacker to draw on top of any window and application running on the infected device. First, malicious applications monitor which applications are started by the user on the infected system. Once the malware detects an app (e.g. banking or payment facilitating) it will redraw an exact login screen on top of the legitimate one. The user is incapable of distinguishing the fake from the original and enters his credentials in the wrong dialog. The malware will then upload the stolen credentials to its Command & Control server.
Exploitability Index
From an attackers point of view, each of the discussed methods have their own pros and cons. I call this exploitability index. It measures the difficulty in exploiting OS gaps vs the ease of delivering malicious payload. For example, privilege escalation is the hardest to exploit but relatively easier to deliver (a simple installation would do the trick). Another class of trojans requires the user to take extra steps before the actual malicious payload executes. A good example is an unsuspecting user heading to settings to enable accessibility permission.
Analysis
Below, I analyzed over 2k+ banking trojans that were collected from VirusTotal between 2017-2018. They had been classified as “banking trojans” by at least 10 vendors. The dataset might not be big enough to make meaningful conclusions but will provide good insight into trends and popular methods used. Here are few questions that we are trying to answer
- How many trojans exploit accessibility/notification permission?
- How many trojans rely on dangerous telephony permissions?
- How man malicious apps misuse overlay alert?
- Is there code reuse between these apps? Can we create a cluster of apps that use the same malicious code?
To help with this analysis, I will be using App Detonator. App detonator is an API-based analysis engine where samples are detonated in a sandboxed environment for static & dynamic analysis. Static detonation is really fast. Depending on the size of the app, it takes somewhere between 5-10 seconds. Such analysis provides us with details about app signing certificate, manifest entries, dex class & method used, native code details, etc. With these, we can safely answer #1, #2 & #3. I will come to #4 later on
Here is a sample response from /analyze API.
We now proceed to detonating 2506 banking trojan samples. Here is a python script that iterates through malicious trojans and generate the report needed.
Accessabiblity permission count 9
Notification permission count 2
Dangerous telephony permission count 1850
SYSTEM_ALERT_WINDOW permission count 1080
Looks like our dataset is skewed towards apps that utilize telephony permission & apps that misuse the system alert feature. 73% of apps at least contain RECEIVE_SMS, SEND_SMS, READ_SMS, READ_CONTACTS or CALL_PHONE
To answer our fourth question, we need to analyze the actual code which is buried inside classes.dex file. There are different methodologies that we can employ to check if two apps are using the same code. Fuzzy hash solutions like ssdeep generate a similarity digest by dividing a file into segments using the rolling Hash method, unlike the existing hashing method that guarantees integrity. But ssdeep is very generic. But it would be nice if these fuzzy hashes take into account the structure of dex file. Dexofuzzy is a project that parses the dex file inside the APK file to extract the opcode, and the extracted features are used to generate similarity digests using ssdeep. The features are also used to search for similar malicious code by tokenizing the generated Dexofuzzy to N-gram size and using the sliding window technique.
$ dexofuzzy -f 09f2b02d23754bbda99f93c97cf832287e9527b98a70be1ca8186069a999d727.apk
768:1DaLb5+PRGF3JtZZVtbJx+QgfdmpcFVdvS3lkM5672b:1av8PRGF3fZrt9gfdmpc9K4Sb
Next, we cluster these apps into groups whose N-gram token match. Here we choose n to be 20 allowing us to group the most similar apps into a single cluster. Here is an interactive graph that shows 44 clusters and the top classes used y apps in these clusters. We can clearly deduct that telephony-based trojans dominate.
Click here for interactive chart
What happens if we set n to be 7. Obviously, there will be more clusters and we will start to see different class & methods used. Besides telephony framework APIs, classes such as Lcom/mix/kr/SMSReceiver$1, Lcom/mix/kr/Contact$1, etc are found in 29 apps. Hence, there is a code reuse among these apps.
Click here for interactive chart
