When mobile malware runs its code inside another process, such as Android's Zygote or the iOS SpringBoard, it inherits that process's access and hides behind a trusted name. MITRE ATT&CK for Mobile tracks this as T1631 Process Injection, under both Defense Evasion (TA0030) and Privilege Escalation, with one sub-technique, T1631.001 Ptrace System Calls. ATT&CK lists both the technique and the sub-technique for Android and iOS, and states that neither platform offers a legitimate way to achieve process injection: it requires existing root access or a vulnerability. That makes T1631 a marker of a deeply compromised device rather than an ordinary app problem. This guide covers the cases ATT&CK documents, the platform protections on both operating systems, detection through integrity and attestation signals, and response. It is for mobile security engineers and incident responders and complements the MITRE ATT&CK for Mobile Guide.
Key takeaways
- Injection implies compromise of the platform. ATT&CK states Android and iOS have no legitimate injection path, so evidence of T1631 means root, a jailbreak or a working exploit.
- Both platforms are in scope. ATT&CK lists Android and iOS for T1631 and T1631.001, with cases on each: Triada and Zen on Android, LightSpy and INSOMNIA on iOS.
- Prevention is mostly the operating system. SELinux, Verified Boot and patching on Android; sandboxing, signed entitlements, ASLR and Execute Never on iOS. Your job is keeping devices current and proving it.
- Detection is indirect. You will rarely see the injection itself; you will see failed integrity verdicts, unexpected device state in MDM and odd network traffic.
- Response means rebuild. A device where code ran inside system processes cannot be cleaned with confidence: preserve evidence, then reflash or replace.
What T1631 covers
ATT&CK describes process injection as executing arbitrary code in the address space of a separate live process, which can give access to that process's memory, system and network resources and possibly elevated privileges, and can evade security products because execution is masked under a legitimate process. The technique mirrors Enterprise T1055 Process Injection; see the T1055 Process Injection Defensive Guide for the desktop view.
T1631.001 Ptrace System Calls covers injection through the ptrace debugging interface, which lets one process observe and control another, including its memory and registers. ATT&CK notes ptrace injection may not be possible against high-privilege processes and, on some systems, against processes that are not children of the injecting process. This guide does not describe the mechanics further; defenders need to know that ptrace attachment to system processes outside a debugging context is never normal on a production device.
Cases ATT&CK documents
| Case | Platform | What ATT&CK records | Mapped to |
|---|---|---|---|
| Triada | Android | Injects code into the Zygote process so it is included in all forked processes, and into the Play Store app, web browser and other apps | T1631.001 |
| Zen | Android | Injects code into the Setup Wizard at runtime to extract CAPTCHA images, and into libc of running processes | T1631.001 |
| FjordPhantom | Android | Injected malicious code and a hooking framework through a virtualization solution (see T1670 Virtualization Solution) | T1631 |
| LightSpy | iOS | Injects a dynamic library into the SpringBoard process to enable audio and video recording | T1631 |
| INSOMNIA | iOS | Grants itself permissions by injecting its hash into the kernel's trust cache | T1631.001 |
The Android cases show the value of the target: Zygote is the parent of app processes, so code placed there reaches every app started afterwards. The iOS cases show the same logic: SpringBoard is the home screen process with broad access, and the trust cache decides which binaries the kernel treats as trusted.
Platform protections on Android and iOS
ATT&CK v20 maps no mobile mitigations directly to T1631. The protections below are the platform controls that make injection require root or an exploit in the first place, taken from Android and Apple documentation.
| Protection | Android | iOS |
|---|---|---|
| Process isolation | SELinux mandatory access control over all processes, including root; Android ships in enforcing mode, with all domains enforced since Android 5.0 | All third-party apps are sandboxed, run as the non-privileged mobile user and can reach outside their sandbox only through system services |
| Code integrity at boot | Verified Boot chain of trust from hardware through bootloader, boot and system partitions, with rollback protection | Secure boot chain; signed system volume (see Apple Platform Security) |
| Memory protections | Exploit mitigations and fixes delivered through Android security updates | ASLR for apps and system libraries; Execute Never marks pages non-executable, and writable plus executable memory needs an Apple-only entitlement |
| Privilege limits | SELinux confines even root processes; Play Integrity on Android 13 and later gives hardware-backed proof of a locked bootloader and certified OS | Signed entitlements that cannot be changed; APIs do not let apps escalate privileges to modify other apps or the OS |
| Integrity attestation | Play Integrity API device verdicts, hardware-backed on Android 13 and later | App Attest (DeviceCheck framework); see the Mobile App Attestation guide |
| Extreme hardening for targeted users | Keep to certified devices with current patches | Lockdown Mode (iOS 16 and later) reduces attack surface in Messages, web browsing, FaceTime and connections |
Detection and measurement
ATT&CK v20 detection strategies for T1631 and T1631.001 correlate, on Android, device owner policy and compliance queries and security log events with network logs and dynamic analysis; on iOS, Apple MDM device information, security info and profile lists with Network Extension or enterprise VPN flow metadata and instrumented analysis. In practice the useful signals are these.
| Signal | Source | Why it matters |
|---|---|---|
Device loses MEETS_DEVICE_INTEGRITY | Server-side Play Integrity results | Unlocked bootloader or modified OS, the precondition for Android injection |
| Unexpected MDM security state | Apple MDM SecurityInfo and DeviceInformation queries; Android DPC compliance queries | Changes to passcode, encryption or management state that should not happen |
| SELinux reported permissive | MTD agent or forensic acquisition | Android shipped enforcing, so permissive indicates tampering |
| Traffic from system processes to unknown hosts | Android Enterprise network logging; per-app VPN; Apple Network Extension flow data | Injected code in a system process still has to talk to its operator |
| Known spyware indicators | MVT analysis of iOS backups, sysdiagnose and Android data | Matches against published indicators for families such as those above |
Metrics:
- Percentage of devices passing a server-verified integrity check in the last 24 hours.
- Percentage of devices on the latest major OS and a security patch under 90 days old, per platform.
- Number of integrity failures investigated, and median time to quarantine.
- Percentage of high-risk users with Lockdown Mode enabled where it fits their work.
- Percentage of managed apps that request and enforce attestation verdicts for sensitive actions.
Implementing the controls
- Set patch and OS floors per platform. Use MDM compliance rules to quarantine Android and iOS devices below your minimum version or patch level; equal policy depth on both platforms.
- Block compromised devices from corporate data. Feed integrity and MTD results into conditional access so devices failing attestation lose access to email, files and SSO until rebuilt.
- Add attestation to your own apps. Call Play Integrity on Android and App Attest on iOS for logins and high-value transactions, and decide on the server.
- Offer Lockdown Mode to targeted iOS users. Pilot with a few users first: Apple notes it blocks MDM enrolment and configuration profile installation, so agree how those devices will be managed.
- Test and roll back: start integrity enforcement in report-only mode, review false positives (custom ROMs, test devices) for two weeks, then enforce; keep a break-glass exception list with expiry dates.
Responding to suspected injection
- Isolate: revoke corporate access and remove the device from networks carrying sensitive data.
- Preserve: acquire an iOS backup and sysdiagnose, or an Android acquisition, before any reset; record MDM state and network logs for the period.
- Rebuild, do not clean: reflash or replace the device; code that ran inside Zygote, SpringBoard or the kernel trust cache cannot be removed with confidence by uninstalling an app.
- Rotate everything the device held: passwords, MFA enrolments, session tokens and keys. See the Mobile Spyware Infection Response Playbook.
Where identity fits
Code injected into a browser, the Play Store app or SpringBoard can read what those processes hold, including session cookies, OAuth tokens and API keys stored by apps on the device. Mobile backends should treat tokens from a device that fails attestation as untrusted, keep token lifetimes short and bind refresh tokens to the device where possible. See the Mobile Access Credentials guide.
Framework mapping
| Framework | Reference | Relevance to T1631 |
|---|---|---|
| ATT&CK for Mobile | TA0030 Defense Evasion; Privilege Escalation; related T1404 Exploitation for Privilege Escalation and T1670 Virtualization Solution | Injection depends on an exploit or root, and FjordPhantom links it to virtualization |
| NIST SP 800-53 Rev. 5 | SI-16 Memory Protection; SI-7 Software, Firmware, and Information Integrity; SI-2 Flaw Remediation; SI-4 System Monitoring | Memory and integrity protections, patching, monitoring |
| NIST CSF 2.0 | PR.PS-02; DE.CM-09 | Keep software maintained; monitor runtime environments |
| OWASP MASVS | MASVS-RESILIENCE | App-level defences against a hostile runtime |
Common failure patterns
- Treating it as an app issue: uninstalling the visible malicious app and returning a device whose system processes were modified.
- Platform imbalance: strong Android integrity checks but no iOS equivalent, or the reverse, although ATT&CK lists cases on both.
- Client-only integrity checks: apps that check their own environment locally, which injected code can tamper with, instead of verifying attestation on the server.
- Exceptions that never expire: developer or test devices exempted from integrity enforcement and later used for production access.
- Slow patching of high-risk users: the people most likely to face exploit chains wait longest for OS updates.
Practitioner checklist
- Set minimum OS and patch levels for Android and iOS and quarantine devices below them.
- Connect MTD and attestation results to conditional access.
- Verify Play Integrity and App Attest results on the server for sensitive actions.
- Alert on integrity loss and on SELinux not enforcing.
- Offer Lockdown Mode to targeted iOS users with a management plan.
- Rebuild, never clean, devices with suspected injection, after preserving evidence.
- Rotate all credentials and tokens held on an affected device.
Standards and references
- MITRE ATT&CK: Process Injection (Mobile T1631)
- MITRE ATT&CK: Ptrace System Calls (T1631.001)
- Android Open Source Project: Security-Enhanced Linux in Android
- Android Open Source Project: Verified Boot
- Apple Platform Security: Security of runtime process in iOS and iPadOS
- Android Developers: Play Integrity API integrity verdicts
- Apple: About Lockdown Mode
- MVT Project: Mobile Verification Toolkit documentation
Related NHI Mgmt Group resources: MITRE ATT&CK for Mobile Guide · Mobile Device Security Guide · Mobile App Attestation · Mobile Forensics Guide