Ptrace system call injection is MITRE ATT&CK T1055.008. It targets Linux and is listed under the Stealth and Privilege Escalation tactics. It is a sub-technique of Process Injection: running arbitrary code in the address space of a separate live process so that the activity hides behind something legitimate.
How attackers use it
The ptrace system call exists so a debugging process can observe and control another process and each of its threads, including changing memory and register values. That is exactly what an injector needs.
MITRE describes two common patterns. In the first, arbitrary code is written into a running process, for example into memory obtained through malloc, and then invoked by using PTRACE_SETREGS to set the register holding the next instruction to execute. In the second, PTRACE_POKETEXT or PTRACE_POKEDATA copy data to a chosen address in the target's memory, such as the address of the next instruction.
There is a limit worth knowing. MITRE notes that ptrace injection may not work against processes that are not children of the injector, or that run with higher privileges. That limit is the basis of the main mitigation below.
When it works, the injected code can reach the target's memory and its system and network resources, and possibly higher privileges. When it fails because of memory protections, adversaries may turn to related approaches such as VDSO hijacking.
How to detect it
The record lists no data sources, but MITRE's detection strategy is specific. It correlates audit logs of ptrace system calls, memory modifications such as poketext and pokedata, and suspicious register manipulation on a target process that the originator does not normally debug. It alerts on processes that attempt to ptrace non-child or privileged processes, especially when abnormal memory or execution behavior follows.
So the signals are:
- A ptrace call from a process that is not a debugger or a known tool.
- A ptrace attach to a process that is not the caller's child.
- A ptrace attach to a higher-privileged process.
- Memory or register changes in the target afterward.
On hosts running auditd, ptrace syscalls can be audited, which gives you the raw events to correlate. Developer workstations and servers will look different here. Debuggers and tracing tools are normal on the first and rare on the second, so the same event deserves different weight.
How to reduce the risk
MITRE lists two mitigations.
Restrict ptrace with Yama. The setting at /proc/sys/kernel/yama/ptrace_scope can restrict ptrace to privileged users. MITRE also points to security kernel modules that add access control and process restrictions, naming SELinux, grsecurity and AppArmor.
Behavior Prevention on Endpoint. Some endpoint security tools can block certain types of process injection based on the common behavior sequences involved. Confirm yours covers Linux workloads, including servers and container hosts.
In plain steps:
- Read the current ptrace_scope value on each host class and pick a stricter value where nothing needs to debug live processes.
- Keep SELinux or AppArmor enforcing rather than permissive.
- Remove debuggers and tracing tools from production images where you can.
- Turn on blocking in your endpoint tool.
Check your own environment
These are read-only checks on Linux.
Show the current Yama ptrace setting:
cat /proc/sys/kernel/yama/ptrace_scope
If the file does not exist, Yama is not active on that kernel, which is worth noting in itself.
List the loaded auditd rules to see whether ptrace is audited (needs root):
sudo auditctl -l
Search existing audit events for ptrace syscalls (needs root and auditd):
sudo ausearch -sc ptrace
Check whether SELinux is enforcing, where it is installed:
getenforce
Then ask two questions of the results. Which hosts have a permissive ptrace_scope, and why? Which ptrace events came from tools you do not recognize?
Quick check
What does MITRE say may limit ptrace injection?
It may not be possible against processes that are not child processes of the injector, or that have higher privileges.
Which kernel setting does MITRE name for restricting ptrace?
Yama, through /proc/sys/kernel/yama/ptrace_scope, which can limit ptrace to privileged users.
