Cerberus Analysis
In February 2020, I received a SMS on my cell phone that made me quite suspicious. When I visited the https://ko[.]tc/hediyekazani web address mentioned in the message, I found that I was redirected to the http://www-bedavainternethediyeuygulama[.]com web address. A short time after receiving the SMS, when I visited the website again, I saw that the images on the site had changed. Saying “suspicion is the whip of a cyber security researcher,” I decided to take a closer look at this situation.
I downloaded the 5GBeta.apk file from the website and uploaded it to the Koodous web application, which is used for mobile malware analysis. The analysis failed. Then I uploaded this application to the VirusTotal web application and, although I encountered a clue that it was a banking malware (Cerberus), I did not see the address of the command and control center in the behavioral analysis output. I couldn’t find answers to the questions that came to my mind, so I decided to quickly analyze the 5GBeta.apk application dynamically using the Genymotion Android emulator.
As soon as the malicious application was installed on Android, it began to request permissions one by one to achieve its bad intentions. After obtaining the permissions and successfully completing the installation, it hid its icon and started working in the background and communicating with the command and control center with the kryll[.]ug (8[.]208.19.185) web address. When I searched the 8[.]208.19.185 IP address on VirusTotal, it was clear from the passive DNS information that it was not innocent at all.
In my virtual Android operating system, a screen of Google Play, which was created to steal my credit card information, appeared as there was no banking application installed. When I entered a 16-digit credit card number created for testing, I saw that the save button (SAVE) was not activated. When I made the credit card field 19, the SAVE button became active. Probably the malicious person has made the control of the 3-digit CVV2 number specific to the form where the credit card number is entered and such an error has occurred. After seeing that all the information I entered went to the command and control center in encrypted form, I decided to pursue the encryption key.
Before pursuing the encryption key, I installed and ran 10 mobile apps of different banks on my virtual system to confirm if the malicious application had stolen any banking information. As a result of my tests, the malicious application was able to steal all the information entered by the user by opening a fake screen over the login screen of the targeted mobile banking application when it was running.
In order to find the encryption key, I used the GDA tool to decompile the 5GBeta.apk application, and by looking at the AndroidManifest.xml file which contains the basic information about the application, I saw that the classes between the MainActivity class, which will run first when the malicious application starts, and the source code were different. This indicated that the malicious code block was loaded dynamically during runtime.
When I looked at the folder /data/data/mcneapsbpysnarhkjjm.yjolrmlaqlpzyjfuls.gsiwerlnfzdy where the malicious application was installed, I noticed the large files ring0.apk and NpA.json. I learned that NpA.json was actually a DEX file, and when I decompiled it using the jadx tool to see the source code, I encountered the MainActivity class that was present in the AndroidManifest.xml file.
After analyzing the encrypted strings, I found that the f class is responsible for decrypting them. To do this, it takes the first 12 characters of the encrypted string as an RC4 key, and uses that key to decrypt the rest of the string, which is BASE64 decoded. (For example, if the encrypted string is mjwpnqfxpgweNDNiYjQ2M2JiNzMxNzE3OWM5ODRjZmI1ZWFkYzYxMjY4NDE4YTY3MDVhNTZlZGZlMGNhNmQ1ZDVlMzU2MTE5NWU5YjYyNw==, the RC4 encryption key is mjwpnqfxpgwe. Using this key, the rest of the characters (NDNiYjQ2M2JiNzMxNzE3OWM5ODRjZmI1ZWFkYzYxMjY4NDE4YTY3MDVhNTZlZGZlMGNhNmQ1ZDVlMzU2MTE5NWU5YjYyNw==) are decoded by BASE64 and then decrypted by the encryption key.) I was also able to easily decrypt all the strings by using the Java code in the f class and compiling it with the help of compilejava.net website.
After observing that the encrypted data sent to the command and control center was in JSON format, I focused on the parts of the code where this class was used. Since I knew that the malicious application sent the sti=004&q=info_device parameter to the command and control center at certain intervals, and then the encrypted ws= parameter, I found the code block where these two values were concatenated. Upon analyzing this code block, I found that the ws parameter was encrypted with the alien_ring0_wdfes RC4 key.
When it came to decrypting the encrypted data I previously obtained with the alien_ring0_wdfes encryption key, and confirming the validity of the encryption key, I also learned that the fake screens (html) came from the command and control center, as mentioned at the beginning of the text.”
In conclusion, it was surprising and concerning to learn that the Cerberus mobile banking malware, which has been frequently talked about in recent years for its features and name, has started targeting citizens with SMS containing their name and surname. As always, I stress that Android users should avoid installing apps from unknown sources.
Hope to see you in the following articles.
Note: