AN1655: Analytic 1655
Application vetting services could closely scrutinize applications that request Device Administrator permissions.
Analyst context for executives and security teams
This analytic highlights a mobile security review point: Android applications that request Device Administrator permissions deserve extra scrutiny during app vetting. For leaders, the decision value is whether the organization has a reliable way to identify and review high-privilege mobile apps before they create unmanaged device, identity, or operational risk.
Executive priority
Prioritize this as a mobile governance and risk-control question rather than a standalone alert. Executives should ask whether Android app approval, mobile device management, and compliance evidence can show which apps request Device Administrator permissions, who approved them, and whether that access is still justified. This matters for business continuity and audit readiness because excessive mobile administrative privileges can complicate incident response and device control decisions.
Technical view
For SOC, mobile security, and IR teams, validate whether Android app vetting workflows capture permission requests, specifically Device Administrator permissions. Because the ATT&CK object provides no official detection logic, tactics, or relationships, teams should treat this as a control-validation analytic: confirm that app inventory, mobile management data, and vetting records can identify apps requesting this permission and support review decisions.
Likely telemetry
- Android application permission metadata
- Mobile device management or enterprise mobility management application inventory
- App vetting or mobile application security review results
- Approved application allowlist or catalog records
- Device compliance and enrollment records
Detection direction
- Validate that Android apps requesting Device Administrator permissions are visible in app vetting or mobile management workflows.
- Tune review processes to distinguish expected enterprise administration tools from unusual or unjustified apps requesting elevated device permissions.
- Check for blind spots where personally owned, unmanaged, sideloaded, or unvetted Android apps may not be represented in enterprise telemetry.
- Because no official detection is provided, avoid treating this as a complete SOC detection without local logic, thresholds, and response criteria.
Mitigation priorities
- Require formal review for Android applications that request Device Administrator permissions.
- Maintain an approved application catalog and document business justification for high-privilege mobile apps.
- Use mobile management and compliance processes to enforce approved app usage where organizational policy allows.
- Periodically revalidate whether apps with Device Administrator permissions remain necessary and approved.
Analyst notes and limits
This Glexia take is based only on ATT&CK analytic AN1655. The object is a detection analytic in the mobile ATT&CK domain for Android and states that application vetting services could closely scrutinize applications requesting Device Administrator permissions. No tactics, relationships, official detection logic, aliases, or labels were supplied.
The source does not provide detection syntax, event IDs, specific data sources, related techniques, threat groups, software, or evidence of exploitation. Local Android management architecture, ownership model, app distribution process, and available telemetry are required to turn this into an operational detection or control test.
Analytic 1655
Application vetting services could closely scrutinize applications that request Device Administrator permissions.
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 | 5033d6aa3220… |
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 AN1655Open 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.