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.
Knowledge of the threat landscape and implementation of the right malware detection tools remains crucial to be able to protect yourself from fraud.
Mitigating the mobile malware threat starts with awareness. It requires detection and protection to prevent the malware from being successful.