Live Active security incident? Get immediate response
MITRE ATT&CK® Technique

T1036.011: Overwrite Process Arguments

Adversaries may modify a process's in-memory arguments to change its name in order to appear as a legitimate or benign process. On Linux, the operating system stores command-line arguments in the process’s stack and passes them to the `main()` function as the `argv` array. The first element, `argv[0]`, typically contains the process name or path - by default, the command used to actually start the process (e.g., `cat /etc/passwd`). By default, the Linux `/proc` filesystem uses this value to represent the process name. The `/proc//cmdline` file reflects the contents of this memory, and tools like `ps` use it to display process information. Since arguments are stored in user-space memory at launch, this modification can be performed without elevated privileges.

During runtime, adversaries can erase the memory used by all command-line arguments for a process, overwriting each argument string with null bytes. This removes evidence of how the process was originally launched. They can then write a spoofed string into the memory region previously occupied by `argv[0]` to mimic a benign command, such as `cat resolv.conf`. The new command-line string is reflected in `/proc//cmdline` and displayed by tools like `ps`.[1][2]

EnterpriseT1036.011Sub-techniqueObject v2.0 Modified
Glexia's Take

Analyst context for executives and security teams

Analyst confidence High

Overwrite Process Arguments is a Linux masquerading technique where a running process changes the command-line text shown through /proc and tools such as ps. The business issue is not the string change itself; it is that responders and SOC analysts may trust a process listing that now looks benign while the original launch context has been erased. For Linux-heavy environments, this can weaken triage, delay containment, and reduce confidence in incident evidence.

Executive priority

Treat this as a visibility and incident-readiness risk for Linux estates. Security leaders should ask whether process monitoring preserves original execution context, not only current /proc command-line output. This matters for operational resilience because investigations, audit evidence, and containment decisions often depend on knowing what actually executed. It should also influence budget and control priorities for Linux endpoint telemetry, managed detection content, and incident response procedures where Linux servers support critical services.

Technical view

This ATT&CK sub-technique applies to Linux and sits under Masquerading with a stealth tactic. The supplied description states that adversaries can modify in-memory argv data so /proc/<PID>/cmdline and ps display a spoofed benign-looking process name, without requiring elevated privileges. SOC and IR teams should validate whether their telemetry records immutable or early process-start evidence, and whether detections compare process identity from multiple sources instead of relying only on current command-line display. Relationship context notes DET0164, Detection Strategy for Overwritten Process Arguments Masquerading, as a detection strategy for this object, and BPFDoor as software that uses this technique.

Likely telemetry

  • Linux process creation/start telemetry that captures original executable path and command line at launch
  • /proc/<PID>/cmdline observations and process listing data from tools or agents
  • Endpoint detection and response process metadata for Linux hosts
  • Audit or kernel-level process execution records where available
  • File path, executable inode, parent process, PID, start time, and user context

Detection direction

  • Validate that detections do not depend solely on ps output or /proc/<PID>/cmdline because this field may reflect overwritten argv content.
  • Compare current displayed command-line values against original process creation telemetry, executable path, parent process, process start time, and user context.
  • Prioritize Linux hosts where long-running or externally exposed services make process masquerading more consequential for triage.
  • Tune for mismatches such as benign-looking process names paired with unexpected executable locations, parents, users, or runtime behavior.
  • Use the related DET0164 detection strategy as ATT&CK-supported context for building or assessing analytic coverage.

Mitigation priorities

  • Improve Linux endpoint visibility so original process execution evidence is retained before in-memory arguments can be changed.
  • Standardize incident response collection to include multiple process identity sources, not only live process listings.
  • Harden SOC runbooks to treat benign-looking Linux process names as insufficient evidence of legitimacy when other metadata is inconsistent.
  • Prioritize monitoring coverage for critical Linux servers and systems supporting business continuity.
  • Use managed detection or internal detection engineering reviews to test whether masqueraded process arguments would be noticed in existing workflows.
Analyst notes and limits

This object is newly represented as ATT&CK T1036.011, a Linux sub-technique of Masquerading. The key defensive lesson is evidence integrity: current command-line display can be manipulated, so detection and response should correlate independent process attributes. The supplied relationship to BPFDoor provides an example of software using the technique, but it should not be generalized into claims of current activity or exposure.

MITRE provides no official detection text for this object in the supplied fields. The take is therefore based on the official description, platform, tactic, external references, and relationships only. Actual detection feasibility depends on local Linux telemetry, endpoint agent behavior, retention, and whether original process-start data is collected before argv modification.

Official MITRE ATT&CK definition

Overwrite Process Arguments

Adversaries may modify a process's in-memory arguments to change its name in order to appear as a legitimate or benign process. On Linux, the operating system stores command-line arguments in the process’s stack and passes them to the `main()` function as the `argv` array. The first element, `argv[0]`, typically contains the process name or path - by default, the command used to actually start the process (e.g., `cat /etc/passwd`). By default, the Linux `/proc` filesystem uses this value to represent the process name. The `/proc//cmdline` file reflects the contents of this memory, and tools like `ps` use it to display process information. Since arguments are stored in user-space memory at launch, this modification can be performed without elevated privileges.

During runtime, adversaries can erase the memory used by all command-line arguments for a process, overwriting each argument string with null bytes. This removes evidence of how the process was originally launched. They can then write a spoofed string into the memory region previously occupied by `argv[0]` to mimic a benign command, such as `cat resolv.conf`. The new command-line string is reflected in `/proc//cmdline` and displayed by tools like `ps`.[1][2]

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.

1 rows
Domain ID Name Relationship / procedure
Enterprise T1036 Masquerading This object subtechnique of Masquerading.
Associated objects

Groups, software, and campaigns

Malware Enterprise

S1161: BPFDoor

BPFDoor is a Linux based passive long-term backdoor used by China-based threat actors. First seen in 2021, BPFDoor is named after its usage of Berkley Packet Filter (BPF) to execute single task instructions. BPFDoor supports multiple protocols for communicating with a C2 including TCP, UDP, and ICMP and can start local or reverse shells that bypass firewalls using iptables.[1][2]

Linux
Relationship explorer

All related ATT&CK context

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
Modified
Raw hash
b08635c800f4a190...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 2.0 Current bundle b08635c800f4…
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.

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. [1]
    Sandfly BPFDoor 2022

    The Sandfly Security Team. (2022, May 11). BPFDoor - An Evasive Linux Backdoor Technical Analysis. Retrieved September 29, 2023.

    Open source URL
  2. [2]
    Microsoft XorDdos Linux Stealth 2022

    Ratnesh Pandey, Yevgeny Kulakov, and Jonathan Bar Or with Saurabh Swaroop. (2022, May 19). Rise in XorDdos: A deeper look at the stealthy DDoS malware targeting Linux devices. Retrieved September 27, 2023.

    Open source URL
  3. [3]
    mitre-attack T1036.011
    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.