AN1689: Analytic 1689
Remote access software typically requires many privileged permissions, such as accessibility services or device administrator.
Analyst context for executives and security teams
This analytic highlights a practical mobile security concern: on Android, remote access software often depends on highly privileged permissions such as Accessibility Services or Device Administrator. For leaders, the value is not simply identifying an app by name; it is knowing whether the organization can see and govern mobile apps that request privileges capable of enabling remote control, surveillance, or policy bypass.
Executive priority
Prioritize this as a mobile governance and incident-readiness question: can the organization prove which Android devices have apps with privileged permissions, who approved them, and whether those permissions are still justified? This matters for business continuity, compliance evidence, and executive decision-making because unmanaged privileged mobile access can weaken identity, endpoint, and data protection controls even when traditional desktop monitoring is mature.
Technical view
For SOC, mobile security, and IR teams, validate whether Android telemetry exposes applications granted Accessibility Services and Device Administrator privileges. Because the ATT&CK object provides no specific detection logic or tactic mapping, treat this as a control-validation analytic: inventory privileged permission grants, baseline expected remote support or management tools, and review unexpected or newly granted privileged access on Android devices. Investigation should focus on whether the app, permission grant, user, device ownership model, and business justification align.
Likely telemetry
- Android application inventory
- Android permission state, especially Accessibility Services
- Android Device Administrator status
- Mobile device management or enterprise mobility management device compliance records
- App install, update, and removal history
Detection direction
- Confirm that Android privileged permission grants are collected centrally; absence of this data is the primary coverage gap for this analytic.
- Baseline approved remote access, remote support, accessibility, and device administration applications to reduce false positives.
- Alert or review when an unapproved app is granted Accessibility Services or Device Administrator privileges.
- Correlate permission grants with app install time, device compliance status, user role, and whether the device is corporate-owned or personally owned where that context is available.
- Because no official detection logic is supplied, avoid treating app presence alone as malicious; focus on privilege level, approval status, and local policy deviation.
Mitigation priorities
- Maintain an approved list and business justification for Android applications allowed to use Accessibility Services or Device Administrator privileges.
- Use mobile device management or equivalent governance to inventory and enforce privileged permission policy where supported.
- Review exceptions regularly, especially for remote access or support tools that require elevated mobile permissions.
- Ensure incident response playbooks include steps to validate Android privileged app permissions during mobile investigations.
- Preserve compliance evidence showing how privileged mobile permissions are approved, monitored, and revoked.
Analyst notes and limits
This is a detection analytic object for the mobile ATT&CK domain, platform Android, external ID AN1689. The official description is limited to the observation that remote access software typically requires privileged permissions such as accessibility services or device administrator. No tactic, relationship context, or official detection procedure was supplied, so the take is framed around defensive validation and telemetry readiness rather than a specific ATT&CK technique workflow.
The supplied object does not include tactics, related techniques, known software, detection logic, mitigations, or relationships. Local mobile management architecture, device ownership model, approved app catalog, and Android telemetry availability are required to determine actual risk and coverage.
Analytic 1689
Remote access software typically requires many privileged permissions, such as accessibility services or device administrator.
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.0 | Current bundle | 449c17a2e348… |
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 AN1689Open 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.