AN1690: Analytic 1690
Remote access software typically requires many privileged permissions, such as accessibility services or device administrator.
Analyst context for executives and security teams
This analytic points to a practical mobile security concern: remote access software on iOS can require elevated or sensitive permissions. For leaders, the issue is not that every remote access tool is malicious; it is whether the organization can distinguish approved support tooling from unmanaged software with privileged access to business devices and data.
Executive priority
Prioritize this as a governance and visibility question for mobile fleet resilience. Executives should ask whether iOS devices are inventoried, whether privileged app permissions and device management state are auditable, and whether remote support tools are formally approved. This matters for incident response scoping, compliance evidence, and reducing the chance that unmanaged remote access becomes a blind spot in mobile operations.
Technical view
ATT&CK provides an analytic for iOS with the description that remote access software typically requires privileged permissions, such as accessibility services or device administrator, but does not provide a detection implementation or relationships. SOC and mobile security teams should validate whether their MDM/UEM, endpoint, and mobile app inventory sources can identify remote access applications and correlate them with privileged permission or management changes. Because no tactic or related technique is supplied, treat this as a detection-validation prompt rather than a complete analytic.
Likely telemetry
- iOS device inventory and ownership state from MDM/UEM
- Installed application inventory, including approved versus unapproved remote access tools
- App permission and privacy grant records where available
- Device management, configuration profile, and enrollment state changes
- Mobile security alerts related to privileged app behavior or remote administration software
Detection direction
- Validate that approved remote access software is explicitly inventoried and baselined so unmanaged instances stand out.
- Correlate remote access app presence with privileged permission, profile, or device management changes when telemetry supports it.
- Tune for business context: legitimate IT support tools may be expected on some devices, while the same software may be suspicious on executive, unmanaged, or high-risk user devices.
- Confirm iOS telemetry limitations before promising coverage; ATT&CK does not provide a detection query or required data components for this analytic.
- Use allowlists carefully and review them periodically so sanctioned remote access tooling does not become a permanent blind spot.
Mitigation priorities
- Define and maintain an approved list of mobile remote access and support tools.
- Use MDM/UEM policy to restrict or monitor unmanaged applications and sensitive permission use where supported.
- Require documented business justification and support ownership for any remote access software on iOS devices.
- Ensure incident responders can quickly retrieve device inventory, app inventory, and management state during mobile investigations.
- Review compliance evidence showing who can approve privileged mobile software and how exceptions are tracked.
Analyst notes and limits
This object is a detection analytic, not a full ATT&CK technique. The supplied description is sparse and the official detection field is not provided. The platform is iOS, while the example privileged permissions in the description are generic; local iOS management and telemetry capabilities should drive implementation.
No tactic, detection logic, data source list, relationships, attribution, or exploitation context was supplied. Any operational detection must be validated against the organization’s mobile device management, app inventory, and logging coverage.
Analytic 1690
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 | 841511e344b7… |
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 AN1690Open 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.