AN1652: Analytic 1652
Correlates (1) acquisition or presence of elevated control paths capable of forcing a lock state or blocking user interaction, (2) invocation of screen-locking or UI-denial behavior such as DevicePolicyManager lock operations, persistent overlays, accessibility-driven navigation interruption, or foreground lock-screen impersonation, and (3) immediate transition of the device into an unavailable or repeatedly re-locked state while the responsible application remains installed and active. The defender observes a causal chain where an application first gains the ability to control lock-related behavior, then forces or simulates lockout, and the device becomes unusable to the legitimate user.
Analyst context for executives and security teams
This analytic matters because it focuses on Android apps that can make a device unavailable to its legitimate user by gaining lock-related control and then forcing or simulating a lockout. For business leaders, the practical risk is not just malware presence; it is loss of access to mobile devices that may support operations, identity workflows, communications, or field activity. The decision value is whether the organization can prove it collects enough mobile telemetry to reconstruct the chain from permission/control acquisition to lockout behavior to user impact.
Executive priority
Prioritize this as a mobile resilience and incident-response readiness question: can security teams identify when an Android device becomes unusable because an installed app is actively controlling or impersonating lock behavior? Leaders should ask whether managed Android devices provide evidence for application privileges, DevicePolicyManager activity, overlay or accessibility abuse indicators, foreground lock-screen impersonation, and repeated re-locking. This also supports audit and compliance discussions where mobile device control, user access continuity, and response evidence are in scope.
Technical view
For SOC, mobile security, and IR teams, the analytic is correlation-driven rather than a single indicator. Validate whether telemetry can link three events on Android: first, an application obtains or possesses elevated control paths related to lock or user-interaction control; second, it invokes screen-locking or UI-denial behavior such as DevicePolicyManager lock operations, persistent overlays, accessibility-driven navigation interruption, or foreground lock-screen impersonation; third, the device immediately becomes unavailable or repeatedly re-locked while the same responsible application remains installed and active. Because no ATT&CK detection text or relationships were supplied, teams should treat this as a detection-design requirement and test it against local mobile logging, EMM/MDM data, and endpoint/mobile security event availability.
Likely telemetry
- Android application inventory and installation state
- Application permission and privilege state, especially device administration or lock-related control paths
- DevicePolicyManager-related events where available
- Accessibility service enablement and activity indicators where available
- Overlay or foreground application behavior relevant to UI denial or lock-screen impersonation
Detection direction
- Build correlation around sequence and causality, not isolated presence of a permission or a lock event.
- Validate that the same application can be tied to elevated control capability, lock or UI-denial behavior, and the resulting unavailable or repeatedly re-locked device state.
- Tune for legitimate administrative actions by known device management tools to reduce false positives.
- Treat persistent overlays, accessibility-driven interruption, and foreground lock-screen impersonation as higher-risk when temporally close to device unavailability.
- Identify telemetry gaps on unmanaged or lightly managed Android devices, where privilege state, overlay behavior, or lock transitions may not be centrally visible.
Mitigation priorities
- Confirm Android device management coverage and logging depth before assuming this behavior is detectable.
- Restrict and monitor applications that can obtain device administration, accessibility, overlay, or other lock/user-interaction control capabilities where organizational policy allows.
- Maintain an approved baseline of legitimate mobile management and accessibility use cases to support faster triage.
- Ensure incident response procedures include recovery paths for devices that are repeatedly locked or unavailable while preserving evidence about the responsible application.
- Review mobile app approval, deployment, and removal processes so suspicious applications can be identified and remediated without relying solely on user reports.
Analyst notes and limits
This object is an ATT&CK mobile detection analytic for Android. The supplied description defines a causal chain: acquisition or presence of elevated lock/UI control paths, invocation of screen-locking or UI-denial behavior, and immediate device unavailability or repeated re-locking while the responsible application remains installed and active. No tactic, relationship context, or official detection implementation was supplied, so the take emphasizes validation of telemetry and correlation design rather than claiming a complete detection.
The source fields do not provide ATT&CK tactic mapping, related techniques, data components, sample queries, tooling, adversary use, or detection coverage claims. Applicability outside Android is not supported by the supplied object. Local MDM/EMM, mobile endpoint, and Android logging capabilities will determine whether this analytic can be implemented with sufficient fidelity.
Analytic 1652
Correlates (1) acquisition or presence of elevated control paths capable of forcing a lock state or blocking user interaction, (2) invocation of screen-locking or UI-denial behavior such as DevicePolicyManager lock operations, persistent overlays, accessibility-driven navigation interruption, or foreground lock-screen impersonation, and (3) immediate transition of the device into an unavailable or repeatedly re-locked state while the responsible application remains installed and active. The defender observes a causal chain where an application first gains the ability to control lock-related behavior, then forces or simulates lockout, and the device becomes unusable to the legitimate user.
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 | 5f38c0ef6897… |
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 AN1652Open 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.