How do attackers use Anubis (Android Banking Trojan)?

How Anubis is typically used in Android banking attacks

Attackers use Anubis to turn a normal banking session into a controlled fraud workflow. The malware is designed to capture credentials, intercept one-time codes, and present convincing fake screens that sit on top of legitimate banking apps. That combination lets the attacker collect access material, manipulate what the victim sees, and move quickly from initial compromise to transaction abuse.

The practical value of Anubis is not just theft, it is timing. A banking trojan works best when it can watch the victim in real time, wait for a login or payment event, and then interfere at the exact moment the bank or wallet is most likely to trust the session. The result is often a blend of credential theft, session abuse, and transaction fraud rather than a single isolated action.

For a broader view of how android banking trojan operate and the control patterns defenders should expect, Mobile Malware Guide is the most direct companion resource. For malware tradecraft more generally, Malware Guide covers the loader, RAT, evasion and analysis patterns that often sit behind banking trojans.

What attackers rely on once the device is infected

Anubis-style operations depend on abuse of Android trust and user assistance features. Attackers commonly use accessibility service abuse, overlay attacks, and prompt manipulation to make malicious actions look routine. Once those permissions or capabilities are in place, the malware can monitor app activity, imitate login prompts, and capture what a human user would normally consider private or transient.

Remote access and screen control matter because they let the attacker operate through the victim’s own device and reputation. Instead of breaking into a bank directly, the attacker can exploit the existing trust between the device, the app, and the user. That is why fake app updates, sideloaded installers, and requests for intrusive permissions remain so effective as delivery and persistence mechanisms.

When a family is built around mobile credential theft and transaction abuse, the right defensive lens is not only “is the app malicious,” but also “what did it gain the ability to read, display, approve, or forward.” That framing is central to mobile malware analysis and to identifying whether the compromise is still at the infection stage or has already moved into payment fraud.

What defenders should investigate first after suspected Anubis activity

The highest-value indicators are usually on the device, not just in the bank logs. Look for abnormal accessibility permission use, overlay behaviour over financial apps, unexplained app installs or updates, and financial apps that begin behaving differently when opened. Those signals often appear before confirmed theft, especially when the malware is trying to stay hidden while it waits for a login or transfer.

Banking teams should also correlate unusual customer behaviour with transaction anomalies, because these infections frequently surface as authorised-looking activity performed under attacker influence. A device that suddenly changes navigation patterns, hides screens, or triggers repeated reauthentication events can be a sign that the attacker is already inside the session path rather than merely waiting outside it.

For hunters and incident responders, the most useful question is whether the malware is only stealing data or also controlling the session path. That distinction determines whether the response is limited to account recovery or should extend to device containment, customer notification, and broader fraud monitoring.

Risk and Threat Considerations

Anubis is dangerous because it combines credential theft with live session interference, so compromise can persist even when a user believes they are interacting with a legitimate banking app. The threat is not just stolen passwords, but the ability to intercept codes, alter what the victim sees, and push fraudulent transactions through a trusted device.

Failure mechanism: The malware abuses Android permissions and UI overlays to capture credentials and approval codes, then uses remote control or interception to complete fraud within an active session.

Impact: Victims can lose account access, funds, and trust in the device itself, while defenders may see activity that looks legitimate unless they inspect endpoint behaviour and authentication context together.

Practitioner Guidance

What to prioritise: Treat overlay behaviour, accessibility abuse, and suspicious update prompts as device-compromise signals, not just nuisance events. If those indicators coincide with banking login failures or unusual transfers, move immediately to device isolation and fraud review rather than waiting for a confirmed malware signature.

What to verify: Confirm whether the same device is attempting repeated logins, second-factor approvals, or payment actions from unusual timing or context. The key judgement is whether the device is still trustworthy enough to keep using for recovery, because in many cases the answer is no once banking-session manipulation is suspected.

Practitioner takeaway: With Anubis, the decisive issue is whether the attacker has moved from malware presence to active transaction control, because once the session path is being manipulated, account recovery and fraud containment must happen together.

Related resources from NHI Mgmt Group

• How do attackers use Cerberus (Android Banking Trojan)?
• How do attackers use Chameleon Android banking trojan?
• Anubis (Android Banking Trojan)
• How do attackers turn a supply-chain incident into wider NHI compromise?