Striking gold: Inside the GoldDigger Android malware

IBM Trusteer’s in-depth analysis of GoldDigger malware reveals how this sophisticated Android mobile banking Trojan uses virtual environments and evasion techniques. Learn to recognize the threat and protect yourself from bad actors.

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 the newest version of GoldDigger, with insights 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.

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 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 calls getInstalledPackages() , 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.

Capture input from any app currently using the Accessibility service

Get contacts (if user/accessibility approves READ_CONTACTS permission)

Read SMS (if user/accessibility approves READ_SMS permission)

Capture input from targeted banking app using the Accessibility service

Create a virtual space for a targeted app

Record audio and stream it using the RTMP protocol to the C&C

Captures video and streams it using the RTMP protocol to the C&C

Captures camera and streams it using the RTMP protocol to the C&C

Request Accessibility permission

Open banking phishing dialog to display on screen (parameters are: bank name, bank image and bank package name)

Open device information settings screen

Open Google Play Store app

Open the “Install unknown apps” settings screen

Request read and write storage permissions, and camera permission

Request location permissions

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.

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.

9688608017f35b48a719f529046172261af1d28a4ab2e80bc119cd1998f9bc6d

d873c2f85b4bc95f639aec333cfc977a89c2ec36d06a545f59a35f16e4c41685

392b8ecce716ff0645d53f8831be46946cf4931f9124469c1f38b7d3e413aaf9

Join security leaders who rely on the Think for curated news on AI, cybersecurity, data and automation. Learn fast from expert tutorials and explainers—delivered directly to your inbox twice weekly. See the IBM Privacy Statement .

Mobile Security Researcher

IBM Security Trusteer

The global average cost of a data breach reached USD 4.99M while AI-driven attacks increased 56%. Explore the latest findings.

Improve your organization’s incident response program, minimize the impact of a breach and experience rapid response to cybersecurity incidents.

Use IBM threat detection and response solutions to strengthen your security and accelerate threat detection.

Optimize decision-making processes, improve SOC efficiency and accelerate incident response with an intelligent automation and orchestration solution.

Improve your organization’s incident response program, minimize the impact of a breach and experience rapid response to cybersecurity incidents.