Inside Android Banking Trojans in 2026: Why SOVA, Hook, and Octo Are Winning Against Your Device

There is a feature in Android designed to help blind users navigate their phones. It's called the Accessibility Service. It allows an app, with the user's permission, to read everything on the screen, narrate it, and even tap, scroll, and type on the user's behalf. It's a critical accessibility tool and a genuine win for inclusive computing.

It is also the single most-abused feature in the Android ecosystem. Every meaningful Android banking trojan in 2026, including the ones currently active in your region, depends on the Accessibility Service to function. If you understand why, you understand the entire shape of the modern Android banking malware landscape.

This article explains what's actually happening when an Accessibility Service is granted to a malicious app, walks through the family tree of the major banking trojans, and gives you a defense playbook that works in 2026. I'll keep the technical depth at a level that's useful for defenders without requiring you to be a malware analyst.

The Accessibility Service, explained without the buzzwords

Android's permission model is generally well-designed. An app that wants your contacts has to request the contacts permission. An app that wants your microphone has to request microphone access. The user sees a dialog, taps Allow or Deny, and the app gets only what was granted.

The Accessibility Service is different. It's not a single permission. It's a service the user enables manually in Android Settings, by navigating into Settings, Accessibility, and toggling the malicious app's accessibility helper on. Because it's manually enabled rather than prompt-granted, Android's standard runtime permission UI doesn't apply. The user does it deliberately, often because the malicious app has shown a screen that says something like "To activate, please enable our accessibility helper."

Once active, the Accessibility Service can do roughly anything a user can do with their thumbs, plus several things a user cannot do. It can read the contents of every screen — the text in your banking app, the messages in your WhatsApp, the OTPs that appear in your notification shade. It can perform taps and swipes — open apps, dismiss prompts, type into text fields, approve transactions. It can grant additional permissions to other apps, including itself, by tapping through the permission dialogs faster than the user could intervene.

This is not a bug. The Accessibility Service is doing exactly what it was designed to do. The problem is that the same capability that lets a screen reader narrate a banking app to a blind user also lets a banking trojan exfiltrate everything the user types into that banking app and approve transfers on the user's behalf.

Google has been tightening Accessibility Service abuse over the years — the Play Store now reviews accessibility-using apps more strictly, Android 14 added stricter prompts, and Play Protect catches a lot of the obvious cases. None of this stops the malware that arrives via sideloaded APKs distributed through WhatsApp messages, scam SMS links, and phishing sites. The Play Store's protections only apply to the Play Store.

The Cerberus family tree

To understand the 2026 banking trojan landscape, you need to know the Cerberus story.

Cerberus appeared in 2019 as a Malware-as-a-Service offering on Russian-language cybercrime forums. It was one of the more capable Android banking trojans of its era, with overlay attacks, SMS interception, keylogging, and remote control. The author rented it out to other criminals on a subscription model.

In August 2020, after internal disputes between the developers, the full source code of Cerberus was leaked publicly. This is the moment the modern landscape starts. Once the code was free, anyone with moderate Android development skills could fork it, modify it, and ship a derivative.

The descendants began appearing almost immediately. Alien, in early 2020, was the first major fork — researchers later concluded it was actually built by ex-Cerberus developers who took the source code with them when they left. ERMAC followed in 2021, targeting over 450 banking and social media apps. Hook arrived in 2023 as a more sophisticated successor, sold by the same actor who had been running ERMAC. Octo, also a Cerberus descendant, became one of the most active families in 2024 and 2025. Phoenix surfaced in 2024 as essentially Cerberus with a new name. ErrorFather was identified by Cyble in 2024 as a fresh Cerberus-payload campaign.

The pattern across all of these is consistent. They share most of the same architecture: Accessibility Service abuse, overlay attacks on banking apps, SMS and notification interception, command-and-control communication with attacker servers, and increasingly, ATS (Automated Transfer System) modules that can perform fraudulent transactions without showing anything on the user's screen.

Separately from the Cerberus tree, SOVA emerged in 2021 as an independent banking trojan written from scratch. SOVA targets Spain, Italy, France, and increasingly Asian markets. The Nexus banking trojan, identified by Cyble in 2023 and still active in 2026, has been linked back to the SOVA group. Anubis, which predates Cerberus, also continues to evolve in private variants.

In practice, defenders in 2026 face a continuous stream of variants from these two main lineages, with new packaging, new obfuscation, and new distribution campaigns roughly every quarter.

What a 2026 Android banking trojan actually does, end to end

Let me walk through the lifecycle of a typical infection in 2026, drawing on the patterns documented by ThreatFabric, Cyble, Zimperium, and other mobile threat researchers.

The initial vector is almost always social engineering. A WhatsApp message from a compromised contact contains an APK file labeled as a wedding invitation, a delivery notification, a tax document, a bank update, or a traffic violation notice. Indonesian users get the bank-update and traffic-violation versions most often. The APK is not detected by antivirus on first scan because the dropper stage is benign — it's a small, unsigned application whose only job is to download the actual payload after installation.

The user installs the APK after enabling "install from unknown sources." The dropper runs, fetches the actual banking trojan payload from an attacker-controlled server, and triggers a permission flow that asks the user to enable an "accessibility helper for app stability" or similar phrasing. The user, having gotten this far, taps Enable, navigates to Accessibility settings, and toggles the service on. Game over.

From this point, the trojan operates silently in the background. It registers with its command-and-control server, sending the device model, Android version, list of installed apps, and contact information. The C&C server checks the installed app list against a target list — the major Indonesian banking apps for an Indonesian device, US bank apps for a US device, European apps for European devices. If matches are found, the C&C server sends back commands telling the trojan which specific apps to target.

When the user opens, say, the BCA mobile banking app, the trojan detects the launch via Accessibility events. It instantly draws a fake login screen on top of the real one — an overlay attack. The fake screen looks pixel-perfect identical to the real BCA login. The user types their user ID and PIN. The trojan captures both, dismisses the overlay, and lets the real app proceed. The user has no idea anything unusual happened.

In parallel, the trojan reads incoming SMS messages, looking for OTPs from the bank's verification flow. When an OTP arrives, the trojan exfiltrates it to the C&C server before the user even reads the SMS. The attacker now has username, PIN, and live OTP. They authenticate against the real bank from their own machine and initiate a transfer to a mule account.

The modern variants — Hook, Octo, the newer SOVA descendants — go further. Their ATS modules can perform the entire fraudulent transaction on the user's actual device, using Accessibility to tap buttons and type values directly into the real banking app. From the bank's fraud-detection perspective, the transaction comes from the legitimate device, with the legitimate fingerprint, from the legitimate IP. The behavioral signals that would normally flag remote fraud are absent.

This is why the 2026 banking trojan landscape is so dangerous. The malware isn't bypassing your bank's security. It's using your phone, with your authorizations, to operate normally — just on behalf of someone else.

What the defense actually looks like in 2026

The single most effective defense is mechanical. Do not install APK files from links. The vast majority of banking trojan infections in 2026 trace back to a sideloaded APK. The Play Store and the App Store, despite their flaws, do scan for known malware, do review apps before publishing, and do remove identified bad actors. Sideloaded APKs bypass all of that.

If you must sideload — for an open-source app, a legitimate developer's beta, an app from a country where the Play Store doesn't operate — verify the file's SHA-256 hash against the developer's official signed release. Yes, this is technical. Yes, most users won't do it. The point is that the bar for "trustworthy sideload" is high enough that, in practice, the answer is almost always to use the Play Store.

Review your installed Accessibility Services regularly. Open Settings, search for "Accessibility," and look at the list of installed accessibility services. Anything you don't recognize, disable. Anything you don't actively use, disable. The Accessibility Service is so dangerous that the principle of least privilege should apply aggressively here. I check this list quarterly on my own devices, and I have exactly one entry — Google's Live Caption — which is whitelisted because I use it.

Use Google Play Protect's enhanced protection, and check that it's actually enabled. Open the Play Store, tap your profile icon, tap Play Protect, tap Settings, and verify that "Scan apps with Play Protect" and "Improve harmful app detection" are both on. This won't catch every banking trojan, but it catches a meaningful percentage of the older Cerberus-derived families.

Keep your device on the latest Android version that your manufacturer supports. The mitigations against Accessibility Service abuse have improved meaningfully in Android 13, 14, and 15. If your phone is stuck on Android 11 because the manufacturer stopped releasing updates, that phone is structurally less safe for banking. This is an unpopular thing to say, but it's true.

For your banking apps specifically, enable any device-binding or biometric-binding feature the bank offers. Most major Indonesian and global banks now support a feature where the app will only work on a single registered device, and re-registering on a new device requires a separate verification flow. This breaks the ATS module's assumption that the original device is the one performing the transaction.

If you suspect infection — battery drain that's unusual, your device feels sluggish, you see authorization prompts you didn't expect, or you find apps you don't remember installing — factory reset the device. I know this sounds drastic. It is the only reliable way to remove a banking trojan that has Accessibility Service privileges, because the trojan can prevent its own uninstallation through standard means by abusing exactly the same Accessibility capabilities that make it dangerous in the first place.

The bigger picture

The Android banking trojan landscape is not getting better. It is professionalizing. The actors behind these families operate like software companies — they ship updates, they have customer support for their criminal customers, they patch detection bypasses, they advertise new features. Hook 2.0 in 2024 added a remote-control feature comparable to TeamViewer. The 2026 SOVA variants include native Android screen-streaming that bypasses the need for any external remote-access tool. The trajectory is clear.

Google is fighting back through Play Protect improvements, stricter Accessibility Service review, and the ongoing reduction of sideload-friendliness in newer Android versions. Banks are fighting back through device binding, behavioral fraud detection, and biometric requirements. Both efforts work, partially.

The gap that remains is the user. A banking trojan in 2026 cannot install itself. It cannot grant itself Accessibility Service. It cannot bypass Play Protect on the Play Store. It can only succeed if the user sideloads an APK and toggles a switch in Settings. Both of those actions require deliberate, conscious decisions. The defense is to make those decisions deliberately, not in a rush, not under social pressure, and not because a stranger in a WhatsApp message told you to.

If you take one rule from this article: never enable Accessibility Service for any app you didn't deliberately seek out for accessibility purposes. If a freshly-installed app asks for it, the answer is no. The cost of refusal is that the app won't work. The cost of approval can be your bank account.