T1055.009: Proc Memory

Proc Memory is a Linux process-injection sub-technique where malicious code is run inside another live process through the /proc filesystem. For leaders, the significance is not the mechanics; it is that activity can appear to come from a legitimate process, potentially bypassing process-name-based monitoring and complicating incident scoping.

Executive priority

Prioritize this where Linux systems support business-critical services, privileged workloads, or externally exposed infrastructure. The decision question is whether the organization can prove it collects enough Linux endpoint evidence to distinguish legitimate /proc inspection from suspicious memory manipulation. ATT&CK also links this technique to KV Botnet Activity, described in the supplied context as involving end-of-life SOHO equipment and critical infrastructure victim segments, making asset lifecycle and Linux visibility relevant to resilience planning.

Technical view

Validate coverage for Linux process-injection behavior under the broader Process Injection technique T1055. Focus on access to /proc/[pid] memory mapping data, suspicious interaction with /proc/[pid]/maps or related process memory interfaces, and command-line patterns involving utilities such as dd interacting with process memory paths. Because official detection text is not provided, use the related DET0541 detection strategy as a starting point but test it against local Linux logging, endpoint sensor, and response capabilities. IR teams should be prepared for code execution to be masked under an otherwise legitimate process context.

Likely telemetry

Linux process creation and command-line telemetry, especially utilities interacting with /proc/[pid] paths
File access or audit telemetry for /proc/[pid] directories, memory maps, and process memory-related files
Parent-child process relationships, including unusual background or child processes used as injection targets
Endpoint behavior-prevention or EDR events showing inter-process memory manipulation or suspicious process behavior
Privilege context for the accessing process and the target process

Detection direction

Do not rely only on process names; injected execution may be hidden inside legitimate processes.
Validate DET0541-style logic against real Linux telemetry sources available in the environment.
Tune for suspicious combinations: /proc enumeration, memory map access, write-like behavior, and unusual command-line utilities touching process paths.
Account for false positives from legitimate debugging, monitoring, profiling, and administrative tools that inspect /proc.
Correlate with privilege escalation context because the technique is mapped to stealth and privilege-escalation tactics.

Mitigation priorities

Apply M1022 by restricting file and directory permissions and enforcing least privilege on Linux systems, especially for sensitive processes and directories.
Apply M1040 behavior prevention on endpoint where available to block or alert on suspicious process behavior rather than relying solely on signatures.
Reduce unnecessary administrative access that could permit interaction with other processes through /proc.
Prioritize hardening and monitoring for Linux systems supporting critical services or legacy/end-of-life infrastructure.
Use incident-response playbooks that preserve process, command-line, and /proc access evidence before rebooting or reimaging systems.

Analyst notes and limits

This object is Linux-specific and is a sub-technique of Process Injection. MITRE provides no official detection text, but the relationship set includes DET0541 as a detection strategy and mitigations M1022 and M1040. The supplied references describe /proc-based process memory manipulation and dd usage; defensive validation should remain environment-specific.

The supplied ATT&CK object does not include detailed detection analytics, procedures, data sources, or platform variants beyond Linux. Any conclusion about exposure, active exploitation, or control effectiveness requires local telemetry, endpoint configuration, asset criticality, and incident evidence.

Official MITRE ATT&CK definition

Proc Memory

Adversaries may inject malicious code into processes via the /proc filesystem in order to evade process-based defenses as well as possibly elevate privileges. Proc memory injection is a method of executing arbitrary code in the address space of a separate live process.

Proc memory injection involves enumerating the memory of a process via the /proc filesystem (/proc/[pid]) then crafting a return-oriented programming (ROP) payload with available gadgets/instructions. Each running process has its own directory, which includes memory mappings. Proc memory injection is commonly performed by overwriting the target processes’ stack using memory mappings provided by the /proc filesystem. This information can be used to enumerate offsets (including the stack) and gadgets (or instructions within the program that can be used to build a malicious payload) otherwise hidden by process memory protections such as address space layout randomization (ASLR). Once enumerated, the target processes’ memory map within /proc/[pid]/maps can be overwritten using dd.[1][2][3]

Other techniques such as Dynamic Linker Hijacking may be used to populate a target process with more available gadgets. Similar to Process Hollowing, proc memory injection may target child processes (such as a backgrounded copy of sleep).[2]

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 proc memory injection may also evade detection from security products since the execution is masked under a legitimate process.

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

How security teams should use this page

Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.

ATT&CK relationship table

Related techniques

This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.

Filter related techniques 1 rows

Domain	ID	Name	Relationship / procedure
Enterprise	T1055	Process Injection	This object subtechnique of Process Injection.

Associated objects

Groups, software, and campaigns

C0035: KV Botnet Activity

KV Botnet Activity consisted of exploitation of primarily “end-of-life” small office-home office (SOHO) equipment from manufacturers such as Cisco, NETGEAR, and DrayTek. KV Botnet Activity was used by Volt Typhoon to obfuscate connectivity to victims in multiple critical infrastructure segments, including energy and telecommunication companies and entities based on the US territory of Guam. While the KV Botnet is the most prominent element of this campaign, it overlaps with another botnet cluster referred to as the JDY cluster.[1] This botnet was disrupted by US law enforcement entities in early 2024 after periods of activity from October 2022 through January 2024.[2]

Relationship explorer

All related ATT&CK context

mitigates · Mitigation M1040: Behavior Prevention on Endpoint Enterprise subtechnique of · Technique T1055: Process Injection Enterprise detects · Detection Strategy DET0541: Detection Strategy for /proc Memory Injection on Linux Enterprise mitigates · Mitigation M1022: Restrict File and Directory Permissions Enterprise uses · Campaign C0035: KV Botnet Activity Enterprise

Mitigations

Mitigation direction

M1040: Behavior Prevention on Endpoint

Behavior Prevention on Endpoint refers to the use of technologies and strategies to detect and block potentially malicious activities by analyzing the behavior of processes, files, API calls, and other endpoint events. Rather than relying solely on known signatures, this approach leverages heuristics, machine learning, and real-time monitoring to identify anomalous patterns indicative of an attack. This mitigation can be implemented through the following measures:

Suspicious Process Behavior:

- Implementation: Use Endpoint Detection and Response (EDR) tools to monitor and block processes exhibiting unusual behavior, such as privilege escalation attempts. - Use Case: An attacker uses a known vulnerability to spawn a privileged process from a user-level application. The endpoint tool detects the abnormal parent-child process relationship and blocks the action.

Unauthorized File Access:

- Implementation: Leverage Data Loss Prevention (DLP) or endpoint tools to block processes attempting to access sensitive files without proper authorization. - Use Case: A process tries to read or modify a sensitive file located in a restricted directory, such as /etc/shadow on Linux or the SAM registry hive on Windows. The endpoint tool identifies this anomalous behavior and prevents it.

Abnormal API Calls:

- Implementation: Implement runtime analysis tools to monitor API calls and block those associated with malicious activities. - Use Case: A process dynamically injects itself into another process to hijack its execution. The endpoint detects the abnormal use of APIs like `OpenProcess` and `WriteProcessMemory` and terminates the offending process.

Exploit Prevention:

- Implementation: Use behavioral exploit prevention tools to detect and block exploits attempting to gain unauthorized access. - Use Case: A buffer overflow exploit is launched against a vulnerable application. The endpoint detects the anomalous memory write operation and halts the process.

M1022: Restrict File and Directory Permissions

Restricting file and directory permissions involves setting access controls at the file system level to limit which users, groups, or processes can read, write, or execute files. By configuring permissions appropriately, organizations can reduce the attack surface for adversaries seeking to access sensitive data, plant malicious code, or tamper with system files.

Enforce Least Privilege Permissions:

- Remove unnecessary write permissions on sensitive files and directories. - Use file ownership and groups to control access for specific roles.

Example (Windows): Right-click the shared folder → Properties → Security tab → Adjust permissions for NTFS ACLs.

Harden File Shares:

- Disable anonymous access to shared folders. - Enforce NTFS permissions for shared folders on Windows.

Example: Set permissions to restrict write access to critical files, such as system executables (e.g., `/bin` or `/sbin` on Linux). Use tools like `chown` and `chmod` to assign file ownership and limit access.

On Linux, apply: `chmod 750 /etc/sensitive.conf` `chown root:admin /etc/sensitive.conf`

File Integrity Monitoring (FIM):

- Use tools like Tripwire, Wazuh, or OSSEC to monitor changes to critical file permissions.

Audit File System Access:

- Enable auditing to track permission changes or unauthorized access attempts. - Use auditd (Linux) or Event Viewer (Windows) to log activities.

Restrict Startup Directories:

- Configure permissions to prevent unauthorized writes to directories like `C:\ProgramData\Microsoft\Windows\Start Menu`.

Example: Restrict write access to critical directories like `/etc/`, `/usr/local/`, and Windows directories such as `C:\Windows\System32`.

- On Windows, use icacls to modify permissions: `icacls "C:\Windows\System32" /inheritance:r /grant:r SYSTEM:(OI)(CI)F` - On Linux, monitor permissions using tools like `lsattr` or `auditd`.

Change history

Object version and sync metadata

The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .

ATT&CK release: 19.1
Object version: 2.0
Created: Jan 14, 2020, 01:34 UTC (UTC+00:00)
Modified: May 12, 2026, 15:12 UTC (UTC+00:00)
Raw hash: ecb4e2be145ffb87...

Imported snapshots across ATT&CK releases (1)

Release	Bundle imported	Object version	Modified	Status	Raw hash
19.1	May 18, 2026, 07:08 UTC (UTC+00:00)	2.0	May 12, 2026, 15:12 UTC (UTC+00:00)	Current bundle	`ecb4e2be145f…`

Raw source

Mirrored ATT&CK source object

The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.

Open mirrored raw JSON Open MITRE-hosted copy

Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

[1]
Uninformed Needle

skape. (2003, January 19). Linux x86 run-time process manipulation. Retrieved December 20, 2017.
Open source URL
[2]
GDS Linux Injection

McNamara, R. (2017, September 5). Linux Based Inter-Process Code Injection Without Ptrace(2). Retrieved February 21, 2020.
Open source URL
[3]
DD Man

Kerrisk, M. (2020, February 2). DD(1) User Commands. Retrieved February 21, 2020.
Open source URL
[4]
mitre-attack T1055.009
Open source URL

Source and licensing

Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.

Official MITRE ATT&CK site Official STIX data repository MITRE ATT&CK terms of use

Analyst context for executives and security teams