Perseus Android Banking Malware: Accessibility Abuse and Notes-App Theft

Executive summary

Perseus is an Android banking malware family reported in March 2026. Its notable behavior is the abuse of Android Accessibility Services to automate interaction with the device and inspect information visible on screen. Reporting from Broadcom, ThreatFabric, and BleepingComputer describes a campaign that goes beyond banking-app overlays: the English variant can search common note-taking applications for passwords, PINs, recovery phrases, and other secrets.

The exact package names, distribution lures, commands, and affected regions can change between samples. Treat this article as a defensive overview, not as a claim that every APK calling Accessibility is Perseus.

Why Accessibility Services matter

Accessibility APIs are designed to help users interact with Android devices. Once a malicious app receives the permission, it may be able to observe UI elements, read visible text, click controls, navigate between screens, and in some cases capture screen content. That authority can turn a user-approved permission into account takeover or on-device fraud.

The permission is therefore a strong risk signal, not a verdict by itself. Legitimate accessibility tools exist. The security question is whether the application’s purpose matches the permission and whether the device or enterprise policy allows the combination of Accessibility, overlay, SMS, notification, and screen-capture capabilities.

Observed attack flow

Perseus samples have been associated with phishing and unofficial distribution channels. Lures can imitate streaming or utility applications, a system update, or another service that appears to need “full features.” The common step is persuading a user to install an APK and activate a highly privileged service.

Do not infer that an app is safe because it has a familiar icon or a convincing permission explanation. Verify the publisher, signing certificate, distribution channel, requested permissions, and update path.

2. Accessibility activation

After installation, the app guides the user to Android’s Accessibility settings. If the service is activated, the malware can interact with other apps under the user’s session. The victim may see a legitimate banking screen while the malware reads the UI or performs actions in the background.

3. Notes-app discovery and screen collection

The unusual feature highlighted by researchers is a command that checks for note-taking applications and opens them one by one. The malware can search visible text for credentials and recovery phrases. ThreatFabric also reported screenshot and remote-interaction capabilities in analysed samples.

Plain-text notes are a high-value target because they often contain passwords, card details, seed phrases, and recovery codes in a single place. A password manager with a strong device and vault policy is safer than an ordinary note, but it still needs its own threat model.

4. Overlay and automated transaction abuse

Banking trojans commonly combine Accessibility with overlays, SMS or notification access, and automated transfer flows. The malware can display a fake login surface, read one-time codes, or navigate an already authenticated application. Whether a particular Perseus sample supports each capability must be verified from the sample; the family label should not be used as a shortcut for unsupported claims.

Indicators worth reviewing

On a device or MDM console, investigate:

an unknown or recently installed app requesting Accessibility Services;
Accessibility activated for an app that has no assistive-technology purpose;
unexpected “draw over other apps,” SMS, notification, or screen-capture permissions;
an app installed from an unofficial store, messaging attachment, or fake update page;
repeated launches of note-taking or banking apps without a matching user action;
unusual foreground-service activity, screen captures, or outbound traffic after banking use;
new device-admin, VPN, or unknown profile settings.

These signals are triage leads, not proof of infection. Preserve the package, version, signing information, permissions, and relevant device logs before removing evidence.

Containment and recovery

For users

Disconnect the device from sensitive accounts if compromise is suspected; avoid entering new credentials on it.
From a clean device, contact the bank or exchange and report possible session or transaction compromise.
Revoke suspicious Accessibility, overlay, notification, SMS, VPN, and device-admin permissions.
Remove the suspicious app only after collecting basic evidence if an investigation is required.
Rotate passwords and recovery codes from a clean device; invalidate active sessions and API keys.
Review bank, email, cloud, and password-manager activity for unauthorized changes.
If persistence or full device takeover is suspected, use the organization’s approved rebuild or factory-reset process.

For enterprises

Use MDM to restrict sideloading and unknown sources where business requirements allow.
Maintain an allowlist of apps and certificate identities for managed devices.
Alert on new Accessibility services and unusual combinations of high-risk permissions.
Bind high-risk transactions to device integrity, user intent, transaction context, and step-up authentication.
Monitor mobile API sessions for impossible travel, device changes, rapid beneficiary creation, and unusual transfer patterns.
Test the mobile app and backend together; certificate pinning does not stop a compromised user session.
Prepare a playbook for device quarantine, session revocation, fraud review, and evidence preservation.

What mobile security testing should cover

An assessment should include the APK and the service backend:

Area	Test question
Permission design	Does the app request only permissions required for its stated function?
Device binding	Can a stolen session or altered device perform high-risk actions?
Overlay and accessibility	Does the app detect or safely respond to suspicious UI automation?
Transaction controls	Are amount, beneficiary, device, and user intent checked server-side?
OTP and recovery	Can a screen reader, overlay, or notification path bypass step-up controls?
Telemetry	Can fraud and security teams link device, session, API, and transaction events?

No single control can identify every accessibility-abusing trojan. Layered device policy, application integrity, backend fraud signals, and rapid session revocation reduce the blast radius.

Frequently asked questions

Is every Accessibility-enabled app malicious?

No. Accessibility is a legitimate Android capability. The warning sign is an unexpected app requesting it, especially when combined with overlay, SMS, notification, or screen-capture permissions.

Can Play Protect guarantee that a device is clean?

No security product provides a universal guarantee. Official distribution, updates, device protection, and user awareness reduce risk; organizations still need MDM, application controls, and incident response.

Should sensitive information be stored in a notes app?

Avoid storing passwords, card data, recovery phrases, or one-time codes in plain text. Use an approved password manager or hardware-backed process and protect the recovery path separately.

Does mobile app pentesting prevent device malware?

No. It can reveal weak device binding, overlay handling, API authorization, and transaction controls. Endpoint and user controls are still required for malware delivered outside the application.