We present a study of the core similarities, differences, and evolution of the original Mirai and its new variant, HolyMirai.
Android banking trojans are nothing new, and Cerberus is just the latest in a long line of such malware to hit the headlines. Even the fact that Cerberus is being “rented out” on underground forums is not unique. Malware “for hire” has become a theme. This trojan uses peoples’ worry of COVID-19 to steal financial data such as credit card numbers. It also uses overlay attacks to trick victims into providing personal information and can capture two-factor authentication details.
“Corona-Apps.apk” is a variant of the Cerberus banking trojan. They are usually spread via phishing campaigns. Corona-Apps.apk uses its connection with the actual virus name to trick users into installing it on their smartphones.
Corona-Apps.apk variant has a very aggressive behavior after installation. A high level overview can be read on Avira’s blog.
After installation, network traffic can be seen between the application and the C&C server ‘botduke1.ug’
Figure 1: The traffic between the app and the C&C server
The application has a well defined set of commands such as: “info_device”, “new_device”, “saved_data_device” and “pause_attacker”. The “info_device” is requested every few seconds. This keeps the C&C server updated with the newest information about the device.
Figure 2: The application sends an “upgrade_n_patch” command which gets as response a chunk of binary data
This sophisticated trojan has a large AndroidManifest file: lots of receivers, activities, services, intent-filters etc.
The code found in the distributed APK is the same in the majority of classes”. The code is heavily obfuscated and has no real purpose other than to waste the analyst’s time.
Besides the heavily obfuscated package name, two activities that caught our attention were:
Figure 3: The permissions: in the red box: the path to the classes not present in the Source Code
The payload of this variant is a dex file named RRoj.json. When the payload is decompiled, it shows the obfuscated code of the malware. This reveals the class names which have been referenced in the distributed APK manifest file (qugyujzldpxqazyrqtc.uindwdxr.smlelfodpiernkx ).
Figure 4: The path to the classes can be seen in the Source Code view of the dropped payload
To evade detection, this variant of Cerberus encrypts every constant string it uses: the strings used to log the activity and as function parameters (we’ll later see how this variant uses mechanism to dynamically request additional permissions).
The decryption method is interesting, it consist of 2 stages. Here’s an overview:
Figure 5: The decryption function, used throughout the program
Decoded base-64 is a string where every 2 characters are processed as a single byte. It means that the length of the output string is always half of the original one.
The function takes every 2 consecutive characters and converts them into digits in base 16. The first one is bitwise shifted to the left 4 times. The output byte will be the sum of the 2 characters, as seen below:
Figure 6: The first stage of the decryption
The output from the previous function is passed to the RC4 cipher. Further, it decrypts it using the hardcoded key.
Figure 7: The “e” and “d” field of the parent class “c” contains the decryption keys
The payload requests some permissions that may be considered dangerous. Because it doesn’t have a manifest it does that by using the API call requestPermissions. As shown, the permission strings are encrypted to avoid detection.
Figure 8: The “o” field of the class “a” contains the encrypted permission strings
Figure 9: Decrypted permissions
Do not grant permissions to applications that do not state the reason for asking such permissions. Download and install applications only from reliable sources—be suspicious of gimmicks and untrusted sources.
Mitigating the mobile malware threat starts with awareness. It requires detection and protection to prevent the malware from being successful.