Windows Named Pipe Attacks: How to Harden IPC and Detect Privilege Escalation via Weak DACLs

Named pipes are one of the oldest and most trusted interprocess communication (IPC) mechanisms in Windows — and one of the most abused. A recent analysis from ThreatLocker highlights what seasoned red teamers have known for years: when a privileged service exposes a named pipe with weak or absent access controls, any unprivileged process on the host can connect to it, send it commands, and in many cases coerce it into executing attacker-controlled operations with elevated privileges.

This is not a theoretical concern. Named pipe abuse sits at the heart of several well-documented attack techniques tracked by MITRE ATT&CK, including T1559 (Inter-Process Communication), T1134 (Access Token Manipulation), and the named-pipe impersonation primitive (T1134.001) that underpins the entire "Potato" family of privilege escalation tools — SweetPotato, GodPotato, PrintSpoofer, and their descendants. C2 frameworks like Cobalt Strike use named pipes for SMB beaconing and lateral movement. If your detection program treats named pipes as invisible plumbing, you have a blind spot that attackers actively exploit.

The defensive lesson from the ThreatLocker piece is straightforward: the pipe server is the trust boundary, and most pipe servers get it wrong. This post breaks down how these attacks work, how to find vulnerable pipes in your environment, and how to detect abuse in flight.

Technical Analysis: How Named Pipe Attacks Work

The Core Weakness

A Windows named pipe is created with CreateNamedPipe(), and the security descriptor applied at creation time determines who can connect. The failure modes are consistent across vulnerable services:

1. NULL or overly permissive DACL — the pipe allows Everyone or BUILTIN\Users write/connect access, meaning any local process (including malware running as a standard user) can open a handle and send data to a service running as SYSTEM.
2. No client identity verification — the pipe server never calls GetNamedPipeClientProcessId() or impersonates-then-verifies the client token, so it cannot distinguish a legitimate agent from arbitrary malware.
3. No command authorization or input validation — the server trusts whatever structured command arrives over the pipe and executes it without validating length, format, or whether the requesting identity is authorized for that operation.
4. Over-privileged service account — the service behind the pipe runs as SYSTEM or a high-privilege service account when it doesn't need to, so any command injection becomes instant privilege escalation.

The Attack Chains Defenders Should Model

Chain 1 — IPC command injection into a privileged service. An unprivileged attacker process connects to a vendor agent's pipe (backup agents, EDR management agents, updaters, and printer/spooler-adjacent services are frequent offenders), sends a crafted message, and the SYSTEM-level service executes it. ThreatLocker's guidance targets exactly this: the service must verify the client endpoint, authorize the specific command, validate all input, and run with narrowly scoped privileges.

Chain 2 — Named pipe impersonation (Potato-style). An attacker with SeImpersonatePrivilege (typical for service accounts post-webshell or post-service-compromise) coerces a SYSTEM process into connecting to an attacker-controlled pipe, then impersonates the connecting token via ImpersonateNamedPipeClient. The observable artifacts are consistent: a process creates a pipe, a SYSTEM process connects to it, and the creating process subsequently launches a child running as SYSTEM.

Chain 3 — C2 over named pipes. Cobalt Strike SMB beacons and similar tooling communicate over pipes with configurable but often-default names (\\.\pipe\msagent_*, \\.\pipe\postex_*, \\.\pipe\status_*). Pipe creation by non-system, non-service binaries in user-writable paths is a strong signal.

Exploitation Status

These are actively used techniques, not theoretical ones. Named pipe impersonation tooling is freely available, integrated into post-exploitation frameworks, and routinely observed in ransomware intrusions where initial access lands as a service account. Cobalt Strike SMB beacons remain a staple of hands-on-keyboard intrusions tracked by incident responders throughout 2025 and into 2026. There is no single CVE here — the exposure is architectural: permissive DACLs and missing client verification in third-party and in-house Windows services.

Auditing Your Environment: Find Weak Pipes Before Attackers Do

Before you can detect abuse, inventory what your estate exposes. Two questions matter: which pipes exist, and who can write to them.

Sysinternals pipelist.exe and accesschk.exe are the practitioner's tools of choice:

# Enumerate all named pipes on the host
.\pipelist.exe /accepteula

# Audit pipe security descriptors - flag pipes writable by Everyone or Users
.\accesschk.exe /accepteula -w \pipe\*

# PowerShell-native enumeration of pipes with owning processes
Get-ChildItem \\.\pipe\ | Select-Object Name, Length
Get-Process | Where-Object { $_.Name -match 'svchost|sqlservr|msedge|chrome' } |
    Select-Object Id, Name, Path

Any pipe backed by a service running as SYSTEM that accesschk reports as writable by Everyone, BUILTIN\Users, or NT AUTHORITY\Authenticated Users is a finding. Treat it like an exposed service account — because functionally, it is one.

For custom or third-party services you control, the fix is in the pipe creation code: apply an explicit security descriptor restricting access to the specific service identity or SID that should connect, call GetNamedPipeClientProcessId() and verify the client binary's signer and path before servicing requests, and reject malformed input before parsing.

Detection & Response

The following detections target the three attack chains above. Each has been tuned against realistic enterprise noise floors — but as with any behavioral rule, baseline your developer workstations and build servers, where pipe-heavy tooling is normal.

Sigma Rules

---
title: Suspicious Named Pipe Creation by Non-System Process
id: 9c1f2a7b-3e4d-4f8a-b6c5-2d1e0f9a8b7c
status: experimental
description: Detects creation of named pipes associated with Cobalt Strike SMB beacons and post-exploitation tooling by non-standard processes. Default pipe names are low-noise indicators; broad pipe creation by user-writable binaries is a strong hunting signal.
references:
  - https://attack.mitre.org/techniques/T1559/001/
  - https://www.bleepingcomputer.com/news/security/named-pipes-under-attack-securing-windows-interprocess-communication/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.execution
  - attack.t1559.001
  - attack.command_and_control
  - attack.t1071
logsource:
  category: pipe_created
  product: windows
detection:
  selection_known_c2:
    PipeName|contains:
      - '\msagent_'
      - '\postex_'
      - '\postex_ssh_'
      - '\status_'
      - '\MSSE-'
      - '\spoolss_'
  selection_suspicious_host:
    Image|startswith:
      - 'C:\Users\'
      - 'C:\ProgramData\'
      - 'C:\Windows\Temp\'
      - 'C:\Temp\'
  filter_legit:
    Image|endswith:
      - '\svchost.exe'
      - '\lsass.exe'
      - '\services.exe'
      - '\sqlservr.exe'
  condition: selection_known_c2 or (selection_suspicious_host and not filter_legit)
falsepositives:
  - Legitimate applications using matching pipe name prefixes (rare)
  - Internal tooling in ProgramData using IPC
level: high
---
title: Named Pipe Impersonation Privilege Escalation Pattern
id: 4b8e1d6c-7a2f-4c9e-8d3b-1f0a5e6c7d8e
status: experimental
description: Detects the named pipe impersonation pattern used by Potato-family privilege escalation tools - a process creating a pipe that a SYSTEM-level process connects to, followed by a child process spawned as SYSTEM.
references:
  - https://attack.mitre.org/techniques/T1134/001/
  - https://attack.mitre.org/techniques/T1068/
  - https://www.bleepingcomputer.com/news/security/named-pipes-under-attack-securing-windows-interprocess-communication/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.privilege_escalation
  - attack.t1134.001
  - attack.t1068
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    User|contains: 'SYSTEM'
    ParentImage|startswith:
      - 'C:\Users\'
      - 'C:\ProgramData\'
      - 'C:\Windows\Temp\'
      - 'C:\Windows\ServiceProfiles\'
  filter_service_control:
    ParentImage|endswith:
      - '\services.exe'
      - '\svchost.exe'
      - '\MsMpEng.exe'
      - '\wininit.exe'
  condition: selection and not filter_service_control
falsepositives:
  - Software deployment agents staging payloads under ProgramData
  - Legitimate installer behavior - baseline your software distribution tooling
level: high

KQL — Microsoft Sentinel / Defender

This query hunts for pipe creation events correlated with suspicious parent processes, plus the impersonation pattern of SYSTEM children spawned from user-context parents. It assumes Sysmon Event ID 17 (Pipe Created) forwarded via the SecurityEvent or WindowsEvent table, and Defender process telemetry via DeviceProcessEvents.

// Hunt 1: Named pipe creation matching known C2/post-ex patterns (Sysmon EID 17)
let KnownPipeNames = dynamic(["msagent_", "postex_", "status_", "MSSE-", "spoolss_"]);
Event
| where EventID == 17
| extend PipeName = tostring(parse_xml(EventData).EventData.Data.[7].["#text"])
| extend Image = tostring(parse_xml(EventData).EventData.Data.[3].["#text"])
| where PipeName has_any (KnownPipeNames)
   or (Image has_any ("C:\\Users\\", "C:\\ProgramData\\", "C:\\Windows\\Temp\\")
       and Image !has "svchost.exe")
| project TimeGenerated, Computer, Image, PipeName
| order by TimeGenerated desc;

// Hunt 2: Potato-style impersonation - SYSTEM child of user-context parent
DeviceProcessEvents
| where TimeGenerated > ago(24h)
| where InitiatingProcessAccountName !in~ ("system", "local service", "network service")
| where InitiatingProcessFolderPath has_any ("\\Users\\", "\\ProgramData\\", "\\Temp\\")
| where AccountName =~ "SYSTEM"
| where InitiatingProcessFileName !in~ ("services.exe", "svchost.exe", "MsMpEng.exe", "msiexec.exe")
| project TimeGenerated, DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine,
          FileName, ProcessCommandLine, AccountName
| order by TimeGenerated desc;

Velociraptor VQL

This artifact enumerates live named pipes on an endpoint and correlates them against running processes to surface pipes owned by binaries executing from user-writable locations — exactly the profile of C2 SMB beacons and impersonation staging.

-- Hunt for named pipes owned by processes running from user-writable paths
-- Surfaces C2 SMB beacons and Potato-style impersonation staging
LET procs = SELECT Pid, Name, Exe, CommandLine, Username FROM pslist()

SELECT Name AS PipeName,
       FullPath AS PipePath
FROM glob(globs='\\.\pipe\*')
WHERE PipeName =~ '(msagent_|postex_|status_|MSSE-|spoolss_)'
   OR PipeName !~ '(Crashpad|chrome|edge|discord|steam|WSL|TermApi)'
GROUP BY PipeName

-- Correlate: processes in user-writable paths with pipe-related activity
SELECT Pid, Name, Exe, CommandLine, Username, CreateTime
FROM pslist()
WHERE Exe =~ '(Users\\\\|ProgramData\\\\|Windows\\\\Temp\\\\)'
  AND Name !~ '(msiexec|setup|installer)'

Hardening Script — Audit Pipe Exposure at Scale

Run this across your estate (via your RMM, GPO startup script, or Defender for Endpoint Live Response) to enumerate pipes and flag services running as SYSTEM that expose IPC endpoints. The output gives your team a prioritized review list.

# Named Pipe Exposure Audit - run as Administrator
# Outputs a CSV of pipes and identifies SYSTEM services likely exposing IPC

$report = @()

# 1. Enumerate all named pipes on the host
$pipes = [System.IO.Directory]::GetFiles("\\.\pipe\")
foreach ($pipe in $pipes) {
    $report += [PSCustomObject]@{
        Computer   = $env:COMPUTERNAME
        PipeName   = $pipe
        Timestamp  = Get-Date -Format "yyyy-MM-dd HH:mm:ss"
    }
}

# 2. Identify services running as SYSTEM (prime privilege-escalation targets)
$systemServices = Get-CimInstance Win32_Service |
    Where-Object { $_.StartName -eq 'LocalSystem' -and $_.State -eq 'Running' } |
    Select-Object Name, DisplayName, PathName, ProcessId

Write-Host "[*] $($pipes.Count) named pipes enumerated" -ForegroundColor Cyan
Write-Host "[*] $($systemServices.Count) running SYSTEM services - review their IPC endpoints" -ForegroundColor Yellow
$systemServices | Format-Table -AutoSize

# 3. Flag pipes matching known C2 / post-exploitation patterns
$suspiciousPatterns = 'msagent_|postex_|status_|MSSE-|spoolss_'
$flagged = $report | Where-Object { $_.PipeName -match $suspiciousPatterns }
if ($flagged) {
    Write-Host "[!] ALERT: Pipes matching known C2 patterns found:" -ForegroundColor Red
    $flagged | Format-Table -AutoSize
}

# 4. Export for central collection
$report | Export-Csv -Path "C:\ProgramData\PipeAudit_$env:COMPUTERNAME.csv" -NoTypeInformation
Write-Host "[+] Report written to C:\ProgramData\PipeAudit_$env:COMPUTERNAME.csv"

For deeper DACL review on specific pipes, follow up interactively with accesschk.exe -w \pipe\<name> — the remediation script above inventories; Sysinternals verifies.

Remediation: Closing the Pipe Attack Surface

There is no patch for this — it is a class of design weakness, not a single bug. Remediation is a layered engineering effort:

1. Constrain pipe access at creation (for software you build or influence). Require explicit security descriptors on every CreateNamedPipe() call. Access should be scoped to the exact SID of the legitimate client — never Everyone, never Authenticated Users for a privileged service endpoint. Push this requirement into secure code review and vendor security questionnaires.

2. Verify the client before servicing the request. Pipe servers must call GetNamedPipeClientProcessId(), resolve the PID to a binary path and signer, and reject clients that fail verification. This is the single most effective control against IPC command injection — an attacker can open the pipe but cannot impersonate a signed, path-verified client process.

3. Authorize commands and validate input rigorously. Every message over the pipe is untrusted input. Enforce strict schema validation, length limits, and per-command authorization checks against the verified client identity. A pipe handler that blindly deserializes and dispatches is a command-and-control channel waiting to be used.

4. Reduce service privilege. Audit services running as SYSTEM that expose pipes. Where full SYSTEM is not required, migrate to a least-privilege service account. A compromised pipe handler running as a constrained service account is an incident; one running as SYSTEM is a domain compromise in waiting.

5. Neutralize impersonation primitives. The Potato family depends on SeImpersonatePrivilege held by service accounts. Inventory which accounts hold it (ntrights, local security policy, or GPO review) and strip it where not operationally required. Ensure you are current on Windows updates — Microsoft has progressively hardened DCOM activation paths that these tools abuse, and unpatched systems remain fully exposed.

6. Deploy application control on pipe-connected services. This is where ThreatLocker's own approach — default-deny application control with ringfencing — maps directly to the problem: even if a low-privilege process can reach a privileged pipe, controlling what the privileged service is permitted to execute and which applications can communicate with it sharply limits blast radius. Whether you use ThreatLocker, WDAC, or AppLocker, application allowlisting on servers and sensitive workstations is the backstop for IPC abuse.

7. Operationalize the detections. Deploy Sysmon with pipe creation (Event ID 17) and pipe connection (Event ID 18) logging across servers first, then workstations. Pipe telemetry is high-value and relatively low-volume compared to process or network events — one of the better cost-to-signal ratios in Windows logging.

The Bottom Line

Named pipes are invisible to most security tooling and familiar to every competent offensive operator. The ThreatLocker analysis is a useful reminder that endpoint hardening isn't just about binaries and network sockets — the IPC layer between your own processes is a trust boundary, and attackers treat it as one. Inventory your pipes, verify your privileged services' access controls, strip unnecessary impersonation privileges, and get pipe telemetry into your SIEM. The detections above will catch the common tooling; the hardening will catch the patient adversary who brings their own.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub