How Android Banking Trojans Work

An Android banking trojan does not break encryption and does not attack the bank. It waits for the victim to authenticate, and takes the credentials at the point where they are still in plaintext: the keyboard.

Everything else in the family — the permissions, the staged delivery, the anti-analysis — exists to make that one moment possible and to keep it working afterwards.

Understanding the capability chain matters for triage, because the individual components are each unremarkable. Overlay permission is used by legitimate chat applications. Accessibility services exist for users who need them. A single signal proves nothing; the combination is the finding.

The four capabilities

1. Overlay

The attack requires drawing a window on top of the banking application, pixel-identical to its login screen. The victim types into the attacker's window.

On Android this needs SYSTEM_ALERT_WINDOW, and modern variants pair it with a check for which application is in the foreground, so the fake screen appears at the right moment rather than at random. Foreground detection in turn generally requires enumerating installed packages, which is how QUERY_ALL_PACKAGES becomes part of the set: the malware needs to know which bank's overlay to render.

In a report this surfaces as two distinct findings: the permission on its own, and the permission combined with foreground detection. The second is materially stronger evidence than the first, and Droidwatch scores them separately for that reason.

2. Accessibility abuse

The Android accessibility API was built so that assistive software can read the screen and act on the user's behalf. That is precisely the capability an attacker wants.

With an accessibility service granted, malware can read the contents of any window including one-time codes, dismiss permission dialogues automatically, grant itself further permissions without user interaction, and prevent its own uninstallation by intercepting the settings screen.

The distinction that matters in triage is between an application that declares an accessibility service and one whose code shows it using the API to click, read fields and navigate. The declaration alone appears in legitimate software. The usage pattern does not.

3. SMS interception

If a transaction requires a code sent by SMS, the trojan needs to read it before the victim does — or instead of the victim.

Two capabilities appear here: reading incoming messages, and forwarding them to an operator-controlled number or endpoint. Forwarding is the stronger signal, because it has no plausible benign explanation in an application that is not an SMS client.

Since Android restricted SMS permissions on Play, this capability increasingly arrives alongside a request to be set as default SMS application, which grants it wholesale. A parallel route avoids SMS entirely: a notification listener reads the code from the notification itself, which covers one-time codes delivered through push rather than SMS.

4. Staged delivery

Mature families do not ship the payload in the installed APK. The first stage is small, requests little, and passes review. Once running, it downloads the real payload and loads it at runtime.

This defeats any analysis limited to the installed file, which is most automated scanning. A static report can still catch it: dynamic code loading through DexClassLoader or a PathClassLoader over a downloaded file, an embedded download URL, a high-entropy blob in assets/ the manifest never explains, and a request to install packages from unknown sources are all visible without executing anything.

A dropper signal on an application presenting as a banking product is escalation-worthy on its own, regardless of what the first stage does.

The permission set

The capabilities above map onto a specific and recognisable group of manifest declarations:

None of these is individually conclusive. Each has legitimate users. The set as a group has no legitimate application category.

Persistence

Two further capabilities appear across families and are worth noting because they change incident response, not just classification.

Device administrator. An application registered as device admin resists uninstallation through the normal route. Removing it requires revoking the admin right first — which the accessibility service is often used to prevent.

Combination with accessibility. Device admin plus accessibility abuse is the pair that turns a malware finding into a device-reimaging decision. The user cannot reliably remove it unaided, and support guidance that assumes a normal uninstall will fail in front of the customer.

What the combination means

Droidwatch tracks these as eight distinct banking signals, and the scoring reflects that the combinations carry the weight:

A report listing overlay permission and nothing else describes a messaging application. A report listing overlay with foreground detection, accessibility usage, SMS forwarding and a dropper describes a banking trojan, and the confidence comes from the intersection rather than from any single item.

Mapping to ATT&CK

Each capability corresponds to a technique in MITRE ATT&CK Mobile, and Droidwatch maps findings to techniques so the report drops into an existing detection programme rather than sitting beside it:

That mapping is the difference between a report that says this is bad and one a detection engineer can act on: the technique identifier is the shared vocabulary between the analysis and the controls that are supposed to catch it next time.

Where identity comes first

Before any of this, one question resolves faster and more decisively: is the application what it claims to be?

A package impersonating a bank, signed with a certificate that does not match the one on Google Play, is a repackaging incident. That finding does not require behavioural analysis and generally belongs with brand protection the same day, because the distribution channel is still live.

Droidwatch checks package identity against Play and examines the signing certificate as part of the same analysis. Certificate reuse across apparently unrelated applications is frequently the most productive pivot available from a single sample, because it links campaigns that share nothing else.

Distribution

The technical capability set explains what the malware does once installed. It does not explain how it arrives, and in the Latin American and Iberian markets the delivery routes are consistent enough to be worth stating:

• Smishing with an update pretext. A message claiming the banking application requires a mandatory update, linking to a package outside Play.
• Voice-led installation. A caller presenting as the institution's fraud department walks the victim through enabling installation from unknown sources and granting the accessibility prompt. This route defeats most on-device warnings, because the victim is being coached past them in real time.
• Alternative stores and aggregator sites. Repackaged versions of legitimate banking applications, frequently with the correct name and icon and an incorrect signing certificate.

All three share a property that matters for defence: the malicious package never passes through the institution's own release pipeline. Detecting it is a monitoring problem, not a build problem.

What static analysis establishes, and what it does not

Everything described above is visible without executing the sample. Static analysis establishes capability: what the application is able to do.

It does not establish behaviour. An application able to intercept SMS may never do so, or may do so only on instruction from its command-and-control server. Where a decision turns on runtime behaviour, dynamic analysis is required — and on Droidwatch that is Android only, executing against the customer's own device or emulator through the Droidwatch agent, available from the Pro plan. No sample executes on Droidwatch infrastructure.

For triage purposes the distinction rarely blocks a decision. A package carrying the full capability set, signed with a certificate that does not match the institution it claims to represent, does not require runtime confirmation to justify escalation. The triage workflow sets out the six steps that produce that classification, and the report walkthrough covers where each piece of evidence appears in the output.

Indicators extracted from samples analysed on the platform are published in the public threat feed under CC BY 4.0.

Have a sample? Upload an APK. No payment method required.