Skip to content

Inside BTMOB An Analytical Breakdown of a Leaked Android RAT... #1663

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
carlospolop wants to merge 1 commit into from
Closed

Inside BTMOB An Analytical Breakdown of a Leaked Android RAT... #1663

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
60 changes: 44 additions & 16 deletions src/mobile-pentesting/android-app-pentesting/accessibility-services-abuse.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -134,6 +134,12 @@ ClayRat exposes this capability with the `show_block_screen` / `hide_block_scree

Because TYPE_ACCESSIBILITY_OVERLAY windows never raise the `SYSTEM_ALERT_WINDOW` permission prompt, the victim only sees the decoy UI while the RAT keeps interacting with the real apps underneath.

#### C2-driven overlay workflow (BTMOB case study)

- `brows` commands order the bot to spin up a hidden `WebView`, load attacker-controlled HTML/JS (remote URL, inline payload or decrypted asset) and pipe DOM events plus credential fields back over the persistent WebSocket channel, so operators can phish logins without re-packaging the APK.
- `ject` manages overlay kits per package: HTML/CSS/JS blobs are shipped encrypted inside the APK or pulled from `/yaarsa/private/` on demand, decrypted, and displayed only when Accessibility sees the targeted banking app in the foreground.
- Because the overlay lives inside the Accessibility process, the C2 can push multi-step flows (login → MFA → payment approval) and inject arbitrary JS in real time while the legitimate app underneath keeps receiving the original touches.

### 2. On-Device Fraud automation
Malware families such as **PlayPraetor** maintain a persistent WebSocket channel where the operator can issue high-level commands (`init`, `update`, `alert_arr`, `report_list`, …). The service translates those commands into the low-level gestures above, achieving real-time unauthorized transactions that easily bypass multi-factor-authentication tied to that very device.

Expand Down Expand Up @@ -183,6 +189,31 @@ Additional ClayRat commands map the environment and keep C2 resilient:
- `get_cam` / `get_camera` capture front-camera stills, while `get_keylogger_data` serializes lock PINs plus passwords, view descriptions and hints scraped from sensitive fields.
- `get_proxy_data` fetches a proxy WebSocket URL, appends the unique device ID and spins a job that tunnels HTTP/HTTPS over the same bidirectional channel (T1481.002 / T1646).

### 8. Accessibility-assisted dropper chains & silent install

BTMOB-style campaigns wrap the commercial RAT inside an innocuous decoy (streaming app, productivity tool, etc.) bundled as `Dropper.zip`. The decoy hosts the real payload under `/assets/APK.zip` (or similar) and abuses Accessibility to bootstrap everything:

1. First launch displays a fake rationale ("enable Accessibility to unlock premium gestures/automation") and registers the rogue service.
2. When `onAccessibilityEvent()` confirms the service is active, the dropper copies the embedded APK to private storage and fires the stock package installer. Accessibility macros then `dispatchGesture()` through every prompt (*Install*, *Allow from this source*, runtime permission dialogs) and can even open Settings → Notification access / Battery optimization / Overlay lists to flip the associated toggles.
3. The operator keeps the decoy running in the foreground so the user only sees benign content while stage two gains persistence.

```java
private void deployStageTwo(Context ctx) throws IOException {
File apk = new File(ctx.getCacheDir(), "stage2.apk");
try (InputStream in = ctx.getAssets().open("payload.apk");
OutputStream out = Files.newOutputStream(apk.toPath())) {
in.transferTo(out);
}
Uri uri = FileProvider.getUriForFile(ctx, ctx.getPackageName()+".provider", apk);
Intent install = new Intent(Intent.ACTION_VIEW)
.setDataAndType(uri, "application/vnd.android.package-archive")
.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION | Intent.FLAG_ACTIVITY_NEW_TASK);
ctx.startActivity(install);
}
```

Once the second stage is installed it registers its own Accessibility service plus device-admin receivers, pulls campaign config from the C2 and optionally uninstalls the decoy to reduce noise. Because every step is UI-driven, Play Protect and MDM agent prompts are handled the same way as banking-app automation, yielding a "silent" full-RAT deployment without requesting `REQUEST_INSTALL_PACKAGES`.

---

## PlayPraetor – command & control workflow
Expand All @@ -201,26 +232,22 @@ Additional ClayRat commands map the environment and keep C2 resilient:

The **AccessibilityService** is the local engine that turns those cloud commands into physical interactions.

---
## Accessibility RAT C2 fingerprints & RAaS implications

## Detecting malicious accessibility services
The leaked BTMOB backend exposes a repeatable blueprint that red-teamers can spot, hijack or reuse when they want ready-made Accessibility infrastructure:

* `adb shell settings get secure enabled_accessibility_services`
* Settings → Accessibility → *Downloaded services* – look for apps that are **not** from Google Play.
* MDM / EMM solutions can enforce `ACCESSIBILITY_ENFORCEMENT_DEFAULT_DENY` (Android 13+) to block sideloaded services.
* Analyse running services:
```bash
adb shell dumpsys accessibility | grep "Accessibility Service"
```
- **Path grammar:** every deployment exposes `/yaarsa/user/` (operator login/token exchange), `/yaarsa/private/yarsap_<random>.php` (bot task routers) and `/yaarsa/private/updates/` (release notes, archive passwords). Brute-forcing any of these scripts with dummy parameters returns `{"Fail":"\"Invalid request.\""}`, which makes mass-scanning trivial—once you get that response you know you located a compatible panel.
- **Service stack:** Apache 2.4.52 + PHP 8.1.x on 80/443 serves both the web panel and REST APIs, MariaDB listens on 3306, Node.js/Express on 3000 handles builder uploads, and a dedicated WebSocket daemon on 8080 brokers commands like `brows`, `screen`, `ject` and `wrk`. The same Windows host usually exposes RDP (3389) plus RPC high ports, so compromising one service often yields full panel access.
- **Builder coupling:** the Windows GUI (BTMob.exe) simply wraps these endpoints—operators log in with email/password + a token fetched from `/yaarsa/user/`, then the GUI multiplexes WebSocket frames (screen video, harvested creds, file listings) while relaying commands. Because the "builder" archives merely ship apktool/signapk helpers that POST campaign parameters, stealing the backend credentials lets you compile/sign payloads for every tenant.

---
Fingerprinting tip for hijacking:

## Hardening recommendations for app developers
```bash
curl -k https://target.example/yaarsa/private/yarsap_status.php
# {"Fail":"\"Invalid request.\""}
```

* Mark sensitive views with `android:accessibilityDataSensitive="accessibilityDataPrivateYes"` (API 34+).
* Combine `setFilterTouchesWhenObscured(true)` with `FLAG_SECURE` to prevent tap/overlay hijacking.
* Detect overlays by polling `WindowManager.getDefaultDisplay().getFlags()` or the `ViewRootImpl` API.
* Refuse to operate when `Settings.canDrawOverlays()` **or** a non-trusted Accessibility service is active.
Any TLS endpoint that answers like above is almost certainly part of this RAaS family; enumerate the same host for 8080/3000/3306/3389, loot the panel database and you can impersonate existing operators or repurpose their bots without writing your own C2 stack.

---

Expand Down Expand Up @@ -316,11 +343,12 @@ Observed flows for MetaMask, Trust Wallet, Blockchain.com and Phantom:
## NFC-relay orchestration
Accessibility/RAT modules can install and launch a dedicated NFC-relay app (e.g., NFSkate) as a third stage and even inject an overlay guide to shepherd the victim through card-present relay steps.

Background and TTPs: https://www.threatfabric.com/blogs/ghost-tap-new-cash-out-tactic-with-nfc-relay
Background and TTPs: [GhostTap/NFSkate – NFC relay cash-out tactic (ThreatFabric)](https://www.threatfabric.com/blogs/ghost-tap-new-cash-out-tactic-with-nfc-relay)

---

## References
* [Inside BTMOB: An Analytical Breakdown of a Leaked Android RAT Ecosystem](https://www.d3lab.net/inside-btmob-an-analytical-breakdown-of-a-leaked-android-rat-ecosystem/)
* [Return of ClayRat: Expanded Features and Techniques](https://zimperium.com/blog/return-of-clayrat-expanded-features-and-techniques)
* [ClayRat v3 IoCs (Zimperium)](https://github.com/Zimperium/IOC/tree/master/2025-12-ClayRatv3)
* [PlayPraetor’s evolving threat: How Chinese-speaking actors globally scale an Android RAT](https://www.cleafy.com/cleafy-labs/playpraetors-evolving-threat-how-chinese-speaking-actors-globally-scale-an-android-rat)
Expand Down