Security teams can detect Anubis by looking for Android banking trojan behaviour including credential theft, SMS interception, overlay attacks and remote control activity. Watch for sideloaded apps, accessibility service abuse, suspicious permission requests and hidden persistence. Network monitoring should flag connections to untrusted infrastructure, while mobile telemetry can reveal attempts to steal financial app sessions.
What makes Anubis detectable in practice
Anubis is easiest to spot when teams look for behaviour, not just file hashes or package names. The strongest signal set is a cluster of android banking trojan activity, credential theft, SMS interception, overlay abuse and remote control, especially when those behaviours appear together on a device that should only be running legitimate banking or productivity apps.
That matters because banking trojans often blend into ordinary mobile use. A single permission prompt or a single sideloaded app may be ambiguous, but several low-signal events, such as accessibility abuse, hidden persistence and attempts to read SMS, can together form a defensible detection hypothesis.
Which device and app signals usually surface first?
Start with application provenance and privilege abuse. Sideloaded apps, unexpected installers, unusual permission requests and accessibility service abuse are all practical indicators because they often precede the more obvious theft activity. For mobile teams, app trust and runtime behaviour are usually more useful than static reputation alone.
Watch for fake login overlays, permission chaining and attempts to keep running after the user closes the app. Those patterns can indicate that the malware is trying to intercept credentials or approvals while hiding the real screen state from the user. Mobile Malware Guide is a useful reference point for the Android banking trojan techniques that tend to show up in detections.
At the app layer, unusual requests for accessibility privileges, device admin-style control or persistent foreground behaviour deserve review when they do not match the app’s stated purpose. A banking app wrapper, utility app or fake update prompt is often where the initial compromise starts.
How should network and telemetry teams confirm suspicious activity?
Network monitoring should look for outbound connections to untrusted infrastructure, especially when those connections correlate with newly installed apps or anomalous sessions to financial services. The point is not simply to block unknown domains, but to tie communications to a suspicious mobile process, a suspicious installation path or an unusual time window.
Mobile telemetry is most valuable when it shows behaviour that lines up with theft or control. Session theft attempts, SMS interception, overlay launch events and remote-control commands are stronger indicators than any single packet or alert. If the device management stack is available, enrich the alert with app inventory, installation source, permission history and accessibility usage.
Teams that operate broader mobile controls should also compare the device state against policy baselines, since compromised devices often drift from managed settings before they are used for fraud. Mobile Device Security Guide helps connect app-level anomalies to device posture, while Mobile App Security Guide is the better fit when the investigation needs runtime and app-integrity checks.
Risk and Threat Considerations
Anubis is dangerous because it targets the trust path between the user, the device and the financial app. If the malware can read one-time codes, capture overlays or take remote control of the session, fraud can occur without a traditional account takeover signal on the server side.
Failure mechanism: The trojan abuses accessibility and overlay features, then uses persistence and SMS interception to stay embedded long enough to steal credentials, approvals or session material.
Impact: Security teams may miss the compromise until fraudulent transactions, unauthorized app actions or repeated session hijacks appear, and the same device can remain a launch point for repeated abuse.
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 NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1621 — Multi-Factor Authentication Request Generation | Covers mobile banking trojan behavior that targets session approval flows. |
| T1518 — Software Discovery | Fits malware that enumerates installed apps and targets banking software. | |
| Recommendation — Correlate suspicious mobile prompts and session abuse with transaction events to detect approval interception. Hunt for app-enumeration activity on devices showing banking-trojan indicators. | ||
| NIST CSF 2.0 | DE.CM-01 — Security Continuous Monitoring | Detects anomalous mobile activity, permissions and network behaviour. |
| PR.AA-05 — Identity Management, Authentication, and Access Enforcement | Relevant where the trojan steals credentials or hijacks app sessions. | |
| Recommendation — Monitor mobile telemetry and network flow anomalies for banking-trojan indicators. Enforce strong authentication and session controls around financial apps on mobile devices. | ||
| CIS Controls v8 | CIS-10 — Data Recovery | Supports response after mobile compromise by restoring trusted device state. |
| Recommendation — Restore and re-enrol compromised devices before returning them to production use. | ||
Practitioner Guidance
What to prioritise: Treat detections as a device and session problem, not only a malware triage problem. Confirm whether the suspicious app was sideloaded, whether accessibility access was granted, and whether the device has touched banking or payment apps since the first suspicious event.
What to verify: Validate permission history, app installation source, SMS access, accessibility usage and any process that is trying to maintain control after the user exits the app. If the suspicious behaviour lines up with a financial session, assume the session may already be exposed even if the endpoint alert looks low severity.
Practitioner takeaway: The most reliable detection comes from correlating mobile abuse patterns with financial-session activity, because Anubis is built to hide inside normal-looking app behaviour until it can steal or hijack the transaction path.