T1629.002: Device Lockout
An adversary may seek to inhibit user interaction by locking the legitimate user out of the device. This is typically accomplished by requesting device administrator permissions and then locking the screen using `DevicePolicyManager.lockNow()`. Other novel techniques for locking the user out of the device have been observed, such as showing a persistent overlay, using carefully crafted “call” notification screens, and locking HTML pages in the foreground. These techniques can be very difficult to get around, and typically require booting the device into safe mode to uninstall the malware.[1][2][3]
Prior to Android 7, device administrators were able to reset the device lock passcode to prevent the user from unlocking the device. The release of Android 7 introduced updates that only allow device or profile owners (e.g. MDMs) to reset the device’s passcode.[4]
Analyst context for executives and security teams
Device Lockout is an Android mobile technique where malware prevents the legitimate user from interacting with the device, including through device administrator abuse, persistent overlays, call-like notification screens, or foreground-locking pages. For leaders, the practical issue is loss of user access at the moment the device may be needed for business communication, authentication, banking, or incident coordination. It is especially material where Android devices support workforce access, mobile approvals, or transaction authorization workflows.
Executive priority
Treat this as a mobile resilience and identity-access risk, not just a malware nuisance. If employees rely on Android devices for MFA, approvals, communications, or regulated workflows, device lockout can disrupt operations and complicate incident response. Priority questions are: which business processes depend on Android availability, whether managed devices are on recent OS versions, whether MDM/profile-owner controls are governed, and whether the SOC can distinguish legitimate administrative lock actions from suspicious lockout behavior. The supplied ATT&CK relationships also tie this behavior to Android banking malware and mobile ransomware examples, so response plans should include user lockout recovery and evidence preservation.
Technical view
Validate Android-focused coverage for lockout behavior under the broader Impair Defenses context. MITRE notes use of device administrator permissions and screen locking via Android device policy functions, as well as overlay or foreground-locking techniques that can block user interaction. Because ATT&CK provides no official detection text for this object, SOC teams should use the related detection strategy DET0603 as a starting point and test whether mobile telemetry exposes device administrator permission changes, lock events, overlay behavior, persistent foreground activity, suspicious notification screens, and app uninstall friction. IR playbooks should include safe-mode or managed-device recovery paths where appropriate, while preserving app, permission, and event evidence before remediation when possible.
Likely telemetry
- Android device administrator permission grants, changes, and removals
- MDM or enterprise mobility management records for device/profile owner status and passcode policy actions
- Mobile endpoint/security agent alerts for ransomware-like UI blocking, persistent overlays, or suspicious foreground activity
- Android OS version and patch/version inventory, especially pre-Android 7 exposure where passcode reset behavior differed
- Application install source, package metadata, permission requests, and recent app activity around the lockout time
Detection direction
- Confirm whether Android mobile telemetry can observe device administrator permission use and suspicious lock actions; many environments collect MDM posture data but not detailed on-device behavioral events.
- Tune for combinations of risky signals rather than a single event: newly installed or suspicious apps requesting elevated device administration, followed by lockout-like UI behavior or user reports.
- Account for legitimate MDM, helpdesk, and compliance actions that may lock devices or enforce passcode policy; detections should distinguish authorized device/profile owner activity from unexpected third-party app behavior.
- Include overlay and foreground-persistence behaviors in hunting logic, since the ATT&CK description notes lockout can occur without only relying on classic device administrator passcode reset behavior.
- Use relationship context to enrich triage when artifacts overlap with known Android malware families referenced by ATT&CK, including Rotexy, TrickMo, and AndroidOS/MalLocker.B, without assuming attribution.
Mitigation priorities
- Prioritize Android OS currency, aligned with ATT&CK mitigation M1006, because newer mobile operating systems can include security architecture changes that reduce abuse paths; Android 7 changed passcode reset capability to device/profile owners.
- Restrict and govern device administrator, device owner, and profile owner privileges through approved MDM or enterprise mobility processes.
- Maintain an inventory of Android versions, managed status, and business-critical mobile users so response teams know which devices may be harder to recover or investigate.
- Prepare mobile IR procedures for user lockout scenarios, including safe recovery, evidence capture, malware removal, and escalation paths for devices used in MFA or financial workflows.
- Educate helpdesk and SOC teams to treat sudden Android lockout, persistent overlays, or ransom-like screens as potential security events, not only usability issues.
Analyst notes and limits
This take is based only on the supplied ATT&CK object, references, and relationships. The object is an Android sub-technique of Impair Defenses and has no specified tactics in the supplied data. ATT&CK identifies examples of software using this behavior, including Rotexy, TrickMo, and AndroidOS/MalLocker.B, and links a detection strategy, DET0603, but the official detection field for the technique itself is not provided.
Local validation is required. The supplied fields do not establish active exploitation against any organization, do not provide complete detection logic, and do not support claims for iOS coverage for this current object. Telemetry availability will vary significantly between managed Android, BYOD, and privacy-restricted environments.
Device Lockout
An adversary may seek to inhibit user interaction by locking the legitimate user out of the device. This is typically accomplished by requesting device administrator permissions and then locking the screen using `DevicePolicyManager.lockNow()`. Other novel techniques for locking the user out of the device have been observed, such as showing a persistent overlay, using carefully crafted “call” notification screens, and locking HTML pages in the foreground. These techniques can be very difficult to get around, and typically require booting the device into safe mode to uninstall the malware.[1][2][3]
Prior to Android 7, device administrators were able to reset the device lock passcode to prevent the user from unlocking the device. The release of Android 7 introduced updates that only allow device or profile owners (e.g. MDMs) to reset the device’s passcode.[4]
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.
Related techniques
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Mobile | T1629 | Impair Defenses | This object subtechnique of Impair Defenses. |
| Mobile | T1446 | Device Lockout | Device Lockout revoked by this object. |
Groups, software, and campaigns
S0427: TrickMo
S0524: AndroidOS/MalLocker.B
AndroidOS/MalLocker.B is a variant of a ransomware family targeting Android devices. It prevents the user from interacting with the UI by displaying a screen containing a ransom note over all other windows. [1]
S0411: Rotexy
All related ATT&CK context
Mitigation direction
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 | 696845f408c0… |
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]
Microsoft MalLockerB
D. Venkatesan. (2020, October 8). Sophisticated new Android malware marks the latest evolution of mobile ransomware . Retrieved October 29, 2020.
Open source URL -
[2]
Talos GPlayed
V. Ventura. (2018, October 11). GPlayed Trojan - .Net playing with Google Market . Retrieved November 24, 2020.
Open source URL -
[3]
securelist rotexy 2018
T. Shishkova, L. Pikman. (2018, November 22). The Rotexy mobile Trojan – banker and ransomware. Retrieved September 23, 2019.
Open source URL -
[4]
Android resetPassword
Google. (n.d.). DevicePolicyManager. Retrieved October 1, 2019.
Open source URL -
[5]
NIST Mobile Threat Catalogue APP-22Open source URL
-
[6]
mitre-attack T1629.002Open 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.