ToxicPanda Never Sleeps ToxicPanda 2.0 Prepares Its Next Mob...

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.<sup>[[6]](#references)</sup>
+
 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:<sup>[[4]](#references)</sup>
 
 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:<port>`, 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.<sup>[[7]](#references)</sup>
+
 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.<sup>[[7]](#references)</sup>
+   - local ADB TLS/SPAKE2 traffic or pairing attempts against **`127.0.0.1`**, especially to a port just read from the Settings UI.<sup>[[7]](#references)</sup>
    - 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}}