T1642: Endpoint Denial of Service
Adversaries may perform Endpoint Denial of Service (DoS) attacks to degrade or block the availability of services to users.
On Android versions prior to 7, apps can abuse Device Administrator access to reset the device lock passcode, preventing the user from unlocking the device. After Android 7, only device or profile owners (e.g. MDMs) can reset the device’s passcode.[1]
On iOS devices, this technique does not work because mobile device management servers can only remove the screen lock passcode; they cannot set a new passcode. However, on jailbroken devices, malware has been discovered that can lock the user out of the device.[2]
Analyst context for executives and security teams
Endpoint Denial of Service matters because a compromised or abused mobile device can become unavailable to the user, not just have data stolen. In the supplied ATT&CK description, the key business issue is mobile lockout: older Android behavior allowed certain administrator-level apps to reset the lock passcode, while jailbroken iOS devices have had malware observed locking users out. For organizations that rely on mobile devices for operations, approvals, communications, field work, or incident response, this is an availability and resilience concern.
Executive priority
Prioritize this where mobile devices are operationally important, where legacy Android devices remain in use, or where unmanaged/jailbroken devices are allowed to access business services. Leaders should ask whether mobile OS currency, MDM ownership controls, user guidance, and recovery procedures are sufficient to prevent a device lockout from becoming a business interruption or support surge. This technique also supports compliance evidence around mobile device governance, supported OS baselines, and user security guidance.
Technical view
This is a mobile ATT&CK technique for Android and iOS with no official detection text provided. SOC, mobile security, and IR teams should validate coverage around device lockout events, Device Administrator or device/profile owner changes on Android, unsupported Android versions prior to 7, and jailbreak status on iOS. Relationship context shows DET0627 as a detection strategy and M1006 Use Recent OS Version plus M1011 User Guidance as mitigations. Several mobile malware entries are related, especially Android software, so detection engineering should treat unexpected administrative control changes and lockout reports as triage signals rather than relying only on malware family names.
Likely telemetry
- MDM/UEM device inventory, OS version, ownership mode, compliance state, and enrollment status
- Android Device Administrator, device owner, or profile owner permission changes where available
- Mobile device lock/passcode policy change events and failed unlock or lockout-related help desk reports
- Jailbreak detection or iOS device integrity/compliance status
- Mobile security product alerts tied to suspicious administrative behavior or known mobile malware
Detection direction
- Because ATT&CK provides no official detection text, first confirm what mobile management and security telemetry is actually collected and retained.
- Tune for suspicious or unexpected administrative permission grants, ownership-mode changes, or passcode-related policy changes, especially on Android devices below version 7 where applicable.
- Correlate technical events with help desk reports of sudden device lockout; user reports may be an important signal for availability-focused mobile incidents.
- Separate legitimate MDM actions from unexpected app-driven or unauthorized administrative behavior to reduce false positives.
- For iOS, avoid assuming standard MDM passcode reset behavior is equivalent to this technique; the supplied ATT&CK text notes iOS MDM can remove but not set a new passcode, while jailbroken devices are the relevant risk case.
Mitigation priorities
- Maintain recent supported mobile OS versions, aligned to M1006, with special attention to retiring Android versions prior to 7 where feasible.
- Use MDM/UEM policy to enforce supported OS baselines, device compliance, and restrictions on unmanaged or jailbroken devices accessing business services.
- Provide user guidance, aligned to M1011, on avoiding risky app permissions, reporting unexpected lockouts quickly, and not bypassing device security controls.
- Document recovery and escalation procedures for mobile lockout incidents so availability events do not stall operations or incident response communications.
- Review whether business-critical workflows depend on single mobile endpoints and plan alternate access paths for continuity.
Analyst notes and limits
The materiality of this technique depends heavily on the organization’s mobile estate: Android version mix, MDM ownership model, allowance of personal or jailbroken devices, and reliance on mobile devices for critical workflows. Relationship context links this behavior to multiple mobile malware objects, including Android-focused software, but that should be used for prioritization and enrichment rather than attribution.
The ATT&CK object does not provide tactics or official detection guidance. The supplied relationship to DET0627 identifies a detection strategy by name only, without detailed analytics. Local telemetry, MDM capabilities, OS versions, and device ownership models are required to assess actual exposure and coverage.
Endpoint Denial of Service
Adversaries may perform Endpoint Denial of Service (DoS) attacks to degrade or block the availability of services to users.
On Android versions prior to 7, apps can abuse Device Administrator access to reset the device lock passcode, preventing the user from unlocking the device. After Android 7, only device or profile owners (e.g. MDMs) can reset the device’s passcode.[1]
On iOS devices, this technique does not work because mobile device management servers can only remove the screen lock passcode; they cannot set a new passcode. However, on jailbroken devices, malware has been discovered that can lock the user out of the device.[2]
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.
Groups, software, and campaigns
S0298: Xbot
S0536: GPlayed
S0323: Charger
S1185: LightSpy
First observed in 2018, LightSpy is a modular malware family that initially targeted iOS devices in Southern Asia before expanding to Android and macOS platforms. It consists of a downloader, a main executable that manages network communications, and functionality-specific modules, typically implemented as `.dylib` files (iOS, macOS) or `.apk` files (Android). LightSpy can collect VoIP call recordings, SMS messages, and credential stores, which are then exfiltrated to a command and control (C2) server.[1]
S0522: Exobot
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 | 02297e5cde1b… |
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]
Android resetPassword
Google. (n.d.). DevicePolicyManager. Retrieved October 1, 2019.
Open source URL -
[2]
Xiao-KeyRaider
Claud Xiao. (2015, August 30). KeyRaider: iOS Malware Steals Over 225,000 Apple Accounts to Create Free App Utopia. Retrieved December 12, 2016.
Open source URL -
[3]
mitre-attack T1642Open 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.