Wroba malware analysis – written by Amit Tambe and Naavin Ravinthran

Short analysis summary of Wroba malware

The Wroba Android malware launches itself as a rather unconvincing fake copy of Chrome. It asks the victim for several permissions, particularly SMS permissions. It gets the C2 details from VK profiles (a Russian social media website). It intercepts C2 commands received as SMS and accordingly steals different information from the victim which is then forwarded to the C2.

User impact

The malware requests for several permissions that are unrelated to Chrome browser (such as SMS, phone, etc.). Any request for such dangerous permissions is enough grounds for suspicion and must be denied immediately.

Additionally, the malware keeps proliferating using the victim’s phone using crafted SMS messages. These messages are sent to randomly generated numbers, thereby costing the victim in money! As the malware hides itself, it is challenging to notice any activity and it might be too late before a victim specifically checks the SMS app only to find a plethora of messages already sent thereby making him/her an unwitting accomplice in the scam.

Apart from this, the malware also locks the victim’s Wi-Fi which may cause the phone’s battery to discharge quickly.

Technical Analysis of Wroba malware

Anti-analysis methods

We started the analysis of the provided sample (stykktmylk.apk) by performing static analysis of it. It was at this stage itself that we discovered that the sample poses challenges to malware analysts. Our regular analysis tool, JADX, displayed errors (Figure 1) and was unable to open the sample.

Figure 1 JADX throws errors when decompiling the malicious sample

The provided malware sample uses a well-known technique (original paper here) to thwart any potential analysis by malforming the APK so that it “appears” to be encrypted to decompilation tools such as JADX (and others) resulting in an error. The reason it appears as “encrypted” to JADX (and perhaps other tools as well) is the value of FLAGS in the Central Directory header used by the malware sample. The sample cleverly sets the “encrypted” bit to 1 to trick analysis tools (as shown in Figure 2 and Figure 3). This does not hamper installation of the sample on a mobile phone, however. Android simply unpacks the APK assuming no encryption and it works.

Figure 2 Encrypted bit being set to 1 in the FLAGS for multiple files in the APK

Figure 3 Zipinfo utility confirms file pretending to be encrypted

To overcome this problem, we can modify the flag via a hex editor for all the archived files. However, as this can be time consuming, another simple option is to unzip the APK with an archiving tool like 7Zip, and then compress the files back into an APK (which essentially clears out the FLAGS field).

Static Analysis of Wroba malware

After overcoming the anti-analysis method used by Wroba malware, we now begin our static analysis using JADX. As shown in the Figure 4, we see that the malware expects several permissions – phone, SMS, storage write access, read contacts, etc. Also it masquerades itself under the name “Chrome” – highly suspicious behavior!

Figure 4 Wroba Malware expects several sensitive permissions and masquerades as “Chrome”

A quick further glance at the decompiled code tells us that there’s an encrypted DB, and native ARM64 code (Figure 5). We also quickly locate some native library code calls as well (Figure 5). Further, as shown in Figure 6, we are also able to infer that only the “libbn.so” library is used, and the encrypted DB 106QC3J is also loaded. We also note that the database is probably handled more in detail in the native wz.pi method. We therefore direct our analysis efforts there next.

Figure 5 Existence of native libraries, database and native code

Figure 6 Code showing invocation of “libbn.so” and the database

We disassembled the native code using Ghidra, and Figures 7 and 8 show screenshots of different parts of wz.pi method, one which potentially decrypts the code using binary shifting, and the other which decompresses the database.

Figure 7 Potential decryption using binary shifting

Figure 8 Potential decompression of the database

Dynamic Analysis

At this point, we move to dynamic analysis in pursuit of the decrypted decompressed database (or potential code). We begin by installing the malware on a mobile device, and observe that the app installs itself as a Chrome replica (Figure 9) and asks for several permissions (Figure 10).

Figure 9 App masquerades as Chrome

Figure 10 App asks for several permissions

Once the app was granted its expected permissions, the app hid itself from view, thereby making its intentions even more worth of suspicion. The app hides itself by creating a “translucent” activity which always shows its background screen, thereby rendering it effectively hidden.

Decrypted database/payload

So far, we have learned a few things about the malware, but not yet really understood the malicious behaviors at its heart. Once the app was installed on the phone, we searched for an unencrypted copy of the database/any other payload. We were able to retrieve one such payload from the phone the analysis of which shed further light on the malware’s behavior.

We performed a thorough static analysis of the acquired malicious payload. There were numerous pointless rabbit holes along which the malware author tried to trick us with. The malware also includes moderately obfuscated code intending to further slowdown analysis. Despite these roadblocks, we analyzed the malware behavior in depth and can name the following prominent malicious behaviors.

Acquiring C2 server details

Upon loading, the decrypted payload connects to VK (a Russian social media website) and makes connections to specific profiles (Figure 11). It is not the displayed content, though, that Wroba malware is after. Depending on which profile is being visited, the malware extracts different content from the page’s source code, as shown in Figure 12. Figure 13 additionally shows the source code that we obtained from a VK profile that we visited. The encrypted string in “noopener” tag is the one that the malware is looking for.

Figure 11 App makes connections to VK profiles

Figure 12 Pattern matching of VK profile source code

Figure 13 A sample that we checked matched this pattern

The malware further base64 decodes this parsed string, and performs DES decryption on it (as shown in Figure 14). The key required for decryption is hardcoded in the source code. The decrypted string is then further parsed to obtain the C2 server details. These are then further used throughout the app. Wroba malware is diligent and regularly checks for any C2 changes by making regular connections to VK profiles. Checks are also made, for example when network connectivity of the phone changes.

Figure 14 DES decryption of C2 details obtained from VK profile

SMS interception and information exfiltration

As we observed earlier (in AndroidManifest.xml), the malware gets the “SMS read, send, and receive” permissions from the user up front. These permissions are then used to register a broadcast receiver for new SMS messages received. These SMS messages are used by the malware to receive commands/instructions from the C2 server. As shown in Figure 15, Wroba malware intercepts incoming SMS messages, and parses the message body. If the message is from C2, then the message body begins with a “command”. Depending on the command the malware then extracts different types of information. For example, Wi-Fi connectivity information.

Figure 15 SMS messages interception

The malware also exfiltrates this information to the C2 as shown in Figure 16.

Figure 16 Information exfiltration by SMS forwarding

SMS forwarding costs!

As shown in Figure 17, the malware spreads itself to any contacts that the victim may have saved on the phone. In our case, the test device had no previously saved contacts, and hence Wroba  malware forwarded malicious links to randomly generated numbers. The victim is thus at risk of being an unwitting accomplice in this scam.

Figure 17 Unsolicited SMS forwarding

Wroba malware targets primarily South Korean users

The malware targets mainly South Korean and Japanese locale users and checks. It performs the following checks when it starts:

• Checks whether phone number is not a Chinese number (Figure 18)

• Acquire list of installed packages and check whether any of the following packages are found – “com.wooribank.pib.smart”, “com.kbstar.kbbank”, “com.ibk.neobanking”, “com.sc.danb.scbankapp”, “com.shinhan.sbanking”, “com.hanabank.ebk.channel.android.hananbank”, “nh.smart”, “com.epost.psf.sdsi”, “com.kftc.kjbsmb”, “com.smg.spbs”, “com.webzen.muorigin.google”, “com.ncsoft.lineagem19”, “com.ncsoft.lineagem”, “kr.co.neople.neopleotp”, “kr.co.happymoney.android.happymoney”, “com.nexon.axe”, “com.nexon.nxplay”

This list includes an assortment of apps, including both banking apps and gaming apps, particularly popular in South Korea.

• Additionally, the malware also detects if the AHNLab mobile security solution app is installed on the victim’s device and if found, attempts to delete it.
• Additionally, the malware also manipulates the victim’s audio settings by changing the ringer volume. It also fiddles with the Wi-Fi settings primarily to acquire a Wi-Fi lock (which allows the malware to keep the Wi-Fi radio awake even if the user has not used it in a while).

Removal of Wroba malware

Fortunately, the Wroba malware doesn’t implement any “diehard” services. Even though the malware hides itself, it is possible to uninstall it. The end user can go to Settings à Apps (or equivalent menu navigation depending on the phone on which this malware has been installed). The dilemma that the end user now faces is which “Chrome” app to uninstall. This is because there will be two Chrome apps, as the malware masks itself as Chrome. The easiest way to detect the difference is as shown in Figure 19.

Figure 19 Wroba malware uninstallation info

The real Chrome app can’t be uninstalled, but only “disabled”. Hence, it doesn’t have the “Uninstall” option in the app info screen. On the other hand, the malware does have the “Uninstall” option and can thus be removed from the phone with that option.