S0479: DEFENSOR ID
DEFENSOR ID is a banking trojan capable of clearing a victim’s bank account or cryptocurrency wallet and taking over email or social media accounts. DEFENSOR ID performs the majority of its malicious functionality by abusing Android’s accessibility service.[1]
Analyst context for executives and security teams
DEFENSOR ID matters because it represents Android banking malware where the business risk is not only device compromise, but loss of access to financial, cryptocurrency, email, and social media accounts. The key defensive lesson is that mobile accessibility permissions can become a high-impact control point: if abused, they can enable user-interface manipulation, screen observation, and account takeover activity that may bypass traditional endpoint and network assumptions.
Executive priority
Security leaders should treat this as a mobile identity and fraud-readiness issue, not just a malware label. Priority questions are: which business users access banking, cryptocurrency, email, or social platforms from Android devices; whether mobile device management or acceptable-use controls can govern high-risk accessibility permissions; and whether incident response has a playbook for suspected mobile account takeover. For compliance and audit evidence, the practical value is showing that mobile access, permissions, application inventory, and account recovery procedures are governed rather than assumed.
Technical view
ATT&CK provides no official detection text for DEFENSOR ID, so SOC and IR teams should validate coverage through the related behaviors: Android software discovery, web-protocol command and control, screen capture, input injection through accessibility APIs, and persistence via broadcast receivers. Detection engineering should focus on whether managed Android telemetry can show suspicious accessibility-service enablement, installed application inventory changes, unusual app permission combinations, foreground screen or interaction abuse indicators, persistence registrations, and network communication over HTTP/HTTPS from suspect apps. Because the object is Android-only in the supplied fields, coverage validation should stay scoped to Android mobile environments.
Likely telemetry
- Android device inventory and installed application lists
- Mobile device management or enterprise mobility management records for app installation, permissions, and accessibility-service enablement
- Android security or EDR telemetry where available for accessibility API usage, input injection-like behavior, screen capture-related behavior, and broadcast receiver registration
- Network logs or mobile security telemetry showing HTTP/HTTPS communications from mobile applications
- Identity and account activity logs for banking-adjacent, email, social media, and cryptocurrency-related account access where available to the organization
Detection direction
- Do not rely on the malware name alone; validate whether controls detect the ATT&CK-related behaviors associated with this object.
- Prioritize alerts or hunts around Android apps requesting or using accessibility services in combination with sensitive account access, software discovery, screen capture, or input injection-like activity.
- Review web-protocol mobile traffic carefully: HTTP/HTTPS is common and high-volume, so useful detection will likely require app reputation, device context, destination context, and behavioral correlation.
- Use installed-application discovery as context for triage, especially where a suspicious app appears alongside banking, cryptocurrency, email, or social media apps.
- Check for persistence indicators tied to Android broadcast receivers, while accounting for legitimate apps that use broadcast mechanisms for normal functionality.
Mitigation priorities
- Establish policy and technical controls for Android devices that access business-sensitive accounts, especially around app installation sources and high-risk permissions such as accessibility services.
- Use managed mobile controls where available to maintain approved application baselines, monitor risky permissions, and support rapid device isolation or app removal during incidents.
- Harden identity recovery and account takeover response processes for email, social media, banking-related, and cryptocurrency-related accounts used by personnel or business functions.
- Educate users and help desks to treat unexpected accessibility permission prompts or unusual mobile app behavior as security events, not routine support issues.
- Ensure incident response can collect mobile evidence, revoke sessions, reset credentials, and verify account integrity after suspected mobile malware activity.
Analyst notes and limits
The supplied ATT&CK object identifies DEFENSOR ID as Android banking malware that abuses Android accessibility services and links it to software discovery, web protocols, screen capture, input injection, and broadcast receiver persistence. Those relationships are the best basis for practical SOC validation because the object does not include ATT&CK detection guidance or tactics.
This take is limited to the official STIX fields, external references, and supplied relationships. ATT&CK does not provide official detection text, aliases, labels, or tactics for this object in the supplied data. Local conclusions about exposure, exploitation, user impact, or detection coverage require environment-specific mobile, identity, and network evidence.
DEFENSOR ID
DEFENSOR ID is a banking trojan capable of clearing a victim’s bank account or cryptocurrency wallet and taking over email or social media accounts. DEFENSOR ID performs the majority of its malicious functionality by abusing Android’s accessibility service.[1]
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 | T1513 | Screen Capture | DEFENSOR ID can abuse the accessibility service to read any text displayed on the screen.[1] |
| Mobile | T1516 | Input Injection | DEFENSOR ID can abuse the accessibility service to perform actions on behalf of the user, including launching attacker-specified applications to steal data.[1] |
| Mobile | T1418 | Software Discovery | DEFENSOR ID can retrieve a list of installed applications.[1] |
| Mobile | T1437.001 | Web Protocols Sub-technique | DEFENSOR ID has used Firebase Cloud Messaging for C2.[1] |
| Mobile | T1624.001 | Broadcast Receivers Sub-technique | DEFENSOR ID abuses the accessibility service to auto-start the malware on device boot. This is accomplished by receiving the `android.accessibilityservice.AccessibilityService` intent.[1] |
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.0 | Current bundle | 14b6db1e3f43… |
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]
ESET DEFENSOR ID
L. Stefanko. (2020, May 22). Insidious Android malware gives up all malicious features but one to gain stealth. Retrieved June 26, 2020.
Open source URL -
[2]
mitre-attack S0479Open 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.