RedHook malware turns on your phone's Wireless Debugging to stream your screen — and it never touches the consent dialog

On July 9, Group-IB published an analysis of a new build of the Android trojan RedHook, and it contains a first: the malware turns on Wireless Debugging on the victim's own phone and uses it to give itself shell-level privileges — no PC, no USB cable, no root, no exploit. (Group-IB's writeup; BleepingComputer's summary.) The part that should interest anyone who builds or uses a camera app is buried in the capability list. RedHook streams the victim's screen. And once it holds shell privileges, it streams over RTMP, capturing the screen directly — bypassing the MediaProjection API and its mandatory consent dialog. That is worth sitting with. The consent dialog is the thing Android shows you so that screen capture cannot happen silently. RedHook does not defeat it. It goes around it. What actually happens There is no clever zero-day here, which is what makes it worth writing about. The chain is entirely made of legitimate parts: A victim gets a phone call or a message from someone impersonating a bank or a government office, and is walked to a site built to look like the Play Store. They sideload the APK. The app runs a guided walkthrough that convinces them to enable the Accessibility Service, framed as a necessary step to "enable full features." With Accessibility, the malware drives the Settings UI itself — taps the build number seven times to unlock Developer Options, opens Wireless Debugging, hits "Pair device with pairing code," and reads the pairing code off the screen. A full-screen overlay hides all of it. It embeds an ADB client, connects to the phone's own ADB daemon over loopback (127.0.0.1), and comes up as uid 2000. Step 5 borrows from Shizuku, the well-known open-source tool that enthusiasts use to grant apps elevated permissions without rooting. Group-IB's phrasing is precise: "There is no exploit here, 'merely' turning a debugging interface into a path to shell-level privileges." From uid 2000 the app can grant itself runtime permissions, run shell commands, write to Settings.Secure, silently install and uninstall packages, and capture low-level touch events. The current build supports 53 distinct server-issued commands. It also holds on hard: a 1×1-pixel activity to look like a foreground process when the screen is off, silent audio via MediaSession, a WakeLock, two services in separate processes that resurrect each other via bindService() with BIND_AUTO_CREATE, an oom_score_adj of −1000, and a BOOT_COMPLETED receiver that re-enables Wireless ADB and restores the privileged helper within seconds of power-on. Active campaigns are targeting Vietnam and Indonesia. The technique is not regional. Why this matters beyond banking trojans The instinct after a story like this is to distrust the capability. Screen streaming is scary, so screen streaming is bad. Remote camera access is scary, so remote camera access is bad. That reading is wrong, and following it makes you less safe rather than more. RedHook is not dangerous because it streams. It is dangerous because it acquired unaccountable privilege — permission that the user cannot see, did not knowingly grant, and cannot easily revoke. The streaming is a symptom. The disease is a permission model that got escalated behind an overlay. There are entirely legitimate reasons to want a phone to send video somewhere while its screen is off: watching a pet, keeping an eye on a doorway, running a second-angle camera, monitoring a workshop. The question is never does this app stream? It is who can start it, who can see it, and where does it go? What to actually check on your phone Independent of any product, do these now. They take under two minutes. Settings → System → Developer options → Wireless debugging. If you did not deliberately turn this on, turn it off. If Developer Options is enabled and you never enabled it, that is a signal in itself. Settings → Accessibility. Read the list of apps with the Accessibility Service. This is the single most abused permission on Android. A camera app, a flashlight, a file manager, a game — none of these have any business here. Accessibility exists for screen readers and switch access. Check what can install packages. Settings → Apps → Special app access → Install unknown apps. Sideload nothing you did not go looking for. Every RedHook infection starts with an APK from a site that looks like the Play Store but is not. Group-IB's own end-user guidance leads with the same point: be on extreme alert when an application requests the Accessibility Service. The standard a camera app should be held to We build Background Camera RemoteStream, an Android app for recording and live-streaming from a phone with the screen off. So we have an obvious interest here, and you should read the next paragraph with that in mind. The honest version of our pitch is not "trust us." It is that the design choices worth demanding are checkable ones: Footage stays on the device. Recordings are stored locally. There is no cloud pipeline that has to be trusted, because there is no cloud pipeline. No account. No sign-up means no credential to phish, no server-side profile, no password reuse blast radius. Distribution through Google Play only. If you are ever asked to sideload our APK from a site that looks like the Play Store, that site is not us. Streaming goes where you point it. YouTube Live is your own destination on your own account, not an intermediary we operate. None of that is exotic. It is the baseline, and the useful takeaway from RedHook is that you should ask any camera app on your phone to meet it — ours included. We wrote more about the pattern across the category in an analysis of nine Android camera apps, and about the no-cloud approach in this baby monitor walkthrough. The uncomfortable part for developers Shizuku is a good tool. Wireless ADB is a good feature. Accessibility is load-bearing for people who genuinely need it. RedHook did not break any of them — it assembled them. That is the durable lesson. The Android security model increasingly depends on a user correctly evaluating a permission prompt while an attacker is on the phone with them, actively coaching them through it. Consent dialogs are a real protection and RedHook still routed around the screen-capture one by climbing to a privilege level where the dialog does not apply. Treat Accessibility and Wireless Debugging as high-value abuse vectors, as Group-IB puts it. And if you ship an app that touches the camera, the microphone, or the screen, assume your users have just read a story like this one — and make the permissions you request small enough to defend line by line. Background Camera RemoteStream — background recording and live streaming from an Android phone, local storage, no account required. Google Play · superfunicular.com Source: RedHook Returns with a Dangerous Upgrade, Group-IB, July 9, 2026.