In this article, we will take a look at an Android malware sample that I obtained in Fall 2021. We will take a static analysis approach for this sample. The malware has functionality such as sending sensitive information, contacts, call records, etc. to its C&C server.
How I obtained it & how it looks
The malware sample was taken on KST 23:06, 18 Sept 2021 (GMT +09:30) from http://61.227.52[.]208/wooribank.apk.
It is installed as “Woori Bank” and pirates the icon from a legitimate banking app. The SHA256 of the APK file is 6bf3853d2814acef8aa805efda34b156de18e96814a226c66eb4339b567eca55 and the package name is com.cdnb.w003.
Analyzing AndroidManifest.xml
We can observe that the malware is using the permissions listed in the picture below.
It uses almost every permission from receiving calls to sending SMS.
The sample has 2 classes acting as entrypoints. First is com.ppnt.ccmd.aavv.Nforg class and is executed first when the user launches the app.
The second is com.cdnb.w003.MainActivity class, which is registered as launcher activity.
We can also observe that the malware is using the Accessibility Service feature.
Analyzing the APK structure
The APK file has the internal structure as shown below.
There are two suspicious files named secret-classes.dex and secret-classes2.dex. We can also find files such as app.html from path Resources/assets.
In the lib directory, there are 10 native library files for armv7-a architecture. Some of them are related to image processing (rtmp, h264, ….) which is not usual to ordinary banking applications. So we can assume that the sample will act differently than the normal banking applications. (But we should also mind that the native library’s name and its functionality is not always relatable — as libfirebase.so down below)
If we use hex editor or similar tool to examine the secret-classes.dex and secret-classes2.dex file, we can find out that those files don’t have the correct DEX header.
DEX file should start with ASCII characters dex as shown in the picture below.
Source Code Analysis
Decrypting the dex files
By analyzing two entrypoint classes, we can confirm that the malware decrypts secret-classes.dex file on the fly and dynamically loads it using the Android Reflection technique.
As we can see from Figure 12, void a(File, File, m) method looks for files ending with extension .dex and checks whether it’s classes.dex or not. If the file is not classes.dex, then it is passed to the method InDe.decrypt().
InDe.decrypt() method is implemented as a native library function.
By analyzing libdn_ssl.so file, we can find out the function used to decrypt dex file and its encryption type and encryption key.
As shown in Figure 15, the dex file is decrypted using key dbcdcfghijklmaop and AES-128-ECB.
Since we know both the encryption method and key, we can decrypt the dex file without executing the application. The Python script I used for decryption is shown below.
As shown in Figure 16, the decrypted files have the right dex header, and they can be open in the JAVA decompilers such as jadx-gui.
Analyzing malware activity
The malware prompts the user to accept its permission for the Android Accessibility feature as shown in Figure 17.
If a user accepts the permission, the malware uses the code shown below to obtain other permissions.
It can also use the Accessibility feature to launch other apps and/or bypass 2FAs. (See also: How is Android Accessibility Service affected by a banking Trojan?)
After gaining the necessary permissions, the malware sends the information listed below to its C&C server.
- Contacts
- SMS
- Call records
- Voice Records and Videos
- GPS locations
- List of installed applications
- Displayed contents on the screen.
It can also do malicious activities such as
- taking and making calls without user consent
- sending and receiving SMS.
The information collected by malware is encrypted before it is sent to the C&C server.
As shown in Figure 19, it uses AES-128-CBC as the encryption method, and the encryption key is rb!nBwXv4C%Gr^84, IV is 1234567812345678.
Analyzing the C&C address
The malware uses an encrypted IP address stored in the native library and IP addresses from the public Github Gist. The class com.google.oms.firebase loads the native library libfirebase.so.
By analyzing the native library, we can find out that AES-128-ECB is used to decrypt the strings inside the native library.
Base64-decoding MTIzNDU2Nzg5MGFiY2RlZg will give us the decryption key 1234567890abcdef. And base64-decoding, then decrypting CNn+B8i6sDpvF+8HUizn8ynbXbnXD0WBfOjqvrSeqUk= with the key will give us the string http://45.115.127[.]106/.
The second C&C address can be found inside the decrypted secret-classes2.dex file.
The TA uses Github account maxw201653 to distribute encrypted C&C server addresses. (The account is closed now — Feb 2022) The data from Gist can be decrypted using the information from Figure 19.
After analyzing the sample by myself, I looked up similar or the same malware analysis report.
ThreatMiner — Android Trojan Targeting Korean Demographic using GitHub for C2
ThreatMiner has a report analyzing similar malware — they have similar files (ok.html and huokuan.html and Chinese comment inside HTML files) and have the same encryption key and IV for AES-128-CBC. They also utilize Github Gist for C&C, yet another account is used.
Cyble — Sophisticated Spyware Posing As A Banking Application To Target Korean Users
Cyble has a report for similar malware — disguised as the Wooribank app like the one we analyzed above. According to their report, the malware has anti-sandbox techniques applied — it can detect Android Emulator or similar analysis environment. I confirmed that my sample has similar anti-sandbox codes after reading the report.
ESTsecurity — 해외결제를 위장한 스미싱 지속적 유포중!
ESTsecurity has a report about the malware that has the same string inside it (99754106633f94d350db34d548d6091a.zip).
