Skip to content

Total Takeover DroidLock Hijacks Your Device #1666

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

Total Takeover DroidLock Hijacks Your Device #1666

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
54 changes: 54 additions & 0 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 @@ -203,6 +203,58 @@ The **AccessibilityService** is the local engine that turns those cloud commands

---

## DroidLock: Accessibility + Device Admin ransomware workflow

### Staged delivery to keep abusing Accessibility
* **Dropper ➜ payload**: DroidLock first sideloads a seemingly harmless APK that only asks for `BIND_ACCESSIBILITY_SERVICE`. Once the victim turns the service on, the dropper installs/launches the second stage despite recent Android fraud mitigations because every subsequent dialog (install unknown apps, notification access, default SMS app, microphone, contacts, etc.) is automatically confirmed through synthetic `performGlobalAction()` clicks.
* **Permission chaining**: The second stage immediately enables `NotificationListenerService`, SMS/contacts/call-log access and microphone/screen-capture prompts without further human input, giving the operator the same reach as a fully privileged user-mode agent while staying inside sanctioned APIs.

### Package-aware overlays and pattern theft
DroidLock subscribes to `AccessibilityEvent.TYPE_WINDOW_STATE_CHANGED`, correlates the foreground package with two C2-managed lists and reacts instantly:

```java
@Override
public void onAccessibilityEvent(AccessibilityEvent event) {
if (event.getEventType() != AccessibilityEvent.TYPE_WINDOW_STATE_CHANGED) return;
String pkg = String.valueOf(event.getPackageName());
if (lockTargets.contains(pkg)) { showPatternOverlay(patternLayout); return; }
String html = overlayDb.get(pkg);
if (html != null) showWebViewOverlay(html);
}
```

* **`APP_BLOCK_LOCK_PATTERN`** pushes package names that should trigger a pre-built 3×3 pattern layout stored under `assets/`, allowing attackers to harvest the unlock gesture in front of the real banking/app screen.
* **`INJECT_APP`** keeps a local database that maps package⇢HTML templates, so the RAT can instantly launch a full-screen WebView phishing overlay for any targeted brand (bank, telco, enterprise app) without shipping a new APK.
* **Fake update blockers**: `BLACK_SCREEN` and `BLACK_SCREEN_UPDATE_SYSTEM` commands render opaque overlays that either mimic an OS update or a powered-off display, keeping the victim idle while ATS routines steal data underneath.

### DevicePolicyManager-backed lockout pressure
Once the operator fires the `DEVICE_ADMIN` command and the user grants it, DroidLock weaponises the legitimate `DevicePolicyManager` API:

* `BLOCK_BIOMETRIC` calls `setKeyguardDisabledFeatures()` to disable biometric/PIN unlocks so overlays can coerce the victim to re-enter PINs/patterns.
* `RANSOMWARE` spawns a WebView-based ransom note that blocks the UI for 24 hours unless the victim emails the attacker; the threat is credible because `WIPE` calls `dpm.wipeData(0)` and `lockNow()` can immediately brick access.
* `APP_BLOCK` lets the C2 specify packages that should be instantly covered/closed, usually AV, MDM or banking apps, while `UNINSTALL_APP` issues silent removals of supplied package names.

The result is ransomware without encryption—Device Admin alone provides screen locks, forced credential resets and remote factory resets that keep the victim locked out until the ransom is paid.

### WebSocket orchestration with a 15-command dictionary
After an initial HTTP registration (device fingerprint, geodata, installed apps), DroidLock upgrades to a bidirectional WebSocket session used for real-time tasking:

* **Privilege & lockdown**: `DEVICE_ADMIN`, `BLOCK_BIOMETRIC`, `WIPE`, `TURNSCREENON`.
* **Deception & phishing**: `RANSOMWARE`, `BLACK_SCREEN*`, `NOTIFICATION` (spoof arbitrary notifications), `INJECT_APP`.
* **Overlay targeting**: `APP_BLOCK`, `APP_BLOCK_LOCK_PATTERN` keep overlay target lists fresh without redeploying the client.
* **Remote control**: `VNC` toggles continuous input replay, `TURNSCREENON`/`screen_on` keep the display awake, `MUTE` silences the device, `CAMERA` captures stills, and `UNINSTALL_APP` removes defensive packages.

Because the channel is persistent, operators can orchestrate complete on-device fraud loops (open bank app ➜ inject overlay ➜ intercept OTP ➜ dismiss alarms) with desktop-like latency.

### Screen streaming + notification harvesting
* The `RANSOMWARE`/`VNC` flows reuse Accessibility to accept the MediaProjection consent dialog, spin up a `VirtualDisplay`, capture frames as JPEG, base64-encode them and exfiltrate them over the WebSocket feed, effectively turning the handset into a VNC endpoint.
* A bundled `NotificationListenerService` tied to the same command channel dumps OTP/2FA notifications via `NOTIFICATION`/`notifications` commands and can craft arbitrary push lures to nudge the victim into sensitive workflows.
* `TURNSCREENON`, `screen_on` and `screen_tap` ensure the attacker can wake the panel, inject gestures and watch the result even if the victim tries to power the device off.

Zimperium also published the associated [IOC set for DroidLock](https://github.com/Zimperium/IOC/tree/master/2025-12-DroidLock), which documents the observed APK hashes, overlay templates and C2 infrastructure that implement the workflow above.

---

## Detecting malicious accessibility services

* `adb shell settings get secure enabled_accessibility_services`
Expand Down Expand Up @@ -321,6 +373,8 @@ Background and TTPs: https://www.threatfabric.com/blogs/ghost-tap-new-cash-out-t
---

## References
* [Total Takeover: DroidLock Hijacks Your Device](https://zimperium.com/blog/total-takeover-droidlock-hijacks-your-device)
* [DroidLock IoCs (Zimperium)](https://github.com/Zimperium/IOC/tree/master/2025-12-DroidLock)
* [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