- AN0466 · Analytic 0466 — Detects adversary behavior where the command-line arguments of a running process are overwritten in memory to spoof the process name, typically replacing it with a benign or misleading string. The detection correlates unexpected null byte sequences, discrepancies between `/proc/<pid>/cmdline` and process ancestry, and suspicious memory writes shortly after process start.
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/<PID>/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/<PID>/cmdline` and displayed by tools like `ps`.(Citation: Sandfly BPFDoor 2022)(Citation: Microsoft XorDdos Linux Stealth 2022)
Open in the interactive knowledge mesh
Detection overview
Use the published detection strategies below and validate required telemetry in the target environment.
Observed groups
No current Enterprise group relationship is published in this bundle.
Cyber Knowledge context
Use these routes to move from the ATT&CK behavior into explanation, implementation, evidence handling, validation, and defensive operations. Relevance is generated from explicit identifiers/names and governed topic mappings; it is not attribution evidence.
Debugging, tracing, and runtime instrumentation
Malware Analysis & Reverse Engineering · topic-match · 51/100Controlled dynamic behavior and differential observation
Malware Analysis & Reverse Engineering · topic-match · 48/100Module 4 — Detection engineering and detection as code
Blue Team & Defensive Security · tactic-route · 24/100Disk, file-system, and persistence forensics
Digital Forensics & Incident Response (DFIR) · tactic-route · 24/100
Malware Analysis & Reverse Engineering · topic-match · 51/100Controlled dynamic behavior and differential observation
Malware Analysis & Reverse Engineering · topic-match · 48/100Module 4 — Detection engineering and detection as code
Blue Team & Defensive Security · tactic-route · 24/100Disk, file-system, and persistence forensics
Digital Forensics & Incident Response (DFIR) · tactic-route · 24/100
MITRE mitigations
No ATT&CK mitigation relationship is published for this technique. Apply risk-based controls and verify scope.