From 062bd847cb69f075c2700ee7d70235d25c080534 Mon Sep 17 00:00:00 2001 From: HackTricks News Bot Date: Thu, 30 Jul 2026 14:03:25 +0000 Subject: [PATCH 1/3] Add content from: Inside an N26 Impersonation Campaign: From Vishing and Fake ... --- .../android-malware-post-exploitation.md | 79 +++++++++++++++++++ 1 file changed, 79 insertions(+) diff --git a/src/generic-methodologies-and-resources/basic-forensic-methodology/android-malware-post-exploitation.md b/src/generic-methodologies-and-resources/basic-forensic-methodology/android-malware-post-exploitation.md index 19535d5b20e..ca5a940929a 100644 --- a/src/generic-methodologies-and-resources/basic-forensic-methodology/android-malware-post-exploitation.md +++ b/src/generic-methodologies-and-resources/basic-forensic-methodology/android-malware-post-exploitation.md @@ -860,6 +860,83 @@ struct Header { - Once verified, the bot sends a `MsgType=0` body carrying the operator-defined **group string** (e.g. `android-postboot-rt`). If the group is enabled, the C2 responds with `MsgType=2 (confirm)`, after which tasking (MsgType 5–12) begins. - Supported verbs include SOCKS-style TCP/UDP proxying (residential proxy monetization), reverse shell / single command exec, file read/write, and **Mirai-compatible DDoSBody** payloads (same `AtkType`, `Duration`, `Targets[]`, `Flags[]` layout). + +## Copybara-style banker / RAT tradecraft: per-app Play Store blackholes, parser differentials, and decoy overlays + +### Per-application `VpnService` blackhole against `com.android.vending` + +A more targeted installation-coercion pattern is to create a **VPN that only captures Google Play Store traffic** instead of taking the whole device offline. The dropper calls `VpnService.Builder.addAllowedApplication("com.android.vending")`, installs IPv4/IPv6 routes into a local TUN, and then simply discards packets for a short installation window. + +Why it matters: +- The victim still has connectivity in most apps, so the outage looks like a transient Play Store / Play Protect problem rather than a device-wide network failure. +- The same dropper can immediately resume the sideloading flow after the user grants `ACTION_MANAGE_UNKNOWN_APP_SOURCES`. +- In one observed case the UI polled the unknown-source permission state every **800 ms**, so installation resumed almost instantly after approval. + +Hunting ideas: +- `VpnService` + `addAllowedApplication("com.android.vending")` +- both `addRoute("0.0.0.0", 0)` and `addRoute("::", 0)` with no forwarding path from the TUN reader +- constants such as `240000` near VPN teardown / timers even if nearby strings claim a shorter block +- same code path also invoking `PackageInstaller`, `ACTION_INSTALL_PACKAGE`, or `ACTION_MANAGE_UNKNOWN_APP_SOURCES` + +### Hostile APK/ZIP parser differentials + +Some droppers intentionally build APKs that Android or tolerant ZIP readers can still process while common analysis tooling disagrees about the file layout. + +Interesting anti-analysis shapes: +- **local-header vs central-directory mismatches** (for example different compression methods for the same entry) +- **oversized ZIP extra fields** and random Unicode path components +- **extremely long asset names** used to hide the real payload near the end of a path that desktop tools fail to materialize +- **file-versus-directory collisions** below names normally treated as files, such as `classes.dex/`, `AndroidManifest.xml/`, or `resources.arsc/` + +Practical workflow: + +```bash +zipinfo -v sample.apk +7z l sample.apk +bsdtar -tf sample.apk +python -m zipfile -l sample.apk +jadx sample.apk -d out-jadx +apktool d sample.apk -o out-apktool +``` + +If these tools produce different entry lists, or one sees `classes.dex` while another sees children under `classes.dex/`, treat the APK as **parser-differential anti-analysis** rather than a broken download. Tools such as [apkInspector](https://github.com/erev0s/apkInspector/) are useful to diff local headers against the central directory before rebuilding a normalized sample. + +### Long-path asset tail loaders + RC4 JAR staging + +A useful loader pattern is: **benign-looking outer APK -> hidden JAR at the tail of an abnormally long asset path -> RC4/XOR decrypt -> DEX loader -> embedded payload APK**. + +Generic reversing steps: +1. Start from the custom `Application` subclass or the earliest `attachBaseContext()` / `onCreate()` hook. +2. Check whether the loader opens an asset with a suspiciously long name and then seeks to a tail offset instead of treating the whole asset as a normal file. +3. Reimplement the lightweight decryptor (`RC4`, rolling XOR, custom KSA/PRGA) and dump the recovered JAR/ZIP. +4. Inspect the recovered stage for `DexClassLoader`, reflective `pathList` edits, or `PackageManager.getPackageArchiveInfo()` calls used to show the embedded APK label/icon before install. +5. Look for a final `assets/base.apk` (or similarly generic filename) that is installed through the standard `PackageInstaller` flow. + +This pattern matters because the visible Java code in the outer APK may only contain UI glue and permission shepherding; the real installer logic lives in the decrypted second stage. + +### Context hiding instead of biometric bypass + +Accessibility bankers do not always need to break biometric crypto. A full-screen branded loading page or a generic utility **WebView decoy** can hide the real app while Accessibility performs taps underneath. If the victim is tricked into approving a genuine biometric / system prompt whose context is concealed, the attacker gets authorization **without** bypassing the biometric primitive itself. + +Operational clues: +- locale-driven HTML decoys such as `pg-en.html`, `pg-it.html`, ... loaded full-screen in a `WebView` +- hard-coded battery / temperature / RAM values used only to make the decoy look alive +- `TYPE_ACCESSIBILITY_OVERLAY` or opaque activity screens shown while `dispatchGesture`, `ACTION_SET_TEXT`, `performGlobalAction`, or notification suppression runs in parallel +- strings / structures indicating **server-defined overlays**, e.g. an `inj` object containing `package` + template filename so new target apps can be added without rebuilding the APK + +### Split MQTT control/media channels for Accessibility RATs + +Some Android RATs keep low-bandwidth control traffic separate from screen/camera streaming. + +A practical pattern to hunt for: +- MQTT topic such as `commands_FromPC` for serialized commands +- separate registration topic such as `RegisterMyDevice` +- one port/channel for command dispatch and a second port/channel for MediaProjection or camera traffic +- Android ID or a similarly stable device identifier substituted into the registration payload before subscription/publish + +This split keeps UI automation responsive while heavier screen or camera data uses a different socket/QoS profile. + + ## References - [Premium Deception: Uncovering a Global Android Carrier Billing Fraud Campaign](https://zimperium.com/blog/premium-deception-uncovering-a-global-android-carrier-billing-fraud-campaign) @@ -882,6 +959,8 @@ struct Header { - [Rokarolla : Android Banker with Complete Device Takeover Capabilities](https://zimperium.com/blog/rokarolla-android-banker-with-complete-device-takeover-capabilities) - [Zimperium IOC – Rokarolla commands](https://github.com/Zimperium/IOC/blob/master/2026-06-Rokarolla/commands.md) - Kimwolf Android TV Botnet: ENS-Based C2 Evasion, TLS+ECDSA C2 Protocol, and Large-Scale Proxy/DDoS Operations - [blog.xlab.qianxin.com](https://blog.xlab.qianxin.com/kimwolf-botnet-en/) +- [Inside an N26 Impersonation Campaign: From Vishing and Fake Control 1.0 to the Copybara Android RAT](https://d3lab.net/inside-an-n26-impersonation-campaign-from-vishing-and-fake-control-1-0-to-the-copybara-android-rat) +- [apkInspector](https://github.com/erev0s/apkInspector/) {{#include ../../banners/hacktricks-training.md}} From d2573dc2bd920d3a3193fc6379331f6d93ff3773 Mon Sep 17 00:00:00 2001 From: HackTricks News Bot Date: Wed, 5 Aug 2026 08:38:43 +0000 Subject: [PATCH 2/3] Add content from: Octagon: Technical Analysis of a Fake Bahrain Civil Defense ... --- .../android-malware-post-exploitation.md | 51 +++++++++++++++++++ 1 file changed, 51 insertions(+) diff --git a/src/generic-methodologies-and-resources/basic-forensic-methodology/android-malware-post-exploitation.md b/src/generic-methodologies-and-resources/basic-forensic-methodology/android-malware-post-exploitation.md index 19535d5b20e..4ca2afee38a 100644 --- a/src/generic-methodologies-and-resources/basic-forensic-methodology/android-malware-post-exploitation.md +++ b/src/generic-methodologies-and-resources/basic-forensic-methodology/android-malware-post-exploitation.md @@ -145,6 +145,56 @@ Triage ideas: - fake media/font assets later passed into `ZipInputStream`, `DexClassLoader`, or custom RC4 helpers - reflection on `pathList`, `dexElements`, `ContextImpl`, or `LoadedApk` close to asset decryption +### Manifest-declared components resolved only at runtime + +A useful dropper hunting pattern is when `AndroidManifest.xml` declares activities/services that are **missing from the root `classes.dex`**. The visible APK often keeps the real implementations inside an encrypted asset (`*.ttf`, `*.dat`, `*.jar`, `*.base`), decrypts it into private storage, and only then exposes the missing classes through `DexClassLoader` or reflective `DexPathList` injection. + +Practical workflow: + +1. Extract every class name referenced by `AndroidManifest.xml`. +2. Compare them against all packaged `classes*.dex` files, not just the first DEX. +3. Treat unresolved components as a strong signal for staged code loading. +4. Hook asset reads, private-file writes, and class-loader APIs to recover the hidden module at runtime. + +High-signal events to correlate: +- `AssetManager.open()` / `Resources.openRawResource()` on non-media assets with high entropy +- `FileOutputStream` / `openFileOutput()` writing `*.dex`, `*.jar`, `*.apk` under app-private paths +- `DexClassLoader`, `PathClassLoader`, `InMemoryDexClassLoader`, or reflection touching `pathList` / `dexElements` +- `adb logcat` entries revealing generated payload paths or class-loading failures + +Quick triage: + +```bash +# Manifest vs DEX diff +apkanalyzer manifest print app.apk | rg 'service|activity|receiver' +unzip -l app.apk | rg 'classes.*\.dex|assets/|res/raw/' + +# Recover runtime payloads from the app sandbox +adb shell run-as sh -c 'find . -type f \( -name "*.dex" -o -name "*.jar" -o -name "*.apk" -o -name "*.json" -o -name "*.db" -o -name "*.xml" \) 2>/dev/null' +adb logcat | rg 'DexClassLoader|ClassNotFoundException|PackageInstaller|app_' +``` + +### Asset-to-`PackageInstaller` staging and nested child payloads + +Another useful evasion pattern is to hide stage 2 inside `assets/` and **stream it directly into a `PackageInstaller` session** instead of first dropping a plainly named APK in shared storage. After the child package is installed, that second package may generate another `DEX`/`JAR` under `/data/user/0//app_*` and dynamically load the final module. + +Hunting ideas: +- correlate `ACTION_MANAGE_UNKNOWN_APP_SOURCES` / `REQUEST_INSTALL_PACKAGES` with `PackageInstaller.createSession` -> `openWrite` -> `fsync` -> `commit` +- watch for the parent package stopping a temporary service (often VPN / overlay / lure UI) immediately after install, then launching the new package +- inspect `PACKAGE_ADDED` / `PACKAGE_REPLACED` receivers, private `app_*` directories, and follow-on `DexClassLoader` activity in the child app + +### `AccountManager` + Sync Adapter persistence + +A less common but very useful Android persistence primitive is to register a **fake account** and attach a **Sync Adapter** to it. The malware then uses `ContentResolver.setSyncAutomatically()`, `addPeriodicSync()`, or `requestSync()` so Android wakes it on a schedule even when no long-running service is visible. + +What to look for: +- authenticator XML/resources plus code calling `AccountManager.addAccountExplicitly` +- a sync adapter service with `android.content.SyncAdapter` metadata +- suspicious sync intervals (for example every 30 minutes) or forced immediate sync right after connectivity returns +- boot receivers / WorkManager jobs whose only purpose is to re-register the account or reschedule sync + +This is especially useful in samples that already store queue/state locally (SQLite + SharedPreferences): periodic sync becomes the exfil/reconnect trigger for offline-collected SMS, credential captures, contacts, or phishing results. + ### Anti-analysis kill-switch Packed loaders often **self-terminate** when emulator or analysis checks fail (e.g., `CPU_ABI` validation) by calling: @@ -862,6 +912,7 @@ struct Header { ## References +- [Octagon: Technical Analysis of a Fake Bahrain Civil Defense Application](https://labs.k7computing.com/index.php/octagon-technical-analysis-of-a-fake-bahrain-civil-defense-application/) - [Premium Deception: Uncovering a Global Android Carrier Billing Fraud Campaign](https://zimperium.com/blog/premium-deception-uncovering-a-global-android-carrier-billing-fraud-campaign) - [SmsRetrieverApi reference](https://developers.google.com/android/reference/com/google/android/gms/auth/api/phone/SmsRetrieverApi) - [Android `CookieManager` reference](https://developer.android.com/reference/android/webkit/CookieManager) From b6f7e6a2b87a234dab8df08277f0912c1580f9dd Mon Sep 17 00:00:00 2001 From: Carlos Polop Date: Thu, 6 Aug 2026 13:07:10 +0200 Subject: [PATCH 3/3] References: cite already-listed sources on the lines that mention them (1 citations) --- .../android-malware-post-exploitation.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/generic-methodologies-and-resources/basic-forensic-methodology/android-malware-post-exploitation.md b/src/generic-methodologies-and-resources/basic-forensic-methodology/android-malware-post-exploitation.md index 974c1f38257..e218afce141 100644 --- a/src/generic-methodologies-and-resources/basic-forensic-methodology/android-malware-post-exploitation.md +++ b/src/generic-methodologies-and-resources/basic-forensic-methodology/android-malware-post-exploitation.md @@ -639,7 +639,7 @@ Note: Many DevicePolicyManager controls require Device Owner/Profile Owner on re ### NFC relay orchestration (NFSkate) Stage-3 can install and launch an external NFC-relay module (e.g., NFSkate) and even hand it an HTML template to guide the victim during the relay. This enables contactless card-present cash-out alongside online ATS.[[12]](#references) -Background: [NFSkate NFC relay](https://www.threatfabric.com/blogs/ghost-tap-new-cash-out-tactic-with-nfc-relay). +Background: [NFSkate NFC relay](https://www.threatfabric.com/blogs/ghost-tap-new-cash-out-tactic-with-nfc-relay).[[12]](#references) ### Operator command set (sample) - UI/state: `txt_screen`, `screen_live`, `display`, `record`