A Senior ISC Handler at the SANS Internet Storm Center has published a technical analysis demonstrating how standard Linux process-monitoring tools — ps, top, htop — can be deceived by documented masquerading techniques. The post is educational and expository; it does not report active threat intelligence or specific campaigns. It is a lesson on a structural Linux kernel mechanism.
- On Linux the process name lives in two locations:
/proc/<pid>/comm(15 characters max, used bypsandtop) and/proc/<pid>/cmdline(full argv, used byps aux). prctl(PR_SET_NAME)modifiescomm; alteringcmdlinerequires overwriting theargv[0]buffer and, if insufficient, spilling into the contiguousargv[1..n]andenvironregions.- The author demonstrated masquerading as
[kworker/0:1-events], a typical kernel worker thread name. - eBPF tools such as Kunai detect the true executable path (
exe.path) but cannot recover the original exec name if the file has been removed.
The Dual Channel That Deceives Standard Tools
The source precisely distinguishes the two Linux kernel naming channels. /proc/<pid>/comm is a 15-character field the kernel exposes for every process; ps and top read it to display the short name. /proc/<pid>/cmdline contains the full command line — the argv vector passed at execve time.
The implementation difference is critical: comm is modifiable via a single prctl(PR_SET_NAME, ...) system call. The C code shown by the source sets the name to "kworker/0:1" and ps output shows [kworker/0:1-events], complete with the square brackets typical of kernel threads. An analyst who trusts only the visible name will classify the process as legitimate.
cmdline is more complex to alter. The source specifies that argv[0] is a fixed-size buffer: it cannot be reallocated or pointed elsewhere because the kernel reports the original memory region. To overcome this constraint, the code must overwrite the contiguous bytes following argv[0], spilling into argv[1..n] and potentially environ, zeroing the affected area. This operation leaves structural traces — the command line appears anomalous or truncated — but tools that do not verify internal consistency may ignore them.
The prctl Mechanism and Its Detection Limits
The use of prctl(2) with the PR_SET_NAME argument is documented in the official Linux manual, cited as contextual reference. The system call is legitimate: services and applications use it to identify their own threads. Its dual nature — useful function but abusable — is what makes detection based on process name fundamentally unreliable.
The source cites MITRE ATT&CK T1036, Masquerading, as the classification framework for the technique. The reference places masquerading among recurring tactics of Chinese, Russian, Iranian, and other APTs. The SANS post mentions "Velvet Ant Chinese group," but the bibliographic reference is not resolvable with the provided sources; the specific use of this prctl/argv implementation by that group is therefore not verifiable.
"When you list running processes on a computer, can you trust what you see?"
— Senior ISC Handler, SANS Internet Storm Center
The author's practical test, run on a REMnux system in a controlled lab environment, shows the masqueraded process with PID 130888. The experiment is the author's proof-of-concept, not in-the-wild malware: there is no independent verification that the code has been observed in active malware. The post's publication date is not specified in the sources as an original June 24, 2025 date or a republication of earlier analyses.
Why eBPF Changes (Part of) the Game
The source introduces Kunai as an example of an eBPF tool that partially bypasses the problem. Unlike ps and top, which read the /proc files generated by the kernel in user space, Kunai intercepts calls at kernel level and traces the real executable path via the exe.path field.
The JSON output shown by the source is explicit: the path is /home/remnux/ps-masquerade, with error: "file not found" indicating the file was removed after execution. The ancestors reveal the real execution chain. However, the source underscores a limit: if the executable is deleted, Kunai "won't be able to find back the exec name." The original exec name is not recoverable, even though the provenance chain identifies it indirectly.
It is not specified whether Kunai generates automatic alerts or requires manual log analysis. The dossier does not quantify the prevalence of this technique in active 2025 campaigns.
What Changes
The lesson of the SANS post is structural, not operational: the process names read by ps and top are kernel outputs that the user can alter. This is not a vulnerability to patch but a characteristic of Linux design, with implications for anyone who uses those names as security inputs.
The source does not specify kernel-level mitigations or recommend specific detection architectures. The piece's value lies in documenting a gap: tools that read /proc in user space see what the process decides to show, while eBPF tools that intercept sched:sched_process_exec see the executable path at execution time — with the documented limit that the original name is lost if the file is removed.
The contrast with Windows is stark and cited by the source: on Windows the PEB is writable in userland but the kernel EPROCESS fields are not modifiable from user mode. On Linux, both channels are technically alterable by the process itself.
Limits and Context
This article is based on a single structured primary source: the SANS Internet Storm Center diary. The techniques described are documented but their prevalence in active 2025 campaigns is not verified. The code shown is educational proof-of-concept, not in-the-wild malware. No indicators of compromise (IOCs) or specific documented campaigns are present.
The reference to "Velvet Ant Chinese group" is not verifiable with the provided sources. PID 130888 is an example from the author's practical test, not an IOC. The REMnux system is a controlled lab environment, not a compromised production system.
The source does not specify whether Kunai generates automatic alerts on masquerading or quantify the technique's real-world prevalence. Operational implications for SOC or Blue Teams are not part of the original brief: the post is didactic analysis, not active threat intelligence reporting.
Information is based on the cited source and current as of publication.
Sources
- https://isc.sans.edu/diary/rss/33102
- https://isc.sans.edu/diary/An+Example+of+Stack+String+in+High+Level+Language/33008
- https://attack.mitre.org/techniques/T1036/
- https://man7.org/linux/man-pages/man2/prctl.2.html