S0422: Anubis
Analyst context for executives and security teams
Anubis matters because it represents Android malware with banking-trojan and information-stealing behavior, not just a single malicious app. The ATT&CK relationships show a mobile threat pattern that can capture credentials and GUI input, abuse accessibility features, collect local data, audio, screen, location, contacts, SMS and call information, resist removal, disable tools, and encrypt data for impact. For organizations with mobile access to banking, email, MFA, collaboration, or operational workflows, the decision issue is whether mobile security controls can see risky permissions, suspicious accessibility use, dynamic code loading, and sensitive-data collection before account compromise or business disruption follows.
Executive priority
Treat this as a mobile identity and data-protection risk, especially for Android fleets or BYOD users accessing corporate accounts. Leaders should ask whether mobile device management, mobile threat defense, identity controls, and incident response processes can answer: which Android devices have high-risk permissions, which apps abuse accessibility or device administrator capabilities, whether mobile events feed the SOC, and how quickly a compromised device can be isolated from corporate services. Because the ATT&CK object has no official detection text, audit and readiness evidence should focus on validated telemetry and response playbooks rather than assumed detection coverage.
Technical view
For SOC, detection engineering, and IR teams, Anubis should be mapped to Android behaviors across credential/input capture, discovery, collection, command-and-control support, persistence/defense evasion, and impact. Validate coverage for Download New Code at Runtime, Keylogging, GUI Input Capture, Software/Process/System Information Discovery, Audio/Screen/Location capture, Accessibility abuse, SMS and Call Control, Prevent Application Removal, Disable or Modify Tools, System Checks, Contact List access, Match Legitimate Name or Location, Archive Collected Data, Data from Local System, Dead Drop Resolver, and Data Encrypted for Impact. The main technical risk is that static app review alone may miss post-install code loading and behavior gated by system checks, while normal Android permission prompts can make malicious collection look user-authorized unless correlated with app reputation, permission combinations, accessibility state, foreground/background behavior, and network activity.
Likely telemetry
- Android app inventory, package names, signing information, install source, icons/names, and version history
- Android permission grants and changes, including microphone, location, contacts, SMS, call, accessibility, device administrator, storage, and screen capture-related consent
- Accessibility service enablement, device administrator status, and attempts to prevent app removal
- Mobile threat defense or EDR events for dynamic code loading, downloaded payloads, suspicious runtime behavior, and security tool modification
- Network telemetry from mobile devices or secure web gateways, including connections to external web services used as possible dead drop resolvers and follow-on infrastructure
Detection direction
- Prioritize behavior correlation over single indicators: high-risk permission bundles plus accessibility abuse, device administrator use, dynamic code download, and sensitive data access are more meaningful than app name alone.
- Tune for suspicious impersonation using package name, icon, or app label similarity to trusted applications, while accounting for legitimate enterprise apps that may use similar permissions.
- Validate whether the SOC receives mobile security events at all; many organizations have endpoint visibility for laptops but limited Android telemetry for BYOD or unmanaged devices.
- Look for post-install behavior that static app-store or pre-publication scanning may not catch, especially downloaded code and behavior changes after system or sandbox checks.
- Monitor for user-impact behaviors such as blocked removal, disabled security tools, SMS/call manipulation, and local data encryption, because these can affect containment and business continuity.
Mitigation priorities
- Establish Android fleet visibility first: inventory devices, installed apps, permissions, accessibility services, device administrator apps, and unmanaged/BYOD access paths to corporate resources.
- Restrict corporate access from devices that lack required mobile management or mobile threat telemetry, especially for privileged, finance, banking, and sensitive-data workflows.
- Harden permission and app-install policy: limit unknown sources, review high-risk permission combinations, and educate users to treat keyboard, accessibility, screen capture, SMS, call, microphone, contact, and location requests as high risk when not business-justified.
- Integrate mobile alerts with identity controls so suspected device compromise can trigger session revocation, MFA reset, password reset, conditional access changes, and fraud review as appropriate.
- Prepare IR procedures for Android compromise: isolate device access to corporate services, preserve MDM/mobile telemetry, identify affected accounts and apps, and handle cases where removal is blocked by accessibility or device administrator abuse.
Analyst notes and limits
This take is based on ATT&CK S0422 for Anubis, an Android malware family described as originally used for cyber espionage and retooled as a banking trojan, plus its supplied ATT&CK technique relationships. The breadth of relationships indicates why defenders should treat it as a mobile behavior cluster spanning credential theft, surveillance, discovery, persistence/defense evasion, C2 support, collection, and impact. The most important local validation question is not whether an organization has heard of Anubis, but whether Android telemetry and identity response processes can expose and contain these behaviors.
MITRE provides no official detection text for this object, and the supplied tactics are not specified. This summary does not assert current activity, attribution, prevalence, customer exposure, or guaranteed detection. Defensive priorities must be validated against the organization’s actual Android management model, BYOD scope, mobile telemetry, identity architecture, and legal/privacy constraints for mobile monitoring.
Anubis
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Mobile | T1453 | Abuse Accessibility Features | After accessibility service is granted, Anubis lures the victim into changing the Accessibility settings on the device, disabling application removal, and executes screen taps and other commands without the victim’s knowledge.CitationCyble_Anubis_May2021 |
| Mobile | T1533 | Data from Local System | Anubis can exfiltrate files encrypted with the ransomware module from the device and can modify external storage.CitationCofense AnubisCitationTrend Micro Anubis |
| Mobile | T1532 | Archive Collected Data | Anubis exfiltrates data encrypted (with RC4) by its ransomware module.CitationCofense Anubis |
| Mobile | T1424 | Process Discovery | Anubis can collect a list of running processes.CitationZimperium z9 |
| Mobile | T1426 | System Information Discovery | Anubis can collect the device’s ID.CitationCofense Anubis |
| Mobile | T1582 | SMS Control | Anubis can send, receive, and delete SMS messages.CitationCofense Anubis |
| Mobile | T1633.001 | System Checks Sub-technique | Anubis has used motion sensor data to attempt to determine if it is running in an emulator.CitationTrend Micro Anubis |
| Mobile | T1616 | Call Control | Anubis can make phone calls.CitationCofense Anubis |
| Mobile | T1418 | Software Discovery | Anubis can collect a list of installed applications to compare to a list of targeted applications.CitationCofense Anubis |
| Mobile | T1417.002 | GUI Input Capture Sub-technique | Anubis can create overlays to capture user credentials for targeted applications.CitationCofense Anubis |
| Mobile | T1629.003 | Disable or Modify Tools Sub-technique | Anubis can modify administrator settings and disable Play Protect.CitationCofense Anubis |
| Mobile | T1471 | Data Encrypted for Impact | Anubis can use its ransomware module to encrypt device data and hold it for ransom.CitationCofense Anubis |
| Mobile | T1430 | Location Tracking | Anubis can retrieve the device’s GPS location.CitationCofense Anubis |
| Mobile | T1655.001 | Match Legitimate Name or Location Sub-technique | Anubis has requested accessibility service privileges while masquerading as "Google Play Protect" and has disguised additional malicious application installs as legitimate system updates.CitationCofense AnubisCitationTrend Micro Anubis |
| Mobile | T1636.003 | Contact List Sub-technique | Anubis can steal the device’s contact list.CitationCofense Anubis |
| Mobile | T1513 | Screen Capture | Anubis can take screenshots.CitationCofense Anubis |
| Mobile | T1629.001 | Prevent Application Removal Sub-technique | Anubis may prevent malware's uninstallation by abusing Android’s ` performGlobalAction(int)` API call. |
| Mobile | T1407 | Download New Code at Runtime | Anubis can download attacker-specified APK files.CitationTrend Micro Anubis |
| Mobile | T1417.001 | Keylogging Sub-technique | Anubis has a keylogger that works in every application installed on the device.CitationCofense Anubis |
| Mobile | T1481.001 | Dead Drop Resolver Sub-technique | Anubis can retrieve the C2 address from Twitter and Telegram.CitationCofense AnubisCitationTrend Micro Anubis |
| Mobile | T1429 | Audio Capture | Anubis can record phone calls and audio.CitationCofense Anubis |
All related ATT&CK context
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.3 | Current bundle | 202fcad2d23c… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
Cofense Anubis
M. Feller. (2020, February 5). Infostealer, Keylogger, and Ransomware in One: Anubis Targets More than 250 Android Applications. Retrieved September 25, 2024.
Open source URL -
[2]
mitre-attack S0422Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.