From 6214732d5766858256ddc1a24b1731c9bafc6eb1 Mon Sep 17 00:00:00 2001 From: HackTricks News Bot Date: Thu, 20 Aug 2026 12:51:31 +0000 Subject: [PATCH] Add content from: ToxicPanda Never Sleeps: ToxicPanda 2.0 Prepares Its Next Mo... --- .../android-app-pentesting/shizuku-privileged-api.md | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/src/mobile-pentesting/android-app-pentesting/shizuku-privileged-api.md b/src/mobile-pentesting/android-app-pentesting/shizuku-privileged-api.md index ebdb72ed632..257d1d3b383 100644 --- a/src/mobile-pentesting/android-app-pentesting/shizuku-privileged-api.md +++ b/src/mobile-pentesting/android-app-pentesting/shizuku-privileged-api.md @@ -190,12 +190,17 @@ If you are specifically testing work-profile bypasses or required-app replacemen [Android Enterprise Work Profile Required-App Replacement](android-enterprise-work-profile-bypass.md) #### Accessibility-assisted local Wireless ADB pairing and Shizuku-style helpers + +Android 11+ supports Wireless Debugging pairing by code, and the paired host remains authorised until the user forgets it or revokes ADB debugging authorisations.[[6]](#references) + Some Android RATs now replicate the **Shizuku architecture** instead of waiting for the user to start Shizuku explicitly. The interesting part is the **attack chain**, not Shizuku itself:[[4]](#references) 1. A rogue [Accessibility service](accessibility-services-abuse.md) navigates Settings, taps the build number seven times, enables **Developer Options -> Wireless debugging**, opens **Pair device with pairing code**, and reads the code directly from the UI tree while an overlay hides the workflow. 2. An embedded ADB client then pairs with the same handset's own `adbd` over **`127.0.0.1`**, so the phone becomes both the **ADB host and target** with no PC or USB cable involved. 3. After pairing, the malware launches a helper process under **UID 2000 (`shell`)** and talks to it over **Binder IPC** exactly like a Shizuku-enabled app would talk to a shell-backed UserService. +A protocol-level variant automates the pairing dialog itself: Accessibility launches `Settings.ACTION_APPLICATION_DEVELOPMENT_SETTINGS`, enables Wireless Debugging, and polls the **Pair device with pairing code** modal for both its dynamic port and six-digit secret. An embedded client then connects to `127.0.0.1:`, establishes TLS, performs the PIN-backed SPAKE2 exchange, authenticates its generated ADB key pair, exchanges peer metadata, and finally submits ADB commands in the `shell` context. This is **not root**, and the exact post-pairing commands must be recovered from the sample or runtime traffic because the public analysis did not publish them.[[7]](#references) + That gives the malware a non-root but still highly privileged execution context that can usually: - run arbitrary shell commands as `uid 2000` @@ -239,7 +244,8 @@ The same design is also a good detection model: watch for **Shizuku-authorised a 3. Capabilities are limited to what the current backend has. On ADB-backed sessions, that means the effective attack surface is the one exposed to **`com.android.shell`** on that Android build, plus whatever SELinux permits. 4. A normal Shizuku session does **not** survive a reboot unless the device is rooted and Shizuku is configured as a startup daemon. However, malware that stores ADB pairing keys and can re-enable Wireless Debugging (for example via Accessibility + `WRITE_SECURE_SETTINGS` / `Settings.Global` abuse) may reconnect to local `adbd` after boot and recreate the shell helper without root. 5. High-signal detection ideas for this abuse chain: - - local ADB traffic or pairing attempts against **`127.0.0.1`** + - correlate Accessibility-driven taps on **Build number**, an `APPLICATION_DEVELOPMENT_SETTINGS` launch, Wireless Debugging activation, and immediate scraping of a six-digit pairing modal; this sequence is much stronger than any event alone.[[7]](#references) + - local ADB TLS/SPAKE2 traffic or pairing attempts against **`127.0.0.1`**, especially to a port just read from the Settings UI.[[7]](#references) - shell-owned helper processes spawned from an app workflow (for example a native library acting as a local privileged server) - unexpected writes to `Settings.Secure` / `Settings.Global` or silent grants of `WRITE_SECURE_SETTINGS` - suspicious `BOOT_COMPLETED` receivers that restore debugging state or reload stored ADB keys @@ -262,5 +268,7 @@ The same design is also a good detection model: watch for **Shizuku-authorised a - [3] [awesome-shizuku - list of supported apps](https://github.com/timschneeb/awesome-shizuku) - [4] [RedHook Returns with a Dangerous Upgrade](https://www.group-ib.com/blog/redhook-android-rat-upgraded/) - [5] [Root My Pixel: Automated Temporary Root and KernelSU Late Loading on Google Pixel Devices](https://github.com/alex193a/Root-My-Pixel) +- [6] [Android Debug Bridge: Connect to a device over Wi-Fi](https://developer.android.com/tools/adb#connect-to-a-device-over-wi-fi) +- [7] [ToxicPanda Never Sleeps: ToxicPanda 2.0 Prepares Its Next Mobile Strike](https://zimperium.com/blog/the-toxicpanda-never-sleeps-toxicpanda-2.0-prepares-its-next-strike-on-mobile) {{#include ../../banners/hacktricks-training.md}}