Anubis is an Android banking trojan that steals credentials and can abuse accessibility features to control the device and perform fraudulent actions. Defenders should check for malicious sideloaded apps, overlay abuse, suspicious permission requests, and account activity that suggests unauthorised transfers or credential capture.
What the malware does on an Android device
Anubis is an android banking trojan that is built for theft and fraud, not just disruption. It targets the device as a trusted user endpoint, then uses that access to capture credentials, watch for sensitive activity, and interfere with normal banking flows.
The important security point is that mobile malware often succeeds by blending into ordinary app behaviour. Once a trojan can read what the user sees, intercept what the user types, or trigger actions on their behalf, the compromise becomes harder to spot than a simple login theft.
Why accessibility abuse makes it more dangerous
Anubis is especially concerning because it can abuse Android accessibility features to gain broad control over the device. That turns a permissions feature meant to help users into a pathway for clicking through prompts, reading screen content, and performing actions that look legitimate to the operating system.
This kind of abuse matters because it weakens the user’s ability to trust what is happening on screen. Even when the user does not approve a fraudulent transfer directly, the trojan may be able to navigate the interface, approve prompts, or keep itself active while hiding from casual inspection.
For defenders, the presence of accessibility abuse is a clue that the malware is not only stealing data but also trying to preserve interactive control after initial compromise. That is why suspicious permission requests and unexpected accessibility service enrolment deserve immediate review, especially on devices used for finance.
How organisations and users spot likely exposure
Exposure usually starts with a malicious or tampered app install, so defenders should look for sideloaded applications, unexpected app stores, and apps that request unusual privileges for their stated purpose. A device that suddenly has overlay permission, accessibility access, or admin-like reach without a clear business need should be treated as suspect.
Monitoring bank and account activity is also important because the first visible sign may be a transaction or login that the user did not intend. Repeated failed logins, changed contact details, new trusted devices, or transfers that do not match normal behaviour can all indicate credential capture or device-driven fraud.
Mobile Malware Guide is the best companion resource for the broader Android trojan pattern, including overlay abuse, sideloading and accessibility misuse. For the underlying malware tradecraft across trojans, keyloggers and other families, Malware Guide provides the wider threat context.
Containment, cleanup and account recovery
Once Anubis-like behaviour is suspected, containment has to cover both the device and the accounts that were used on it. Removing the app alone is not enough if the trojan already captured passwords, session material, or one-time codes, because those can still be used after the malware is gone.
Post-incident review should focus on whether the attacker obtained credentials, session access, or enough device control to authorise transactions. If that happened, the practical response is to treat the affected accounts as compromised and review recent activity for unauthorised transfers, profile changes, linked device changes, and any recovery-channel abuse.
From a detection standpoint, unusual overlay prompts, accessibility abuse, and repeated permission changes are valuable signals, but they are often easier to confirm through endpoint and account evidence together than in isolation. The device, the banking session, and the transaction history should be reviewed as one incident chain.
Risk and Threat Considerations
An Android banking trojan is dangerous because it combines credential theft with device control, which lets an attacker move from simple access capture to transaction abuse. The risk is not limited to password loss, it can extend to fraudulent approvals, account takeover and concealment of malicious activity on the victim device.
Failure mechanism: The trojan abuses trusted device features, such as accessibility services and overlays, to observe, impersonate or automate user actions while stealing credentials and session information.
Impact: Organisations and users can face unauthorised transfers, account compromise, recovery-channel abuse and a delayed detection window because the activity may look like normal device interaction.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1056 — Input Capture | Android banking trojans capture user input and screen interactions to steal credentials. |
| T1548 — Abuse Elevation Control Mechanism | Accessibility and permission abuse helps malware gain broader device control. | |
| Recommendation — Monitor for input-capture activity and correlate it with suspicious mobile credential theft. Detect abuse of trusted device controls that enables privilege-like mobile manipulation. | ||
| CIS Controls v8 | CIS-10 — Malware Defenses | Mobile trojans are a malware-detection and containment problem requiring defensive controls. |
| CIS-6 — Access Control Management | Account takeover and unauthorised transfers depend on weak account and permission control. | |
| Recommendation — Apply malware defenses to detect, isolate and remove malicious mobile applications. Review and revoke unnecessary account access paths after suspected mobile compromise. | ||
| NIST SP 800-53 Rev 5 | SI-3 — Malicious Code Protection | The subject is mobile malware that must be identified and contained as malicious code. |
| Recommendation — Deploy malicious code protections to detect and block trojanised mobile apps. | ||
Practitioner Guidance
What to watch for: Treat unexpected accessibility enrollment, overlay permissions and sideloaded finance-related apps as high-signal findings. In mobile environments, the strongest warning sign is usually not a single malicious indicator, but a cluster of suspicious app provenance, privilege requests and account anomalies.
Governance implication: Security teams should define clear rules for what mobile permissions are acceptable on managed and personal devices used for financial access. That policy is most effective when it is paired with user reporting that makes unusual prompts or unauthorised transfers easy to escalate quickly.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org