AN1696: Analytic 1696
On Android, the user can review which applications have Device Administrator access in the device settings and revoke permission where appropriate. Application vetting services can detect and closely scrutinize applications that utilize Device Administrator access.
Analyst context for executives and security teams
This analytic is intended to support review of mobile applications that hold elevated device administration privileges. Its business value is in helping security and mobile program owners verify that powerful app permissions are visible, reviewed, and revoked when inappropriate. However, the supplied ATT&CK fields are internally inconsistent: the platform is listed as iOS, while the official description refers to Android Device Administrator access.
Executive priority
Treat this as a governance and mobile-security control-validation item rather than a complete detection rule. Leaders should ask whether mobile device privilege grants are inventoried, reviewable by users or administrators, and included in application vetting. The main decision value is confirming that mobile application risk reviews include elevated device-management permissions and that there is an accountable process to remove inappropriate access.
Technical view
SOC, mobile security, and detection engineering teams should validate whether their mobile security tooling or application vetting process can identify applications requesting or using device-administration-style privileges. Because no official detection logic, tactics, or relationships are supplied, teams should not treat AN1696 as a ready-to-deploy analytic. The platform/description mismatch should be resolved against local ATT&CK content or internal mobile platform scope before implementation.
Likely telemetry
- Mobile application inventory and permission metadata
- Application vetting or mobile app reputation results
- Mobile device management or enterprise mobility management records where available
- User or administrator review records for elevated mobile app permissions
Detection direction
- Confirm whether the monitored mobile platform actually supports the permission model described by the analytic; the supplied object lists iOS, while the description references Android.
- Validate that application vetting flags apps using elevated device administration privileges for additional scrutiny.
- Tune review workflows to distinguish expected enterprise management applications from unapproved or unnecessary apps with elevated permissions.
- Document coverage gaps where personal devices, unmanaged devices, or limited mobile telemetry prevent permission visibility.
Mitigation priorities
- Establish an application vetting requirement for mobile apps that request elevated administration privileges.
- Require periodic review and revocation of inappropriate mobile app administrative access where the platform supports it.
- Maintain an approved list or governance process for legitimate enterprise management applications.
- Use mobile management controls and user guidance to make elevated permission grants visible and actionable.
Analyst notes and limits
AN1696 is a detection analytic in the mobile ATT&CK domain with no supplied detection text and no relationship context. The official description discusses Android Device Administrator access, but the supplied platform field is iOS, so platform applicability should be verified before using this in reporting or engineering work.
This take is limited to the supplied STIX fields and external reference. No tactics, related techniques, detection logic, data components, mitigations, or relationships were provided. The platform inconsistency reduces confidence and requires local validation.
Analytic 1696
On Android, the user can review which applications have Device Administrator access in the device settings and revoke permission where appropriate. Application vetting services can detect and closely scrutinize applications that utilize Device Administrator access.
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 | 535605d96b1a… |
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 AN1696Open 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.