AN1825: Analytic 1825
Defender observes an app gaining input-observation capability (AccessibilityService enablement, default IME set, draw-over-apps permission), then creating an intercept surface (overlay window, accessibility event stream consumption or IME keystroke callbacks), followed by persistence (local keylog/clipboard dump) and/or small, frequent network egress. Chain: capability/permission → listener/overlay activation → bursty input read events → local write → near-term exfil.
Analyst context for executives and security teams
This analytic matters because it describes a high-risk Android pattern: an app obtains the ability to observe user input, activates a mechanism such as an accessibility listener, overlay, or input method, then stores or sends small amounts of captured input data. For leaders, the issue is not just malware detection; it is whether the organization can prove that managed mobile devices, high-risk users, and incident responders have visibility into input-capture behavior that could expose credentials, messages, clipboard data, or other sensitive business information.
Executive priority
Prioritize this where Android devices are used for privileged access, workforce authentication, executive communications, regulated data handling, or operational workflows. The business decision is whether mobile security controls and SOC processes can identify suspicious combinations of permissions, input-observation activity, local storage, and near-term network egress. This can support incident triage, mobile policy enforcement, audit evidence for endpoint monitoring, and risk decisions around bring-your-own-device versus managed-device access.
Technical view
For Android environments, validate whether telemetry can correlate the chain described by MITRE: input-observation capability or permission change, such as AccessibilityService enablement, default IME selection, or draw-over-apps permission; activation of an intercept surface, such as overlay window creation, accessibility event stream consumption, or IME keystroke callbacks; bursty input-read activity; local persistence such as keylog or clipboard dump writes; and small, frequent network egress shortly afterward. Because the official object provides no separate detection text and no relationship context, teams should treat this as a behavioral correlation requirement rather than a single indicator.
Likely telemetry
- Android app permission and capability changes, including AccessibilityService, default input method, and draw-over-apps state
- Mobile device management or mobile threat defense events for app installation, permission grants, and configuration changes
- Android accessibility, overlay, and input method activity where available
- Local file write activity or application storage events indicating possible keylog or clipboard dump persistence
- Clipboard access or input event telemetry where collected and permitted
Detection direction
- Correlate permission/capability acquisition with subsequent listener, overlay, or IME activity rather than alerting on permission state alone.
- Tune for sequence and timing: capability or permission change followed by intercept-surface activation, bursty input reads, local write activity, and near-term egress.
- Separate expected accessibility or keyboard apps from unusual apps by using approved app inventory, device ownership context, and user role.
- Watch for blind spots on unmanaged Android devices, limited mobile telemetry, privacy-restricted event collection, and network egress that blends into normal mobile traffic.
- Use app reputation, package metadata, user/device risk, and recent installation or update timing to reduce false positives without suppressing suspicious behavior chains.
Mitigation priorities
- Maintain an approved inventory for accessibility services, input methods, and apps allowed to draw over other apps on managed Android devices.
- Restrict or review high-risk permissions and configuration changes through mobile management policy where available.
- Require stronger scrutiny for apps requesting input-observation capabilities, especially on devices used for privileged or sensitive business access.
- Ensure SOC and incident response playbooks include mobile collection steps for app permissions, package metadata, local storage indicators, and network activity.
- Use conditional access or equivalent access governance to reduce exposure from devices that lack required mobile telemetry or control enforcement.
Analyst notes and limits
This is a detection analytic object for Android in the ATT&CK mobile domain. It provides a useful behavioral chain but does not include tactics, relationships, aliases, or an official detection procedure. The strongest operational value comes from validating whether local mobile telemetry can connect the full sequence across permissions, input interception, persistence, and egress.
The source object does not identify associated techniques, threat groups, software, campaigns, active exploitation, or guaranteed detection methods. Local device management model, telemetry availability, privacy constraints, and approved accessibility or keyboard use must determine final alert logic and response thresholds.
Analytic 1825
Defender observes an app gaining input-observation capability (AccessibilityService enablement, default IME set, draw-over-apps permission), then creating an intercept surface (overlay window, accessibility event stream consumption or IME keystroke callbacks), followed by persistence (local keylog/clipboard dump) and/or small, frequent network egress. Chain: capability/permission → listener/overlay activation → bursty input read events → local write → near-term exfil.
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 | dcba3fedab9f… |
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 AN1825Open 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.