AN1666: Analytic 1666
The defender correlates Android accessibility or UI-automation-capable behavior from an app identity with injected user-interface actions occurring on behalf of the user in another foreground application. The strongest Android evidence is accessibility-enabled or similarly privileged app behavior that triggers programmatic clicks, global actions, or text insertion into another app's active UI, especially when those actions occur without matching user touch interaction, while the injecting app is backgrounded or foreground-service-only, or when the target foreground app belongs to a sensitive category such as banking, payments, identity, communications, or enterprise access. The detection is strengthened when the injected input sequence is followed by target-app navigation, form submission, transaction progression, or network activity from the target context.
Analyst context for executives and security teams
AN1666 is a mobile detection analytic focused on Android apps that use accessibility or UI-automation-style privileges to act inside another foreground app. For leaders, the significance is that this behavior can turn a user’s trusted mobile session—such as banking, payments, identity, communications, or enterprise access—into a control gap if programmatic clicks, text entry, or navigation occur without matching human touch activity.
Executive priority
Prioritize this where Android devices are used for sensitive business workflows, identity access, communications, or regulated transactions. The key decision is whether the organization has enough mobile telemetry and policy control to distinguish legitimate accessibility use from app-driven UI injection. This affects mobile threat detection readiness, incident triage quality, identity and access risk, and evidence for controls around privileged mobile app behavior.
Technical view
SOC, mobile security, and IR teams should validate whether they can correlate an app identity that has accessibility-enabled or similar UI-automation capability with injected actions in a different foreground application. Stronger cases include programmatic clicks, global actions, or text insertion when the injecting app is backgrounded or only running as a foreground service, when user touch input is absent, or when the target app is sensitive. Analysts should also look for follow-on target-app navigation, form submission, transaction progression, or network activity from the target app context. No ATT&CK tactic or relationship context was supplied, so implementation should be framed as behavior validation rather than attribution or campaign-specific detection.
Likely telemetry
- Android accessibility service enablement and usage events
- App identity and package/process context for the app performing UI automation
- Foreground application state and target app identity
- UI action evidence such as programmatic clicks, global actions, or text insertion
- User touch interaction or input-event telemetry for comparison
Detection direction
- Confirm that mobile telemetry can join accessibility-capable app behavior to UI actions occurring in another foreground app.
- Tune for sequences where injected UI actions occur without corresponding user touch interaction, especially if the injecting app is backgrounded or foreground-service-only.
- Raise priority when the target foreground app is in a sensitive category such as banking, payments, identity, communications, or enterprise access.
- Use follow-on behavior—navigation, form submission, transaction progression, or network activity from the target context—to strengthen confidence.
- Account for legitimate accessibility tools and enterprise automation as false-positive sources; app allowlisting, user consent records, and business justification are important triage inputs.
Mitigation priorities
- Inventory Android apps with accessibility or UI-automation-capable privileges, especially on devices used for sensitive business or identity workflows.
- Limit approval of accessibility privileges to apps with documented business need and trusted provenance.
- Use mobile device management or equivalent policy controls to restrict risky app installation and privilege granting where feasible.
- Review sensitive mobile workflows for compensating controls when UI injection telemetry is limited.
- Ensure incident response playbooks include steps to preserve mobile app, accessibility, foreground app, and network context when suspicious UI automation is reported.
Analyst notes and limits
This object is a detection analytic for the mobile ATT&CK domain and Android platform. Its value is in correlation: app privilege state, UI automation behavior, foreground target context, lack of matching user input, and follow-on target-app activity. The supplied object has no tactic mapping, no relationship context, and no separate official detection section beyond the description, so local implementation details must come from the organization’s Android telemetry and mobile security stack.
Assessment is limited to the supplied ATT&CK fields and external reference. No active exploitation, attribution, specific malware, guaranteed detection coverage, or non-Android platform applicability is supported by the provided data.
Analytic 1666
The defender correlates Android accessibility or UI-automation-capable behavior from an app identity with injected user-interface actions occurring on behalf of the user in another foreground application. The strongest Android evidence is accessibility-enabled or similarly privileged app behavior that triggers programmatic clicks, global actions, or text insertion into another app's active UI, especially when those actions occur without matching user touch interaction, while the injecting app is backgrounded or foreground-service-only, or when the target foreground app belongs to a sensitive category such as banking, payments, identity, communications, or enterprise access. The detection is strengthened when the injected input sequence is followed by target-app navigation, form submission, transaction progression, or network activity from the target context.
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 | 2decf864c6f4… |
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 AN1666Open 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.