DEV Community

Anoymask
Anoymask

Posted on

ToxicPanda 2.0 Chains VPN, Accessibility, and ADB

#security #threatintel

1. Basic Information

2. Executive Summary

ToxicPanda 2.0 is an Android banking malware. It uses fake installation screens to gain VPN and Accessibility permissions. Then, it automatically operates Android settings to connect to the local ADB daemon. Without rooting the device, it uses shell privileges to change settings and add persistence. Finally, it steals financial information using Accessibility and fake screens or overlays.

3. Attack Flow

1. Distribution and Initial Setup

  1. The attacker uses Amazon Web Services storage to distribute ToxicPanda 2.0 samples. The specific method to trick users into downloading the file is not public.
  2. The dropper shows a fake installation screen and asks the user to allow an Android VPN connection.
  3. After permission is granted, the local VPN blocks network traffic to Google Play and Google Play Services.
  4. The dropper decrypts and installs an encrypted payload from its assets, then asks the user to enable the Accessibility Service.

2. Exploiting Wireless Debugging and ADB

  1. The Accessibility Service reads the Android settings screen. If Developer Options are disabled, it automatically taps "Build number" seven times to enable them.
  2. It goes to the Wireless Debugging screen, enables the feature, and opens "Pair device with pairing code."
  3. It uses Accessibility to read the six-digit pairing code and dynamic port shown on the screen.
  4. It uses this information to pair with the local ADB daemon listening on 127.0.0.1 using SPAKE2/TLS.
  5. It gains ADB shell user privileges. Then, it runs commands to grant runtime permissions, relax background limits, enable necessary components, and establish persistence. The report does not mention root access.

3. Financial Information Theft and Remote Control

  1. It sends the package names and icons of installed apps to the C2 server to identify target financial apps.
  2. When the user opens a target app, the C2 server sends a fake HTML screen. The malware displays this screen over the real login or transaction screen.
  3. It uses a transparent overlay to catch touch positions and steal the PIN of the financial app. Another fake lock screen steals the device PIN, pattern, and password.
  4. After the first HTTPS request, it keeps an encrypted WebSocket connection open to receive commands from the C2 server and send back collected data.
  5. It has 167 remote commands implemented. It can take screenshots, simulate input, steal SMS and contacts, install APKs, and request Device Administrator rights. However, this does not mean attackers used all commands in real attacks.

4. Attacker Position and Execution Location

  • Attackers operate distribution infrastructure and C2 servers on the internet to send commands to infected devices.
  • The dropper, payload, Accessibility screen operations, and ADB client run on the victim's Android device.
  • The ADB connection does not connect directly to a debug port from the outside. The malware connects to the ADB daemon running locally at 127.0.0.1 on the same device.
  • The malware only gains Android shell user privileges. Initial reports do not show root access or kernel exploit usage.

5. Visibility for Victims and Administrators

Victims

  • A screen that looks like part of the installation asks for VPN permissions. Then, the app asks to enable the Accessibility Service.
  • The settings screen opens automatically, and Developer Options or Wireless Debugging might become enabled in a short time.
  • Financial apps and lock screens are replaced with fake screens that look real. Entered PINs and passwords are stolen.
  • A fake system update screen may appear in the front to hide actions happening in the background.

Administrators and SOCs

  • MDM and MTD tools can spot unauthorized app installations, unknown apps with VPN, Accessibility, or Device Administrator rights, and enabled Developer Options or Wireless Debugging.
  • On the network side, administrators may spot AWS distribution links, initial HTTPS traffic, long-running WebSockets, and traffic to IOCs.
  • Standard PC EDR solutions cannot see permission changes, screen overlays, or local ADB pairing inside an Android device.

6. Success and Failure Conditions

Success Conditions

  • The user downloads and runs a malicious APK from outside Google Play.
  • The user allows the dropper's VPN connection, and device defenses do not block the next payload.
  • The Accessibility Service is enabled, allowing the app to read settings and perform automatic actions.
  • Wireless Debugging on Android 11 or later is enabled, and the app reads the displayed pairing code and port.
  • The device can connect to the distribution infrastructure and C2 server.

Failure Conditions

  • MDM or device policies block apps from unknown sources, unauthorized VPNs, unauthorized Accessibility Services, and Developer Options or Wireless Debugging.
  • The user denies VPN or Accessibility requests and deletes the malicious app.
  • Google Play Protect or Mobile Threat Defense detects and isolates the dropper or the unpacked payload.
  • Network defenses block the distribution site, C2 server, and WebSocket traffic, stopping command retrieval and data exfiltration.

7. What Happens Upon Success

  • Login credentials, transaction PINs, and device lock credentials for financial, crypto, and payment apps are stolen.
  • ADB shell privileges bypass normal runtime permission prompts to change permissions, background behavior, and component settings.
  • Lists of installed apps, icons, screen contents, SMS messages, and contacts can be stolen.
  • Attackers can remotely control the device continuously via WebSockets and update target app lists or fake screens.
  • If Device Administrator is allowed, implemented commands might change screen lock settings to values chosen by the attacker. However, the article does not confirm real-world use of this command.

8. Observable Logs

Email

  • No email vector was described, and no related logs were identified.

Proxy / SWG / DNS

  • Access to AWS distribution URLs, domains, and IPs listed in Zimperium IOCs.
  • Traffic shifting from initial HTTPS to a persistent WebSocket connection.
  • Long-running WebSockets from Android devices that do not match normal business use.

Endpoint / EDR

  • Downloading and installing unauthorized APKs, and decrypting and unpacking payloads from assets.
  • VPN Service, Accessibility Service, and Device Administrator requests by unknown apps.
  • Enabling Developer Options and Wireless Debugging, followed by local ADB pairing.
  • ADB shell commands such as pm grant, changes to background limits, and component activation.
  • Fake login screens using WebView, transparent overlays, and fake lock screens.

Identity / IdP

  • Logins or transactions from unusual devices, locations, or IPs that follow the theft of financial service credentials and PINs on the device.
  • Although enterprise IdPs are not directly targeted, similar overlay theft cannot be ruled out if users enter corporate credentials on an infected device (Inference).

SaaS / Cloud

  • Access to AWS-hosted distribution sites. AWS usage itself is not malicious; correlation with IOCs, APK hashes, and device behavior is required.
  • MDM and MTD audit events for app inventory, permissions, security status, Developer Options, and USB or Wireless Debugging.

Network

  • HTTPS handshake and two-way WebSocket from the infected device to the C2 server.
  • Application data encrypted with AES-ECB. Network equipment alone may not be able to inspect contents inside TLS.
  • If traffic continues after matching an IOC, preserve connection destinations, timestamps, and traffic volume before isolating the device.

9. Attack Success Determination

  • Attack Attempt Observed (Success Unconfirmed): Only observed access to distribution URLs or APK downloads; app launch and permission grants are unconfirmed.
  • User Action Confirmed: Confirmed malicious APK launch, VPN connection allowed, or Accessibility Service enabled.
  • Initial Execution Confirmed: Dropper successfully decrypted, unpacked, and installed the payload from assets.
  • Malware Execution or Authentication Success Confirmed: Confirmed C2 WebSocket, Accessibility actions, Wireless Debugging pairing, or ADB shell access.
  • Information Theft or Session Compromise Confirmed: Credentials entered into fake screens, transmission of app lists, PINs, or lock credentials to C2, or unauthorized login/transactions using stolen data.
  • Lateral/Further Compromise Confirmed: Execution of remote commands such as additional APK installation, retrieval of SMS, contacts, or screens, Device Administrator abuse, or financial transaction manipulation.

10. Investigation Playbook

Trigger

  • MDM or MTD detects VPN, Accessibility, or Device Administrator permissions granted to an unknown Android app.
  • Developer Options or Wireless Debugging is unexpectedly enabled on a managed device.
  • Detection of traffic to Zimperium IOCs or suspicious long-running WebSockets.
  • User reports suspicious overlays on financial apps or lock screens.

Initial Verification

  • Identify device owner, model, Android version, management status, and the package name, signature, and hash of the detected app.
  • Map out the APK source, installation time, and the grant times for VPN, Accessibility, and Device Administrator.
  • Do not confirm infection based on IOC matches alone; verify payload unpacking, permission grants, C2, and ADB evidence step-by-step.

Device

  • Isolate the device from the network. If possible, keep the power on while preserving MDM/MTD telemetry and the app list.
  • Check VPN profiles, Accessibility Services, Device Administrator status, Developer Options, Wireless Debugging, and paired ADB keys.
  • Collect APKs, unpacked files, app data, settings changes, WebView caches, and notification/SMS/contact access logs.
  • Do not assume root access; distinguish between actions possible with an ADB shell user and actual modifications made.

Authentication and Cloud

  • List financial, crypto, email, and corporate SaaS accounts used on the device during the infection window.
  • Check for suspicious logins, sessions, MFA changes, transfers, and API operations. Revoke sessions and change credentials as needed.
  • Search MDM for other devices with the same app, certificate, hash, and permission configuration.

Post-Exploitation

  • Check for post-C2 actions such as screenshots, inputs, SMS/contact collection, APK installs, and Device Administrator activities.
  • Coordinate with financial institutions to check for transactions using stolen PINs and credentials.
  • Expand the investigation to other devices with the same distribution source, signature, or package name.

Containment

  • Isolate the device, and disable malicious VPNs, Accessibility Services, Device Administrators, and ADB pairing.
  • Revoke sessions for related accounts and change credentials and PINs from a clean device.
  • Follow organizational policy to wipe and re-enroll managed devices after preserving evidence. Do not assume simple app deletion removes settings changes or extra payloads.
  • Block IOCs in DNS, SWG, and MTD solutions, but do not block entire AWS infrastructure globally.

Severity Tiers

  • Contact with distribution site / APK download only
  • APK launch / VPN / Accessibility permitted
  • Payload unpacked / C2 established
  • Wireless Debugging paired / ADB shell obtained
  • Credentials / PINs / device info stolen
  • Remote control / fraudulent transactions / additional payload executed

11. Defense and Detection Ideas

Single Events

  • Accessibility Service or Device Administrator granted to an unauthorized app.
  • Wireless Debugging enabled and new ADB pairing created on a managed device.
  • Detection of hashes, domains, or IPs listed by Zimperium.
  • An unknown app creates a VPN profile and blocks Google Play traffic.

Time-Series Correlation

  • Unauthorized APK launch -> VPN allowed -> Google Play traffic stopped -> payload deployed -> Accessibility allowed.
  • Developer Options enabled -> Wireless Debugging enabled -> pairing screen displayed -> local ADB connection -> permission changes.
  • Financial app opened -> suspicious WebView/overlay -> C2 transmission -> abnormal login/transaction.

Threat Hunting Perspectives

  • Non-Google Play apps requesting VPN, Accessibility, and Device Administrator all together.
  • Accessibility events rapidly navigating settings screens and repeatedly tapping the Build number.
  • ADB pairing directed to the device's own loopback address, followed immediately by shell commands.
  • Behavior monitoring for target app lists and icons, followed by monitoring for financial app launches.
  • Android APKs with long-running WebSockets and static AES keys.

Log Gaps

  • BYOD devices often do not provide visibility into app permissions, Developer Options, Wireless Debugging, or local ADB actions.
  • Because HTTPS and WebSocket traffic are encrypted, network logs alone cannot determine commands or stolen data.
  • Android standard logs have a short retention period, requiring rapid evidence collection before device isolation.
  • Confirming financial fraud requires coordination with financial institutions and users outside the corporate SOC.

Priority Mitigations

  • Use MDM to restrict non-Google Play apps, unauthorized Accessibility Services, unauthorized VPNs, and Developer Options/Wireless Debugging.
  • Deploy Mobile Threat Defense to correlate APKs, permissions, overlays, ADB, and C2 on the device.
  • Educate users not to approve screens requesting VPN or Accessibility during app installation.
  • Use transaction verification, device binding, and phishing-resistant authentication for financial and corporate accounts.

12. Facts / Inference / Hypothesis

Facts

  • Zimperium reported that ToxicPanda 2.0 includes 167 remote commands and overlays targeting 349 financial, payment, and crypto apps.
  • The dropper requests VPN permissions, blocks traffic to Google Play and Google Play Services, and then deploys the payload from its assets.
  • The Accessibility Service automatically operates Developer Options and Wireless Debugging, and pairs with the local ADB using displayed codes.
  • The privilege gained after pairing is an ADB shell user account; root access was not reported.
  • C2 communication starts over HTTPS and then uses a persistent WebSocket encrypted with AES-ECB. Keys are generated from static byte arrays in the code.
  • Overlays can steal financial app credentials, PINs, and device lock credentials.

Inference

  • Blocking Google Play traffic likely aims to prevent Play Protect and official validation or update mechanisms from stopping the infection chain.
  • On corporate-managed devices, MDM/MTD correlation of rapid changes to VPN, Accessibility, Developer Options, and Wireless Debugging provides strong detection signals around C2.
  • If users enter corporate SaaS credentials on an infected device, risks of compromise exist via similar fake screens or remote control, beyond just financial apps.

Hypothesis

  • Attackers might combine the 167 public commands and dynamic target lists to add Japanese financial, crypto, and enterprise apps in the future. However, the article does not specify Japan as a targeted country.
  • The specific initial vector that lures users to AWS distribution sites remains unknown, leaving multiple possibilities such as fake sites, messages, or secondary droppers.

13. MITRE ATT&CK Mapping

Mappings use Mobile ATT&CK for Android.

  • T1453 Abuse Accessibility Features (Confidence: high) — Uses Accessibility Service for Android settings control, screen monitoring, permission grants, and persistence.
  • T1516 Input Injection (Confidence: high) — Uses Accessibility to automate repeated taps on the Build number and navigate settings screens.
  • T1623.001 Command and Scripting Interpreter: Unix Shell (Confidence: high) — Executes commands as a shell user after local ADB pairing.
  • T1417.002 Input Capture: GUI Input Capture (Confidence: high) — Captures PINs and credentials via overlays mimicking financial apps and lock screens.
  • T1437.001 Application Layer Protocol: Web Protocols (Confidence: high) — Uses HTTPS and WebSockets for C2.
  • T1521.001 Encrypted Channel: Symmetric Cryptography (Confidence: high) — Encrypts C2 data using AES-ECB with static keys.
  • T1406 Obfuscated Files or Information (Confidence: high) — Decrypts and executes encrypted payloads and obfuscated code/strings from assets.
  • T1418 Software Discovery (Confidence: high) — Enumerates installed app package names and icons and sends them to C2.
  • T1629.003 Impair Defenses: Disable or Modify Tools (Confidence: medium) — Blocks traffic to Google Play / Google Play Services using a local VPN. Disabling Play Protect itself via settings was not confirmed.
  • T1626.001 Abuse Elevation Control Mechanism: Device Administrator Permissions (Confidence: medium) — Device Administrator requests and password change commands are implemented, but execution in real attacks is unconfirmed in the article.
  • T1646 Exfiltration Over C2 Channel (Confidence: high) — Exfiltrates overlay-harvested data and device information via C2.

14. Open Questions / Further Research

  • The specific initial access method used to lure users to AWS distribution sites, and the social engineering prompts used to allow non-Google Play installations.
  • Actual infection counts, real-world victim numbers, attacker groups, and campaign duration.
  • Which of the 167 commands were executed on real victim devices, and whether Device Administrator or screen lock modification features were used.
  • A complete list of the 16 targeted countries, and whether Japanese apps and users are included.
  • Success rates of automated Wireless Debugging operations across different Android versions, OEMs, and languages.
  • Google Play destinations blocked by the VPN, the duration of the block, and error messages visible to the user.
  • Connections between public IOCs and other distribution buckets, C2 servers, certificates, and app signatures.

15. Impact on SOCs and Organizations

  • Although the article does not explicitly name specific target countries, it automates settings for multiple OEMs like Samsung, Xiaomi, OPPO, Vivo, and Huawei. This makes the technique technically applicable to global enterprises managing corporate and BYOD Android devices.
  • Even without root access or zero-days, if users grant strong permissions, the malware can reach ADB shell. Vulnerability management alone cannot prevent this; organizations must control app installations, permissions, and debugging settings.
  • VPN, Accessibility, Wireless Debugging, and financial app overlays rarely appear in traditional PC SOC logs. Therefore, integrating MDM and MTD telemetry into a SIEM offers high value.
  • If an infected device was used for business email, SSO, VPN, or financial services, organizations must review related sessions and transactions alongside device recovery.
  • When BYOD devices lack sufficient telemetry, organizations must tighten connection controls and risk-based authentication to restrict corporate service access from potentially infected devices.

16. Summaries by Target Audience

For SOC Teams

Correlate time-series events including VPN and Accessibility grants on unknown APKs, enabled Developer Options/Wireless Debugging, local ADB pairing, and C2 WebSockets. Do not mistake ADB shell access for root privileges; evaluate permission changes, data exfiltration, and remote commands stage by stage.

For Administrators

Use MDM to restrict non-Google Play apps, unauthorized VPNs, Accessibility, and Device Administrators, as well as Developer Options and Wireless Debugging. Feed Android telemetry to the SOC. Wipe and re-enroll suspected infected devices under management after preserving evidence.

For Users

Do not approve requests for VPN connections, Accessibility, or Device Administrator privileges during normal app installations. If settings screens move by themselves, fake update screens do not disappear, or financial apps look abnormal, disconnect the device from the network and report the issue.

Top comments (0)