M1010: Deploy Compromised Device Detection Method
A variety of methods exist that can be used to enable enterprises to identify compromised (e.g. rooted/jailbroken) devices, whether using security mechanisms built directly into the device, third-party mobile security applications, enterprise mobility management (EMM)/mobile device management (MDM) capabilities, or other methods. Some methods may be trivial to evade while others may be more sophisticated.
Security context for executives and security teams
This mitigation is about being able to tell when a mobile device may be rooted, jailbroken, or otherwise compromised before that device becomes a trusted path into business systems. Its value is not just “mobile security”; it helps determine whether mobile access, credentials, VPN profiles, certificates, and enterprise apps should still be trusted when the underlying device integrity is questionable.
Executive priority
Prioritize this where mobile devices have access to sensitive applications, credentials, VPNs, certificates, or regulated data. Leaders should ask whether the organization can identify and respond to compromised Android or iOS devices, whether those signals affect access decisions, and whether evidence is available for incident response and compliance reviews. Because MITRE notes that some methods may be trivial to evade, budget and governance decisions should focus on layered device-integrity validation rather than relying on a single jailbreak/root check.
Technical view
ATT&CK lists this as a mobile mitigation that can use built-in device mechanisms, third-party mobile security applications, EMM/MDM capabilities, or other methods to identify compromised devices. It mitigates mobile techniques involving privilege escalation, hooking, command and shell execution, defense impairment, user evasion, and credential access from iOS password stores/keychain. SOC, mobile security, and IR teams should validate whether compromised-device signals are collected, how reliable they are, whether they are correlated with access to enterprise resources, and how alerts are handled when adversary behavior may attempt to hide artifacts or modify security tools.
Likely telemetry
- EMM/MDM device compliance and posture records
- Rooted or jailbroken device indicators from mobile security tooling or built-in device mechanisms
- Mobile security application health and tamper status
- Device operating system, security posture, and enrollment state
- Enterprise app access logs tied to device identity and compliance state
Detection direction
- Validate that compromised-device detection is actually enabled and centrally visible, not only configured locally on the device.
- Test whether root/jailbreak, hooking frameworks, shell access, and security-tool impairment create actionable posture changes or alerts in EMM/MDM or mobile security tooling.
- Tune response workflows so device-integrity failures are correlated with sensitive access, credential use, VPN/certificate use, and high-risk enterprise applications.
- Account for evasion: MITRE explicitly notes that some detection methods may be trivial to evade, and related techniques include hooking and disabling or modifying tools.
- Define false-positive handling for legitimate developer, test, or administrator devices so SOC teams can distinguish approved exceptions from unmanaged risk.
Mitigation priorities
- Establish a mobile device integrity baseline for managed devices before allowing access to sensitive enterprise resources.
- Use layered compromised-device detection methods where possible, combining built-in mechanisms, EMM/MDM posture, and mobile security application signals.
- Tie compromised-device findings to access policy, incident triage, and device remediation workflows rather than treating them as informational-only alerts.
- Monitor for tampering with mobile security tools and posture reporting, especially on Android where related ATT&CK techniques include hooking and disabling or modifying tools.
- Review credential exposure risk for iOS devices because this mitigation is related to techniques involving password stores and keychain access.
Additional notes and limits
The most important decision point is whether mobile device trust is enforced or merely observed. This mitigation is especially relevant where mobile devices hold business credentials, certificates, VPN configurations, or access to sensitive apps. Relationship context shows coverage relevance to Android and iOS techniques, but the mitigation object itself does not specify platforms or tactics.
MITRE provides no official detection text for this mitigation, and the mitigation description does not prescribe a specific technology or validation method. Effectiveness depends on the local mobile fleet, EMM/MDM configuration, mobile security tooling, access policies, and the ability to resist or detect evasion. This summary does not assert active exploitation, attribution, or guaranteed detection coverage.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Deploy Compromised Device Detection Method
A variety of methods exist that can be used to enable enterprises to identify compromised (e.g. rooted/jailbroken) devices, whether using security mechanisms built directly into the device, third-party mobile security applications, enterprise mobility management (EMM)/mobile device management (MDM) capabilities, or other methods. Some methods may be trivial to evade while others may be more sophisticated.
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.
Techniques used
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.003 | Disable or Modify ToolsSub-technique | Mobile security software can typically detect if a device has been rooted or jailbroken and can inform the user, who can then take appropriate action. |
| Mobile | T1628.002 | User EvasionSub-technique | Mobile security products that are part of the Samsung Knox for Mobile Threat Defense program could examine running applications while the device is idle, potentially detecting malicious applications that are running primarily when the device is not being used. |
| Mobile | T1623 | Command and Scripting Interpreter | Mobile security products can typically detect jailbroken or rooted devices. |
| Mobile | T1634.001 | KeychainSub-technique | Mobile security products can take appropriate action when jailbroken devices are detected, potentially limiting the adversary’s access to password stores. |
| Mobile | T1629 | Impair Defenses | Mobile security software can typically detect if a device has been rooted or jailbroken and can inform the user, who can then take appropriate action. |
| Mobile | T1634 | Credentials from Password Store | Mobile security products can take appropriate action when jailbroken devices are detected, potentially limiting the adversary’s access to password stores. |
| Mobile | T1617 | Hooking | Mobile security products can often detect rooted devices. |
| Mobile | T1404 | Exploitation for Privilege Escalation | Mobile security products can potentially detect jailbroken or rooted devices. |
| Mobile | T1623.001 | Unix ShellSub-technique | Mobile security products can typically detect jailbroken or rooted devices. |
All related ATT&CK context
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.0 | Current bundle | f27053ce0363… |
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-attackM1010Open source URL
- [2]mitre-attackM1010Open 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.