AN1812: Analytic 1812
A defender correlates an application being granted accessibility service control with subsequent consumption of high-volume accessibility events, interaction with sensitive UI elements or text-entry fields, optional overlay/window presentation over other applications, and near-term local buffering or outbound network transmission, indicating abuse of accessibility features for input capture, credential theft, or automated interaction.
Analyst context for executives and security teams
This analytic is about spotting Android apps that misuse Accessibility Services after being granted control. For leaders, the significance is that an accessibility permission can turn a normal-looking mobile app into a channel for credential capture, sensitive text observation, automated interaction, or overlay-assisted deception. The business decision value is whether mobile security monitoring can connect the permission grant to later risky behavior, rather than treating the permission event as isolated noise.
Executive priority
Prioritize this where Android devices access business applications, identity workflows, or regulated data. The key management question is whether the organization can produce evidence that it monitors high-risk mobile permissions and follow-on behavior such as sensitive UI interaction, text-entry observation, overlays, local buffering, or outbound transmission. This supports incident triage, mobile risk decisions, and audit conversations around protection of credentials and sensitive application data.
Technical view
For SOC, mobile security, and IR teams, validate whether Android telemetry can correlate: an application being granted accessibility service control; high-volume accessibility event consumption; interaction with sensitive UI elements or text-entry fields; optional overlay or window presentation over other applications; and near-term local buffering or outbound network transmission. Because the ATT&CK object provides no separate detection logic and no relationship context, teams should treat this as a correlation objective and test it against their actual mobile telemetry sources, enrollment model, and privacy constraints.
Likely telemetry
- Android application permission or accessibility service grant events
- Accessibility service usage or accessibility event volume indicators
- Application interaction with UI elements and text-entry fields, where available
- Overlay or window presentation events over other applications
- Local file or buffer creation by the application, where observable
Detection direction
- Validate that permission grants are correlated with subsequent behavior, not reviewed only as standalone events.
- Tune for combinations of accessibility control plus high event volume, sensitive UI or text-entry interaction, overlay behavior, and near-term local buffering or outbound transmission.
- Account for false positives from legitimate accessibility tools, enterprise assistive applications, password managers, automation tools, or device management software approved by the organization.
- Confirm whether privacy settings, unmanaged devices, BYOD limitations, or mobile telemetry gaps prevent visibility into UI interaction, overlays, local buffering, or app-level network behavior.
- Use application identity, approval status, device ownership, and business app access context to prioritize triage.
Mitigation priorities
- Maintain an approved baseline for Android applications allowed to use Accessibility Services in enterprise contexts.
- Restrict or review high-risk accessibility permissions on devices that access business identity systems, email, collaboration tools, or regulated data where policy allows.
- Require mobile security, MDM, or EMM controls that can inventory applications and surface risky permission grants and follow-on behaviors.
- Prepare IR playbooks for suspicious mobile accessibility abuse, including device isolation, application removal, credential reset decisions, and evidence preservation consistent with privacy and legal requirements.
- Use compliance evidence to show governance over mobile permissions, application approval, and monitoring coverage for business-critical Android access.
Analyst notes and limits
The supplied ATT&CK object is a mobile detection analytic for Android and describes a behavioral correlation pattern. It does not specify tactics, related techniques, malware, groups, mitigations, or a formal detection query. The most useful local validation is whether the organization can connect the accessibility grant to subsequent sensitive interaction, overlay activity, buffering, or outbound transmission in a defensible timeline.
Official detection content is not provided, and no relationships were supplied. This take therefore avoids claims about specific ATT&CK tactics, active exploitation, adversary attribution, guaranteed detectability, or coverage beyond Android. Actual feasibility depends on local Android management, telemetry depth, privacy constraints, and whether devices are managed or BYOD.
Analytic 1812
A defender correlates an application being granted accessibility service control with subsequent consumption of high-volume accessibility events, interaction with sensitive UI elements or text-entry fields, optional overlay/window presentation over other applications, and near-term local buffering or outbound network transmission, indicating abuse of accessibility features for input capture, credential theft, or automated interaction.
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.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
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.1 | Current bundle | 222dbbca55c9… |
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 AN1812Open 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.