Security teams spend considerable effort protecting credential stores, password managers, and SMS-based OTPs — and attackers know it. Perseus, a newly identified Android banking trojan documented by ThreatFabric, sidesteps most of those defenses entirely by going after something defenders have largely ignored: the notes app sitting on every user's phone, filled with Wi-Fi passwords, crypto seed phrases, and "temporary" credential lists that have been there for three years.
Perseus is distributed through unofficial app stores disguised as IPTV streaming applications. Once installed, it requests Accessibility Services permissions — a permission abuse pattern that has been the backbone of Android trojans since at least 2019 — and from there gains effectively unlimited control over the device. What separates Perseus from the crowded field of Android banking malware is a dedicated module that systematically scans Google Keep, Samsung Notes, Xiaomi Notes, Evernote, and Microsoft OneNote for sensitive text. ThreatFabric describes this as the first instance of Android malware explicitly designed to harvest personal notes at scale. This article breaks down how Perseus operates, what makes it difficult to detect, and what mobile security teams and users should actually do about it.
How Perseus Gains and Maintains Device Control
The Initial Compromise: Fake IPTV Apps
Perseus enters devices through sideloaded APKs on third-party app stores — platforms that lack Google Play Protect's review process. The IPTV lure is well-chosen: users seeking free streaming content are already self-selecting for a higher risk tolerance, and IPTV apps legitimately require a broad set of permissions (network access, storage, display over other apps) that don't immediately raise flags.
After installation, Perseus follows the standard Accessibility Services abuse chain:
- Prompts the user to enable Accessibility Services with a social engineering overlay ("required for app functionality")
- Once granted, uses the Accessibility Services API to read screen content, simulate taps and gestures, and suppress uninstallation attempts
- Establishes persistence by preventing the user from navigating to the app in Settings — a technique that maps to MITRE ATT&CK Mobile T1629.003 (Impair Defenses: Prevent Application Removal)
- Registers the device with the command-and-control (C2) server, including a device fingerprint and a calculated "suspicion score" used to filter out sandbox environments
The suspicion score is worth noting. Perseus checks for root access, running emulators, common mobile analysis frameworks, and device properties inconsistent with a real end-user handset. Devices that score above a threshold receive no further tasking — a deliberate design choice to slow down malware analysis and preserve operational security.
Core Banking Trojan Capabilities
Before reaching the notes-scanning module, Perseus establishes the standard capabilities expected from a modern Android banking trojan:
| Capability | Mechanism | Primary Target |
|---|---|---|
| Overlay attacks | Draws fake login screens over legitimate banking apps | Banking credentials, payment apps |
| Keylogging | Captures keystrokes via Accessibility Services event listeners | All text input |
| Screenshot capture | Periodic or trigger-based screen capture | MFA tokens, payment confirmations |
| UI interaction | Simulates taps to approve transactions, dismiss alerts | Authorized push payment fraud |
| SMS interception | Reads incoming SMS for OTP codes | SMS-based two-factor authentication |
| Screen recording | Continuous recording on demand from C2 | Session hijacking, credential capture |
This feature set alone would make Perseus a significant threat. The notes-scanning capability is layered on top — and it is where the operational novelty lies.
The Notes-Scanning Module: A New Attack Surface
Why Attackers Are Targeting Notes Apps
The shift toward harvesting personal notes reflects a broader attacker insight: users curate and store their most sensitive information in places that feel private but offer no security. A password manager encrypts its vault. A notes app does not. Anecdotal analysis of mobile incident response cases consistently surfaces the same pattern — recovery phrases for cryptocurrency wallets written in Keep, shared Wi-Fi passwords in Evernote, and plaintext credentials in device notes "just until I set up a proper password manager."
Perseus explicitly targets the following applications:
- Google Keep
- Samsung Notes
- Xiaomi Notes
- Evernote
- Microsoft OneNote
The module uses Accessibility Services to read note content without triggering any permission prompt — no additional access request is needed beyond what was already granted. The malware scans note text for high-value patterns: seed phrases (12 or 24 random words), passwords, recovery codes, and private key material. Matched content is exfiltrated to the C2 server.
Important: This attack requires no special permissions beyond Accessibility Services. Any Android malware that has obtained Accessibility Services access can, in principle, read the contents of any app visible on screen — including notes. The Perseus module makes this systematic and automated. Treating notes apps as a secure credential store was never safe; this malware makes the consequences concrete.
What "Contextual Data Harvesting" Actually Means
ThreatFabric characterizes Perseus as a shift toward harvesting "contextual, user-curated data." In practical terms, this means attackers are moving beyond the transactional (intercept this OTP, capture that password field) toward the archival: collect everything the user has deliberately written down and stored.
The operational value is significant. A single successful note exfiltration from a crypto-active user might yield wallet seed phrases worth far more than any individual banking credential. For corporate users, notes frequently contain VPN credentials, internal URLs, and API keys copied during onboarding or troubleshooting. From an attacker's perspective, these are high-value, low-noise targets that were previously accessible only through phishing or physical access.
Anti-Analysis Capabilities and Why They Matter for Detection
Perseus includes a multi-layered anti-analysis framework that complicates both automated detection and manual reverse engineering:
| Anti-Analysis Technique | What It Checks | Effect on Detection |
|---|---|---|
| Root detection | su binary, Magisk, SuperSU, busybox | Avoids execution on rooted analysis devices |
| Emulator detection | Build properties, hardware identifiers, sensor absence | Halts payload on AVDs and most mobile sandboxes |
| Device fingerprinting | IMEI, device model, installed apps | Generates suspicion score; C2 withholds commands if score is high |
| Timing checks | Execution speed relative to human interaction | Flags automated testing environments |
| Analysis tool detection | Frida, Xposed, common hooking frameworks | Detects dynamic analysis instrumentation |
The C2 feedback loop — where the device sends its suspicion score and receives conditional tasking — means that security researchers analyzing Perseus in a standard mobile sandbox may observe a largely inert sample. This is intentional. It increases the time between discovery and published analysis, giving the malware more operational runway.
Pro Tip: Mobile SOC and MDR teams should treat behavioral telemetry from production devices as a more reliable detection signal than sandbox detonation results for mature Android trojans. If a device is generating Accessibility Services events for multiple apps in rapid succession — especially across banking, messaging, and note-taking apps — that behavioral pattern is more indicative of malware activity than any single static signature.
Detection, Response, and Hardening for Mobile Security Teams
Detection Signals Worth Monitoring
Given Perseus's anti-analysis capabilities, signature-based detection is likely to lag. The more reliable detection approach focuses on behavioral signals observable through Mobile Device Management (MDM) or Endpoint Detection and Response (EDR) tools deployed on managed devices:
- Accessibility Services enabled for a recently installed, non-Play Store app
- High volume of Accessibility Services events across multiple app categories in a short window
- Network connections to newly registered or low-reputation domains from a device that recently sideloaded an APK
- Battery drain and data usage anomalies consistent with background screen recording
For organizations subject to HIPAA, PCI DSS, or SOC 2 compliance, unmanaged personal devices accessing corporate resources represent a direct control gap. Perseus targeting corporate-connected personal phones is a realistic scenario — BYOD policies that permit access to email, document repositories, or internal systems without MDM enrollment create meaningful exposure.
Remediation and Hardening Measures
| Control | Implementation | Framework Reference |
|---|---|---|
| Block sideloading on managed devices | MDM policy enforcing Play Protect and disabling "Unknown Sources" | CIS Controls v8, Control 2.7 |
| Restrict Accessibility Services | MDM allowlist for permitted Accessibility apps | NIST SP 800-124 Rev. 2 |
| Mobile threat defense (MTD) | Deploy MTD agents to detect overlay and Accessibility abuse in real time | CIS Controls v8, Control 10.1 |
| User education on notes security | Communicate explicitly that notes apps are not secure credential stores | ISO 27001, A.7.2.2 |
| Incident response playbook for mobile | Include mobile device isolation and notes app compromise in IR procedures | NIST SP 800-61 Rev. 2 |
The user education point deserves emphasis. Technical controls alone will not address the underlying behavior that makes notes-based credential storage so prevalent. A targeted communication to employees — specifically naming notes apps and seed phrases — is more effective than a generic "don't store passwords insecurely" reminder.
Key Takeaways
- Audit your Accessibility Services policy immediately. Any MDM-managed device that permits arbitrary apps to hold Accessibility Services access is a Perseus-class threat waiting to happen. Build an allowlist and enforce it.
- Add a notes-specific line to your security awareness training. Employees storing credentials, recovery phrases, or API keys in Keep, Evernote, or OneNote need explicit guidance — not a general reminder about password hygiene.
- Behavioral detection outperforms signatures here. Build SIEM or MTD rules around Accessibility Services event volume and cross-app access patterns, not just hash-based or domain reputation indicators.
- Treat BYOD devices accessing corporate resources as a compliance issue. If unmanaged personal devices can reach internal systems or data, Perseus on that device is a data breach scenario under GDPR, HIPAA, and PCI DSS.
- Don't rely on sandbox detonation as your primary malware verdict. Perseus's suspicion scoring will suppress behavior in most automated analysis environments. Escalate to hands-on analysis or production behavioral telemetry when sandbox results are inconclusive for high-confidence phishing or sideload submissions.
Conclusion
Perseus does not represent a technical leap in Android malware capability — Accessibility Services abuse, overlay attacks, and SMS interception have been documented for years. What it represents is an attacker recognition that users have created a new, largely undefended data store on their own devices. The notes app is treated as a scratchpad, not a secrets vault, and that behavioral norm has turned it into a reliable exfiltration target.
For mobile security teams, the practical response is straightforward even if the execution requires work: enforce Accessibility Services restrictions through MDM, deploy behavioral monitoring that accounts for cross-app access patterns, and add a specific, concrete line to security awareness training about what should never live in a notes app. For individual users — especially those with cryptocurrency assets — the answer is simpler still: a seed phrase written in Google Keep is as exposed as a seed phrase written on a sticky note on the monitor. Do not store it there. Start a mobile security review this week before the next variant builds on what Perseus has proven works.
Frequently Asked Questions
How does Perseus actually get onto a device if it isn't on the Play Store? Perseus is distributed through unofficial third-party app stores and direct APK download links, typically promoted through piracy communities, Telegram channels, and social media posts advertising free IPTV streaming. Users download and manually install the APK, which requires enabling "Install from Unknown Sources" or "Allow from this source" in Android settings. This is why MDM policies that disable sideloading on managed devices are an effective preventive control.
Does enabling two-factor authentication protect against this malware? Partially. Perseus can intercept SMS OTPs and capture authenticator app codes through screen recording and keylogging, which undermines most common 2FA implementations. Hardware security keys (FIDO2/WebAuthn) are significantly more resistant because they require physical interaction and bind authentication to the specific origin — a process that overlay attacks cannot replicate. For high-value accounts, hardware keys are the only 2FA method that Perseus-class malware cannot reliably bypass.
Can Google Play Protect detect Perseus? Google Play Protect scans installed apps and can detect known malware signatures, but its coverage of sideloaded APKs is limited by user permission decisions and the speed of signature updates. Perseus's anti-analysis features and conditional C2 behavior are specifically designed to slow down detection pipeline analysis. Play Protect is a useful baseline control but should not be treated as sufficient on its own for high-risk users or managed device fleets.
What should a user do if they think their device is infected? Immediately revoke Accessibility Services for any unrecognized app via Settings → Accessibility. Change passwords for all accounts accessed from the device using a separate, trusted device. If the device had access to cryptocurrency wallets, treat all seed phrases stored on or accessed from that device as compromised and move assets to new wallets immediately. Report the incident to your IT or security team if the device also accessed corporate resources, as data breach notification obligations may apply.
Why are notes apps specifically targeted rather than password managers? Password managers encrypt their vaults, require a master password, and do not expose content through standard Accessibility Services text-reading APIs in the same way that notes apps do. Notes apps treat their content as displayable text — by design, since the user needs to read it. This makes notes content straightforwardly accessible via Accessibility Services event listeners. The targeting is not technically sophisticated; it is a rational response to the fact that users store sensitive material there with no protection, making it lower-effort and higher-yield than attacking a properly implemented password manager.
Enjoyed this article?
Subscribe for more cybersecurity insights.