Mobile malware that changes a device PIN or account credential turns a compromise into an outage: the user, and often the business, loses access to the device and everything on it. MITRE ATT&CK for Mobile tracks this as T1640 Account Access Removal, an Impact technique in which accounts are deleted, locked or manipulated (for example by changing credentials) so legitimate users can no longer get in. This guide covers how the technique works on mobile, which platform controls now limit it, how to detect it with MDM and app vetting telemetry, and how to recover. It is written for mobile security engineers, endpoint teams and incident responders, and goes deeper than the MITRE ATT&CK for Mobile Guide.
Key takeaways
- ATT&CK lists Android only. T1640 in ATT&CK v20 has Android as its only platform, and its one procedure example is Monokle resetting the user's password or PIN.
- Device Administrator is the abuse path. The ATT&CK mitigation (M1011 User Guidance) warns that Device Administrator permissions are very dangerous and that very few apps need them.
- Modern Android closes most of the gap. Google deprecated the device admin reset password policy, which stops functioning on Android 11 and throws a SecurityException for apps targeting API level 24 and above.
- Detection is about who called the API. The ATT&CK detection strategy (DET0605) flags DevicePolicyManager resetPassword, lockNow or wipeData calls from any package that is not your MDM agent.
- Recovery depends on management mode. A managed device can be unlocked, reset or wiped centrally; an unmanaged personal phone usually means a factory reset and restore from backup.
What T1640 looks like on a mobile device
ATT&CK describes Account Access Removal as interrupting the availability of system and network resources by inhibiting access to accounts used by legitimate users. On a phone the "account" is most often the device lock screen credential itself, but the same intent covers app accounts and cloud identities whose credentials an attacker changes after stealing them.
- Device credential reset: a malicious app with device administrator rights calls the password reset API and sets a PIN the user does not know. This is the behaviour ATT&CK records for Monokle (S0407), surveillance software that ATT&CK says can reset the user's password or PIN.
- Account credential change: with stolen credentials or session tokens, an attacker changes the password or recovery details of an email, social or enterprise account from the phone, locking the owner out of the service.
- Destructive follow-on: the same admin policies that allow a forced lock also allow a wipe, so a lockout can escalate into data loss.
The technique sits next to Endpoint Denial of Service (T1642), which ATT&CK uses for lock screen ransom and overlay lockouts. The enterprise equivalent, covering directory and cloud accounts, is in the MITRE ATT&CK T1531 Account Access Removal.
Android and iOS: what each platform allows
ATT&CK lists T1640 for Android only. It has no iOS procedure example, and this guide does not invent one. The platform facts below explain why the risk differs.
| Control point | Android | iOS and iPadOS |
|---|---|---|
| Who can reset the lock screen credential | Legacy device admin apps could, until Google deprecated USES_POLICY_RESET_PASSWORD; on Android 11 it stops functioning and apps targeting API level 24 and above get a SecurityException. Device owner and profile owner (Android Enterprise) remain the managed path. | The MDM Clear Passcode command removes the passcode; it needs the device UnlockToken and the AllowPasscodeRemovalAndLock access right. ATT&CK notes, in its T1642 entry, that MDM can only remove a passcode, not set a new one. |
| Forced lock and wipe | USES_POLICY_FORCE_LOCK and USES_POLICY_WIPE_DATA remain available to device admins for consumer lock and wipe use cases. | Lock and erase are MDM commands sent by the enrolling server, not by third party apps. |
| Hardening option for high-risk users | Managed device or work profile mode through an EMM, with app allow lists. | Lockdown Mode (iOS 16 and later) blocks installing configuration profiles and enrolling in MDM while it is on. |
The practical consequence: on current, patched Android the third party lock screen reset path is largely closed, so T1640 risk concentrates on old OS versions, sideloaded apps with device admin rights, and account takeover of cloud services. On iOS the lock screen path runs through the MDM server, which makes the MDM itself a privileged non-human identity worth protecting. See the Mobile Device Management Security Guide.
Prevention controls
- Raise the OS floor: set an MDM compliance rule that blocks corporate access below a supported Android or iOS version. The device admin reset behaviour changed in Android 11, so devices below it deserve stricter treatment.
- Control device admin grants: on Android Enterprise, use managed device or work profile mode and an app allow list so only the DPC holds administrative policy. Google's migration guidance points to device owner mode for company owned devices and work profile mode for personal devices.
- Block sideloading: keep installs from unknown sources disabled by policy on managed devices, and keep Google Play Protect on, which checks apps at install, periodically scans the device, and may deactivate or remove harmful apps.
- Train users on admin prompts (M1011 User Guidance): teach that an "activate device admin" prompt from a flashlight, utility or "security" app is a red flag.
- Protect the accounts behind the phone: phishing resistant MFA and alerts on password or recovery changes reduce the cloud account variant. See the Mobile Access Credentials.
- Back up: enforce cloud or managed backup so a reset device can be restored quickly.
Detection and measurement
ATT&CK detection strategy DET0605 (Detection of Account Access Removal) correlates three evidence sources on Android: dynamic API traces from app vetting (DevicePolicyManager resetPassword, lockNow or wipeData called by a caller not in your MDM agent package list), permission grant state from the DPC, and host status from DPC security state queries and SecurityLog.
| Signal | Where to collect it | What to alert on |
|---|---|---|
| Active device admin apps | EMM managed app inventory, DPC queries | Any device admin that is not the approved DPC |
| Password, lock or wipe API calls | App vetting and dynamic analysis | Calls from packages outside the MDM agent list |
| Unexpected passcode or compliance change | MDM compliance and device information reports | Passcode state changed with no matching admin action |
| Helpdesk lockout tickets | ITSM | Cluster of "forgot PIN" tickets on one app or OS version |
| Cloud account recovery changes | Identity provider audit logs | Password or recovery change from a new device followed by lockout |
Metrics: share of fleet on supported OS versions; number of non-DPC device admin apps found per month (target zero); median time from lockout report to restored access; percentage of devices with a verified backup in the last 30 days; percentage of corporate apps vetted dynamically before approval.
Response and recovery
- Confirm the cause: distinguish a forgotten PIN from an unexpected change. Check MDM logs for any admin issued lock or clear command first.
- Contain: revoke the device's tokens and sessions at the identity provider and block it from corporate resources through conditional access.
- Restore access: on iOS use Clear Passcode where the MDM holds an UnlockToken; on Android Enterprise use the DPC's managed reset path; otherwise plan a factory reset.
- Preserve evidence before wiping: where the device can be unlocked, capture the app list and logs. For suspected spyware use the Mobile Spyware Infection Response Playbook and the Mobile Verification Toolkit (MVT).
- Rotate credentials: assume anything on the device was exposed, including app tokens and API keys cached by mobile apps.
- Restore and verify: re-enrol, restore from backup and confirm only the approved DPC holds admin rights.
Common failure patterns
- Old Android left on the network: devices below Android 11 keep the legacy reset password behaviour, and they are often the devices nobody tracks.
- Treating lockouts as helpdesk noise: PIN resets get closed without asking why, so a malicious device admin goes unnoticed.
- No UnlockToken or escrow: the MDM cannot clear a passcode it never escrowed, forcing a wipe and data loss.
- Wiping before triage: the fastest fix destroys the evidence needed to know what else the app took.
- Forgetting the MDM's own credentials: the MDM console can lock or wipe every device, so a stolen admin account produces the same impact at scale.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| ATT&CK for Mobile | T1640; M1011 (the only mitigation ATT&CK v20 maps); DET0605 | Technique, mitigation and detection strategy |
| NIST SP 800-53 Rev 5 | AC-19 Access Control for Mobile Devices; CM-11 User-installed Software; CP-9 System Backup; IA-5 Authenticator Management | Device policy, app control, recovery, credential handling |
| NIST CSF 2.0 | PR.PS-05; DE.CM-09; RS.MI-01 | Block unauthorised software, monitor devices, contain incidents |
Practitioner checklist
- Set an OS version floor in MDM compliance and block access below it.
- Enrol corporate Android devices in device owner or work profile mode.
- Report every active device admin app and alert on anything other than the DPC.
- Escrow the iOS UnlockToken so the MDM can clear a passcode.
- Disable unknown sources and keep Play Protect on for managed Android devices.
- Correlate helpdesk lockout tickets with MDM and identity logs.
- Protect MDM admin accounts with phishing resistant MFA and least privilege.
- Write a lockout runbook that preserves evidence before any wipe.
Standards and references
- MITRE ATT&CK: T1640 Account Access Removal (Mobile)
- Google: Device admin deprecation
- Android Developers: Device administration overview
- 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 · Android Enterprise Security Guide · Mobile Malware Guide · Mobile Threat Defense Buyer's Guide