AN1701: Analytic 1701
Correlates (1) activation of Device Administrator privileges by an application, (2) absence or mismatch of legitimate user interaction during the approval flow, and (3) immediate execution of administrator-level control actions (e.g., password reset, device lock, policy enforcement, prevention of uninstall). The defender observes a causal chain where an application transitions into a privileged device control role and rapidly exercises those capabilities outside expected user-driven patterns.
Application vetting services can check for the string `BIND_DEVICE_ADMIN` in the application’s manifest.
Analyst context for executives and security teams
This analytic matters because Android Device Administrator privileges can give an application high-control capabilities over a device. The decision value is not just whether an app requests the permission, but whether privilege activation appears to happen without expected user approval and is quickly followed by administrator-level actions such as locking the device, resetting a password, enforcing policy, or preventing uninstall.
Executive priority
For organizations that rely on Android endpoints, this is a mobile resilience and governance issue: leaders should confirm whether mobile security operations can prove when an app becomes a device administrator, whether that approval was user-driven, and what administrative actions followed. This supports incident triage, compliance evidence around managed devices, and prioritization of mobile application vetting controls.
Technical view
SOC, mobile security, and IR teams should validate whether they can correlate three evidence points on Android: Device Administrator activation by an application, user-interaction context during the approval flow, and rapid follow-on administrator actions. Because no ATT&CK tactic or formal detection logic is supplied, teams should treat this as a correlation pattern to operationalize and test against local mobile management, endpoint, and application-vetting data sources.
Likely telemetry
- Android application manifest data, including presence of BIND_DEVICE_ADMIN
- Device Administrator activation events for applications
- User approval or interaction context during Device Administrator enablement
- Administrator-level control actions such as device lock, password reset, policy enforcement, or uninstall prevention
- Mobile device management or mobile endpoint security logs where available
Detection direction
- Validate correlation across privilege activation, approval-flow interaction evidence, and immediate administrator-level actions rather than alerting only on BIND_DEVICE_ADMIN presence.
- Tune for timing and causality: an app that becomes a device administrator and rapidly exercises control capabilities outside expected user-driven patterns should receive higher scrutiny.
- Account for legitimate enterprise device management apps, which may produce similar administrative events and require allowlisting or contextual suppression.
- Identify blind spots where mobile telemetry does not capture user interaction, administrator activation, or post-activation control actions.
- Use application vetting to flag apps whose manifests include BIND_DEVICE_ADMIN, but do not treat the string alone as proof of malicious behavior.
Mitigation priorities
- Inventory Android applications that request or use Device Administrator capabilities.
- Strengthen mobile application vetting for Device Administrator declarations in manifests.
- Confirm that approved enterprise management applications are documented so detections can distinguish expected administration from suspicious activation chains.
- Ensure mobile incident response playbooks include review of recent Device Administrator activation and follow-on control actions.
- Prioritize telemetry collection from mobile management, endpoint security, or application-vetting services needed to reconstruct the described causal chain.
Analyst notes and limits
The supplied object is a detection analytic for Android in the mobile ATT&CK domain. It describes a behavioral correlation involving Device Administrator activation, questionable or absent user interaction, and rapid use of privileged device controls. No relationship context, aliases, labels, tactics, or official detection implementation are provided.
This take is constrained to the supplied ATT&CK fields. It does not establish active exploitation, attacker attribution, prevalence, or guaranteed detection coverage. Local Android management architecture and available telemetry will determine whether the analytic can be implemented reliably.
Analytic 1701
Correlates (1) activation of Device Administrator privileges by an application, (2) absence or mismatch of legitimate user interaction during the approval flow, and (3) immediate execution of administrator-level control actions (e.g., password reset, device lock, policy enforcement, prevention of uninstall). The defender observes a causal chain where an application transitions into a privileged device control role and rapidly exercises those capabilities outside expected user-driven patterns.
Application vetting services can check for the string `BIND_DEVICE_ADMIN` in the application’s manifest.
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 | b84f6c4120f6… |
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 AN1701Open 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.