Godfather - Android Banking Trojan

This is a sample gathered from MalwareBazaar. First posted in February 2024.

The Godfather

Godfather is an Android banking Trojan with the purpose of attacking users of popular financial services. “Godfather is designed to allow threat actors to harvest login credentials for banking applications and other financial services, and drain the accounts” (Group-IB).

Godfather’s code is based on an old banking Trojan called Anubis, whose functionality has become outdated due to Android updates and the efforts of malware detection and prevention providers, and has his source code freely available, as stated by Check Point.

APP’s Main Flux

The application attempts to impersonate the Chrome web browser, as evident from its icon and name displayed in the menu.

Figure(1): App's icon and name

When the app is first launched, it creates a pinned notification, hides its Chrome icon, creates a Play Store one and requests, very persistently, for the user to grant permission to the accessibility services.

Figure(2): Activity and notification asking for the accessibility services to be granted

If granted, the system will open this dialog and the malware will send an implicit intent to open a browser with www.google.com/chrome, to somehow make it more believeble.

Figure(3): System asking if the user wants to let app always run in background

While it’s trying to trick the user, the malware creates a file called app.xml on the shared_prefs folder, that will hold a lot of values that will be used and changed throughout the process lifespan. This contains boolean values used for checks (like anti-emulation techniques), a list of packages for banking apps with the corresponding name (encrypted with flowfish algorithm, decrypted at runtime) and language, other strings (base64 encoded or not), some others also encrypted with the blowfish algorithm, like the value corresponding to the min key, which will be the C&C (starts with google.com).

After that, it goes to a telegram channel and retrieves its description , that is the new C&C. It puts the encrypted value on the app.xml shared_prefs.

Figure(4): Decrypt telegram channel URL

Figure(5): Retrieves the description of the Telegram Channel (the C&C), which is stored in a shared preferences field (min)

When the app has accessibility services granted by the user, it starts a a foreground service called Besant. This service opens device’s Settings and a creates a notification with the title: Play Store.

Lastly, it starts a ScheduledExecutorService to:

• Register a new device on the C&C with hxxps[://]zamrakapata[.]com/callnew[.]php, passing some data to it, such as the model, language, etc.

• Check for new C2.

• Check if it has a power manager instance (This class lets it query and request control of aspects of the device’s power state). If it does not, instantiates one and acquires it (acquire().

Then, it checks if the “device” in shared_prefs is equal to 4. Ours was 2. This is probably an anti-emulator check, so we changed the value in the shared_prefs to 4.

It then changes opc key to 1.

Then it checks if oph is false. If yes, starts method speculated(ctx). This method checks if device’s keyguard (the device) is locked.

If it’s not locked, starts a TimerTask. In case opo’s value is set to true, it cancels the timer and leaves the function. Otherwise, it creates an intent with extra values (str - ALL_PIN; id - 1500) and start the activity untraffickable (mw_createWebViews).

On the untraffickable class:

If device equals 4, this class is responsible for creating the WebView with the C2 plus the corresponding parameters.

The current C&C is hxxps[://]zamrakapata[.]com/ (Encrypted version: zH7cPW3ZEHj+LIIGUYw2vUAkGwZKbOFMXkFgaNQxDpY=).

We were able to retrieve it with Frida by hooking into the Uriiah method. The result1 variable is google.com, the result2 is the decrypted URL parsed from the Telegram’s channel description.

Figure(6): Frida function to get the C&C

Overlay Attack Module

After all of this staging, the applications keeps running on the background with accessibility services always on. The code referring to that is on a class called paler, that extends AccessibilityService.

That class has a lot of code, fulled with encrypted strings and redundant functions that do exactly the same. After a lot of decryption, there’s one piece of code that stands out. If we are not running Burp (Anti MITM check) we get a lot of banking packages and names on the shared_prefs. This piece of code checks if the package corresponding to the currently open app is in that list.

Figure(7): Sending the intent to create a WebView

If it is on the list of banking packages (on shared_prefs/app.xml), it injects a WebView by starting the untrafficable()(in Figure 7, it is called mw_createWebViews()) method with the C&C URL + the proper parameters to find that specific banking layout on the server. This is called an overlay attack, and it is a very well known technique, specially on banking trojans.

Note: this piece of code is only called if wc, on the shared_prefs, is set to true, so we also had to change that value, as it was false in ours. If we want to use Frida or probably any other dynamic instrumentation toolkit, we need to change that value after Frida is hooked to the process already.

Figure(8): Overlay Example, injected when the user opens CaixaDirecta banking app

We can hook the loadUrl(), a WebView method, with this Frida script to unveil the full URL of the overlay being injected:

Figure(9): Frida script to hook on to loadurl()

Figure(10): The log with the overlay URL

Defanged version: hxxps[://]zamrakapata[.]com/rx/f[.]php?f=ES_Caixadirecta&p=dav15chp55jy7|en If the user enters his credentials, the threat actors can use them. Combined with access to the SMS messages, he can bypass the Multi-factor Authentication.

Other Features

What we know is present in this sample, but it would be too time-consuming to delve into it extensively at this time

• Heavy Obfuscation
  • Anti-emulation techniques
  • String encryption (AES and Blowfish)
  • Junk code
• Locking/Unlocking the screen
• Establish WebSocket connection

What it may have, based on prior examination of Godfather’s characteristics (conducted by other folks, smarter than me):

• Record the screen
• Keylogger
• Notification Listener
• Sending SMS from infected device
• Receiving commands from C&C
• …

Conclusion

This was a very challenging sample to analyze, as it has a lot of obfuscation techniques.

Due to time restrictions, we won’t explore the full capabilities of the malware. This post will be updated as we analyze it further in the future.

IoCs

APK SHA256: 20116083565a50f6b2db59011e9994e9a9f5db5994703d53233b8b202a5ad2f3

Package name: com.melting.mantaught

C2 Server: hxxps[://]zamrakapata[.]com/