The most dangerous permissions on your Android phone are not the obviously sensitive ones like the camera or your contacts. They are the permissions built to help — the trust permissions designed for users with disabilities, for password managers, and for corporate device management. Modern Android malware has learned to weaponize exactly these mechanisms. By tricking a victim into granting a single Accessibility Service permission, a banking trojan can read everything on the screen, log every keystroke, tap buttons on the user’s behalf, silently approve its own permission requests, intercept multi-factor authentication codes, and drain a bank account without the victim ever seeing the fraudulent transaction.

This is not theoretical. Over the past several years, threat actors behind families like Vultur, SharkBot, Anatsa, Xenomorph, Octo, and Brokewell have industrialized this technique, turning the Android attack surface into a reliable engine for financial fraud. For any organization that lets employees access email, VPNs, or financial systems from Android devices, understanding this class of intrusion is now a core part of mobile risk management.

This article breaks down how the abuse works, which real banking trojans use it, what Google is doing to close the gap, and how your organization can detect and defend against on-device compromise.

The Trust Permissions Attackers Want Most

Android’s security model is built on permissions. Most are narrow and easy to reason about. A few, however, grant sweeping control — and those are the ones threat actors chase.

Accessibility Services: designed for assistance, abused for takeover

The Accessibility Service API exists so that assistive apps — screen readers, switch-access tools, automation aids — can observe and interact with other apps on behalf of users who need help. To do its job, an accessibility app can:

Read on-screen content, including text in other apps’ windows.
Observe events such as which app is in the foreground, what the user typed, and when a window changes.
Perform actions, such as tapping buttons, scrolling, and entering text — effectively simulating the user.

That capability set reads almost exactly like a specification for spyware. Once a user is socially engineered into enabling an accessibility service for a malicious app, the malware gains a near-total window into the device. It can function as a keylogger, capture credentials as they are typed, and auto-grant additional permissions by detecting and tapping the “Allow” buttons on system dialogs faster than a human could react. It can also detect when the user opens a security or antivirus app and navigate away, or block uninstall attempts.

Critically, accessibility abuse lets malware read one-time passcodes and authentication prompts directly off the screen or out of notifications — the core mechanism behind MFA interception. The multi-factor code that is supposed to stop an attacker becomes just another string of text the malware scrapes and forwards.

Screen overlays and “tapjacking”

The second pillar of on-device fraud is the overlay. The SYSTEM_ALERT_WINDOW permission (“Display over other apps”) lets an app draw content on top of other apps. Legitimately, this powers chat-head bubbles and screen-dimming utilities. Abused, it enables overlay attacks: the malware detects when a targeted banking app is opened and instantly draws a pixel-perfect fake login screen over the real one. The victim types their credentials into the attacker’s overlay, believing they are logging into their bank.

A related technique is tapjacking, where an invisible or misleading overlay captures or redirects taps so the user unknowingly approves an action — for example, granting a permission or confirming a transfer while believing they are tapping something else. Combined with accessibility control, overlays let malware both harvest credentials and hide the fraud in progress behind a benign-looking screen.

The Device Admin API and persistence

The Device Admin API was created for legitimate mobile device management (MDM) — letting an enterprise enforce screen locks, password policies, and remote wipe. Malware abuses it primarily for persistence and coercion. An app registered as a device administrator is harder to uninstall, because the user must first revoke admin rights, and malware can use its accessibility control to interfere when the user tries. Some threats have historically leveraged device-admin powers to lock the screen or threaten a factory reset in extortion schemes.

Google has steadily deprecated much of the legacy Device Admin functionality in favor of modern management profiles, and it is no longer the centerpiece of the most advanced banking trojans. But it remains a meaningful part of the attack surface, especially for persistence, and it is why “which apps are device administrators?” belongs on every mobile-security checklist.

How the Full Attack Chain Fits Together

A modern Android banking trojan intrusion typically unfolds in stages:

Delivery. The malware reaches the device through a malicious app. Increasingly this is a dropper — a clean-looking utility (a PDF reader, QR scanner, file manager, or “phone cleaner”) published on the Google Play Store or delivered via sideloading, phishing (smishing) links, or fake browser-update pages. The dropper passes review because it carries no obvious malicious code; it fetches the real payload later.
The permission lure. After install, the app displays a convincing prompt asking the user to enable an accessibility service or “additional settings,” often framed as necessary for the app to function. This social-engineering step is the linchpin of the entire compromise.
Privilege cascade. With accessibility granted, the malware auto-approves further permissions, disables or evades protections, and often obtains overlay and notification-listener access — all with minimal further user interaction.
Reconnaissance and harvesting. It enumerates installed apps to match against a target list of banks and crypto wallets, then deploys overlays and keylogging to capture credentials, and reads OTPs to defeat MFA.
On-device fraud (ODF) / device takeover (DTO). The most advanced families move the fraud onto the victim’s own device. Using remote-control capability (often a VNC-style stream driven through accessibility, sometimes behind a black overlay screen so the victim sees nothing), the operator initiates transfers from the trusted device — defeating fraud-detection systems that flag logins from new devices. Some families use Automated Transfer Systems (ATS) to script the transfer flow automatically.

Real Banking Trojans That Abuse Accessibility

The following families are documented by established mobile-threat researchers. Each illustrates a different facet of the same core abuse.

Vultur — screen recording and remote control

Discovered by ThreatFabric in mid-2021, Vultur was notable as one of the first Android banking trojans to use screen recording and VNC-style remote access rather than traditional HTML overlays to steal credentials. It abuses Accessibility Services to log what is on screen and to enable remote viewing and control, letting operators watch and drive the device in real time. Later versions expanded remote-control and evasion capabilities, underscoring how actively this family is maintained.

SharkBot — Automated Transfer System fraud

Identified by Cleafy in late 2021, SharkBot pioneered the use of an Automated Transfer System on Android among this generation of trojans: rather than just stealing credentials, it abuses Accessibility Services to auto-fill and authorize fraudulent money transfers directly on the device, bypassing multi-factor and behavioral fraud controls. SharkBot has repeatedly been distributed through dropper apps on the Google Play Store, disguised as utilities and security tools.

Anatsa / TeaBot — Play Store droppers at scale

Tracked as Anatsa by ThreatFabric and as TeaBot by Cleafy, this family is a textbook example of the dropper-on-Google-Play model. Its operators repeatedly slip benign-looking apps — PDF readers, file utilities, QR scanners — past Play Store review, then push the banking payload as an update. Campaigns have targeted hundreds of banking and financial apps across multiple countries, and reporting in 2025 documented an Anatsa dropper posing as a PDF app that reached roughly 90,000 installs before removal. Once active, Anatsa uses Accessibility Services for overlays, keylogging, and on-device fraud.

Xenomorph — from “newly hatched” to 400+ targets

ThreatFabric first detailed Xenomorph in early 2022. A later variant (v3) added a full Automated Transfer System framework and expanded its target list to more than 400 banking and financial institutions, including crypto wallets, with campaigns eventually reaching users in the United States. Xenomorph leans heavily on Accessibility Services to drive overlays and automate fraudulent transactions.

Octo — malware-as-a-service for on-device fraud

Octo, detailed by ThreatFabric in 2022, evolved from the older ExobotCompact lineage and is offered as a malware-as-a-service rental to multiple criminal customers. Octo’s signature capability is on-device fraud through remote access: it can stream the screen and, notably, render a black overlay screen and disable the display so the victim believes the phone is off or idle while the operator conducts transactions. An updated “Octo2” variant surfaced in 2024 with improved stability and evasion.

Brokewell — full device takeover

Brokewell, documented by ThreatFabric in 2024, is a newer family built for complete device takeover. It combines data-stealing and remote-control features, abuses Accessibility Services extensively, and has been distributed via fake browser-update pages that lure users into sideloading. Brokewell illustrates the ongoing trend: attackers want not just credentials but persistent, interactive control of the device itself.

The through-line across all six families is the same: the initial compromise hinges on a single accessibility grant, and everything downstream — overlays, keylogging, MFA interception, remote control, automated transfers — flows from that one act of misplaced trust.

Google’s Countermeasures

Google has responded to accessibility abuse on several fronts, and the trajectory matters for defenders assessing residual risk.

Play Store policy limits on the Accessibility API. Google Play policy restricts the IsAccessibilityTool designation and requires apps that request accessibility access to have a use that genuinely relates to accessibility, with an in-app disclosure. Apps that request the permission without a qualifying purpose can be rejected or removed. This raises the bar for malware distributed through the official store — though droppers that fetch payloads later remain a persistent gap.

Android 13 “restricted settings.” Beginning with Android 13, Google introduced restricted settings that block apps installed from outside an app store (sideloaded via an APK) from being granted Accessibility Services and notification-listener access through the normal settings flow. A user must take a deliberate extra step to allow a restricted setting for a sideloaded app. Because so much banking malware arrives via sideloading and social engineering, this control directly targets the most common infection path. (Attackers have adapted by using session-based installers that can be treated differently, so the mitigation reduces rather than eliminates the risk.)

Google Play Protect. Play Protect scans apps from the Play Store and, importantly, performs on-device, real-time scanning of newly sideloaded apps, including code-level analysis to flag apps that abuse sensitive APIs. In some regions Google has piloted enhanced fraud-protection features that block the installation of apps requesting high-risk permission combinations from internet sideloading. Play Protect is a meaningful baseline, but it is not infallible, and it should be treated as one layer rather than a guarantee.

The net effect: the official Play Store is safer than it was, sideloading is meaningfully harder to weaponize on current Android versions, and yet determined threat actors continue to find viable paths — chiefly through convincing social engineering and dropper apps. Defense in depth remains essential.

Protecting Your Organization’s Android Devices

Whether you manage a fleet of corporate phones or support a bring-your-own-device workforce, the following controls materially reduce the risk of an accessibility-driven breach.

Reduce the attack surface

Restrict sideloading. Use MDM/mobile device management to disable installation from unknown sources on managed devices, and require apps to come from vetted sources.
Keep Android current. Prioritize devices on Android 13 or later so restricted-settings protections apply, and enforce timely security patches.
Vet apps, even from the Play Store. Discourage installing “utility” apps (cleaners, flashlight tools, generic PDF/QR apps) from unknown publishers. Droppers thrive in this category.
Enforce Google Play Protect as an on by default baseline through policy.

Watch the trust permissions

Audit Accessibility Services regularly. Any app with accessibility access that is not a known assistive tool, password manager, or approved automation app is a red flag. On managed devices, alert on new accessibility grants.
Audit “Display over other apps” and notification-listener permissions for the same reason — these enable overlays and OTP scraping.
Enumerate Device Admin apps. Know which apps hold device-administrator rights; unexpected entries warrant investigation.

Harden authentication

Prefer phishing-resistant MFA. SMS and app-generated OTPs can be scraped by an on-device attacker. FIDO2 security keys and passkeys bound to the device and origin dramatically reduce the value of a stolen code.
Monitor for account-takeover signals even from “trusted” devices, since on-device fraud is specifically designed to look like legitimate activity from a known phone.

Train users on the decisive moment

The entire attack usually pivots on one prompt: “Enable accessibility for this app.” Teach staff that no legitimate banking, shopping, or utility app needs Accessibility Services to function, and that a request to enable it — especially right after install or from a link — is a strong indicator of malware. Reinforce that fake browser-update pages and unsolicited “your device is infected” pop-ups are common lures.

Detect and respond

Watch for behavioral red flags: rapid battery or data drain, unfamiliar overlays, a phone that seems unresponsive or shows a black screen at odd times, apps that resist uninstall, or unexpected accessibility/admin permissions appearing.
Have a mobile incident-response plan. If compromise is suspected, isolate the device from accounts, revoke sessions and credentials, and preserve the device for forensic analysis before wiping. On-device fraud can continue as long as the malware retains control, so speed matters.
Use mobile threat defense (MTD) tooling integrated with your MDM to flag risky apps and permission states at scale.

Conclusion

Android’s most powerful trust permissions — Accessibility Services, screen overlays, and Device Admin — were built to help users and administrators. Banking trojans like Vultur, SharkBot, Anatsa, Xenomorph, Octo, and Brokewell have turned that trust into a reliable path to full device takeover, MFA interception, and on-device fraud. Google’s Play policies, Android 13 restricted settings, and Play Protect have raised the cost of these attacks, but social engineering and dropper apps keep the threat alive. The strongest defense combines a reduced attack surface, disciplined auditing of trust permissions, phishing-resistant authentication, and a workforce that recognizes the decisive “enable accessibility” moment for what it is.

If your organization needs to investigate a suspected mobile compromise, assess your Android fleet’s exposure, or build a mobile incident-response capability, Honeybadger Solutions LLC can help. As a Service-Disabled Veteran-Owned Small Business specializing in cybersecurity, digital forensics, and incident response, our team performs mobile malware analysis, device forensics, and threat assessments to help you understand what happened, contain it, and prevent the next intrusion. Reach out to talk through your mobile security posture.

About Honeybadger Solutions

Honeybadger Solutions LLC is a Service-Disabled Veteran-Owned Small Business (SDVOSB) delivering cybersecurity, digital forensics, and investigative services to clients nationwide. Whether you are dealing with a compromised device, a suspected intrusion, or you simply want to get ahead of these threats, our team can help.

What we do:

Digital forensics — mobile devices (iPhone, Android) and computers (Windows, macOS, Linux); intrusion reconstruction, evidence preservation, and expert-witness reporting
Cybersecurity & incident response — breach investigation, containment, malware and spyware analysis, and remediation
Penetration testing & security assessments — finding the gaps before an attacker does
Managed IT & endpoint security — hardening, monitoring, and patch management for small and mid-sized organizations
Private investigations — including TSCM / technical surveillance countermeasures (“bug sweeps”)
Executive & personal protection

📞 (602) 725-2818 · 🌐 honeybadgersolution.com · Veteran-Owned (SDVOSB) · Licensed & Insured

Concerned a device or network may already be compromised? Contact Honeybadger Solutions for a confidential consultation — we handle mobile and computer forensics, incident response, and everything above.

Related from the Honeybadger Android device-security series

Part of Honeybadger Solutions’ security-intelligence series. Explore the rest of the Android coverage:

Sources

Vultur, with a V for VNC — ThreatFabric — Vultur’s discovery, use of screen recording/VNC-style remote access and Accessibility Services abuse to steal banking credentials.
Android Banking Trojan ‘Vultur’ Abusing Accessibility Services — SecurityWeek — Corroborates Vultur’s accessibility abuse and remote-control approach.
SharkBot: a new generation of Android Trojans is targeting banks in Europe — Cleafy Labs — SharkBot’s Automated Transfer System, Accessibility Services abuse, and dropper distribution.
SharkBot: a “new” generation Android banking Trojan being distributed on Google Play Store — NCC Group — Confirms SharkBot delivery via Play Store dropper apps.
Deceive the Heavens to Cross the Sea (Google Play droppers) — ThreatFabric — Anatsa and the dropper-on-Google-Play distribution model.
Anatsa Android Banking Trojan Hits 90,000 Users with Fake PDF App on Google Play — The Hacker News — Anatsa/TeaBot campaign reach (~90,000 installs) via a fake PDF app dropper.
Xenomorph: A newly hatched Banking Trojan — ThreatFabric — Xenomorph’s initial discovery and Accessibility-driven overlay abuse.
Xenomorph v3: a new variant with ATS targeting more than 400 institutions — ThreatFabric — Xenomorph’s ATS framework and 400+ target institutions.
Look out for Octo’s tentacles! A new on-device fraud Android Banking Trojan — ThreatFabric — Octo’s ExobotCompact lineage, malware-as-a-service model, on-device fraud, and black-screen overlay.
Octo2: European Banks Already Under Attack by New Malware Variant — ThreatFabric — Octo2 variant with improved evasion (2024).
Brokewell: do not go broke from new banking malware! — ThreatFabric — Brokewell’s device-takeover capabilities, Accessibility abuse, and fake-update delivery.
Android 13 sideloaded apps can’t use accessibility settings — 9to5Google — Android 13 restricted settings blocking sideloaded apps from Accessibility.
Android 13’s New Sideloading Restriction Makes it Harder for Malware to Abuse Accessibility APIs — Esper — Technical explanation of the restricted-settings mitigation and attacker adaptations.
Mobile Communications Best Practice Guidance — CISA — CISA guidance on protecting mobile device communications and reducing mobile risk.
Capacity Enhancement Guide: Mobile Device Cybersecurity Checklist for Organizations — CISA — CISA checklist of mobile-device security controls for organizations.