Linux Process Masquerading Tricks ps and top

On June 24, 2025, a Senior ISC Handler at the SANS Internet Storm Center published a technical demonstration that exposes a structural weakness in Linux monitoring: malicious processes can alter both the name visible in /proc/<pid>/comm and the command line in /proc/<pid>/cmdline, evading standard enumeration tools. The technique leverages legitimate kernel mechanisms — the prctl() syscall and user-space argv/environ memory overwrites — and is classified as T1036 Masquerading in the MITRE ATT&CK framework.

Two Faces of the Same Process: comm and cmdline

The Linux kernel exposes a process name through two virtual files in /proc. /proc/<pid>/comm holds at most 15 characters and feeds ps, top, and name-based searches. /proc/<pid>/cmdline instead reports the full command line, including arguments, and is consulted by ps aux, pgrep -f, and threat-hunting tools that rely on string matching.

The source underscores a critical point: these two interfaces are independent and both manipulable. Modifying comm uses the prctl(PR_SET_NAME, ...) syscall, documented in the Linux kernel manual. Modifying cmdline requires a more invasive step: because argv[0] is a fixed-size buffer, not a relocatable pointer, the entire contiguous region spanning argv and environ must be overwritten, calculating the end offset as end=argv[i]+strlen(argv[i])+1 and zeroing memory up to that limit.

"argv[0] is a fixed-size buffer! You can't just point it somewhere else, because the kernel reports the original memory region" — Senior ISC Handler, SANS ISC

The Demo: From User Process to Fake kworker

The author implemented a C proof-of-concept that applies both techniques in sequence. The first call is prctl(PR_SET_NAME, "kworker/0:1", 0, 0, 0), which populates /proc/<pid>/comm with a plausible name. Next, the set_cmdline() function overwrites argv and environ with the string [kworker/0:1-events].

The result is documented with terminal screenshots: the process with PID 130888, originally launched by user remnux, appears in ps and ps aux as [kworker/0:1-events]. No visible indicator reveals the discrepancy. The example was chosen carefully: kworker is a legitimate kernel thread present on every Linux system, rarely subjected to manual scrutiny.

The technique is cited by the source as an instance of T1036 Masquerading in the MITRE ATT&CK framework. In the introductory paragraph the author mentions the Chinese group Velvet Ant as an example of masquerading used in real campaigns, but the dossier provides no specific details on this correlation and does not state that Velvet Ant employs this specific Linux implementation.

eBPF Limits: Kunai Sees but Does Not Reconstruct

The source tests the masqueraded process with Kunai, an eBPF-based detection tool. The JSON output shows the original executable path — /home/remnux/ps-masquerade — with an error: 'file not found' field and an ancestor chain tracing the execution. This confirms that eBPF, operating at the kernel tracepoint level, can trace back to the inode and path of the executed file regardless of user-space masquerading.

There is, however, a documented limitation. Per the author's direct quote: "A good news is that tools like Kunai (based on eBPF) will catch the real command line but won't be able to find back the exec name." The tool detects the original executable and the real command line, but cannot reconstruct the initial exec name — the parameter passed to the OS at execve() time. This creates a significant visibility gap for SOC analysts: temporal correlation between the launch name and subsequent behavior remains partially obscured.

The dossier does not specify whether Kunai or other eBPF tools can detect the cmdline overwrite in real time as an anomalous event, rather than simply observing its effects after the fact.

What to Do Now

For teams monitoring Linux systems, the demonstration demands three concrete adjustments to the threat-hunting workflow.

First: verify consistency between /proc/<pid>/comm, /proc/<pid>/cmdline, and the executable path in /proc/<pid>/exe before classifying a process as benign. A legitimate kworker does not have a user-space executable in /home.

Second: integrate Kunai or equivalent eBPF tools to trace the real executable path, knowing the gap on the initial exec name persists. Detection of the original executable remains valid but does not fully close the provenance chain.

Third: treat with suspicion processes that show kernel names like kworker but execute from user paths or present cmdline with square brackets in non-standard kernel formats. The source provides no pre-packaged detection rules, but the multi-interface comparison logic is immediately applicable.

The Takeaway: When the Name Is Just a Label

The strength of this demonstration lies in exposing an implicit assumption: that the process name is a reliable identifier. On Linux this assumption is structurally fragile because the kernel provides legitimate mechanisms to modify it, and standard enumeration tools do not validate consistency between name, executable, and command line. Migration to eBPF improves visibility on the original executable but does not fully close the gap, especially for the initial exec name.

For threat-hunting teams, the implication is that process-name-based whitelists — common in SOCs that filter kworker or other kernel threads as benign by definition — require integration with executable integrity checks and behavioral analysis. The source does not specify which integrity checks are preferable or how to implement them.

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

Information is based on the cited source and current as of publication.

Sources

• https://schema.org/FAQPage
• https://schema.org/Question
• https://schema.org/Answer