Listen to this Post
Introduction:
On Linux systems, any process can choose its own name using a simple system call—and that single capability is all an attacker needs to hide in plain sight. Malicious actors routinely rename their cryptominers and backdoors to mimic kernel worker threads like
</code>, <code>[bash]</code>, or simply <code>[0:2]</code>, betting that system administrators scrolling through process lists will dismiss them as "kernel stuff" and scroll right past. However, this deception leaves a telltale fingerprint: genuine kernel threads have no backing executable file, while a masquerading process does. This article breaks down the mechanics of this evasion technique, provides hands-on detection commands, and outlines how to build defenses against one of the most common—and most overlooked—Linux threats. <h2 style="color: yellow;">Learning Objectives:</h2> <ul> <li>Understand how the `prctl(PR_SET_NAME)` syscall and `/proc/self/comm` allow processes to arbitrarily rename themselves.</li> <li>Learn to distinguish genuine kernel threads from masquerading user-space processes using `/proc/[bash]/exe` and <code>/proc/[bash]/cmdline</code>.</li> <li>Implement detection rules and forensic workflows to identify and block process masquerading in enterprise Linux environments.</li> </ul> <ol> <li>The Masquerade Mechanism: How Attackers Become "Kernel Threads"</li> </ol> The Linux kernel maintains a process name field called `comm` (short for "command name"), which is what tools like <code>ps</code>, <code>top</code>, and `htop` display. By default, this field contains the name of the executable. However, the `prctl()` system call with the `PR_SET_NAME` argument—or writing directly to <code>/proc/self/comm</code>—allows any process to overwrite its own `comm` with an arbitrary string. An attacker can compile a simple C program that calls `prctl(PR_SET_NAME, "[kworker/0:2]")` and then executes a cryptominer or backdoor payload. To the unsuspecting admin running <code>ps auxf</code>, the process appears as a legitimate kernel worker thread. The deception is compounded by the fact that many kernel threads use bracket notation (e.g., <code>[bash]</code>, <code>[bash]</code>), making bracketed names appear authoritative. What makes this technique particularly insidious: The attacker doesn't need root privileges to rename their own process—any user can call `prctl(PR_SET_NAME)` on their own process. This means even a low-privilege compromised account can deploy this masquerade. <h2 style="color: yellow;">Detection Command (Linux):</h2> [bash] List all processes with their executable paths Kernel threads will show as broken symlinks or no exe for pid in /proc/[0-9]; do pid_num=$(basename "$pid") exe_path=$(readlink "$pid/exe" 2>/dev/null) comm=$(cat "$pid/comm" 2>/dev/null) if [[ -1 "$exe_path" && "$comm" =~ ^[.]$ ]]; then echo "SUSPICIOUS: PID $pid_num named '$comm' has executable at $exe_path" fi done
This one-liner scans all running processes and flags any that use bracketed kernel-style names but have a valid executable path—the definitive tell.
2. The Critical Tell: /proc/
/exe vs. Kernel Threads</h2>
The fundamental detection principle is simple: genuine kernel threads have no executable file on disk. When you examine `/proc/[bash]/exe` for a real kernel thread like <code>kworker</code>, the symlink points to nothing—it's broken or non-existent. In contrast, a user-space process masquerading as a kernel thread will have a valid `exe` symlink pointing to its actual binary on disk, even though its `comm` says <code>[bash]</code>.
This discrepancy is the cornerstone of detection. Elastic Security's prebuilt rule "Executable Masquerading as Kernel Process" (MITRE T1036.004) operationalizes this exact logic. The rule flags any process with a kernel-style name that also has a non-empty `process.executable` field.
<h2 style="color: yellow;">Forensic Deep Dive:</h2>
[bash]
Check a specific PID manually
pid=1234
echo "Process name: $(cat /proc/$pid/comm 2>/dev/null)"
echo "Executable path: $(readlink /proc/$pid/exe 2>/dev/null)"
echo "Command line: $(cat /proc/$pid/cmdline 2>/dev/null | tr '\0' ' ')"
If name is bracketed AND exe exists → masquerade
If name is bracketed AND exe is broken → genuine kernel thread
Windows Parallel: While Linux uses `prctl` and /proc, Windows attackers often use similar techniques via `SetProcessName` or by modifying the PEB (Process Environment Block). The detection principle remains analogous: verify that the process name matches its actual binary and parent relationships.
3. The REF6138 Campaign: Masquerade in Action
In March 2024, Elastic Security Labs uncovered the REF6138 campaign, a sophisticated Linux malware operation that leveraged process masquerading as a core evasion tactic. Attackers compromised vulnerable Apache2 web servers, deployed cryptominers and DDoS bots, and disguised their malicious processes as kernel threads using the very technique described above.
The campaign demonstrated that masquerading isn't just theoretical—it's actively used in the wild. The backdoor would rename itself to `[kworker/0:2]` or similar while beaconing out to command-and-control infrastructure, making casual process inspection ineffective. Elastic Defend's behavioral rule "Process Masquerading as Kernel Process" successfully blocked this activity, validating the detection approach.
Key takeaway from REF6138: Attackers combine masquerading with other persistence mechanisms like cron jobs and SELinux policy modifications. A comprehensive detection strategy must look beyond just process names.
- Building Detection Rules: From Manual Checks to Automated Alerts
Manual `ps` and `readlink` checks are useful for incident response, but enterprise environments require automated detection. Here's how to build rules across common platforms:
Elastic Defend Rule (Prebuilt):
The rule "Executable Masquerading as Kernel Process" is available out-of-the-box in Elastic Security. It requires Elastic Defend data and triggers when a process with a kernel-style name has a populated `process.executable` field.
Auditd Rule (Linux):
Monitor `prctl` syscalls with `PR_SET_NAME`:
/etc/audit/rules.d/prctl.rules -a always,exit -S prctl -F a0=15 -k process_name_change
Then alert on processes that change their name to a bracketed string.
Sigma Rule (Generic):
title: Linux Process Masquerading as Kernel Thread status: experimental description: Detects processes with kernel-style names that have executable paths logsource: product: linux service: process_creation detection: selection: process.name|re: '^[.]$' filter: process.executable: null condition: selection and not filter
Sysmon for Linux (if available):
Monitor `ProcessCreate` events and flag any where `ProcessName` matches bracketed pattern but `Image` is not empty.
5. Mitigation and Hardening Strategies
Prevention is always better than detection. Consider these hardening measures:
1. Restrict `prctl(PR_SET_NAME)` via Seccomp:
For containerized workloads, use seccomp profiles to block `prctl` with PR_SET_NAME:
{
"defaultAction": "SCMP_ACT_ALLOW",
"architectures": ["SCMP_ARCH_X86_64"],
"syscalls": [
{
"names": ["prctl"],
"action": "SCMP_ACT_ERRNO",
"args": [
{
"index": 0,
"value": 15,
"op": "SCMP_CMP_EQ"
}
]
}
]
}
2. Monitor `/proc/self/comm` writes:
The `prctl` restriction can be bypassed by writing directly to /proc/self/comm. Use fanotify or inotify to monitor writes to /proc//comm.
3. Harden `/proc` with `hidepid`:
The `hidepid` mount option can restrict visibility of other users' processes, but it doesn't prevent masquerading—it only limits who can see the deception.
4. Regular Auditing:
Schedule the detection script from Section 1 as a daily cron job and ship results to your SIEM.
6. Incident Response Workflow for Suspected Masquerading
When you identify a suspicious process, follow this IR checklist:
1. Capture the full context:
ps auxf | grep -B5 -A5 [bash] lsof -p [bash] netstat -tunap | grep [bash]
2. Extract the binary for analysis:
cp /proc/[bash]/exe /tmp/suspicious_binary file /tmp/suspicious_binary strings /tmp/suspicious_binary | grep -i "c2|beacon|miner"
3. Check for persistence:
crontab -l -u [bash] systemctl list-units --type=service --all | grep -i [bash] grep -r "[bash]" /etc/ 2>/dev/null
- Correlate with network logs: Look for outbound connections to known malicious IPs or unusual ports.
-
Contain and eradicate: Kill the process, remove the binary, and clean up persistence mechanisms. Then investigate the initial entry vector.
What Undercode Say:
- Key Takeaway 1: The `prctl(PR_SET_NAME)` syscall and `/proc/self/comm` give any process the power to rename itself—this is not a kernel bug, it's an intended feature that attackers abuse.
- Key Takeaway 2: The definitive detection method is checking
/proc/[bash]/exe—if a process has a bracketed kernel-style name but a valid executable path, it's almost certainly a masquerade.
Analysis: This technique is deceptively simple yet remarkably effective. Many blue teams focus on complex rootkits and kernel-level hiding, overlooking the fact that attackers can achieve near-equivalent stealth with a single syscall. The REF6138 campaign demonstrated that this isn't just theoretical—it's an active, real-world threat. The good news is that detection is equally simple: a single `readlink` check per process exposes the masquerade instantly. However, this requires shifting mindset from "what does the process look like?" to "what does the process actually have?"—a fundamental distinction that separates effective threat hunting from casual process monitoring. Organizations should prioritize deploying rules like Elastic's "Executable Masquerading as Kernel Process" and regularly audit their Linux estates using the manual checks provided above.
Prediction:
- +1 As Linux adoption continues to grow in cloud and enterprise environments, process masquerading techniques will become increasingly prevalent. Expect to see more sophisticated variants that combine name spoofing with PID spoofing and parent process manipulation.
- -1 The simplicity of this technique means it will remain attractive to attackers for the foreseeable future. However, because detection is equally simple (checking
/proc/[bash]/exe), blue teams that implement basic monitoring will have a significant advantage. - +1 SIEM and EDR vendors will continue to refine detection rules for T1036.004, making it harder for attackers to slip through automated alerts. Elastic's prebuilt rule is already a strong foundation.
- -1 Attackers may adapt by using bind mounts to hide their executable paths or by crafting kernel modules that spoof the `exe` symlink—techniques already documented in Atomic Red Team tests. This will require more advanced detection approaches like memory forensics and kernel integrity checking.
- +1 The growing open-source DFIR community will produce more tooling and playbooks around Linux process forensics, lowering the barrier for organizations to defend against these attacks.
- -1 Organizations that rely solely on visual process inspection (e.g., `top` or
htop) without automated rules will remain vulnerable. Human eyes are simply not sufficient to catch this deception at scale. - +1 Integration of these detection rules into CI/CD pipelines and container orchestration platforms will enable proactive blocking of masquerading attempts before they reach production.
- -1 The line between "legitimate" bracketed names and malicious ones is blurry—some legitimate software uses bracketed names for worker threads. False positives will require tuning and context-aware analysis.
- +1 As threat intelligence sharing improves, campaigns like REF6138 will be more rapidly identified and mitigated, reducing the dwell time of masquerading malware.
- -1 Ultimately, the cat-and-mouse game will continue. Attackers will innovate, defenders will detect, and the cycle will persist—but the fundamental principle of checking `/proc/[bash]/exe` will remain a reliable cornerstone of Linux DFIR for years to come.
▶️ Related Video (84% Match):
🎯Let’s Practice For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
IT/Security Reporter URL:
Reported By: Ruben Groenewoud - Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
