Adversaries may inject malicious code into processes via ptrace (process trace) system calls in order to evade process-based defenses as well as possibly elevate privileges. Ptrace system call injection is a method of executing arbitrary code in the address space of a separate live process.
Ptrace system call injection involves attaching to and modifying a running process. The ptrace system call enables a debugging process to observe and control another process (and each individual thread), including changing memory and register values.[1] Ptrace system call injection is commonly performed by writing arbitrary code into a running process (e.g., by using malloc) then invoking that memory with PTRACE_SETREGS to set the register containing the next instruction to execute. Ptrace system call injection can also be done with PTRACE_POKETEXT/PTRACE_POKEDATA, which copy data to a specific address in the target process's memory (e.g., the current address of the next instruction).[1][2]
Ptrace system call injection may not be possible when targeting processes with high-privileges, and on some systems those that are non-child processes.[3]
Running code in the context of another process may allow access to the process's memory, system/network resources, and possibly elevated privileges. Execution via ptrace system call injection may also evade detection from security products since the execution is masked under a legitimate process.
| ID | Name | Description |
|---|---|---|
| S0463 | INSOMNIA |
INSOMNIA grants itself permissions by injecting its hash into the kernel’s trust cache.[4] |
| S0424 | Triada |
Triada injects code into the Zygote process to effectively include itself in all forked processes. Additionally, code is injected into the Android Play Store App, web browser applications, and the system UI application.[5][6] |
| S0494 | Zen |
Zen can inject code into the Setup Wizard at runtime to extract CAPTCHA images. Zen can inject code into the |
This type of attack technique cannot be easily mitigated with preventive controls since it is based on the abuse of system features.
| ID | Name | Analytic ID | Analytic Description |
|---|---|---|---|
| DET0622 | Detection of Ptrace System Calls | AN1685 |
For Android, detect Ptrace System Calls by correlating analyst-visible device/network evidence and management state; use streaming or batched telemetry only where the documented collector is deployed. Correlate Host Status via Android Enterprise DPC [DevicePolicyManager policy/compliance/security-state queries and SecurityLog events where supported]; Network Traffic Flow via Android Enterprise Network Logging / Enterprise VPN [DevicePolicyManager.retrieveNetworkLogs(): DnsEvent / ConnectEvent; VPN flow metadata]; Process Access via Application Vetting / Instrumented Dynamic Analysis [Dynamic API/runtime trace: process in $TargetProcessList$ shows unexpected behavior change (new network destinations, new permission accesses) within $InjectionWindow$ of root status change — behavioral delta in target process post-injection is the anomaly indicator]. Alert on a sequence or state change inconsistent with the device/app baseline, approved management policy, or expected user workflow; do not infer unobserved API calls, file/process activity, or payload content from management state alone. |
| AN1686 |
For iOS, detect Ptrace System Calls by correlating analyst-visible device/network evidence and management state; use streaming or batched telemetry only where the documented collector is deployed. Correlate Host Status via Apple MDM [DeviceInformation / SecurityInfo / ProfileList / restrictions and compliance queries]; Network Traffic Flow via Apple Network Extension / Enterprise VPN [NEFilterFlow / per-app VPN / secure-web-gateway flow metadata]; Process Access via Application Vetting / Instrumented Dynamic Analysis [Dynamic API/runtime trace: kernel log at level=fault referencing task_for_pid, mach_vm_write, or get-task-allow outside developer build on SUPERVISED device — Apple Unified Log kernel subsystem records these violations at fault level; supervised MDM with Unified Log ]. Alert on a sequence or state change inconsistent with the device/app baseline, approved management policy, or expected user workflow; do not infer unobserved API calls, file/process activity, or payload content from management state alone. |