Researchers at Group-IB have detailed a significant upgrade to RedHook, an Android banking trojan first documented by Cyble in 2025 as a threat targeting users in Vietnam. The malware's newest version no longer needs a computer or a USB cable to gain deep control of an infected phone — it grants that access to itself.
RedHook still spreads the old-fashioned way: a phone call or message impersonating a government agency or bank, steering the victim to a fake Google Play page. Once installed, it asks for Accessibility permission — the same "helper" permission legitimate screen-reader and automation apps use — and abuses it to silently open Android's own settings, turn on Developer Options, and switch on Wireless Debugging. It then reads the pairing code shown on screen and connects to the phone's own debugging service over its loopback address, with no external device involved. That sequence hands the malware shell-level privileges (UID 2000) — short of full root, but far beyond a normal app's reach: installing or removing other apps, changing protected system settings, and running commands, all without a single permission prompt appearing. From there it behaves as a standard remote-access trojan — streaming the screen, logging keystrokes, and lifting saved credentials and the device's own screen-lock code. Group-IB also found the malware has expanded its targeting beyond Vietnam into Indonesia, pointing to a broader push across Southeast Asia.
What this means for your business
RedHook goes after personal banking apps directly, but the access pattern — a phone tricked into silently escalating its own privileges — matters to any business where staff use personal or company Android phones for work logins, approvals, or one-time codes:
- Install apps only from the Google Play Store itself, never from a link in a message or call — RedHook's entire infection chain depends on a fake Play page.
- Treat any app that requests Accessibility permission with real suspicion unless it's a screen reader or automation tool you specifically installed for that purpose; it's the one permission this whole chain depends on.
- If Developer Options or Wireless Debugging turn on by themselves, or you don't recognise enabling them, treat the phone as compromised — disable them in Settings, run a security scan, and change passwords from a separate device.
- If your business issues Android phones to staff, a basic mobile device policy that blocks sideloading and flags Developer Options being switched on is a cheap, one-time fix for this entire attack class.
None of this requires new tooling — it's awareness plus a couple of settings checks. The phones your team already carries are a route into company accounts, and social engineering, not clever code, is still the way in.