DET0612: Detection of Input Injection
DET0612 is a mobile ATT&CK detection strategy for recognizing input injection behavior associated with Android abuse of accessibility APIs. For leaders, th...
Analyst context for executives and security teams
DET0612 is a mobile ATT&CK detection strategy for recognizing input injection behavior associated with Android abuse of accessibility APIs. For leaders, the practical issue is not just malware clicking buttons: it is whether the organization can identify when a mobile app is programmatically mimicking a user in ways that could affect account actions, approvals, payments, or other sensitive workflows on managed or workforce devices.
Executive priority
Prioritize this where Android devices support business-critical access, financial workflows, privileged administration, or regulated data handling. The decision value is to confirm whether mobile security monitoring, endpoint/mobile device management, and incident response processes can distinguish legitimate accessibility use from suspicious automation. This also supports audit and compliance conversations around mobile control evidence, especially where organizations allow third-party apps or accessibility permissions on devices used for corporate access.
Technical view
The supplied ATT&CK relationship says this detection strategy detects T1516 Input Injection, a mobile technique on Android involving malicious applications abusing accessibility APIs to mimic user interaction, including clicks or global actions. Because the DET0612 object does not provide an official detection analytic, teams should validate coverage around Android accessibility service enablement, app permission changes, suspicious use of accessibility capabilities by non-assistive applications, and observed UI automation patterns that align with sensitive app activity. IR playbooks should include triage of installed apps, granted accessibility permissions, timing of permission grants, and whether suspicious UI actions coincide with account or transaction events.
Likely telemetry
- Android device inventory and managed/unmanaged device status
- Installed mobile applications and app provenance
- Accessibility service enablement and permission-change events
- Mobile device management or mobile threat defense alerts related to risky permissions or app behavior
- Application activity logs for sensitive business apps where available
Detection direction
- Validate whether accessibility permission changes are logged and retained for Android devices in scope.
- Tune detections to focus on non-assistive or unexpected applications receiving accessibility capabilities, especially near sensitive account, payment, or approval activity.
- Correlate mobile telemetry with identity and application audit logs to identify user actions that appear inconsistent with normal interaction or occur immediately after suspicious permission changes.
- Account for false positives from legitimate accessibility tools, enterprise automation, testing tools, and approved assistive applications; maintain an allowlist or approved-use baseline where appropriate.
- Identify blind spots for personally owned or unmanaged Android devices, limited mobile telemetry, short log retention, and business apps that do not expose useful audit events.
Mitigation priorities
- Establish policy and technical controls for which Android apps may use accessibility services on devices that access corporate resources.
- Use mobile device management or equivalent controls to inventory apps, monitor risky permissions, and restrict untrusted app installation where business policy allows.
- Require stronger identity and transaction safeguards for sensitive workflows accessed from mobile devices, so suspicious UI automation is not the only control point.
- Maintain an incident response process for suspected mobile input injection, including device isolation guidance, app review, permission review, and account/session review.
- Document approved accessibility use cases to support compliance evidence and reduce unnecessary alert noise.
Analyst notes and limits
The ATT&CK object is a detection strategy in the mobile domain, external ID DET0612, and its provided relationship is to T1516 Input Injection. The related technique description supports Android and abuse of accessibility APIs to mimic user interaction. No official DET0612 description, detection logic, tactics, or platforms were supplied directly on the detection strategy object.
This take is based only on the supplied STIX fields, external reference, and relationship context. It does not assert active exploitation, actor attribution, guaranteed detectability, or customer exposure. Local Android management coverage, app audit logging, and identity/application telemetry determine whether this behavior can be detected in practice.
Detection of Input Injection
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 | T1516 | Input Injection | This object detects Input Injection. |
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 | af1e6d3c4c62… |
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 DET0612Open 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.