you are on the clearnet. the addresses listed here only open inside the tor network - download the tor browser here »
AlphaBay.Market
last update: 1 min ago 255 onions tracked
home / news / security
24 August 2026 security 4 min read

ToxicPanda 2.0 expands to 349 apps and blocks Google Play via VPN permissions

The Android banking trojan ToxicPanda has received a substantial update. According to research published by Zimperium (full report here) and covered by BleepingComputer, version 2.0 of the malware now targets 349 applications with phishing overlays, supports 167 remote commands, and abuses Android's VPN service permission to block the device's own access to Google Play and Play Services while the infection is underway.

What the new version does

The headline numbers come from Zimperium's analysis of recent samples. The overlay set covers banking, financial, cryptocurrency and e-wallet applications across 16 countries, and a separate PIN-harvesting module targets 140 financial and crypto apps with a target list that can be updated dynamically. The overlays are rendered invisibly over legitimate apps so that the malware can capture touch input without the victim noticing anything unusual. ToxicPanda 2.0 also spoofs the Android lock screen to capture device PINs, patterns and passwords, and some samples present fake system update screens to disguise ongoing malicious activity. Perhaps more notably, the malware automates abuse of Android's Wireless Debugging Bridge: using Accessibility Services it enables developer options, activates wireless debugging, extracts the six-digit pairing code and connects to the local ADB service. Once it holds shell-level permissions it can grant itself broad privileges, neutralise background restrictions and enforce persistence while bypassing normal runtime consent prompts.

The VPN trick: locking the door behind itself

The most interesting defensive measure is the abuse of the VPN service permission. After obtaining it, the malware creates a local network interface through which it can control traffic, and uses that position to block communications to Google Play and Google Play Services before extracting and installing its payload. The practical effect is that the infected device cannot reach app verification checks, Play Protect communication or security-related updates at exactly the moment they would matter most. A victim who becomes suspicious and tries to look up protection tools or check an app's legitimacy finds the store unresponsive. Zimperium reports that distribution currently runs through Amazon AWS-hosted buckets, which lends the campaigns a degree of ordinary-looking infrastructure. A persistence command called autoBoot identifies the device manufacturer and opens the corresponding OEM-specific auto-start or power management settings on Xiaomi, OPPO, Vivo, Samsung and Huawei devices, defeating battery optimisation features that would otherwise kill background processes.

Where ToxicPanda came from

ToxicPanda is not new. It was first documented by Cleafy in late 2024 as a banking trojan hitting Europe and Latin America, performing on-device fraud: attackers remotely operate the compromised device and initiate transfers while intercepting SMS and authenticator-app one-time codes to defeat two-factor authentication. Cleafy noted significant command overlap with the older TgToxic family and judged that the operators were likely Chinese speakers; later analysis added a domain generation algorithm and shifting targeting, with a 2025 study by BitSight observing heavy focus on Portugal and Spain. It belongs to a broader wave of mobile banking threats. ThreatFabric's reporting on Crocodilus, a separate but contemporaneous family, describes the same template: accessibility-service abuse, overlay credential theft, remote control and OTP harvesting, built from the start to be productised. Whether any given family is sold outright or rented, the pattern is the same and ToxicPanda fits it closely.

The trojan-as-a-service economy

Families like ToxicPanda are commodities. On underground forums, developers sell or rent the malware alongside a web panel for managing bots, overlay packs, build services and ongoing updates, while affiliates handle distribution through smishing and social engineering pages that impersonate app store listings. The buyer does not need to write code; the barrier to running a mobile fraud operation is the price of a subscription plus some patience with spam infrastructure. Each capability added in version 2.0 — the VPN-level blocking, the ADB shell access, the OEM-specific persistence — is a feature update in a commercial product roadmap, not the work of a single bespoke operator.

A short mobile opsec checklist

For readers whose threat model includes smishing-driven malware, the fundamentals still hold:
  • Never install APKs from links received by SMS, messaging apps or lookalike store pages; if you did not seek the app out, do not install it.
  • Treat requests to enable Accessibility Services or VPN permissions as red flags. A legitimate app rarely needs either, and this malware needs both.
  • Keep Google Play enabled rather than disabling Play Protect, and leave developer options and wireless debugging off unless you actively use them.
  • If your bank offers it, prefer a hardware key or an authenticator on a separate device over SMS codes.
  • Use unique credentials per financial service so one compromise does not cascade — our guide on unique logins and password hygiene covers the basics.
Indicators of compromise for the current version have been published by Zimperium in a public GitHub repository for defenders who want to check their environments.

more notes

all news ›