Striking gold: Inside the GoldDigger Android malware

IBM Trusteer researchers consistently investigate financial fraud threats across various digital channels, including mobile. In our latest mobile banking malware research, we explored the GoldDigger malware’s inner workings. This malware was first discovered by Group-IB, in 2023. Although it was detected three years ago, an in-depth technical analysis has not been publicly shared with the community until now.

GoldDigger is a financial Android banking trojan from the RAT category that can perform on-device fraud.

The malware is primarily focused on mobile banking users in South Africa, with additional targets identified across Europe. Artifacts observed both in the code and in the target list from the configuration indicate a clear intent to expand operations on a global scale.

This blog provides our findings about the newest version of GoldDigger, with insights about its virtual environment feature and the capabilities that help cyber criminals use it in mobile banking fraud.

While the use of a virtualized environment was first observed in the GodFather malware, they remain uncommon among financial malware, which typically utilizes overlay or accessibility abuse for fraudulent activities.

GoldDigger uses a sophisticated packer called “dpt-shell”. A packer is a software protection mechanism that compresses, encrypts, or obfuscates an application’s code and resources, making it difficult for security tools and researchers to inspect its contents. This packer is used to hide the malware’s code, prevent analysis, evade detection by antivirus and security solutions, and conceal the malware internal functionality.

The packer is implemented inside a native shared library (.so) file called “libdpt.so” and located in the malware’s assets directory. In contrast to many Android malware packers, this one does not simply drop and load the protected DEX file at runtime.

At a first glance, we can see that the malware builds a path to drop the DEX file inside its private directory:

And indeed, several DEX files were observed being dropped to this path while running the malware:

However, when trying to read the code inside the DEX files, some methods are not complete and are filled with junk code:

Analysis of the packer revealed that the malware hooks libart.so, the core Android Runtime (ART) library. This allows the malware to intercept class loading, modify bytecode at runtime and hide malicious classes from analysis.

To bypass this protection and extract the hidden code, dynamic analysis can be useful. However, the malware implements multiple evasion techniques in the packer. Some examples include:

1. The packer’s native logic is encrypted using RC4, a symmetric encryption stream cipher, with a different key for each sample and decrypted at runtime. Therefore, it must first be decrypted before static analysis can be performed.

2. The packer can detect whether Frida is attached to the process, then proceed to crash it.

3.  Another anti-debugging technique employed is self‑debugging, using the PTRACE system call.

By invoking ptrace(PTRACE_TRACEME) on itself, the process marks itself as being traced. A process can only be traced by a single debugger at a time, so this prevents any external debugger from attaching.

After decrypting and patching the packer, we were able to successfully extract the hidden code during runtime.

The current GoldDigger campaign primarily impersonates airline companies, as well as shopping retailers.

The campaign resulted in a massive infection across many users, mostly in South Africa and the United Kingdom.

When the malware is initially executed, it displays a fake login page. This page is crafted to mimic a legitimate company interface, as part of its social engineering strategy.

After the victim registers as a new user or enters their real account credentials, the malware requests the victim to approve its Accessibility service.

Once approved, the malware displays a screen asking the user to claim their rewards:

The malware then registers the victim to the command-and-control (C&C) server by sending information about the mobile device and the password entered by the victim on the login page.

The C&C server will send the configuration to the malware, including the list of targeted banks, and a token that will be used to communicate with the C&C. This configuration will be stored in the malware’s shared preferences XML file.

The Android Accessibility service is a legitimate Android framework that is designed to assist users by granting apps the ability to read screen content, simulate clicks and interact with other apps.

Financial malware such as GoldDigger exploits this service to perform fraudulent actions.

GoldDigger can inject input to the banking app to mimic user interaction, such as entering text, clicking buttons and performing gestures. In doing so, GoldDigger initiates fraudulent transactions from the victim’s banking app to the attacker.

In addition, the fraudster can see the content of the victim’s screen. When the victim opens a banking app from the configuration list, the malware uses the Accessibility service to steal the credentials from the login page.

In addition, the fraudster can see the content of all SMS messages that are sent to the user and steal the 2FA SMS messages.

GoldDigger is also capable of displaying an overlay dialog on the screen, with content dynamically retrieved from its C&C server. Code analysis suggests this dialog presents a phishing page mimicking a targeted bank’s login screen to harvest victim credentials. This approach is consistent with traditional overlay-based phishing attacks that are commonly used in mobile banking malware.

A unique capability of GoldDigger, is its ability to run a targeted app in a virtual environment, per C&C demand.

A virtual environment application in Android is an app that creates an isolated runtime environment inside the device (within the scope of the virtual app itself), where other apps can be installed and executed independently from the main OS environment. Inside the virtual environment, system API calls can be intercepted and modified by the virtualization framework. For example, if an app callsgetInstalledPackages() , it may see only the apps cloned inside that virtual environment, rather than all apps installed on the real device.

While virtual environments can be used for legitimate features like app cloning, financial malware often abuse them for fraudulent activities.

The malware can intercept and modify all API calls made by the targeted app within the virtual environment, enabling it to bypass detection mechanisms and spoof device identifiers or account information.

In addition, the attacker obtains full visibility into its runtime behavior, enabling real-time interception of credentials and sensitive data.

In the GoldDigger malware, the C&C sends the package name of the app that needs to be running inside the virtual environment, and a service in the malware handles the virtualization.

While some of the service logic is implemented within the GoldDigger malware, part of the functionality is missing and may be delivered via the C&C server or another application. At the time of writing, we were unable to retrieve the missing component.

Here, the GoldDigger manifest references the package name of the missing virtualization component:

In a normal Android flow, an app communicates with the real Android system services through Binder IPC. From here, it receives the actual device state, such as the real list of installed applications.

However, in a virtualized environment things work differently. API calls are redirected through a virtualization layer that intercepts and modifies responses, returning fake or filtered information to apps running inside the virtual space.

Our analysis of the GoldDigger sample, led to the identification of the Binder communication layer (IThirdPartyService, Proxy and Stub interfaces) used to communicate with the virtualization engine. However, the actual virtualization service and the fake system API logic appear to be missing and are likely implemented in the external net.yy.vwork component.

To communicate with the attacker’s C&C server during its ongoing operations, GoldDigger uses the WebSocket protocol. Each request contains a token generated by the C&C and is received from the malware’s first registration. The requests and responses are encrypted with standard AES and a key embedded within the malware code. The malware sends “keep-alive” requests to the C&C system and parses the response, which is returned as a JSON file containing a command number and relevant parameters. Each command comes with code, triggering a malware capability.

To protect yourself, you should regularly review your installed applications and promptly remove any that appear unfamiliar or suspicious. Remaining proactive and cautious will help mitigate risks posed by this evolving attack paradigm.

• Review app permissions: Scrutinize app permissions before granting them. This is especially important when involving Accessibility, Location, Camera and Microphone.
• Strengthen accounts with 2FA: Utilize Two-Factor Authentication on all critical accounts (banking, email) for added security. Be sure to prioritize authenticator apps over SMS-based options.
• Keep software updated: Regularly update your Android OS and installed apps to receive crucial security patches.
• Monitor account activity: Set up alerts or notifications for unusual account activity. These are a key indicator of potential fraud.

In this blog, we’ve analyzed a new version of the GoldDigger malware. We’ve examined the malware’s virtualization capabilities and their potential use in mobile banking fraud.

In addition to these virtualization capabilities, we’ve seen how GoldDigger also leverages overlay attacks and the abuse of the Android Accessibility service to facilitate fraudulent actions. The IBM Trusteer lab will continue to monitor and research the malware to track its ongoing evolution and emerging capabilities.

IBM Trusteer helps you detect fraud and malware, authenticate users and establish identity trust across the omnichannel customer journey. Hundreds of leading organizations rely on IBM Trusteer to help secure their customers’ digital journeys and support business growth.

Special thanks to Camila Sablotny for her valuable help with the investigation.