targeted smartphone users, mainly in the U.S, China, South Korea, and the Russian Federation. Cybercriminals have now expanded Wroba’s targets, shifting their malware campaign to Japan.
This trojan was first developed as an Android-specific mobile banking trojan, capable of stealing files related to financial transactions. Once it has infected a device, Wroba uses SMS to send messages containing malicious links to the host’s stolen contact list.
In this blog, Alexandru Frigioiu, a senior threat researcher at Avira Protection Labs, analyzes a new sample of the Wroba trojan found in the wild. This variant shifts targets from South Korea to Japan. It attempts to compromise banking app users in Japan by displaying a counterfeit version of the Chrome browser with the goal of delivering the payload.
We came across a malware sample in the wild. The sample caught our attention because it displayed attributes such as a randomized file name, package name, and activity name. These suggest a packed application and Android malware.
We quickly realized the app is suspicious enough to take a closer look at the app permissions.
Figure 1: Manifest file
Looking at the “Chrome” application label, we identify that the application was trying to pose as a Chrome browser. However, the discrepancy with the package name made it clear that it was not Chrome and most likely malware.
Additionally, the app was signed with a test certificate from the Android Open Source Project used in the past by several other malware families. Although this certificate is used by some legitimate developers to sign their clean Android apps, this is clearly not the case here.
During our analysis, we saw that the installation screen was trying to pose as a Chrome browser. It was also using the legitimate Chrome icon to make it look familiar.
Figure 2: Chrome application label and icon displayed on the installation screen
After the permissions were granted, the application was launched, the icon disappeared from the launcher.
After we analyzed the APK file, we saw that apart from typical files found in an android app, there was a random file in the “assets” folder:
Figure 3: APK file structure showing the file with a random name in assets
This is typically used by malware to hide a second DEX or APK dropped at installation. Then loaded at runtime when the application is launched.
Looking at the contents of the file, we found that it was encrypted. We decompiled the code to find out what the application was doing with this file.
Figure 4: Encrypted payload
Hash of the file: ccdc5c71c18709cea46e8dce04f985e19c054abfcb19a7ee6d875a09e3aa39b1
The main DEX file is tiny (only 9kb) and we conclude its only function was to decrypt and load the randomly named file from assets.
After decompiling the code, we searched for the file name and found the following method:
Figure 5: Decryption routine
We saw that the file from assets is being read and processed to look like a custom decryption routine. After this, a file named “dex” is saved to “/data/data/buhb.uabvv.szxkr/files/dex”:
Figure 6: Resulting file name
We also saw that this file built the string “dalvik.system.DexClassLoader” out of separate strings (to avoid detection), which is then used to execute the payload:
Figure 7: building “dalvik.system.DexClassLoader”
The function first opens the file from assets, skips the first 4 bytes, and reads the 5th byte used as an XOR key. Then reads the rest of the file in 1024 byte blocks, XOR-es it with the 5th byte, and passes the resulting data to the “this.a” method.
Figure 8: Analysis of decryption routine
The next function is decompressing the data using the deflate method:
Figure 9: The deflate method in function
The data is then base64 decoded:
Figure 10: Base 64 decode mechanism
and the result is written to the file:
Figure 11: New file is created
Now that we know where the decrypted file is stored, we can retrieve it from the device to analyze it:
Figure 12: Decrypted payload (upper left), named “dex”
The decrypted dex file (0cd2b17aa21cd8de63842da21e3464df7bb2bd4a278fffbbfea6b294c3ca9e6d) turned out to be a malware, as expected.
It was found to be a banking trojan from the Wroba family. This family has been in the wild since 2010, and its name is a concatenation of two terms, “we” and “rob”.
Figure 13: HTML code of overlay
Figure 14: Class showing some of the malware functionalities
Figure 15: Preparing overlay HTML content
Figure 16: Targeting Japanese banking apps
Avira detects the original APK, dex file, decrypted payload, and other APKs from the Wroba family as Android/Wroba.
We strongly recommend Android phone users use an anti-virus package. These are available from Avira and other quality digital security providers.
Consumers should always keep the “Unknown Sources” option disabled in their Android device’s settings to avoid installing apps from unknown sources. Android applications should only be installed from official stores such as Google Play, and even then care should be taken!
Everyone, on any device, Android, Windows, macOS and iOS should avoid clicking on unknown links received through SMS messages, emails, ads, and social media posts from untrusted sources.
Finally, mobile phone providers and network operators need to take steps to protect their customers and consider integrating anti-malware technologies such as Avira’s own Anti-malware SDK for Android, and explore threat intelligence solutions that deliver mobile application reputation information.
Read our Q3 2020 malware threat report to find out the top ten Android families detected this quarter.