Run ps on a box you’re pretty sure is clean and you’ll get a tidy column of friendly names. kworker, systemd, sshd, maybe a dbus-daemon for flavor. Comforting. It’s also, potentially, fiction. A SANS Internet Storm Center diary this week walked through Linux process name masquerading, and it’s a useful reminder that a huge amount of cybersecurity work rests on trusting the output of a tool that an attacker can rewrite. The names in your process list are not facts. They’re suggestions the running code chose to display.

This isn’t exotic. It’s MITRE ATT&CK technique T1036, and crews like the China-linked Velvet Ant group have leaned on it for years. The whole point is to make a malicious process boring enough that the analyst’s eyes slide right past it.

Your process list is a suggestion, not a fact

On Linux, a process has more than one place it advertises a name, and they don’t have to agree. There’s the comm value the kernel tracks, the argv[0] string the program presents, and the command line you see in /proc/[pid]/cmdline. A program can overwrite argv[0] at runtime. It can call prctl() with PR_SET_NAME to change what shows up as its thread name. None of this requires root, a rootkit, or any clever kernel tampering. It’s ordinary userland behavior that legitimate software uses too, which is exactly what makes it a great hiding spot.

So when malware spawns and renames itself to [kworker/2:1], brackets and all, it isn’t breaking anything. It’s using the system the way the system works. Your analyst scrolls past a kernel worker thread because of course there’s a kernel worker thread. That’s the trick. There’s no alarm because nothing technically went wrong.

If you’re dealing with an actual rootkit, the situation is worse: the process can be hidden outright by tampering with the calls that enumerate processes. Masquerading is the cheaper, quieter cousin. The attacker doesn’t hide the process. They let you see it and trust it.

Why this breaks a lot of cybersecurity tooling

Here’s the uncomfortable part. A lot of detection logic, threat detection rules, even some EDR content, keys off process names. “Alert if a process called nc opens an outbound connection.” “Flag powershell.exe spawned by Office.” Useful heuristics, until the adversary simply doesn’t use those names. Rename the implant to systemd-resolved and the rule never fires. You built a lock that opens for anyone who writes the right word on a slip of paper.

This is the same rot we keep finding in different rooms of the house. Allowlists that grade software by its signature. Reputation engines that trust a package because it has download numbers. Dashboards that go green because a control reported in. Every one of them is trusting metadata that the other side gets to influence. Defense in depth exists precisely because no single layer, including the one labeling your processes, is honest under pressure.

The fix in concept is simple. Stop asking a process what its name is. Ask what it’s actually doing, where its binary lives, who its parent is, and whether any of that matches the story the name is telling.

What to actually do about it

You don’t fight masquerading by staring harder at ps. You fight it by collecting signals the host can’t edit and by anchoring detection to behavior. Here’s where to start.

• Compare the name to the binary path. A real sshd runs from /usr/sbin/sshd. A process calling itself sshd from /tmp or a user’s home directory is a screaming alert. Read /proc/[pid]/exe, not just the displayed name.
• Watch process parentage. Kernel worker threads have a parent of PID 2 (kthreadd). A “kworker” whose parent is a bash shell or a web server is lying. Lineage is far harder to fake convincingly than a string.
• Instrument the kernel directly. auditd, eBPF tooling, or your EDR’s syscall-level telemetry can record execve with the true executable, hash, and arguments at launch, before anything renames itself.
• Ship logs off the host immediately. If the box is owned, its local logs are suspect. Off-host, append-only telemetry is the version of events the attacker can’t go back and edit. This is non-negotiable for incident response.
• Alert on network behavior, not process identity. A “system” process beaconing to a fresh external IP is suspicious no matter what it’s called. Tie threat-protection rules to connections, listening ports, and data volume.
• Baseline what normal looks like. Know your real process set, paths, and parent relationships per host role. Deviation detection beats signature matching when the signature is attacker-chosen.

Ongoing, fold this into your security hardening cadence. Restrict who can write executables to world-writable directories. Mount /tmp noexec where your apps tolerate it. Keep your detection content reviewed so nobody’s still shipping name-only rules in 2026. And rehearse the incident response play for “the process list can’t be trusted,” because the first instinct under pressure is to believe the screen.

Patch the door before you hunt the intruder

All of this matters more when something is actively kicking down doors, and this week something is. Cisco confirmed that CVE-2026-20230, a high-severity SSRF flaw in Unified Communications Manager, is now being exploited in the wild. An exploited flaw is how the masquerading process gets onto your box to begin with. The renamed implant is act two. The unpatched edge service is act one.

So run both plays. Close the foothold: patch internet-facing systems on the timeline the threat actor is actually working, not your quarterly maintenance window, and put brute-force controls and a tightened firewall in front of every management interface and auth endpoint so the cheap automated attempts die at the edge. Then assume something slipped through anyway and hunt for the liar in your process table.

The encouraging trend is vendors surfacing more of what used to stay quiet. Google Workspace just expanded its admin password-reset alerts to every admin, not only super admins, giving teams visibility into privileged-account changes they previously had to go digging for. That’s the same instinct you need at the host level: make the important events loud, and stop trusting any label the attacker had a chance to write.

Your kworker is probably fine. Probably. The job is building a stack that doesn’t need to take its word for it.

Sources

• Linux Process Name Masquerading (SANS Internet Storm Center)
• Cisco Unified CM flaw CVE-2026-20230 now exploited in attacks
• Google Workspace expands password reset alerts to all admins