DET0697: Detection of Abuse Accessibility Features
DET0697 is a mobile ATT&CK detection strategy for identifying abuse of Android accessibility features. The business issue is that accessibility permissions...
Analyst context for executives and security teams
DET0697 is a mobile ATT&CK detection strategy for identifying abuse of Android accessibility features. The business issue is that accessibility permissions can give an app powerful interaction and observation capabilities, so misuse can affect sensitive data exposure and malware propagation risk on managed or BYOD Android devices. For leaders, the value is not simply knowing this technique exists; it is verifying whether mobile security, identity, and SOC processes can distinguish legitimate accessibility use from suspicious app behavior.
Executive priority
Treat this as a mobile resilience and data-protection validation item. Security leaders should ask whether Android device fleets are inventoried, whether accessibility permission use is visible, whether exceptions for legitimate assistive apps are governed, and whether SOC or mobile security teams have an escalation path when suspicious accessibility behavior is observed. This can support compliance evidence around mobile device control monitoring, but local policy and telemetry determine how defensible that evidence is.
Technical view
The detection strategy has no official detection text in the supplied ATT&CK fields, but it is explicitly related to T1453, Abuse Accessibility Features, in the mobile-attack domain for Android. SOC and detection teams should validate whether they can observe apps requesting or using accessibility capabilities, correlate that with app reputation, installation source, device enrollment state, user reports, and unusual permission combinations, and separate sanctioned accessibility tools from unexpected or newly installed apps. Incident responders should be prepared to preserve mobile device context, application inventory, permission state, and relevant mobile security alerts before remediation.
Likely telemetry
- Android application inventory and package metadata
- Accessibility service enablement or permission state where available
- Mobile device management or enterprise mobility management compliance records
- Mobile threat defense or mobile security alerts, if deployed
- App installation source, install time, and update history
Detection direction
- Confirm whether existing mobile telemetry can show which apps have accessibility features enabled; many SOCs lack this visibility by default.
- Build allowlisting or exception logic for legitimate accessibility needs to reduce false positives and avoid disrupting users who rely on assistive functions.
- Prioritize suspicious combinations: newly installed or untrusted apps with accessibility access, unexpected permission changes, or devices outside normal compliance posture.
- Correlate mobile findings with identity and data-access events when available, because the related technique concerns sensitive data theft risk.
- Document blind spots for BYOD, unmanaged Android devices, or privacy-limited telemetry where accessibility state cannot be collected.
Mitigation priorities
- Establish policy and governance for approved accessibility-service use on managed Android devices.
- Use mobile device management or equivalent controls to maintain app inventory, enrollment status, and compliance visibility where appropriate.
- Limit installation from untrusted sources according to organizational mobile policy.
- Educate users and support teams to recognize unexpected prompts to enable accessibility features.
- Define incident response playbooks for suspicious mobile app permissions, including evidence capture, containment, app removal, and credential-risk review when sensitive data exposure is possible.
Analyst notes and limits
This object is a detection strategy, not a technique. The supplied fields include no official description or detection procedure, so the take is derived from its relationship to T1453 and that technique’s supplied Android-focused description. Coverage decisions should be validated against the organization’s actual Android management model and privacy constraints.
Platforms and tactics are not specified on the detection strategy itself. The only platform support supplied comes from the related T1453 technique, which lists Android. No claims are made about active exploitation, attribution, specific malware, or guaranteed detection coverage.
Detection of Abuse Accessibility Features
No official description is available in the imported ATT&CK source object.
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 | This object detects Abuse Accessibility Features. |
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 | 4cfff3145159… |
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]
mitre-attack DET0697Open 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.