A phone that will not unlock, shows a ransom screen or will not boot is a business outage for the person holding it, and for mobile-first workers it can stop work entirely. MITRE ATT&CK for Mobile tracks this as T1642 Endpoint Denial of Service, an Impact technique used to degrade or block the availability of services to users, and lists it for both Android and iOS. This guide covers the documented patterns (lock screen ransom, persistent overlays, passcode resets and, on iOS, destructive spyware plugins), the platform changes that limit each one, and how to detect, respond and recover. It is for endpoint and mobile security teams and incident responders, and goes deeper than the MITRE ATT&CK for Mobile Guide.
Key takeaways
- Both platforms are listed. ATT&CK v20 maps T1642 to Android and iOS, but the routes differ sharply between them.
- Android passcode resets were closed by OS changes. ATT&CK notes that from Android 7 only device or profile owners (for example MDMs) can reset the passcode, and Google's device admin reset password policy stops functioning on Android 11.
- Overlays remain an Android route. GPlayed, as ATT&CK records, locked users out with a persistent overlay rather than a passcode.
- On iOS the documented cases need a compromised device. ATT&CK says MDM can only remove an iOS passcode, not set one, and that lockout malware was found on jailbroken devices; LightSpy used plugins to disable SpringBoard and stop the device booting.
- Recovery speed is the real control. Managed enrolment, backups and a tested reset path decide whether an incident costs minutes or days.
How T1642 shows up on each platform
| Pattern | Platform | Software (ATT&CK ID) as ATT&CK records it |
|---|---|---|
| Lock device after admin grant and demand ransom | Android | Charger (S0323) locks the device if granted admin permissions and shows a ransom message |
| Remote lock with ransom demand | Android | Xbot (S0298) can remotely lock infected devices and ask for a ransom |
| Set a password and disable the screen | Android | Exobot (S0522) can lock the device with a password and permanently disable the screen |
| Persistent overlay lockout | Android | GPlayed (S0536) can lock the user out by showing a persistent overlay |
| Disable home screen manager, prevent boot | iOS | LightSpy (S1185) used a DeleteSpring plugin to disable SpringBoard and a BootDestroy plugin to stop the device booting |
ATT&CK's iOS text is explicit: the passcode reset approach does not work on iOS because MDM servers can only remove the screen lock passcode, and lockout malware has been seen on jailbroken devices. Apple's documentation for the MDM Clear Passcode command confirms the command removes the passcode, requires the device UnlockToken, and needs the AllowPasscodeRemovalAndLock access right.
Network flooding against mobile services is a separate technique, T1464 Network Denial of Service. Locking a specific account rather than the device is T1640 Account Access Removal.
Platform controls that limit the technique
Android
- Device admin deprecation: Google deprecated four device admin policies (disable camera, disable keyguard features, expire password, limit password) in Android 9, made them throw a SecurityException in Android 10 for apps targeting API level 29, and made USES_POLICY_RESET_PASSWORD stop functioning in Android 11 with a SecurityException for apps targeting API level 24 and above. Force lock and wipe remain available to device admins.
- Background activity limits: Android 10 restricts apps starting activities from the background, which makes it harder for a hidden app to throw a full screen over the user unprompted.
- Managed modes: Google's migration guidance is device owner mode for company owned devices and work profile mode for personal devices, through an EMM.
- Play Protect: checks apps at install, scans periodically, and may deactivate or remove harmful apps, including those from other sources.
iOS and iPadOS
- No third party passcode setting: as above, even MDM can only clear a passcode; the documented iOS cases needed a compromised device.
- Updates (M1006 Use Recent OS Version): keeping devices current closes the exploits that spyware such as LightSpy depends on.
- Lockdown Mode: for high-risk users on iOS 16 and later, Lockdown Mode blocks most message attachment types, link previews and some complex web technologies, and requires the device to be unlocked to connect to accessories. Note that it also prevents MDM enrolment while it is on. See the Mobile Communications Protection for High-Risk Individuals Guide.
Prevention: a phased approach
- Inventory and baseline: list OS versions and active device admin apps across the fleet from your MDM.
- Set compliance rules: block corporate access below your supported OS floor and from devices with unapproved device admins. Run the rule in report-only mode for two weeks to size the impact before enforcing.
- Move Android to managed modes: migrate legacy device admin enrolments to device owner or work profile, pilot one business unit, then roll out.
- Close sideloading: disable unknown sources on managed devices and allow list apps.
- Guarantee recovery: enforce backup, escrow iOS UnlockTokens, and test a full device replacement end to end.
- Train users (M1011 User Guidance): ATT&CK advises cautioning users against granting administrative access to apps.
Rollback: keep compliance actions at "notify" before "block", and keep a break-glass exception group so critical users are not cut off by a mis-scoped rule.
Detection and measurement
ATT&CK detection strategy DET0627 has analytics for both platforms. On Android it correlates app vetting traces of DevicePolicyManager lockNow or resetPassword calls by any caller not in the MDM agent list, DPC permission grant state, and DPC security state and SecurityLog. On iOS it uses app vetting of code signing entitlements and Info.plist keys, plus MDM DeviceInformation, SecurityInfo, ProfileList and restriction queries, treated as periodic observations.
| Signal | Platform | Alert on |
|---|---|---|
| Lock or reset API from a non-MDM package | Android | Any occurrence in vetting or MTD telemetry |
| Unapproved device admin or overlay permission | Android | New grant outside the allow list |
| Unexpected profile or restriction change | iOS | ProfileList or SecurityInfo differs from baseline |
| Device stops checking in | Both | Abrupt check-in loss on a recently healthy device, especially in clusters |
| Lockout or "phone will not start" tickets | Both | Clusters by OS version, app or user group |
Metrics: percentage of devices on a supported OS; count of unapproved device admin or overlay grants (target zero); mean time to restore a locked user to a working device; percentage of devices with a backup in the last 30 days; percentage of Android fleet in device owner or work profile mode.
Response and recovery
- Triage: establish whether the user can reach the lock screen, sees an overlay, or the device will not boot. A ransom message points to Android ransomware; a boot failure on a patched iPhone in a high-risk role warrants a spyware investigation.
- Contain: block the device in conditional access and revoke its tokens; give the user a loan device.
- Do not pay: treat ransom as a sign of malware, not as a recovery path.
- Preserve evidence: where possible take a backup or forensic acquisition before reset. For suspected spyware, follow the Mobile Spyware Infection Response Playbook and consider the Mobile Verification Toolkit (MVT).
- Recover: use the MDM to remove the offending app where the device still checks in on Android; clear the passcode by MDM on iOS; otherwise factory reset and restore.
- Rotate: assume credentials and app tokens on the device were exposed and rotate them.
Common failure patterns
- Legacy device admin enrolments left in place: they keep the older, broader policy surface alive.
- No backup policy: a recoverable lockout becomes permanent data loss.
- Allowing any app overlay permission: overlays remain a working lockout route on Android.
- Wiping before investigating: on high-risk users, the boot failure may be the only visible sign of spyware.
- Weak MDM admin protection: the console's lock and wipe commands can cause the same outage across the fleet.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| ATT&CK for Mobile | T1642; M1006, M1011 (the mitigations ATT&CK v20 maps); DET0627 | Technique, mitigations, detection |
| NIST SP 800-53 Rev 5 | AC-19 Access Control for Mobile Devices; SI-3 Malicious Code Protection; CM-11 User-installed Software; CP-9 System Backup | Device policy, malware protection, app control, recovery |
| NIST CSF 2.0 | PR.PS-02; PR.PS-05; DE.CM-09; RS.MI-01 | Patch, block unauthorised software, monitor, contain |
The enterprise equivalent is T1499 Endpoint Denial of Service.
Practitioner checklist
- Enforce an OS version floor for both Android and iOS.
- Migrate Android device admin enrolments to device owner or work profile.
- Allow list apps and block unknown sources on managed Android devices.
- Alert on device admin, overlay and profile changes outside policy.
- Escrow iOS UnlockTokens and test MDM passcode clearing.
- Enforce backups and keep loan devices for fast recovery.
- Offer Lockdown Mode to high-risk iOS users, accounting for its MDM enrolment limit.
- Preserve evidence before any wipe on high-risk users.
Standards and references
- MITRE ATT&CK: T1642 Endpoint Denial of Service (Mobile)
- Google: Device admin deprecation
- Android Developers: Privacy changes in Android 10
- Apple Developer: Clear Passcode command
- Apple Support: About Lockdown Mode
- Google Play Help: Use Google Play Protect
Related NHI Mgmt Group resources: MITRE ATT&CK for Mobile Guide · Mobile Device Management Security Guide · Android Enterprise Security Guide · Mobile Malware Guide