Zimperium has published analysis of ToxicPanda 2.0, an Android banking trojan that has grown a great deal since it was first documented.

The numbers first: 167 remote commands, 349 targeted applications across banking, financial, cryptocurrency and e-wallet services, in 16 countries. A separate PIN-harvesting module aims at 140 financial apps.

But the technique worth understanding is not in that list.

It uses the VPN permission to blind Google

ToxicPanda 2.0 asks for the VPN service permission. Granted, it stands up a local network interface and starts intercepting and filtering the device's own traffic.

What it filters is the point. Per Zimperium, it blocks communication from Google Play and Google Play Services — and it does this before installing its payload. That means security updates cannot arrive and app verification cannot run at the moment they would matter most.

Android permits exactly one VPN at a time, by design, and a VPN sees everything. So the permission that exists to protect your traffic is also the permission that lets something sit between your phone and the service that would have told you it was there.

This is the week's third defence-blinding story

Not a coincidence, and worth naming as a pattern.

UAT-10147's SPECTRE implant unlinks EDR callbacks in the Windows kernel so security products stop being notified rather than stop running. A Defender driver can delete Defender at boot before it locks itself. And now a phone's VPN slot is used to cut the line to Play Protect.

None of these defeat the defence. They all remove its ability to see or report, which produces the same silence as an environment where nothing is wrong. That is the harder problem, because the absence of an alert is indistinguishable from safety.

Accessibility, converted into a shell

The second technique is the sharper one.

ToxicPanda 2.0 uses Accessibility Services permissions to turn on Wireless Debugging and extract the ADB pairing code. That hands it Android Debug Bridge access — shell-level control of the device.

Zimperium's description of why this matters is exact: it bypasses standard Android runtime consent prompts, granting broad permissions and disabling background restrictions without the dialogs a user would normally see and could normally refuse.

So one permission that people are routinely talked into granting — Accessibility is requested by screen readers, automation tools and a great many things pretending to be them — is converted into a level of access the operating system would never grant through its own prompts.

What else it does

  • Invisible phishing overlays that capture touch input on top of real apps
  • Fake lock screens and update overlays
  • PIN harvesting aimed at 140 financial apps
  • Manufacturer-specific persistence techniques, tailored per device maker

The overlay work is the same family as the fake Windows lock screen SynkLoader paints — except a phone has no Alt+Tab, and no equivalent of the Secure Attention Sequence to prove a screen is genuine.

Where it comes from

Distribution runs through Amazon AWS-hosted buckets, which is the mobile version of the pattern in almost every campaign this month: host on infrastructure nobody can block, and the download is unremarkable.

Zimperium has published indicators of compromise on GitHub.

What to do

  • Look at which apps hold VPN permission. Settings will show what is running a VPN. If it is something you did not knowingly install as a VPN, that is the finding — and it is checkable in under a minute.
  • Audit Accessibility Services the same way. Almost nothing on a normal phone needs it. Anything there that you cannot justify should be removed, not merely disabled.
  • Check whether Wireless Debugging is on. It is in Developer Options and it should be off. If Developer Options is enabled and you did not enable it, treat that as a compromise indicator.
  • Install banking apps only from the Play Store, and only from the bank's own link. Sideloading is the entry point this whole class depends on.
  • If Play Protect appears broken or Play Services keep failing, do not dismiss it. That symptom is the attack here, not an inconvenience.
  • A factory reset is the honest remediation if you find any of the above. Manufacturer-specific persistence is not something to clean by hand.

What is not established

  • Which 16 countries. Not enumerated in the reporting we have seen.
  • How many devices are infected. No victim count published.
  • Who operates it. No attribution stated.
  • Whether Google has shipped a mitigation for the VPN-blocking behaviour. Nothing announced.