> For the complete documentation index, see [llms.txt](https://docs.talsec.app/appsec-articles/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.talsec.app/appsec-articles/articles/droppers-how-banking-trojans-get-onto-android-phones-and-how-talsec-breaks-the-chain-early.md).
# Droppers: how banking trojans get onto Android phones — and how Talsec breaks the chain early
**TL;DR** — Most Android banking trojans are not installed by the victim directly. They arrive through a **dropper**: a harmless-looking app, usually sideloaded, whose only real job is to install the trojan it carries inside. Droppers ask for almost nothing, which is exactly what makes them easy to miss — and exactly what makes them detectable. Talsec's malware detection flags them **on behaviour alone, offline, before the trojan exists on the device**, and the rest of the trojan's toolkit (screen reading, screen streaming, OTP theft, ADB abuse) maps onto controls that are already in the Talsec SDK.
***
## Talsec controls vs. a dropper-delivered banking trojan
| Attacker capability | What it attacks | Talsec control |
| ---------------------------------------------------------------------- | ---------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Installs further packages** (the dropper stage) | Distribution / installation source | **Malware detection** flags sideloaded apps that hold `REQUEST_INSTALL_PACKAGES` |
| **Reads the screen, logs the PIN pad, taps buttons** via Accessibility | Credentials, device takeover | **Accessibility protection** hides sensitive UI from unknown services (`importantForAccessibility`, `setAccessibilityDataSensitive`); known assistive services such as TalkBack stay allowlisted |
| **Streams the live screen** to the operator | Screen content, remote control | **ScreenProtector** detection + `Talsec.blockScreenCapture(activity, true)` (`FLAG_SECURE`) |
| **Reads and deletes OTP SMS** | Second factor | **Malware detection** flags SMS / OTP stealers in offline mode |
| **Grants itself a privileged shell** over wireless ADB | Persistence, full device control | Standard RASP checks **`onAdbEnabled()`** and **`onDebug()`** |
These controls protect the device side. Server-side controls (device binding, a cooling-off period for new payees, out-of-band confirmation) remain the layer that stops the money if a device is fully compromised.
***
## What is a dropper?
A dropper is the **first stage** of a mobile malware infection. It is a small, ordinary-looking app — often a fake streaming, video or utility app — that the victim is persuaded to sideload from a link, a messaging app or a fake store page. It does not steal anything itself. It exists to get a second app, the real banking trojan, onto the phone.
That split is deliberate. The dropper looks clean to a quick inspection, so it survives the moment the user installs it. The trojan, which needs dangerous permissions such as Accessibility, only appears later, installed by the dropper rather than downloaded by the user.
### A typical infection chain
```mermaid
flowchart LR
A[Victim is lured to sideload a fake app] --> B[Dropper asks for 'Install unknown apps']
B --> C[Dropper unpacks and installs the banking trojan]
C --> D[Trojan requests Accessibility]
D --> E[Screen reading, OTP theft, remote control, fraud]
```
1. The victim is lured into sideloading a fake app from outside an official store.
2. The dropper obtains the "install unknown apps" right and installs the trojan from its own encrypted payload.
3. The trojan asks for Accessibility and, once granted, takes over: it reads the screen, captures the PIN, intercepts OTPs and lets the operator drive the device.
## The permission profile: almost nothing, on purpose
Droppers in this class declare very few permissions. A typical manifest holds network access, notifications, a wake lock and **one** that matters:
`android.permission.REQUEST_INSTALL_PACKAGES`
There is no Accessibility service, no SMS permission and no device-admin receiver at this stage. Every one of those belongs to the trojan, which is a separate package installed later.
## Why these apps are droppers
* **The install right is the whole point.** `REQUEST_INSTALL_PACKAGES` with no other dangerous permission is the classic dropper profile. A streaming or utility app has no legitimate reason to install other apps.
* **The payload is packed inside.** Most of the app's size is an encrypted blob with no recognisable file header, sometimes paired with a native loader, plus a receiver that tracks whether the install succeeded.
* **Protection gets switched off first.** Some droppers start a local VPN service so that Google Play Protect is cut off from the network while the payload installs.
* **The real trojan is a separate package.** It carries the Accessibility service and the device-admin receiver, so the dangerous capabilities never appear in the app the user actually chose to install.
***
## How Talsec catches the dropper
Talsec's malware detection, running with its **default configuration in offline mode**, flags this kind of dropper **on behaviour alone**. No signature database and no cloud lookup are needed. Two independent signals fire for each dropper:
| Signal | What it means |
| ---------------------- | ------------------------------------------------------------------------------------------- |
| `installSource` | The app did not come from a trusted store (it was sideloaded). |
| `suspiciousPermission` | The app holds a permission on the high-risk list, here the right to install other packages. |
Because detection looks at **where the app came from and what it can do**, not at its package name or label, the usual evasion tricks — random package names, invisible Unicode characters in the app name, freshly re-signed builds — have no effect.
{% hint style="success" %}
**This is the earliest point you can react.** The dropper is the first thing on the device. Flagging it lets your app respond **before the trojan is installed and before Accessibility is ever granted.**
{% endhint %}
## How Talsec covers the trojan's toolkit
If the trojan does make it onto the device, each of its core abilities maps onto a control that already exists in the Talsec SDK.
### a) Installs further packages
**Threat.** The dropper holds `REQUEST_INSTALL_PACKAGES` and uses it to install the banking trojan.
**Talsec coverage.** Malware detection flags sideloaded apps holding this permission. The trojan the dropper installs is also sideloaded — its installer is the dropper, not a trusted store — so it falls inside the same sideloaded-apps scan scope.
### b) Reads the screen, logs the PIN pad, taps buttons
**Threat.** The trojan uses an Accessibility service to read the live UI tree, log PIN entries, and click or type into the real banking app.
**Talsec coverage.** Accessibility protection hides sensitive UI from unknown services. When an unknown accessibility service is detected, the SDK protects UI elements using `importantForAccessibility` and `setAccessibilityDataSensitive`, so the trojan cannot read PIN digits or locate buttons through the accessibility tree. Well-known assistive services such as Google TalkBack are allowlisted, so users who rely on screen readers are not affected.
### c) Streams the live screen to the operator
**Threat.** The trojan streams the screen (for example via MediaProjection) so the operator can watch and drive the device remotely.
**Talsec coverage.** The ScreenProtector feature detects when the screen is being recorded or mirrored. Combine it with `Talsec.blockScreenCapture(activity, true)`, which uses several techniques including `WindowManager.LayoutParams.FLAG_SECURE`. Apps trying to capture the screen then see only a black image.
### d) Reads and deletes OTP SMS
**Threat.** The trojan reads incoming SMS one-time passwords, types them into the app and deletes them so the victim never sees them.
**Talsec coverage.** SMS and OTP stealers are covered by offline malware detection. The default configuration treats SMS permissions (`READ_SMS`, `RECEIVE_SMS`, `RECEIVE_WAP_PUSH`) as suspicious, alongside `BIND_ACCESSIBILITY_SERVICE`, `BIND_DEVICE_ADMIN`, `QUERY_ALL_PACKAGES` and `REQUEST_INSTALL_PACKAGES`. The final trojan is flagged on the same signals the attack depends on.
### e) Grants itself a privileged shell over wireless ADB
**Threat.** The trojan uses Accessibility to enable Developer Options and Wireless Debugging, then pairs ADB with itself to get shell-level access and persistence.
**Talsec coverage.** This is standard RASP functionality. The `onAdbEnabled()` callback reports that ADB (including wireless debugging) is on, and `onDebug()` reports debugging. For this malware class, ADB switching on unexpectedly on a customer's phone is a strong compromise signal.
***
## Mitigation plan
Detection only protects your users if the app acts on it. The steps below turn each Talsec signal into a response.
* [ ] **Enable offline malware detection** with the default configuration.
* [ ] **Turn on accessibility protection** for all sensitive screens (login, PIN entry, payments).
* [ ] **Enable ScreenProtector** and call `Talsec.blockScreenCapture(activity, true)` on all sensitive screens.
* [ ] **Treat `onAdbEnabled()` and `onDebug()` during a session as high risk:** step up authentication or block transfers rather than only logging.
* [ ] **Send all Talsec signals to your backend** so the risk engine decides, alongside device binding, a cooling-off period for new payees and velocity limits.
{% hint style="warning" %}
**Remaining risk: a fully compromised device.** Client-side checks raise the cost of the attack considerably, but they cannot guarantee a clean device. Server-side controls remain the final barrier.
{% endhint %}
***
*Protect your Android apps against dropper-delivered banking trojans with* [*freeRASP*](https://github.com/talsec/Free-RASP-Community) *and* [*RASP+*](https://talsec.app/)*. Talsec does not distribute or endorse malware; this article describes the attack pattern for defensive purposes.*
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.talsec.app/appsec-articles/articles/droppers-how-banking-trojans-get-onto-android-phones-and-how-talsec-breaks-the-chain-early.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
