MiningDropper: The Android Malware That Mines Crypto and Drops Banking Trojans – How It Evades Detection + Video

By /

Listen to this Post

Featured Image

Introduction:

MiningDropper is a modular Android malware framework that combines cryptocurrency mining with the delivery of secondary payloads such as infostealers, remote access trojans (RATs), and banking trojans. This multi-stage dropper leverages a trojanized version of the open-source Lumolight flashlight app, distributed via phishing links, social media, and fake websites, to bypass antivirus engines and delay forensic analysis through layered obfuscation.

Learning Objectives:

  • Understand the architectural layers of MiningDropper, including XOR-obfuscated native code, AES-encrypted payloads, and dynamic DEX loading.
  • Learn how to analyze and extract malicious payloads from Android APKs using static and dynamic analysis tools.
  • Implement detection and mitigation strategies against anti-emulation techniques used by Android malware.

You Should Know

1. Understanding MiningDropper’s Layered Architecture

MiningDropper’s evasion begins with a weaponized flashlight app. The malware uses a multi-stage execution flow: the initial APK contains native libraries (.so) obfuscated with XOR, which decrypt an AES-encrypted payload. This payload is then dynamically loaded via DexClassLoader, avoiding static detection. The final stage drops banking malware (e.g., BTMOB RAT) and a hidden cryptocurrency miner.

Step‑by‑step guide to analyzing APK structure:

1. Download the suspicious APK (e.g., `flashlight.apk`).

  1. Decompile with `apktool` to inspect `AndroidManifest.xml` and native libraries: 
    apktool d flashlight.apk -o flashlight_decompiled
cat flashlight_decompiled/AndroidManifest.xml | grep -E "uses-permission|android:name"

3. Extract native libraries:

unzip flashlight.apk -d flashlight_extracted
find flashlight_extracted -name ".so" -exec file {} \;

4. Look for suspicious permissions: INTERNET, READ_SMS, RECORD_AUDIO, BIND_ACCESSIBILITY_SERVICE.

2. Analyzing XOR‑Obfuscated Native Code

The native library (e.g., libnative.so) uses XOR with a hardcoded key to hide strings and decrypt subsequent stages. To reverse this, you can extract the `.so` and run a simple XOR brute‑force script.

Step‑by‑step guide to deobfuscate XOR strings:

1. Extract the `.so` from the APK:

unzip flashlight.apk -d apk_contents
cp apk_contents/lib/armeabi-v7a/libnative.so .

2. Use `strings` to find readable sections, but XOR will hide them. Instead, use a Python script to XOR brute‑force:

 xor_bruteforce.py
import sys
data = open(sys.argv[bash], 'rb').read()
for key in range(256):
dec = bytes([b ^ key for b in data])
if b'http' in dec or b'payload' in dec:
print(f"Key {key}: {dec[:200]}")

Run: `python xor_bruteforce.py libnative.so`

  1. For common XOR keys (e.g., 0x5A), use `xxd` and awk: 
    xxd -p libnative.so | tr -d '\n' | sed 's/../0x& /g' | awk '{for(i=1;i<=NF;i++){printf "%c", xor(strtonum($i),0x5A)}}'

3. Decrypting AES‑Encrypted Payloads

Once the native code decrypts an AES‑encrypted blob (usually stored in `assets/` or res/raw/), you can extract the key and IV by debugging the native function or by hooking with Frida.

Step‑by‑step guide to extract and decrypt payloads:

  1. Identify the encrypted file (e.g., assets/enc.dat). Use `file` command to detect entropy: 
    file -b flashlight_extracted/assets/enc.dat  shows high entropy
  2. Use `frida` to hook the AES decryption function (assuming `libnative.so` exports decrypt_payload): 
    // frida_hook.js
Interceptor.attach(Module.findExportByName("libnative.so", "decrypt_payload"), {
onEnter: function(args) {
console.log("Ciphertext length: " + args[bash]);
this.key = Memory.readByteArray(args[bash], 32);
this.iv = Memory.readByteArray(args[bash], 16);
},
onLeave: function(retval) {
console.log(hexdump(this.key));
console.log(hexdump(this.iv));
console.log("Decrypted payload at: " + retval);
}
});

Run with: `frida -U -l frida_hook.js com.flashlight.app`

  1. Alternatively, extract AES key from `.so` using `binwalk` and openssl: 
    binwalk -e libnative.so  extracts embedded files
openssl enc -d -aes-256-cbc -in enc.dat -out decrypted.dex -K $(xxd -p key.bin) -iv $(xxd -p iv.bin)

4. Detecting Anti‑Emulation and Sandbox Evasion

MiningDropper includes checks for emulated environments (e.g., QEMU, BlueStacks) by querying system properties, build tags, and running processes. It also delays payload execution if debugging is detected.

Step‑by‑step guide to bypass anti‑emulation for analysis:

  1. Use a rooted physical Android device or a custom emulator (e.g., Android Studio with modified build.prop).

2. Patch the APK to remove anti‑emulation checks:

  • Decompile with `jadx` to locate anti‑emulation code (search for "goldfish", "ranchu", "vbox", "qemu").
  • Smali patch: change conditionals to always return false. 
    Find smali files with anti-emulation strings
grep -r "goldfish" flashlight_decompiled/smali/
Edit the smali: replace "if-eqz" with "if-nez" or add "const/4 v0, 0x0"
  1. Use Frida to hook `SystemProperties.get` and return real device values: 
    var SystemProperties = Java.use("android.os.SystemProperties");
SystemProperties.get.overload('java.lang.String').implementation = function(key) {
var real = this.get(key);
if (key === "ro.kernel.qemu") return "0";
if (key === "ro.hardware") return "samsungexynos";
return real;
};

5. Dynamic DEX Loading and Payload Extraction

The final stage uses `DexClassLoader` to load an encrypted secondary DEX file from a remote server or from assets. The loaded DEX contains the banking trojan (e.g., BTMOB) and the crypto miner.

Step‑by‑step guide to extract dynamically loaded DEX:

  1. Monitor file creation in the app’s private directory: 
    adb shell
run-as com.flashlight.app
ls -la files/  Look for .dex or .odex files
  2. Use `strace` or `inotify` on Android (requires root): 
    adb shell su -c "inotifyd /data/data/com.flashlight.app/code_cache"

3. Dump loaded DEX from memory using `frida-dexdump`:

frida-dexdump -U -n com.flashlight.app -o /tmp/dumped_dex

4. Convert dumped DEX to JAR and analyze with jadx:

d2j-dex2jar dumped.dex -o output.jar
jadx-gui output.jar

6. Mitigation Strategies for Android Devices

To protect against MiningDropper and similar droppers, implement network‑level and device‑level controls. Organizations should enforce application whitelisting, disable sideloading, and monitor for malicious network traffic.

Step‑by‑step guide to harden Android devices:

  1. Disable installation from unknown sources (Android Settings → Security → Unknown sources → OFF).
  2. Use a mobile threat defense (MTD) solution that detects dynamic DEX loading and crypto‑mining behavior.
  3. Block known C2 domains using DNS filtering (e.g., Pi‑hole or Cisco Umbrella): 
    Example /etc/hosts entries
127.0.0.1 miningdropper-c2[.]com
127.0.0.1 payload-delivery[.]net
  4. Monitor for unusual CPU usage (cryptominers) using `top` on rooted devices or via MDM: 
    adb shell top -n 1 | grep -E "com.flashlight|minerd"
  5. For Windows‑based Android management, use PowerShell to scan connected devices for known malicious packages: 
    adb shell pm list packages | findstr /i "flashlight flashlightapp"

7. Forensic Indicators and YARA Rules

Create YARA rules to detect MiningDropper variants based on strings, native library exports, and AES constants. This helps in incident response and threat hunting.

Step‑by‑step guide to write and run YARA rules:

1. Extract indicators from a sample:

strings flashlight.apk | grep -iE "xor|aes|decrypt|payload|btmob"

2. Create a YARA rule (e.g., `miningdropper.yara`):

rule MiningDropper_Flashlight {
meta:
description = "Detects MiningDropper APK with Lumolight trojan"
author = "Analyst"
strings:
$xor_key = { 5A 5A 5A 5A } // example XOR key pattern
$aes_const = "AES/CBC/PKCS5Padding"
$dex_loader = "Ldalvik/system/DexClassLoader;"
$c2_domain = /miningdropper|payloaddelivery/
condition:
any of ($xor_key, $aes_const) and $dex_loader and filesize < 10MB
}

3. Run YARA against a directory of APKs (Linux):

yara -r miningdropper.yara /path/to/apks/

4. For Windows, use `yara64.exe` with similar syntax.

What Undercode Say:

  • Key Takeaway 1: MiningDropper demonstrates how open‑source apps can be weaponized with multi‑stage, obfuscated loading techniques to evade traditional signature‑based antivirus.
  • Key Takeaway 2: Effective defense requires behavioral monitoring (dynamic DEX loading, CPU spikes) and static analysis tools (apktool, jadx, YARA) to unpack encrypted payloads and detect anti‑emulation tricks.

MiningDropper is not an isolated threat; it represents a growing trend of modular Android malware that combines profit generation (crypto mining) with data theft (banking trojans). The use of native XOR obfuscation and AES encryption forces analysts to move beyond simple string matching. Moreover, the anti‑emulation checks indicate that attackers are actively hindering sandbox analysis. Organizations should adopt a zero‑trust model for mobile devices, enforce application control, and invest in dynamic analysis capabilities. As mobile malware evolves, expect more droppers to abuse legitimate app frameworks and leverage server‑side payload rotation to avoid hash‑based detection.

Prediction: Within the next 12 months, we will see MiningDropper variants targeting iOS through trojanized TestFlight apps, and the integration of AI‑generated mutation layers to defeat YARA rules. Enterprises will need to deploy on‑device machine learning models to detect anomalous DexClassLoader invocations and crypto‑mining CPU patterns in real time.

▶️ Related Video (76% Match):

🎯Let’s Practice For Free:

IT/Security Reporter URL:

Reported By: Mayura Kathiresh – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅

🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]

💬 Whatsapp | 💬 Telegram

📢 Follow UndercodeTesting & Stay Tuned:

𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky

Related Posts: