Mobile T1404 Exploitation for Privilege Escalation is an adversary exploiting a bug in the operating system, kernel or a privileged component to break out of the app sandbox and gain root or kernel control of a phone. MITRE ATT&CK for Mobile v20 lists it under Privilege Escalation for both Android and iOS, with one of the longest procedure lists in the mobile matrix, from commodity rooting trojans to zero-click spyware chains. Once it succeeds, permissions, sandboxing and most app-level controls stop applying. This guide is for mobile security engineers, MDM administrators, SOC analysts and incident responders: what the technique covers, what the recorded cases teach, how to shrink the window with patching and attestation, and what detection is realistic on a platform that hides the kernel from you. For the matrix overview see the MITRE ATT&CK for Mobile Guide.
Key takeaways
- Patch latency is the attack surface. Most Android cases in ATT&CK use known, already fixed vulnerabilities; the defence is getting devices onto current patch levels and retiring those that cannot get there.
- Zero-click chains exist, but are targeted. Operation Triangulation chained an iMessage attachment, a font interpreter flaw and kernel bugs to reach root on iOS up to 16.2.
- Detect the result, not the exploit. Defenders rarely see the exploit itself; they see a failed attestation, a changed boot state or an MTD root or jailbreak signal.
- ATT&CK lists three mitigations. Security Updates (M1001), Attestation (M1002) and Deploy Compromised Device Detection Method (M1010).
- Every secret on the device is exposed after root. Treat tokens, keys and enrolment credentials on an escalated device as compromised and revoke them centrally.
What T1404 covers
ATT&CK describes T1404 as exploiting a programming error in an application, a service, the operating system or the kernel to run adversary-controlled code with higher privileges, moving from a low-privileged process to root. On a phone, every third-party app already runs in a sandbox with a distinct identity, so escalation is the step that turns a malicious app or a browser exploit into full device control. The technique has no sub-techniques. The Enterprise counterpart is the T1068 Exploitation for Privilege Escalation guide.
- Android: targets include the Linux kernel, vendor drivers and SoC firmware, and privileged system services. Fixes arrive through the Android Security Bulletins (platform, upstream kernel and SoC series), which Google publishes monthly, and then through each manufacturer's update.
- iOS: targets include the XNU kernel, WebKit and JavaScriptCore, and message parsing components. Apple publishes fixes in its security releases and does not disclose or confirm security issues until an investigation has occurred and a fix is generally available.
Procedure examples and what they teach
ATT&CK v20 records more than twenty software entries and one campaign for T1404. A representative set, as ATT&CK and its cited sources state them:
| Software or campaign | Platform | Escalation as recorded | Lesson |
|---|---|---|---|
| Operation Triangulation (C0054) | iOS | Kernel vulnerability used to obtain root; Kaspersky documents CVE-2023-32434 (XNU integer overflow) plus CVE-2023-38606 to bypass hardware kernel memory protection | Zero-click delivery, chain designed for iOS up to 16.2; only fast patching and attack surface reduction help |
| INSOMNIA (S0463) | iOS | Exploits a WebKit vulnerability to achieve root | Browser engine bugs are a privilege escalation entry, not only a code execution one |
| Pegasus for iOS (S0289) and Pegasus for Android (S0316) | iOS, Android | Exploits OS vulnerabilities; the Android variant attempts well-known Android vulnerabilities | Commercial spyware uses both zero-days and known bugs; see the Commercial Spyware Guide |
| Exodus (S0405) | Android | Exodus Two attempts to elevate privileges with a modified DirtyCow exploit | Old kernel bugs remain usable on unpatched fleets |
| Gooligan (S0290), HummingBad (S0322), Dvmap (S0420), ShiftyBug (S0294) | Android | Root exploits bundled into apps; ShiftyBug carries at least eight public rooting exploits | Commodity malware roots out-of-date devices at scale |
| Agent Smith (S0440) | Android | Exploits known OS flaws including Janus to replace legitimate apps | Signature scheme bugs let malware swap trusted apps; see the APK Signing guide |
| SpyDealer (S0324) | Android | Used a commercial rooting app to gain root | Legitimate rooting tools are part of the threat; block their installation |
Prevention
| Control | Android | iOS |
|---|---|---|
| M1001 Security Updates | Enforce a maximum security patch level age through the device policy controller; buy models with a published update commitment; retire devices out of support | Enforce a minimum OS version and a deadline for updates through MDM; retire devices that cannot run a supported release |
| M1002 Attestation | Play Integrity MEETS_STRONG_INTEGRITY requires, on Android 13 and higher, a locked bootloader, a certified image and security updates within the last year for all partitions | Managed Device Attestation through MDM, and App Attest in your own apps; see the Mobile App Attestation guide |
| M1010 Compromised Device Detection | MTD agent root detection, Play Protect status | MTD agent jailbreak detection |
| Attack surface reduction | Advanced Protection mode; block unknown sources; managed Google Play only | Lockdown Mode (iOS 16 and later) blocks most message attachment types and some complex web technologies, the paths zero-click chains use |
The Play Integrity device verdict is especially useful because a blank verdict means the device shows signs of attack, such as API hooking, or system compromise, such as being rooted. See the Apple Lockdown Mode Guide and the Android Advanced Protection guide for configuration detail.
Detection: what is realistic
ATT&CK v20 detection guidance correlates permissions, host status from MDM and network flow data, and warns against inferring API calls or file activity that management data cannot show. For iOS it adds a vetting and dynamic analysis signal: a fault-level unified log entry in the com.apple.kernel or com.apple.sandbox subsystem close in time to an integrity check failure, which needs elevated access and is a lab or forensic signal rather than a fleet one.
- Attestation drop: a device that passed MEETS_DEVICE_INTEGRITY and now returns a blank device verdict, or an iOS device that fails managed device attestation, is the strongest fleet signal.
- Android boot state: the enterprise SecurityLog TAG_OS_STARTUP event records Verified Boot state and dm-verity mode at each start; an escalated attacker who modifies partitions usually changes it.
- MTD verdicts: root and jailbreak detections, known exploit app hashes and connections to exploit infrastructure.
- Patch exposure: devices behind the current Android patch level (each bulletin defines two patch levels, ending -01 and -05) or behind the current iOS release are the population exploits reach.
- Forensics: for suspected targeted spyware, use the Mobile Verification Toolkit on iOS backups, filesystem dumps and sysdiagnose archives, or on Android backups, with consent, following the Mobile Spyware Infection Response Playbook.
How to implement
- Measure patch exposure: report every managed device by OS version and patch level, and by model support status.
- Set targets: for example, current iOS minor release within 14 days and Android patch level no older than 60 days, with shorter deadlines when a release fixes exploited flaws.
- Pilot: enforce in report-only mode first, then on IT staff, then high-risk roles, then all users. Rollback is returning the rule to report-only; keep a short, owned exception list.
- Bind access to posture: make corporate apps and identity providers require a compliant, attested device, so a failed attestation removes access at the next token refresh.
- Harden high-risk users: enable Lockdown Mode or Advanced Protection for executives, journalists, administrators and others likely to be targeted.
- Respond: on a confirmed escalation, isolate the device, preserve evidence before any reset, revoke credentials, and restore or replace the device.
Decision guidance
- MDM compliance or MTD: MDM gives OS and patch state and is enough for most organisations; MTD adds root or jailbreak and exploit infrastructure detection and is worth it for high-risk roles or BYOD access to sensitive data.
- Company-owned or BYOD: on company-owned Android devices you can collect security logs; on BYOD rely on attestation inside your own apps and on conditional access.
- Small organisations: patch enforcement and attestation-based access cover most risk. Large organisations should add MTD, log collection and a forensic route.
Where identity fits
Root or kernel access defeats app sandboxing, so OAuth refresh tokens, API keys embedded in apps, MDM enrolment certificates and VPN credentials on the device are all readable. Prefer hardware-backed, non-exportable keys, short-lived tokens, and device-bound sessions, and revoke all of them when a device is confirmed escalated. See the Mobile Access Credentials guide.
Detection and measurement
- Share of devices on the current iOS release or within the Android patch level target.
- Median days from an OS security release to 90 percent fleet adoption.
- Devices out of vendor support still enrolled (target zero).
- Attestation pass rate per platform, and number of attestation drops investigated.
- Time from attestation failure to blocked access.
Framework mapping
| Framework | Reference | Relevance to T1404 |
|---|---|---|
| MITRE ATT&CK Mobile | M1001, M1002, M1010 | Listed mitigations |
| NIST SP 800-53 Rev 5 | SI-2 Flaw Remediation; RA-5 Vulnerability Monitoring and Scanning | Patching and exposure tracking |
| NIST SP 800-53 Rev 5 | SI-7 Software, Firmware, and Information Integrity; SC-39 Process Isolation | Integrity checks and sandboxing |
| NIST CSF 2.0 | ID.RA-01, PR.PS-02, DE.CM-09 | Find, fix and monitor |
| ISO/IEC 27001:2022 Annex A | A.8.8 Management of technical vulnerabilities; A.8.1 User endpoint devices | Vulnerability and device management |
| OWASP MASVS | MASVS-RESILIENCE | App checks on platform integrity |
Common failure patterns
- Counting OS version, not patch level: two Android devices on the same major version can be years apart in fixes.
- Keeping out-of-support devices: they will never receive the fix the commodity rooting kits target.
- Resetting before preserving evidence: a reset destroys what forensic tools need.
- Trusting client-side root checks alone: a rooted device can hide from in-app checks; verify server-side with attestation.
- Forgetting the credentials: rebuilding the phone but leaving its tokens and certificates valid.
Practitioner checklist
- Publish patch level and OS version targets per platform and enforce them in MDM.
- Retire devices out of vendor support.
- Gate access to corporate data on attestation.
- Deploy MTD for high-risk roles and BYOD with sensitive access.
- Enable Lockdown Mode or Advanced Protection for targeted users.
- Collect Android security logs on company-owned devices.
- Preserve evidence, then revoke tokens and certificates, before rebuilding a suspect device.
Standards and references
- MITRE ATT&CK: Exploitation for Privilege Escalation (Mobile T1404)
- Android Open Source Project: Android Security Bulletins overview
- Apple: Apple security releases
- Android Developers: Play Integrity API integrity verdicts
- Android Developers: SecurityLog
- Apple: About Lockdown Mode
- OWASP: Mobile Application Security Verification Standard
- Kaspersky Securelist: Operation Triangulation, the last hardware mystery
Related NHI Mgmt Group resources: MITRE ATT&CK for Mobile Guide · Mobile Device Security Guide · iOS and iPadOS Enterprise Security Guide · Android Enterprise Security Guide · Mobile Malware Guide