CRIL analyzes a surge in an ongoing campaign to deliver MiningDropper — a modular Android malware framework - at scale.
Cyble Research and Intelligence Labs (CRIL) has been monitoring a significant surge in the use of “MiningDropper”, a sophisticated Android malware delivery framework that combines cryptocurrency mining capabilities with the deployment of infostealers, Remote Access Trojans (RATs), and banking malware.
MiningDropper employs a multi-stage payload delivery architecture that combines XOR-based native obfuscation, AES-encrypted payload staging, dynamic DEX loading, and anti-emulation techniques. This layered design enables threat actors to evade static detection, delay analysis, and dynamically control the delivery of the final payload.
Our analysis indicates that MiningDropper is being actively leveraged across multiple campaigns, with a particularly notable infostealer campaign targeting Indian users, alongside a BTMOB RAT campaign affecting LATAM, Europe, and Asia.
Additionally, large-scale telemetry analysis shows widespread distribution with low detection rates, highlighting the effectiveness of its evasion techniques and the rapid reuse of its modular architecture across campaigns.
| Category | Description |
| Type | Multi-stage dropper |
| Capabilities | Crypto mining |
| Infection Vector | Smishing, Social Media, and Fraudulent Websites |
| Initial Payload | Trojanized LumoLight application |
| Final Payloads | Infostealer, RAT, Banking Trojan |
| Obfuscation Techniques | XOR-based string obfuscation in native code, AES-encrypted asset files |
| Target Region | Asia, Europe, LATAM |
Recently, CRIL observed a notable surge in the use of MiningDropper (also referred to as BeatBanker) as an adaptable malware delivery framework for distributing infostealers, Remote Access Trojans (RATs), and banking malware.
The threat actor employs a multi-stage payload architecture that incorporates XOR-based native-string obfuscation, AES-encrypted payload staging, and anti-emulation techniques, significantly complicating detection and analysis.
Our investigation revealed that MiningDropper is actively leveraged across multiple campaigns, with particularly notable activity observed in two primary campaign clusters:
Infostealer Campaign
This campaign primarily targets users in India by impersonating:
In October 2025, Cyble analyzed a campaign that used RTO services as a lure, during which multiple malware variants were identified, including one that used MiningDropper. In its more recent variant, MiningDropper incorporates native code along with a trojanized open-source application.
In this campaign, victims are lured to download malicious APK files via phishing websites or social media platforms, ultimately leading to the deployment of infostealer payloads designed to harvest sensitive user and financial data.
The following sites were identified as distributing MiningDropper as part of an infostealer campaign:
BTMOB RAT Campaign
The second campaign distributes MiningDropper via fraudulent sites targeting users across:
In this case, the dropper delivers BTMOB RAT, a full-featured Android remote access trojan. We first identified BTMOB RAT in February 2024 as a variant of the SpySolr malware, capable of credential harvesting, device takeover, real-time remote control, and facilitating financial fraud operations.
At the time of its initial discovery, the malware was distributed without a packer and was detected by multiple antivirus products. However, in recent campaigns this year, BTMOB RAT is being distributed via MiningDropper, significantly reducing its detection footprint to as few as 1–3 detections.
The following phishing sites were identified as distributing MiningDropper as part of a BTMOB RAT campaign:
Over the past month, we identified more than 1,500 MiningDropper samples in the wild, highlighting the rapid proliferation and reuse of this malware framework. Detection telemetry reveals:

These observations underscore that MiningDropper is not merely another Android dropper, but a scalable malware-as-a-framework, enabling threat actors to efficiently deploy diverse payloads while maintaining a low detection footprint.
A detailed technical analysis is presented in the following section.
MiningDropper employs a multi-stage, modular architecture combining native code, dynamic loading, staged decryption, and configuration-driven payload delivery. Each stage progressively unpacks the next payload while minimizing static exposure and hindering detection.
For the technical analysis, we analyzed the APK “Free Secure – Annulation.apk” (58a94f889547db8b2327a62e03fb2cce3bda716278d645ee8094178ecda2e9e6), which is being distributed via a phishing site “hxxps://free-secure[.]com/Free%20Secure%20-%20Annulation.apk”.

Initial Native Stage
The threat actors appear to have trojanized the open-source Android application project “LumoLight.” The malicious activity is executed via the application subclass, which loads the native library “librequisitionerastomous.so.” This library contains XOR-obfuscated strings that are decrypted at runtime, a technique used to hinder static analysis and evade automated detection mechanisms.

After decrypting the strings from the native code, it is evident that the native library has implemented anti-emulation techniques. The application checks platform details, system architecture, and device model information to determine whether it is running on an emulator.
If an emulated or rooted environment is detected, the malware terminates its malicious execution.

The native library is also responsible for decrypting and executing the first-stage payload from the APK’s assets directory. The asset “x7bozjy2pg4ckfhn” is decrypted using a long hardcoded XOR key, producing the first-stage DEX payload.


After decrypting the first-stage payload, the native code dynamically loads the DEX file using DexClassLoader and invokes the malicious class “com.example.virusscanbypassbootstrapper.DexLoader.”

First Stage Payload
The decrypted first-stage payload acts primarily as a bootstrap loader. Its main purpose is to receive execution from the native library, decrypt the next-stage payload, and execute it. This stage contains a loadDex() method that decrypts the second-stage payload and executes it via dynamic code loading.

The first stage retrieves the encrypted second-stage file “4ozvcznaamqmioqf/sorxbqp8” from the assets folder and decrypts it using AES.
The AES key is derived from the first 16 bytes of the SHA-1 hash of the filename sorxbqp8, showing that the TA uses filename-derived key material rather than storing raw AES keys directly.
This approach slightly increases analysis effort because the decryption key must be reconstructed from the naming logic rather than extracted as a static constant.

After decryption, the first stage loads the recovered second-stage dex using Dex Class Loading.
Second Stage Payload
The second-stage payload is the most visible portion of the chain from the victim’s perspective. It presents a fake Google Play update interface that deceives the user into believing a legitimate update or service repair is underway.
This stage effectively serves as the social-engineering layer of the infection flow, masking the malicious installation behind a familiar Android/Google-themed update prompt.

In addition to the visual lure, the second stage loads the class com.qnez.sarcilistranscendingly.App responsible for decoding and orchestrating the remaining stages. This component decrypts the file “jajmanpongids” using AES, again deriving the key from the first 16 bytes of the SHA-1 hash of the filename plus the suffix 1.
In this case, the effective key material is based on jajmanpongids1. The decrypted output is a ZIP archive that contains the third-stage installer components.

Based on the observed code paths, the malware operates in two distinct modes: one linked to the “miner” component and the other to a “user payload.”
The behavior indicates that the second-stage payload initially activates the miner module, then transitions state—either upon completion or failure—and then executes the user-defined payload.
This distinction highlights that the campaign is built to support flexible, multi-purpose monetization rather than a fixed single-payload approach.
The second stage also decrypts one of two configuration files from assets: “norweyanlinkediting” for the miner path or “udela” for the user-defined path. Both use the same AES pattern, with the key derived from the first 16 bytes of the SHA-1 hash of the filename plus 1.
For the user-defined payload, the decrypted configuration contains:
{"isRemoteControl": true, "isTestKeyEnabled": false, "splits": ["transnaturationsaxhorn", "mischanterperilling", "unwieldlyostearthritis"], "subscriptionEndMillis": 1777220616438, "messageAuthenticationCode": "HaZRwGj6UZDpqKSf43o/Cg==", "simpleInstaller": "deprecated"}
For the miner payload, the configuration contains:
{"isRemoteControl": false, "isTestKeyEnabled": false, "splits": ["bilbopseudomelanosis"], "subscriptionEndMillis": 4611686018427387903, "messageAuthenticationCode": "eVAmHju3UqrVWR56gOMaUQ==", "simpleInstaller": "deprecated"}
The third-stage payload uses these configuration files to identify which encrypted asset files correspond to the remote control payload and which are associated with the miner component.
Third Stage Payload
The third-stage payload is extracted from the decrypted ZIP archive “jajmanpongids.zip”, which contains the DEX file “enchantmentcrosses” along with ARM native libraries. Similar to earlier stages, this payload leverages native code and XOR-based string obfuscation to evade analysis.
Functionally, it operates as a split-APK installer module that reconstructs and installs the final payload package using components defined in the configuration.


Final Payloads
For the user-defined path, the third stage processes the three split entries listed in the configuration: transnaturationsaxhorn, mischanterperilling, and unwieldlyostearthritis. These files are present in the APK assets and are encrypted using the same AES pattern used elsewhere in the chain.
After decryption, the components are merged to reconstruct the final malicious package. In this sample, this merged payload is attributed to BTMOB RAT.
BTMOB RAT can perform multiple malicious activities, including credential theft via WebView-based injections, keylogging, and data exfiltration. It abuses Android Accessibility Services to gain extensive control over the device, enabling actions such as unlocking the device, simulating user interactions, and granting additional permissions.
Furthermore, it supports real-time remote control via WebSocket-based C2 communication, enabling attackers to monitor the infected device’s screen in real time, manage files, record audio, and execute commands.
For the miner path, the third stage decrypts the single asset bilbopseudomelanosis, again using filename-derived AES key material. In this branch, the output is a standalone APK that handles cryptocurrency mining.
Taken together, the final stage design reveals that MiningDropper is better understood as a multi-payload Android delivery framework than a simple miner dropper.
The same loader family can deliver radically different end payloads with only configuration and asset changes, which explains how the campaign can scale across a large number of samples while maintaining a consistent core architecture.
MiningDropper demonstrates a layered, modular Android malware architecture designed to make static analysis difficult while giving Threat Actors flexibility in final payload delivery.
The malware combines a native bootstrapper, memory-only string deobfuscation, filename-derived AES decryption, staged DEX loading, configuration-driven payload delivery, and split APK reconstruction to install either a cryptocurrency miner or a more capable user-defined payload such as BTMOB RAT.
This design allows the threat actor to reuse the same distribution and installation framework across hundreds of samples while adapting the final monetization objective to operational needs.
We have listed some essential cybersecurity best practices that serve as the first line of defense against attackers. We recommend that our readers follow the best practices given below:
| Tactic | Technique ID | Procedure |
| Initial Access (TA0027) | Phishing (T1660) | MiningDropper is distributed via phishing sites |
| Execution (TA0041) | Native API (T1575) | Dropper used native code to decrypt payloads |
| Defense Evasion (TA0030) | Obfuscated Files or Information (T1406) | Dropper stores the encrypted payload in the assets |
| Defense Evasion (TA0030) | Virtualization/Sandbox Evasion (T1633) | Dropper implemented anti-emulation techniques |
| Discovery (TA0032) | System Information Discovery (T1426) | Dropper checks the device information to identify the running environment |
The IOCs have been added to this GitHub repository. Please review and integrate them into your Threat Intelligence feed to enhance protection and improve your overall security posture.