Detecting and Mitigating Proc Memory Injection on Linux (T1055.009)

Proc memory injection is MITRE ATT&CK T1055.009. It applies to Linux and falls under Stealth and Privilege Escalation. Like the rest of the Process Injection family, it executes code inside a separate live process to evade process-based defenses.

How attackers use it

Every running process has a directory under /proc/[pid], and it includes the process's memory mappings. MITRE explains that an adversary can enumerate a process's memory through this filesystem, then build a return-oriented programming (ROP) payload from gadgets, which are existing instructions in the program that can be chained together.

The mappings matter because they expose offsets, including the stack, and gadgets that address space layout randomization (ASLR) would otherwise keep hidden. Once enumerated, the target's memory can be overwritten, and MITRE names dd as a tool that can do the writing through /proc/[pid]/maps. The usual target is the stack.

Two more details from the page. Other techniques such as Dynamic Linker Hijacking may be used to populate the target with more gadgets. And, as with process hollowing, the target may be a child process such as a backgrounded copy of sleep.

The benefits to the adversary are those of any injection: the code runs under a legitimate process, with access to its memory and resources and possibly its privileges.

MITRE also lists one campaign example in which final payload installation involved mounting and binding to the /proc/ filepath on the victim system, so the operation continued in memory while on-disk artifacts were removed. The takeaway for defenders is that /proc activity is worth watching on hosts where nothing should be touching it.

How to detect it

MITRE's detection strategy looks for a process that enumerates and modifies another process's memory using /proc/[pid]/maps and /proc/[pid]/mem. That includes spotting gadget discovery through memory mappings and overwriting memory with low-level file modification or dd.

Signals to look for:

• A process reading /proc/[pid]/maps for a process that is not its own.
• A write to /proc/[pid]/mem from anything other than a known debugger.
• dd run against /proc paths.
• Unusual mount or bind operations involving /proc.

File access auditing can capture the first three if you have rules for those paths. Without them, the activity leaves very little behind, which is the point of the technique.

How to reduce the risk

MITRE lists two mitigations.

Restrict file and directory permissions. Limit access to sensitive files such as /proc/[pid]/maps and /proc/[pid]/mem. In practice this means reviewing who can reach another process's entries and tightening where the system allows it.

Behavior Prevention on Endpoint. Some endpoint security tools block certain types of process injection based on common behavior sequences. Check that your Linux coverage includes this class.

Steps you can take:

1. Review how /proc is mounted on your hosts and whether any mount options restrict visibility of other users' processes.
2. Limit which accounts can run as the same user as sensitive services, since same-user access is the easiest path to their memory entries.
3. Add audit rules for writes to /proc/[pid]/mem.
4. Enable blocking in your endpoint tool.

Check your own environment

Read-only checks on Linux.

See how /proc is mounted and with which options:

mount | grep ' /proc '

List audit rules currently loaded, to see whether anything covers /proc (needs root):

sudo auditctl -l

Look at permissions on the mappings of one of your own processes:

ls -l /proc/$$/maps /proc/$$/mem

Then check a long-running service. Which user does it run as, and who else on the host shares that user? Whoever shares the account can usually reach its entries.

Quick check

Sources

• MITRE ATT&CK T1055.009 Proc Memory