Mobile ATT&CK Privilege Escalation Tactic: Detecting Root and Kernel Exploits on Android and iOS

Mobile malware usually lands as an ordinary app or inside a sandboxed process, and the Privilege Escalation tactic (TA0029) in MITRE ATT&CK for Mobile is how it breaks out of that box. ATT&CK v20 defines the tactic as the adversary "trying to gain higher-level permissions" and notes that attackers may enter a device with very limited privileges and need a device weakness to get further. This hub explains the three current Mobile techniques under TA0029, how they chain with the rest of an intrusion, which signals defenders can actually see on Android and iOS, and which controls change the outcome. It is written for mobile security engineers, MDM and mobile threat defence (MTD) administrators, and incident responders. Each technique has its own deep page, linked from the table below; this page is the overview and the priority list.

Key takeaways

• The tactic is small but decisive. ATT&CK v20 lists three techniques under TA0029: T1404 Exploitation for Privilege Escalation, T1626 Abuse Elevation Control Mechanism (with T1626.001 Device Administrator Permissions) and T1631 Process Injection (with T1631.001 Ptrace System Calls).
• Exploitation dominates the procedure data. In the v20 dataset T1404 has 18 linked software entries and the Operation Triangulation campaign; T1626.001 has 9; T1631 and T1631.001 have 5 between them.
• Patch level is the primary control. MITRE maps M1001 Security Updates, M1002 Attestation and M1010 Deploy Compromised Device Detection Method to T1404, so OS currency plus integrity attestation is the core of the defence.
• Android device admin abuse is a policy problem. Banking trojans such as Asacub, Exobot and XLoader use the legacy device administration API to resist removal; work profile and fully managed enrolment with a curated app catalogue take that path away.
• Visibility is indirect. Neither Android nor iOS gives defenders a process-level event stream, so detection relies on MDM compliance state, attestation verdicts, MTD findings and forensic checks such as MVT.

What the tactic means on a phone

On a desktop, privilege escalation usually means moving from a standard user to an administrator or SYSTEM. On Android and iOS the boundaries are different. Every app runs in its own sandbox (a separate Linux user ID and SELinux domain on Android, a container with entitlements on iOS), the kernel is hardened, and the boot chain is verified. Gaining "higher-level permissions" therefore means one of three things:

• Root or kernel code execution: exploiting a flaw in the kernel, a driver or a privileged system service to escape the sandbox entirely (T1404). This is what full-chain spyware and older rooting malware do.
• A privileged OS role granted by the user: tricking the user into approving an elevated role, most often an Android device administrator (T1626.001), which lets the app lock the screen, wipe data or resist uninstallation.
• Running inside another process: injecting code into a more privileged or more trusted process (T1631). ATT&CK states that neither Android nor iOS has a legitimate way to do this, so it depends on existing root access or a vulnerability.

ATT&CK for Mobile also keeps accessibility abuse (T1453) and permission prompts under other tactics, so a page on "mobile privilege escalation" in everyday language would range wider than TA0029. For the matrix as a whole, see the MITRE ATT&CK for Mobile Guide.

Every technique in the tactic

The table lists every current (not revoked or deprecated) technique and sub-technique carrying the privilege-escalation phase in the ATT&CK for Mobile v20 dataset. Counts are the number of distinct software (malware or tool) and campaign or group objects with a "uses" relationship to that technique in the dataset; mitigations are the "mitigates" relationships.

Mitigation names in v20: M1001 Security Updates, M1002 Attestation, M1006 Use Recent OS Version, M1010 Deploy Compromised Device Detection Method, M1011 User Guidance, M1013 Application Developer Guidance. Process Injection has no mitigation mapped in v20 because it relies on root or an exploit already obtained, so the controls that stop T1404 are the ones that matter for it too.

Where to start: ranked for defenders

1. T1404 Exploitation for Privilege Escalation. The widest procedure base (Pegasus for Android and iOS, Gooligan, HummingBad, Skygofree, Exodus, LightSpy, FinFisher and others in v20) and the highest impact: a successful kernel exploit defeats the sandbox and most app-level controls. Every defence here is about reducing exposure time to known vulnerabilities and detecting a device that is no longer in a trustworthy state.
2. T1626.001 Device Administrator Permissions. No exploit is needed, only a convincing prompt. v20 links it to banking and spyware families including Asacub, Exobot, Red Alert 2.0, XLoader for Android, Crocodilus, Hornbill and Sunbird. It is common in consumer-targeted fraud and in bring-your-own-device fleets where users install apps freely.
3. T1631 Process Injection and T1631.001 Ptrace. Seen in Triada, Zen, INSOMNIA, FjordPhantom and LightSpy. Because it needs root or an exploit first, treat it as a consequence of T1404 or of a rooted device rather than a separate front door.

How it chains with other tactics

Method: for each software object in ATT&CK for Mobile v20 that uses at least one technique carrying the privilege-escalation phase (28 of the 128 current software entries with technique relationships), we counted the other tactics its techniques fall under. Discovery appears for 22 of the 28, Defense Evasion for 21, Collection for 21, Command and Control for 18, and Impact and Persistence for 12 each. In practice, privilege escalation sits in the middle of the chain: the malware arrives, escalates, then hides, collects and phones home.

Kaspersky's analysis of Operation Triangulation describes the escalation stage concretely: after remote code execution through a TrueType font flaw (CVE-2023-41990) in an iMessage attachment, the chain used an XNU integer overflow (CVE-2023-32434) and a hardware MMIO flaw that bypassed the Page Protection Layer (CVE-2023-38606) to gain root before installing the spyware. Apple mitigated the hardware issue in iOS 16.6. That is T1404 in its purest form, and it shows why patch timing matters more than any on-device scanner. See the Zero-Click Exploits Guide.

Detection priorities

ATT&CK v20 attaches a detection strategy to each technique: DET0665 for T1404, DET0642 for T1626, DET0630 for T1626.001, DET0632 for T1631 and DET0622 for T1631.001. Their analytics (for example AN1758 and AN1759 for T1404 on Android and iOS) all work the same way: correlate management state from Android Enterprise or Apple MDM, application vetting results and network evidence, and treat state queries as periodic observations rather than real-time events. That is honest about the platforms: you will not get a kernel exploit alert, you will see a device whose state has changed.

For forensic triage of a suspected high-end compromise, use the Mobile Verification Toolkit (MVT), which Amnesty International's Security Lab describes as a tool for consensual forensic analysis of Android and iOS devices. For how attestation results should feed access decisions, see Mobile App Attestation.

Metrics that show coverage

• Patch latency: median days from an Android security bulletin or Apple security release to 90 percent of managed devices on the fixed level.
• Unsupported devices: count of devices that no longer receive security updates, trending to zero.
• Integrity failure rate: share of sessions or devices failing device integrity, with every failure triaged.
• Unapproved device admins: number of Android devices with a non-allowlisted device administrator, target zero.
• Time to quarantine: minutes from a compromised-device finding to conditional access blocking corporate resources.

Prevention and hardening

Android

• Enrol in work profile or fully managed mode: Google's device admin deprecation notice explains that legacy device admin policies such as USES_POLICY_DISABLE_CAMERA and USES_POLICY_LIMIT_PASSWORD were deprecated in Android 9 and throw a SecurityException for apps targeting API 29 on Android 10. Personal devices should use a work profile and company devices fully managed (device owner) mode through an EMM. That leaves no legitimate reason for a third-party app to be a device administrator.
• Close the sideloading path: restrict installation from unknown sources through the EMM so malicious APKs cannot arrive outside the managed store. See APK sideloading.
• Gate on integrity: require MEETS_DEVICE_INTEGRITY (and MEETS_STRONG_INTEGRITY for high-risk apps) before releasing sensitive data or tokens.
• Set a minimum patch level: compliance rules that block access when the security patch level is older than an agreed window (for example 60 or 90 days) and retire models out of support.

iOS and iPadOS

• Enforce OS currency: Apple says it does not disclose or confirm security issues until patches are generally available, so the release itself is the signal to act. Use MDM-managed software update deadlines and track Background Security Improvements where Apple publishes them.
• Lockdown Mode for high-risk users: Apple describes it as an optional, extreme protection for people who may be personally targeted. It blocks most message attachment types and complex web technologies, and it prevents new configuration profiles and MDM enrolment while on, so enrol the device before the user turns it on. It needs iOS 16 or later.
• Supervise corporate devices: supervision unlocks restrictions that reduce exposure, and MDM queries give the OS build and security state that compliance depends on.

Rollout order

1. Inventory: pull OS version, patch level and enrolment mode for every device that touches corporate data.
2. Report-only compliance: apply patch-level and integrity rules in monitor mode for two to four weeks and measure how many devices would fail.
3. Pilot enforcement with IT and security staff, then a business pilot ring; keep a documented exception path with an expiry date.
4. Enforce fleet-wide through conditional access; roll back by switching the rule to report-only, not by deleting it.
5. Offer Lockdown Mode and a forensic check route to executives, journalists and other high-risk users.

Decision guidance

• Small organisation, mostly BYOD: rely on app protection policies, a minimum OS version for access, and integrity checks in your own apps. A full MTD product may be more than you need; a strict patch rule removes most T1404 exposure.
• Large or regulated organisation: add an MTD agent for root, jailbreak and malicious app detection, feed its risk level into conditional access, and keep a forensic route (MVT or a specialist provider) for suspected spyware. See the Mobile Threat Defense Buyer's Guide.
• App owners: M1013 Application Developer Guidance is the only mapping for T1626; do not request device administrator rights, and check integrity server side rather than in the client alone.

Where identity fits

An escalated app can read what the sandbox used to protect: OAuth refresh tokens, session cookies, API keys embedded in apps and certificates used for Wi-Fi or VPN. Treat a device that fails integrity as a compromised credential store: revoke its tokens and device certificates, not just the user's password. Bind tokens to hardware-backed keys where the platform supports it, and keep secrets out of app binaries. See the Mobile Device Security Guide for the wider device baseline.

Common failure patterns

• Allowing access from out-of-support devices: a phone that no longer receives security updates is permanently exposed to public T1404 exploits.
• Trusting client-side root checks: rooting and hooking tools hide from in-app checks; verify attestation tokens on the server.
• Ignoring device admin prompts in BYOD: without an approved list, a banking trojan holding device admin looks like any other app.
• No response path for integrity failures: a failed verdict that only generates a dashboard entry does not revoke the tokens already on the device.
• Treating a factory reset as complete recovery: some rooting malware wrote to the system partition; reflash or replace, and check firmware integrity.

Framework mapping

Practitioner checklist

• Inventory every managed device's OS build and security patch level weekly.
• Set and enforce a maximum patch age, and block out-of-support models.
• Require device integrity attestation for apps that hold sensitive data, verified server side.
• Move Android fleets off legacy device admin to work profile or fully managed enrolment.
• Alert on any non-allowlisted Android device administrator.
• Restrict sideloading on managed Android devices.
• Offer Lockdown Mode and a consensual MVT check to high-risk users.
• Revoke tokens and certificates automatically when a device turns non-compliant.

Standards and references

• MITRE ATT&CK: Privilege Escalation, Mobile (TA0029)
• NIST: SP 800-124 Rev. 2, Guidelines for Managing the Security of Mobile Devices in the Enterprise
• Android Developers: Play Integrity API integrity verdicts
• Google: Device admin deprecation
• Apple: About Lockdown Mode
• Apple: Apple security releases
• Kaspersky Securelist: Operation Triangulation, the last (hardware) mystery
• Amnesty International Security Lab: Mobile Verification Toolkit documentation

Related NHI Mgmt Group resources: MITRE ATT&CK for Mobile Guide, Mobile ATT&CK Execution Tactic, Mobile ATT&CK Command and Control Tactic, Spyware and Stalkerware Guide, Mobile Forensics Guide.