Skip to content
feed: live
>_ 0dayNews
mobile

RedHook Android RAT pairs Wireless ADB on-device

Group-IB details RedHook using Accessibility to enable Wireless Debugging, pair over loopback, and run shell as uid 2000. No CVE. Southeast Asia targeted.

RedHook Android RAT pairs Wireless ADB on-device
Photo: GK tramrunner at English Wikipedia / Wikimedia Commons · CC BY-SA 3.0
fuse Marisol "Fuse" Delgado · Published · 3 min read

Group-IB published a new RedHook writeup on 2026-07-09 and BleepingComputer picked it up today. What is worth acting on: this is not a bug and there is no CVE. RedHook abuses an Android feature — Wireless Debugging — by pairing the phone to itself over the loopback interface, and there is no patch coming for that on your calendar.

What actually changed

Group-IB attributes the trick to a new RedHook variant. The chain, as reported: the malware talks the user into granting the Accessibility Service, then drives Settings on their behalf — flipping Developer Options on, toggling Wireless Debugging, reading the pairing code Android displays on-screen, and connecting to the device’s own ADB daemon at 127.0.0.1. From there it runs a Shizuku-based helper as uid 2000 (shell), which is enough to grant itself WRITE_SECURE_SETTINGS, install and remove packages, and execute arbitrary shell commands.

Group-IB’s phrasing: “The device can be its own host. The malware embeds its own ADB client and connects to the device’s daemon over the loopback interface (127.0.0.1), so that the whole ADB flow runs on-device.” That is not a bug in Android’s implementation. Wireless Debugging shipped in Android 11 and has always let you pair over the network — this campaign just found a way to be both endpoints on the same phone, driven by the Accessibility Service. Group-IB flags it as the first time it has watched malware use Wireless Debugging that way in the wild.

No root is required. Group-IB does not name a CVE and I would not expect one; there is no vendor bug here to file.

Group-IB reports the campaign hitting Vietnam and Indonesia so far, distributed via phone-call and messaging phishing that impersonates government agencies or banks and steers victims to lookalike Play sites. Everything after the Accessibility grant runs under a full-screen overlay while a 1×1-pixel invisible activity keeps the malicious UI alive in the background.

Why the “no CVE” shape matters for defenders

If you’re waiting on a Play Protect signature or a Google patch note, you’ll be waiting a while. This is a permission-hygiene problem shaped like a malware campaign, not a patch-Tuesday problem. Two knobs matter, and they’re both administrative:

  • Accessibility Service grants are the entire social-engineering gate. Once granted, the user is not going to see the rest of the chain — the overlay is there specifically to hide it.
  • Wireless Debugging being on at all on a device the user did not personally enable it on is an anomaly. It requires Developer Options, which requires seven taps on the build number. If your fleet’s not doing app development, this being on is a signal by itself.

What to actually do

  • Enumerate Accessibility Service grants across your managed Android fleet. Anything not shipped by an app you deployed should not be on that list. This is the highest-value single check for the RedHook chain and every accessibility-abusing Android RAT that came before it — RedWing, GodFather, TrickMo, Anatsa.
  • Alert on Developer Options → Wireless Debugging being enabled. MDMs that expose the development_settings_enabled and adb_wifi_enabled secure settings can pull this. Anything non-zero on a device that never had a developer on it is worth a look.
  • Disable sideloading at policy. RedHook is distributed through fake Play sites, not Play itself. Blocking unknown-sources install is the mitigation upstream of every other check on this list. Confirm Play Protect is on and left on.
  • Brief users on the specific phishing shape: a phone call or message impersonating a government agency or bank that ends with a link to what looks like Google Play. If the Play page is not play.google.com, it is not Play.
  • Hunt on the IOCs Group-IB published: APK SHA-256 453333bffdd1850ea2e0647f7c805530b578919978a01b1e2be52d6eb2add946, C2 endpoints api.3n7wj[.]com and wss://skt.3n7wj[.]com / wss://sktv.3n7wj[.]com. Vietnam- and Indonesia-facing environments first, but the pattern travels.

Patch this behavior into your Android MDM baseline before you touch anything else in your mobile queue this week. Deprioritize a signature-based response; a signature will miss the next variant, the Accessibility + Wireless Debugging shape probably won’t.

The honest timeline

  • July 2025 — RedHook first documented, attributed by Cyble.
  • 2026-07-09 — Group-IB publishes the upgraded-variant blog with the Wireless ADB chain, IOCs, and the Vietnam/Indonesia targeting note.
  • 2026-07-12BleepingComputer picks it up. Google has said nothing publicly about tightening the Wireless Debugging pairing UX.
  • Now — no CVE, no vendor patch expected, no Play Protect coverage claim. Defense is administrative.

Sourcing

Found this useful? Share it.