> 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/defending-mobile-banking-apps-against-the-rokarolla-trojan.md). # Defending Mobile Banking Apps Against the Rokarolla Trojan In June 2026, security researchers published research on a new Android banking trojan they named **Rokarolla**, after its command-and-control servers. Within days it was being tracked against **217 banking and cryptocurrency apps**, driven by a toolkit of roughly **137 remote commands**. The malware takes over the device, silences main security countermeasures, intercepts the channels a bank would normally use to warn the user, and runs fraud while the victim sees nothing unusual. This guide is for the people who have to react to that: Android engineers, security architects, and product owners at banks and fintechs. We will walk through how Rokarolla works, then map each behaviour to a concrete Talsec defence guiding you to understand where client-side security can stop the attack and where it can only flag it so your backend can respond.
### Rokarolla behaviour mapped to Talsec protections Talsec makes **your app aware** that the device is compromised, early enough to change how the session behaves. Mapping against these four Talsec SDK products: 1. [freeRASP](https://docs.talsec.app/freerasp/freerasp/introduction) (free) and [RASP+](https://docs.talsec.app/premium-products/product/rasp) (premium) 2. [freeMalwareDetection](https://docs.talsec.app/freerasp/freemalwaredetection/introduction) (free) and [Malware Detection](https://docs.talsec.app/premium-products/product/malware-detection) (premium) | Rokarolla behaviour | What it does | Talsec protection | | ---------------------------------------------------------------------------------------------------- | -------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Sideloaded dropper** (fake Chrome/TikTok, poses as Play Protect) | Gets installed from a browser/website instead of a store |

Scan for sideloaded apps

available both in freeMalwareDetection,
Malware Detection

| | **Second-stage payload on the device** with Accessibility + SMS + Call-handler + overlay permissions | The actual malware sitting alongside your app |

Malware Detection scanner (onMalwareDetected) — package/hash blocklists + permission-based detection; the online App Reputation API confirms known Rokarolla APK samples.

available both in freeMalwareDetection (basic protection) and Malware Detection. App Reputation API is available only on premium plan.

| | **Fake login & lock-screen overlays** drawn on top of your app | Captures PIN, pattern, password, card data | **Overlay Protection** available in *RASP+*. | | **Accessibility abuse** — UI scraping, keylogging, on-screen text extraction, automated transfers | Reads and drives your app's UI | **Accessibility Service Misuse Protection** in *RASP+*. | | **Screen logging / screenshot exfiltration** via Accessibility | Ships screenshots of your app one frame at a time | **Screen capture blocking** (`blockScreenCapture`) + screenshot/recording detection available both in *freeRASP* and *RASP+*. | ### How Rokarolla actually works The kill chain is straightforward, which is part of why it works. ``` [Phishing / smishing site] → fake "Chrome"/"TikTok" APK │ (sideload) ▼ [Dropper, posing as Google Play Protect] │ disables Play Protect, requests permissions ▼ [Accessibility · SMS handler · Call handler · Overlay] │ downloads core payload ▼ [Device takeover + information vacuum] ├─ Fake overlays → capture PIN / pattern / credentials ├─ Keylogger + UI scraping (Accessibility) ├─ OTP interception (default SMS/call handler) └─ Mutes audio, hides icon, keeps screen on → victim never notices ``` **Distribution.** Rokarolla never touches the Play Store. It spreads through rogue sites advertising popular apps. The user is pushed to download an APK directly — sideloading — and the first thing they install is a dropper dressed up as Google Play Protect. **Privilege escalation.** Once running, the dropper fetches the payload and asks for the permissions that make everything else possible: Accessibility Services, notification access, and the **default SMS and call handler** roles. One of its early commands disables Play Protect so it can stay hidden. **Execution and isolation.** When the victim opens a targeted app, Rokarolla draws a pixel-matched fake login page over the real one and records everything typed. It keylogs (``), scrapes on-screen text, and — instead of the noisy live screen-casting older families used — quietly takes screenshots through Accessibility and exfiltrates them frame by frame. To finish a fraudulent transfer it suppresses audio and vibration, hides its icon, blocks incoming calls, and consumes the bank's OTP SMS directly. The user holds a phone they think they control while someone else drives it. That last part is the real innovation, and it is why detection has to happen *client-side and early*. By the time your backend sees an anomaly, the OTP has already been intercepted. ### Why standard app hardening is not enough Obfuscation (R8/ProGuard) protects your code from reverse engineering. It does nothing against an overlay drawn on top of your running app. Certificate pinning guarantees a secure channel to your backend. It cannot help when Accessibility scrapes the data off the screen *before* it is ever encrypted. The gap is the **device environment** itself. A banking app needs to answer a different question: *is this device safe to transact on right now?* Three properties matter for a real-world deployment: * **No performance friction.** Banking users abandon apps that stutter or drain the battery. Scanning has to run in the background, off the UI thread. * **Zero-day reach.** A brand-new Rokarolla build won't be in any signature database yet. The defence has to recognise the *risk profile* — sideloaded source plus dangerous permission combinations — not just known hashes. * **Low false positives.** Block a legitimate user because they have a harmless accessibility tool installed, and your support desk drowns. The response has to be proportionate. This is exactly the shape of Talsec's layered model. ### The Talsec approach: detect the environment, then react Talsec doesn't sit between the malware and the OS. It runs inside *your* app, watches the environment, and fires callbacks you decide how to handle. Against Rokarolla, four layers do the work. **1. Malware scanning.** [freeMalwareDetection](https://docs.talsec.app/freemalwaredetection) (the free community variant) and the premium [Malware Detection](https://docs.talsec.app/premium-products/product/malware-detection) product scan installed apps in the background. Locally, they use package-name and hash blocklists plus **permission-based risk scoring**: the combination of *sideloaded source + Accessibility + overlay capability* is a high-confidence indicator of an app like Rokarolla's payload. The premium tier adds an online App Reputation API to confirm known strains. **2. Untrusted installation source.** Rokarolla's dropper arrives from a browser, not a store. `onUntrustedInstallationSourceDetected` flags your *own* app's install origin, and the malware scanner's source filtering does the same for other apps on the device. **3. Overlay and Accessibility-misuse protection.** This is where [RASP+](https://docs.talsec.app/premium-products/product/rasp) earns its place. Rokarolla's entire credential-theft mechanism is built on overlays and Accessibility-service abuse. RASP+ is designed specifically to detect overlay attacks, screen readers, and Accessibility misuse — the techniques at the centre of this trojan. **4. Screen-capture blocking.** Rokarolla exfiltrates screenshots through Accessibility. freeRASP can detect screenshots and recordings, and — more usefully here — actively block capture with `Talsec.blockScreenCapture(activity, true)`, which renders sensitive screens as black to a screen logger. A note on what is *not* in this list: SMS and call interception. Once an app holds the default SMS/call-handler role, no in-app SDK can stop it reading messages. Talsec's contribution is upstream of that — it tells your app the device is compromised, so your backend can stop trusting SMS OTP on that session entirely and fall back to phishing-resistant authentication. ### Integration Malware detection ships as part of freeRASP, so a single integration gives you the malware callback plus the rest of the RASP checks. The steps below follow the official [Android integration guide](https://docs.talsec.app/freerasp/freerasp/integration/android); see it for the full configuration reference. #### Add the dependency Register Talsec's artifact repository in your project's `settings.gradle` (keep it last): ```groovy // settings.gradle (:project) repositories { google() mavenCentral() maven { url "https://jitpack.io" } maven { url "https://europe-west3-maven.pkg.dev/talsec-artifact-repository/freerasp" } } ``` ```groovy // app/build.gradle dependencies { implementation 'com.aheaditec.talsec.security:TalsecSecurity-Community:18.0.2' } ``` #### Initialise in your Application class Start Talsec in `onCreate` so protection is live before any screen loads. Run it in `TalsecMode.BACKGROUND` to keep it off the UI thread. ```kotlin class BankApplication : Application() { override fun onCreate() { super.onCreate() val config = TalsecConfig.Builder(EXPECTED_PACKAGE_NAME, SIGNING_HASHES) .watcherMail("security@yourbank.example") .supportedAlternativeStores(arrayOf("com.sec.android.app.samsungapps")) .prod(true) .killOnBypass(true) .build() ThreatListener(threatListener).registerListener(this) Talsec.start(this, config, TalsecMode.BACKGROUND) } } ``` #### Handle the Rokarolla-relevant threats You only override the callbacks your policy cares about. For this threat model, these are the ones that matter — kept high-level here; in practice each one feeds a risk engine rather than acting directly: {% hint style="info" %} APKs hashes available [here](https://github.com/Zimperium/IOC/blob/master/2026-06-Rokarolla/apks.csv) {% endhint %} ```kotlin val detectionConfig = SuspiciousAppDetectionConfig( // Known Rokarolla hashes (see the link above) hashes = setOf("755ee39ff11bad65193c4806cadb9cedda41e20663c35494cb7d4e9646ddcf21"), // Flag any app whose manifest requests one of these permission sets... requestedPermissions = setOf( setOf("android.permission.READ_SMS"), setOf("android.permission.BIND_ACCESSIBILITY_SERVICE"), setOf("android.permission.REQUEST_INSTALL_PACKAGES") ), // ...and raise confidence when the dangerous one is actually granted grantedPermissions = setOf( setOf("android.permission.BIND_ACCESSIBILITY_SERVICE") ), // Only look at sideloaded apps; trust Google Play malwareScanScope = MalwareScanScope( scanScope = ScopeType.SIDELOADED_ONLY, trustedInstallSources = listOf("com.android.vending") ), ... ) ... ``` } #### Block screen capture on sensitive screens Hook this into `ActivityLifecycleCallbacks` so it covers the whole app, and switch it on for screens showing balances, OTPs, or transfer confirmations: ```kt // Render the screen black to any screen logger Talsec.blockScreenCapture(activity, true) ``` ### Mapping detection to product decisions Detection is only useful if it changes what your app does. A practical pattern is a small risk engine that collects Talsec signals and applies different policies to different user actions. **Login.** If Talsec reports an untrusted source plus an installed app abusing Accessibility, don't pre-fill the password field and don't fall back to SMS OTP — that's exactly the channel Rokarolla owns. Use in-app biometric or key-pair validation instead, so a screen capture or intercepted SMS yields nothing useful. On a confirmed malware match, end the session and show a full-screen block explaining the device needs cleaning. **High-value transfers (ACH, P2P, bill pay).** If an overlay-capable app is active in the background, intercept the transfer path. Require out-of-band biometric signing (FIDO2/WebAuthn). Rokarolla's automated transfer flow depends on masking confirmation inputs; changing the verification sequence breaks the script. **Profile changes (password reset, MFA device registration).** These are what an attacker goes after to make persistence permanent. On any unverified-environment signal, halt and require live verification or a cooling-off delay, and push the event to your fraud backend for review. The principle throughout: **proportionate response.** A clean session sees zero friction. A genuinely compromised one gets contained at the exact moment it matters. ### Summary Rokarolla is a good stress test for a mobile security posture because it attacks at the device layer. The defence is to make your app aware of its environment and react before the user transacts. * **For developers:** one freeRASP integration gives you the malware callback, untrusted-source detection, and screen-capture blocking, all running in the background with a clean Kotlin API. * **For architects:** local heuristics keep working offline; the App Reputation API adds confirmed-malware coverage online. The combination fails secure either way. * **For product owners:** detection maps directly to graduated responses — allow, step-up, or block — so security tracks the actual threat level instead of punishing clean users. No client-side SDK removes a trojan from a phone. But detecting it early, honestly, and acting on it is the difference between a flagged session and a drained account. **Start here:** * [freeRASP & freeMalwareDetection](https://docs.talsec.app/freerasp/freerasp/integration/android) * [Malware Detection (premium)](https://docs.talsec.app/premium-products/product/malware-detection) * [RASP+ (premium)](https://docs.talsec.app/premium-products/product/rasp) --- # 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 dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.talsec.app/appsec-articles/articles/defending-mobile-banking-apps-against-the-rokarolla-trojan.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.