How can organisations defend against Anubis (Android Banking Trojan)?

How Anubis typically gets a foothold

Anubis is most effective when a user is persuaded to install a malicious app, often outside trusted app stores or through a lookalike download flow. Once installed, the trojan leans on Android permission prompts, overlay abuse, and accessibility abuse to observe banking activity, intercept inputs, and expand what it can see on the device.

The practical implication is that defence starts before malware execution. A strong mobile control set should reduce app-install paths, make high-risk permissions visible, and prevent unmanaged devices from reaching sensitive corporate services. The Mobile Malware Guide is a useful reference for the Android abuse patterns that matter here.

What controls reduce the real attack surface

The highest-value controls are the ones that narrow what the user and the malware can do after first contact. Enforce managed-device controls for corporate access, require OS patching, block sideloading where policy allows, and treat accessibility, SMS, and overlay-related requests as exception-prone rather than routine. A mobile threat defence capability can add device-level detection for suspicious app behaviour, but it should complement, not replace, hard policy controls.

App vetting matters, but user education alone is not enough. If the organisation allows personal devices, separate those from higher-trust business workflows and make access conditional on device posture. That is often the difference between a nuisance infection and a compromise that can reach email, banking, or internal portals. The Malware Guide provides broader context on trojan behaviour and detection approaches that support that control set.

How to spot compromise and contain it quickly

When Anubis is suspected, prioritise indicators that show credential interception or UI manipulation, not just antivirus hits. Repeated permission prompts, unexplained accessibility service enablement, odd screen overlays, banking app instability, and SMS interception attempts are all reasons to move from monitoring to containment.

Containment should focus on removing the app, revoking its access path, and checking whether the device was used to access corporate services while compromised. If the device handled banking or enterprise credentials, force credential reset where appropriate and review session tokens, not just passwords. For teams already operating mobile monitoring, mobile malware guidance helps align alerting with the behaviours most likely to precede theft.

Practitioner Guidance

What to prioritise: Treat permission abuse and unmanaged access as the core problem. If the device can install unvetted apps or grant accessibility access without business justification, your detection will always lag the attacker.

What to verify: Confirm that corporate access is conditional on managed-device posture, that sideloading is restricted where feasible, and that high-risk permissions are reviewable by security or mobility admins. Verify that incident responders can quarantine a device quickly without waiting for user action.

Practitioner takeaway: The strongest defence against android banking trojan is not a single scanner, it is a stack that blocks risky installation paths, constrains permissions, and makes compromise visible early enough to reset access before credential theft spreads.

Related resources from NHI Mgmt Group

• How can organisations defend against Cerberus (Android Banking Trojan)?
• How can organisations defend against Chameleon Android banking trojan?
• Why do German-language banking Trojan campaigns remain effective against organisations in German-speaking regions?
• How do attackers use Anubis (Android Banking Trojan)?