# The Pipe Dream That Became a Privilege Escalation Highway
Windows named pipes have existed since the NT kernel. They predate the web browser. They predate most of the developers currently writing enterprise software. And in 2026, they remain one of the most reliably exploited primitives in attacker playbooks — not because the technology is broken, but because defenders keep treating them as infrastructure rather than an attack surface.
That gap between "this is how Windows works" and "this is how attackers use it against you" is exactly where incidents happen.
## What Named Pipes Actually Are, and Why They Matter
A named pipe is a file-system object that lets processes communicate — on the same machine or across a network — without sockets, shared memory, or explicit synchronization code. The kernel handles the plumbing. You write to \\.\pipe\something, another process reads from it, and data flows.
The problem is what happens when that "something" is a service running as SYSTEM, and an attacker can either connect to it or — worse — *create* it before the legitimate service does.
The second scenario is called named pipe squatting, or pipe hijacking. The attack is elegant and brutal: an unprivileged process registers a pipe name before the privileged service does, the service connects as expected, and the attacker calls ImpersonateNamedPipeClient(). The kernel hands over a copy of the privileged token. Congratulations — you're SYSTEM.
This isn't theoretical. PetitPotam, the 2021 NTLM relay technique that lit up Active Directory environments, leveraged the LSARPC named pipe to coerce domain controllers into authenticating outbound. PrintNightmare's early variants moved through the spooler's named pipe interface. Go look at your Cobalt Strike documentation — default beacon profiles use named pipes (\\.\pipe\msagent_*, \\.\pipe\postex_*) for peer-to-peer C2 because they blend into legitimate Windows traffic and most EDR configurations don't log pipe creation events with any granularity.
## The Impersonation Chain Nobody Talks About
The most underappreciated attack path here isn't pipe squatting — it's impersonation chaining. Once an attacker has a SYSTEM token through pipe impersonation, they can use that token to create new processes, access protected registry hives, or pivot to network resources using that identity. The initial pipe compromise becomes a beachhead for everything downstream.
What makes this particularly sharp for defenders: the indicators are sparse. Pipe creation events live in ETW (Event Tracing for Windows), not in the Security event log most SIEMs ingest by default. Unless you're running Sysmon with pipe monitoring enabled (EventID 17 for pipe creation, EventID 18 for pipe connection), you're flying blind.
The ThreatLocker guidance identifies four controls worth thinking about:
Endpoint verification — confirm that the process connecting to a named pipe is actually who it claims to be, not just a process that knows the pipe name.
Command authorization — don't treat pipe communication as inherently trusted just because it's local IPC. Validate the content, not just the channel.
Strict input validation — named pipes used by services commonly accept structured messages. Attackers will fuzz those structures looking for parsing bugs that lead to memory corruption or logic bypasses.
Narrowly scoped privileges — services that communicate over pipes should run at the lowest privilege level their function requires. A named pipe server running as SYSTEM that only needs to query a local database should not be running as SYSTEM.
## Where This Shows Up in Real Environments
The environments most exposed to named pipe attacks share a few traits. First, they tend to have legacy software — applications written when "security" meant a login screen — that uses named pipes with permissive DACLs or world-readable ACLs. Second, they're running EDR configurations focused on process behavior and file writes, not on IPC monitoring. Third, their patch cadence on non-web-facing Windows services is measured in months, not weeks.
That profile matches a lot of industrial, healthcare, and government environments. It also matches any organization that's been through enough M&A to have subsidiaries still running Windows Server 2012.
The other high-risk category: developer workstations. Named pipe vulnerabilities in local service components — security tooling, development frameworks, update mechanisms — have been a reliable LPE vector for years. An attacker with phishing access to a dev machine who can escalate from user to SYSTEM has effectively compromised whatever that developer can reach with their credentials.
## What Defenders Should Actually Do
Sysmon pipe monitoring is non-negotiable if you don't have it. Add EventID 17 and EventID 18 to your collection; build alerts on pipe names matching known C2 patterns (a current list is maintained in the Sigma rules repository and various threat intel feeds).
Beyond detection, audit the DACLs on named pipes your services expose. pipelist.exe from Sysinternals and accesschk.exe will show you what's open and to whom. Named pipes that grant Everyone or Authenticated Users write access should be treated as vulnerabilities until proven otherwise.
For new development: if your application uses named pipes for IPC, implement server-side impersonation carefully. Call ImpersonateNamedPipeClient() only after validating the client, and revert to self immediately after the operation completes. The documentation makes this look optional. It is not.
---
## HackWire Analysis
Named pipe attacks are having a quiet renaissance, and the timing is not coincidental.
As EDR products have gotten better at catching process injection and reflective DLL loading, attackers have shifted lateral movement toward legitimate Windows IPC mechanisms — named pipes, COM objects, WMI subscriptions — because these generate less signal. You can move laterally through a named pipe connection and never touch disk, never spawn a child process, and never trigger a classic behavioral rule. The telemetry gap is real.
What's missing from most coverage of this topic: the connection to modern C2 frameworks. The default pipe names used by Cobalt Strike, Metasploit's Meterpreter, and Havoc C2 are documented and detectable — but only if you're collecting the right events. Organizations that haven't reviewed their Sysmon configuration in the last twelve months should assume they have this gap.
There's also a supply chain angle that deserves attention. Security software itself — AV engines, DLP agents, endpoint management tools — frequently exposes named pipes with elevated privilege. A vulnerability in those pipe interfaces doesn't just compromise the tool; it potentially hands an attacker a signed, trusted path to SYSTEM on every endpoint in the fleet. This has happened. It will happen again.
The practical action for security teams this week: run accesschk -w -l \pipe\* on a representative sample of endpoints and look for anything world-writable. What you find will be instructive.
— *HackWire Editorial*
---
## Related Coverage