Android Overlay and Accessibility Malware: Inside Crocodilus, Anatsa, and DroidLock
Android's permission model is designed to let users delegate narrow capabilities to apps. Two capabilities are unusually dangerous in combination: the ability to draw over other applications (SYSTEM_ALERT_WINDOW) and the accessibility service framework. The first enables pixel-perfect phishing overlays; the second grants programmatic reading of the screen and simulated user actions. In 2025, three malware families — Crocodilus, Anatsa, and DroidLock — demonstrated how mature this abuse has become. None of them relies on a kernel exploit. They rely on social engineering and on permissions that users grant voluntarily.
1. The Permission Model and Its Blind Spots
Android separates normal permissions, dangerous runtime permissions, and special permissions. Overlay and accessibility are special permissions because they are not ordinary data access; they change the user's interaction with the device. Google requires an explicit settings flow for both, and Android 13+ added “Restricted settings” for sideloaded apps, which blocks accessibility activation until the user explicitly allows it.
The protection is meaningful but incomplete:
- Users are trained to tap “Allow.” A fake “enable accessibility to continue” screen looks like a legitimate onboarding step.
- Accessibility was built for assistive technology. It can read text, click buttons, scroll, and navigate back — exactly the primitives needed to operate a banking app.
- Overlays can be transparent. The victim sees the real app underneath while the malware captures taps or draws a credential prompt on top.
- Droppers stage the payload. The installed app is benign at review time and downloads the malicious component later, bypassing store scanning.
2. Crocodilus: Overlay Plus Remote Control
Crocodilus was documented by ThreatFabric in March 2025. It targeted Android users in Spain and Turkey before expanding, and its defining feature was the combination of overlay screens with accessibility-driven remote control. The malware displayed fake login screens over banking and cryptocurrency wallet applications, then used accessibility to read notifications, intercept one-time codes, and perform taps on the victim's behalf.
The infection chain typically began with a sideloaded APK delivered through a phishing page or a messaging lure. Once installed, the app requested accessibility access and, in some variants, attempted to disable security features or hide its icon. Crocodilus is notable because it did not need a sophisticated exploit: the victim granted the two permissions that made the attack possible.
The lesson is architectural. If an app can read the screen and simulate touches, it can operate any other app the user can operate. That is a remote-access capability, not a convenience feature.
3. Anatsa: The Dropper That Lives in the Store
Anatsa, also tracked as TeaBot, is an Android banking trojan that has been distributed through Google Play dropper applications disguised as PDF readers, document scanners, and utility apps. The published app contains no obvious banking payload. After installation, it downloads a second-stage APK from a remote server and asks the user to “update” or “enable” the app. The second stage requests accessibility, then overlays banking applications.
The pattern matters for defenders because it defeats a simplistic “is it in the Play Store?” check. Store review is a point-in-time assessment; a dropper can change behavior after approval. Anatsa campaigns have targeted hundreds of financial applications across Europe and the United States, adapting overlays to each target's login flow.
Why accessibility is the key
<!-- A malicious service declares the accessibility capability -->
<service
android:name=".AccessibilityHandler"
android:exported="true"
android:permission="android.permission.BIND_ACCESSIBILITY_SERVICE">
<intent-filter>
<action android:name="android.accessibilityservice.AccessibilityService" />
</intent-filter>
<meta-data
android:name="android.accessibilityservice"
android:resource="@xml/accessibility_config" />
</service>
The configuration file determines what the service can observe. A malicious app requests the broadest event types and capabilities, including canRetrieveWindowContent, canPerformGestures, and the ability to observe notifications. Once enabled, it receives events from every app the user opens.
4. DroidLock: When the Payload Is Ransomware
In December 2025, Zimperium published research on DroidLock, an Android ransomware family targeting Spanish-speaking users. DroidLock was distributed through sideloaded applications and abused accessibility and device-administration capabilities to lock the screen, change the device PIN, and display extortion messages. Unlike banking trojans, which prefer stealth, ransomware wants the victim to notice.
The technical progression is familiar: a socially engineered install, a request for elevated permissions, and then abuse of those permissions to remove the user's control. The defensive implication is the same: a device that grants accessibility and device-admin rights to an unknown app is no longer under the owner's exclusive control.
5. Detection and Hunting on a Device
Enterprise teams can audit managed devices for the following indicators. On a test device, use adb and the package manager:
# List services that declare accessibility capability
adb shell dumpsys accessibility | sed -n '1,120p'
# List device administrators
adb shell dumpsys device_policy | grep -i -A3 'admin'
# List apps with overlay permission
adb shell appops query-op SYSTEM_ALERT_WINDOW allow
# Inspect recently installed packages and installers
adb shell pm list packages -3 -i
Look for apps with innocuous names (“PDF Reader,” “Cleaner,” “Wallet Update”) that request accessibility, have no accessibility-related purpose, or were installed by a browser or messaging app rather than a store. Check whether the app hides its launcher icon, requests device-admin rights, or downloads an APK after installation.
6. Defensive Controls
- Restrict sideloading. On managed devices, disable installation from unknown sources and require managed Google Play. On personal devices, treat any APK sent through chat as hostile until proven otherwise.
- Enforce accessibility allowlists. Enterprise mobility management can restrict which packages may bind an accessibility service. For high-risk users, review enabled services monthly.
- Block overlay permission by policy. Most productivity apps do not need
SYSTEM_ALERT_WINDOW. Deny it by default and require an exception. - Protect OTPs. Do not rely on SMS codes as the sole second factor. Use phishing-resistant authentication such as passkeys or hardware security keys for banking and corporate accounts.
- Monitor dropper behavior. Alert on apps that install other APKs, request accessibility shortly after launch, or open a screen that asks the user to “enable” a security setting.
- Patch the OS. Keep Android security updates current. Restricted settings and improved accessibility warnings reduce, but do not eliminate, the attack surface.
7. Conclusion
Crocodilus, Anatsa, and DroidLock are different payloads built on the same foundation: user-granted special permissions. The malware does not break Android's security model; it persuades the user to widen it. Defenders should treat accessibility and overlay access as high-risk capabilities, audit them continuously, and design authentication that remains safe even when the device screen is being read by another app. The most effective control is not a signature — it is a permission policy that assumes the user will eventually tap “Allow.”