T1559

Inter-Process Communication

Execution Last updated:

Adversaries may abuse inter-process communication (IPC) mechanisms for local code execution, command-and-control channel establishment, or lateral movement. IPC mechanisms allow processes to share data, communicate, or synchronize execution. On Windows, adversaries commonly abuse named pipes to relay commands between C2 framework components (Havoc SMB demon, Cobalt Strike pipe-based beacons, Metasploit named pipe stagers), move data between kernel and user mode components (Uroburos/Snake malware), or pipe output from arbitrary commands to a controlling process (LunarWeb, ROADSWEEP, OilBooster). The IPC$ administrative share provides a network-accessible path for named pipe connections, enabling cross-host pipe-based C2 (HyperStack, Cobalt Strike lateral movement). On Linux and macOS, adversaries leverage Unix domain sockets (PITSTOP), shared memory segments via shmget (RotaJakiro), and anonymous pipes for inter-process communication. Medusa Ransomware and Cyclops Blink use the CreatePipe API to coordinate parallel operations. Raspberry Robin embeds a Tor client that communicates with its main payload via shared process memory. Detection focuses on named pipe creation by high-risk processes, non-standard pipe names matching known C2 framework patterns, and unusual network-based IPC$ share access.

What is T1559 Inter-Process Communication?

Inter-Process Communication (T1559) maps to the Execution tactic — the adversary is trying to run malicious code in MITRE ATT&CK.

This page provides production-ready detection logic for Inter-Process Communication, covering the data sources and telemetry it touches: Network Share: Network Share Access, Network Traffic: Network Connection Creation, Windows Security Event ID 5145, Microsoft Defender for Endpoint DeviceNetworkEvents. The queries below are rated high severity at medium confidence, and ship for 7 SIEM platforms — KQL, SPL, Elastic, QRadar, Sumo, YARA-L, LogScale.

MITRE ATT&CK

Tactic
Execution
Technique
T1559 Inter-Process Communication
Canonical reference
https://attack.mitre.org/techniques/T1559/
Microsoft Sentinel / Defender
kusto 
let SuspiciousPipePatterns = dynamic([
    "postex_", "meterpreter", "msf-pipe", "cobaltstrike", "havoc_",
    "MSSE-", "dsniff", "win_svc_pipe", "agent_pipe", "status_",
    "msagent_", "mojo_fuzz", "winsock_pipe"
]);
let CommonSystemPipes = dynamic([
    "srvsvc", "wkssvc", "netlogon", "samr", "lsarpc", "spoolss",
    "browser", "epmapper", "MsFteWds", "atsvc", "trkwks", "W32TIME_ALT",
    "svcctl", "eventlog", "InitShutdown", "winreg", "protected_storage",
    "ROUTER", "LSM_API_service", "IPCDump"
]);
let HighRiskProcesses = dynamic([
    "rundll32.exe", "regsvr32.exe", "mshta.exe", "wscript.exe", "cscript.exe",
    "powershell.exe", "pwsh.exe", "certutil.exe", "msiexec.exe", "dllhost.exe"
]);
// Detection 1: Non-standard named pipe access over IPC$ network share (Security Event 5145)
// This covers remote lateral movement and C2 relaying via named pipe tunneling
let NetworkIPCPipeAccess = SecurityEvent
| where TimeGenerated > ago(24h)
| where EventID == 5145
| where ShareName contains "IPC$"
| where RelativeTargetName !in~ (CommonSystemPipes)
| where IpAddress !in ("127.0.0.1", "::1", "-", "0.0.0.0")
| where SubjectUserName !endswith "$"  // Exclude expected machine account traffic
| extend PipeName = tostring(RelativeTargetName)
| extend IsSuspiciousPipeName = PipeName has_any (SuspiciousPipePatterns)
| extend DetectionSource = "IPC$NetworkPipeAccess"
| project
    TimeGenerated,
    Computer,
    AccountName = SubjectUserName,
    Domain = SubjectDomainName,
    PipeName,
    IsSuspiciousPipeName,
    DetectionSource,
    SourceAddress = IpAddress,
    SourcePort = IpPort,
    AccessMask;
// Detection 2: High-risk process initiating SMB connections (potential pipe tunnel establishment)
let HighRiskSMBPipeConn = DeviceNetworkEvents
| where Timestamp > ago(24h)
| where RemotePort == 445
| where InitiatingProcessFileName has_any (HighRiskProcesses)
| extend PipeName = ""
| extend IsSuspiciousPipeName = false
| extend DetectionSource = "HighRiskProcessSMBPipe"
| project
    TimeGenerated = Timestamp,
    Computer = DeviceName,
    AccountName,
    Domain = "",
    PipeName,
    IsSuspiciousPipeName,
    DetectionSource,
    SourceAddress = LocalIP,
    SourcePort = LocalPort,
    AccessMask = "",
    InitiatingProcess = InitiatingProcessFileName,
    InitiatingCommandLine = InitiatingProcessCommandLine,
    RemoteIP,
    RemotePort;
// Combine both detections
NetworkIPCPipeAccess
| extend InitiatingProcess = "", InitiatingCommandLine = "", RemoteIP = "", RemotePort = int(null)
| union HighRiskSMBPipeConn
| sort by TimeGenerated desc

Detects suspicious inter-process communication abuse via two complementary methods. First, monitors Security Event ID 5145 (network share object access) for access to non-standard named pipes over the IPC$ share from non-machine accounts and non-loopback addresses — the primary signal for C2 frameworks using named pipe tunneling for lateral movement (Cobalt Strike, Havoc, Metasploit). Standard Windows system pipes (srvsvc, lsarpc, samr, etc.) are excluded to reduce noise. Known malicious pipe name patterns are flagged with IsSuspiciousPipeName=true for immediate escalation. Second, identifies high-risk LOLBin and scripting processes initiating SMB connections to port 445, which may indicate pipe-based C2 channel setup or remote pipe access for lateral movement. Requires Security Event auditing with 'Detailed File Share' audit policy enabled.

high severity medium confidence

Data Sources

Network Share: Network Share Access Network Traffic: Network Connection Creation Windows Security Event ID 5145 Microsoft Defender for Endpoint DeviceNetworkEvents

Required Tables

SecurityEvent DeviceNetworkEvents

False Positives

  • Legitimate administrative tools using IPC$ for remote management — PsExec, SC.exe, remote registry operations, and WMI will access standard pipes like svcctl and winreg over IPC$
  • Backup and monitoring agents (Veeam, Zabbix, SolarWinds) that use named pipes for inter-process coordination or query Windows services via SMB
  • Software deployment systems (SCCM, Intune) connecting to IPC$ shares on managed endpoints for policy application and software push installations
  • Database services (SQL Server) using named pipes as an alternative client connection transport, especially in environments with pipe-based connection strings
  • IT automation platforms (Ansible WinRM, Chef, Puppet) that use SMB and named pipes for remote configuration management on Windows targets
  • EDR and AV products that use named pipes for kernel-user communication may generate pipe creation events from svchost.exe or their own service processes

Sigma rule & cross-platform mapping

The detection logic for Inter-Process Communication (T1559) above is provided in a vendor-neutral form so you can deploy it on any SIEM. The same logic is shipped here as native KQL (Microsoft Sentinel / Defender), SPL (Splunk), Elastic (Elastic Security (EQL)), QRadar (IBM QRadar (AQL)), Sumo (Sumo Logic CSE), YARA-L (Google Chronicle / SecOps), LogScale (CrowdStrike LogScale (CQL)) queries. In Sigma terms, this detection targets the following logsource: 

logsource:
  category: network_connection
  product: windows

Browse the community-maintained Sigma rules for this technique:

SigmaHQ rules for T1559 Sigma rules on detection.fyi

Platform-specific guides for T1559

Detect in Microsoft Sentinel (KQL) Detect in Splunk (SPL) Detect in Elastic Security (Elastic) Detect in IBM QRadar (QRadar) Detect in Sumo Logic CSE (Sumo) Detect in Google Chronicle (YARA-L) Detect in CrowdStrike LogScale (LogScale)
Last updated: 2026-04-21 Research depth: deep
References (9)

Testing Methodology

Validate this detection against 5 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.

  1. Test 1Named Pipe Server Creation via PowerShell (Simulated C2 Listener)

    Expected signal: Sysmon Event ID 17 (PipeEvent - CreatePipe): Image=powershell.exe, PipeName=argus_ipc_test_pipe, ProcessId=<pid>, User=<current user>. Security Event 4688 (if process command line auditing is enabled) for the PowerShell invocation.

  2. Test 2Named Pipe with Known C2 Framework Pattern (Cobalt Strike postex_ simulation)

    Expected signal: Sysmon Event ID 17 (PipeEvent - CreatePipe): Image=powershell.exe, PipeName=postex_ssh_8a3f, ProcessId=<pid>. This is the highest-confidence detection trigger — the pipe name exactly matches the Cobalt Strike postex_ pattern.

  3. Test 3IPC$ Named Share Access via Net Use (Remote Pipe Connection Simulation)

    Expected signal: Windows Security Event ID 5145: ShareName=\\*\IPC$, IpAddress=127.0.0.1 (loopback — note: the detection filters loopback by default; modify the IpAddress filter to include 127.0.0.1 to capture this test). Security Event 4624 (logon) for the SMB session establishment. Sysmon Event ID 3 for the network connection on port 445 from cmd.exe.

  4. Test 4Anonymous Pipe Process Output Capture (OilBooster/ROADSWEEP Pattern)

    Expected signal: Sysmon Event ID 1 (Process Create): Parent Image=powershell.exe, Child Image=whoami.exe, ParentCommandLine contains 'RedirectStandardOutput'. Security Event 4688 (if command line auditing enabled) for whoami.exe creation with parent PID of the PowerShell process. Note: anonymous pipes do NOT generate Sysmon Event ID 17 — they are transient kernel objects with no name.

  5. Test 5Unix Domain Socket Listener (Linux IPC Abuse Simulation)

    Expected signal: Linux auditd (if configured with AF_UNIX socket rules): SYSCALL record for socket() with a0=1 (AF_UNIX), SYSCALL record for bind() with the socket path, SYSCALL record for listen(). Syslog/EDR process creation event for python3 with the IPC-related command arguments. File creation event for /tmp/argus_uds_test.sock. Check with: 'lsof /tmp/argus_uds_test.sock' or 'ss -xln | grep argus' while the script is running.

Response Playbook

Triage

  1. Identify and classify the pipe name: Is it a random GUID-style name (common for legitimate apps), a human-readable name matching known C2 patterns (postex_, meterpreter, cobaltstrike), or a known Windows system pipe? Known C2 pipe names are immediate escalation triggers.
  2. Examine the process creating or accessing the pipe: What is the full process tree (grandparent → parent → child)? Was the process spawned from a document (Word, Excel spawning powershell.exe → named pipe creation is high-risk), a web browser, a scheduled task, or a service?
  3. Determine if the pipe access is local-only or network-based: SecurityEvent 5145 with a non-loopback SourceAddress confirms network-based IPC access. Network-based pipe access between hosts requires an authenticated SMB connection first — check for corresponding logon events (4624/4648) from the same source address.
  4. Check for concurrent process injection indicators: Did the process creating the pipe also call CreateRemoteThread (Sysmon Event ID 8), OpenProcess, or WriteProcessMemory shortly before or after pipe creation? This pattern indicates injection staging via named pipe.
  5. Look for follow-on activity from the pipe-creating process: subsequent network connections to external IPs (C2 beaconing), file writes to temp or startup directories, new process creation with unusual parents, or registry modifications for persistence.
  6. Assess the user context: Is this a service account, interactive user, or SYSTEM? Does the user's role explain the observed pipe activity? Service accounts creating unusual pipes warrant escalation even without other indicators.

Containment

  1. If a known C2 framework pipe name is confirmed (postex_, meterpreter, havoc_): immediately isolate the endpoint using EDR network isolation or emergency VLAN change to cut the C2 channel without losing the endpoint for forensic collection.
  2. If network-based IPC$ pipe access is confirmed from an unexpected source: block the source IP at the perimeter firewall and check all hosts that received connections from that source in the same time window for lateral movement.
  3. Kill the suspicious process and its children: use EDR or Task Manager to terminate, and document the PID, parent PID, command line, and loaded modules before termination.
  4. If compromised credentials are suspected (pipe-based lateral movement often follows credential theft): immediately disable the affected account in Active Directory, revoke all active sessions and Kerberos tickets, and force a password reset.
  5. Preserve pipe artifacts: before killing the process, if memory forensics is feasible, capture a memory dump of the suspicious process to recover pipe handles, in-memory payloads, and C2 configuration.
  6. If Linux Unix domain socket abuse is suspected (PITSTOP pattern at /data/runtime/cockpit/wd.fd or similar): identify the socket file with 'lsof | grep unix', identify the owner process, and terminate it. Check /proc/<pid>/fd for open file descriptors.

Evidence Collection

  1. Sysmon Event ID 17 and 18 from the affected endpoint for the detection timeframe: provides pipe names, creating/connecting process images, PIDs, and timestamps.
  2. Sysmon Event ID 1 (Process Create) for the pipe-creating process and its parent: reveals the full command line, parent process, and user context that explains why the pipe was created.
  3. Sysmon Event ID 3 (Network Connection) from the suspicious process: identifies outbound C2 connections or SMB connections to other hosts that coincide with pipe creation.
  4. Sysmon Event ID 8 (CreateRemoteThread): if found from the same process or targeting the same process, confirms code injection using the named pipe as a staging mechanism.
  5. Windows Security Event ID 5145 from the target host: confirms which named pipe names were accessed over the network, from which source IPs, and by which accounts.
  6. Windows Security Event IDs 4624/4648 from the target host correlating with pipe access timestamps: identifies the authentication mechanism used to establish the SMB session before pipe access.
  7. Process memory dump of the suspicious process (procdump.exe -ma <pid> or EDR-native collection): may contain in-memory payload, C2 configuration (server address, port, jitter), and pipe communication buffers.
  8. Linux: /proc/<pid>/fd to enumerate open pipe file descriptors; auditd logs for socket() and connect() syscalls if auditd rules cover SOCK_STREAM/AF_UNIX; /tmp and /run directories for Unix domain socket files left by malware.

Escalation Criteria

  • ! Named pipe name exactly matches a known C2 framework pattern: postex_*, meterpreter, MSSE-*, cobaltstrike, havoc_* — treat as confirmed compromise regardless of other context.
  • ! Network-based IPC$ pipe access originating from a non-administrative host or external IP — this indicates an attacker using a compromised foothold to move laterally via named pipe tunneling.
  • ! Office application (Word, Excel, Outlook) or browser process is observed creating a non-standard named pipe — strongly indicates exploitation of a document macro, browser vulnerability, or loaded malicious DLL.
  • ! Named pipe creation immediately followed by CreateRemoteThread (Sysmon Event ID 8) targeting a different process — confirms code injection staged through a named pipe.
  • ! Multiple hosts in the environment show the same non-standard pipe name within a short window — indicates automated lateral movement or worm-like propagation using pipe-based C2.
  • ! A SYSTEM-context process creates a non-standard named pipe with no corresponding legitimate service — may indicate privilege escalation via named pipe impersonation (potato-style exploits) combined with T1559.

Investigation Guide

Forensic Artifacts

  • > Windows Object Namespace \Device\NamedPipe\: live pipe enumeration using Sysinternals WinObj.exe or Process Monitor filter 'Path contains \pipe\' shows all active named pipe instances and their owner processes at time of investigation.
  • > Sysmon Event Log (Microsoft-Windows-Sysmon/Operational): Event IDs 17 and 18 provide historical record of pipe creation and connection with process context; requires Sysmon PipeEvent rules enabled.
  • > Windows Security Event Log: Event ID 5145 (Detailed File Share audit) records named pipe access over IPC$; must have 'Audit Detailed File Share' GPO setting enabled.
  • > ETW provider Microsoft-Windows-Kernel-File: captures CreateNamedPipe and related kernel-level file system operations on the \Device\NamedPipe\ path; accessible via WPR, xperf, or third-party ETW consumers.
  • > Process memory (live or dump): named pipe handles appear in the process handle table; in-memory C2 configuration for pipe-based implants often contains the pipe name, server, and connection parameters in plaintext or lightly encoded form.
  • > Linux /proc filesystem: /proc/<pid>/net/unix lists all Unix domain sockets created by a process; /proc/<pid>/fd shows symbolic links to pipe file descriptors (pipe:[inode]) for anonymous pipes.
  • > Linux auditd: syscall rules for socket() with AF_UNIX family, bind(), connect() on socket paths, and shmget()/shmat() for shared memory creation capture IPC activity at the kernel level; configure with '-a always,exit -F arch=b64 -S socket -F a0=1 -k unix_socket'.
  • > Windows Prefetch files (C:\Windows\Prefetch\): the prefetch file for the suspicious process records DLL load order and file paths accessed, which may include pipe paths referenced during execution.

Tuning Guidance

Begin by enabling the required audit sources: (1) Windows 'Detailed File Share' audit policy must be enabled (auditpol /set /subcategory:'Detailed File Share' /success:enable) for SecurityEvent 5145 to fire; (2) Sysmon must be configured with PipeEvent rules — add <PipeEvent onmatch='exclude'> with rules excluding Chrome, Edge, SQL Server, and known AV product pipe patterns. For the KQL detection, build an organization-specific allowlist of expected IPC$ pipe access patterns from your management tooling (SCCM, WSUS, backup agents) by running the query with the machine account and system pipe filters removed for 7 days in observation mode, then adding observed legitimate patterns to the CommonSystemPipes list. For the SPL detection, the RiskScore threshold of 2 may produce too many alerts in environments with heavy development tool usage — consider raising to 3 and requiring SuspiciousCreator=1 OR SuspiciousCreator=0 AND SuspiciousPipeName=1. Chromium-based browser pipe volume is the largest source of false positives in pipe monitoring; add an exclusion for any pipe name matching '^\\mojo\.' to eliminate Chrome IPC noise. In environments using SQL Server with named pipe transport, add exclusion patterns for 'sql\\query' and 'MSSQL$' pipe prefixes. For Linux/macOS coverage of Unix domain socket and shared memory abuse (RotaJakiro shmget pattern, PITSTOP Unix socket), consider ingesting auditd logs and writing Syslog-based detections for socket() syscalls with AF_UNIX family and shmget() calls from unexpected process contexts.

Hunting Queries

Hunt for accounts or source IPs accessing an unusually broad variety of named pipes via IPC$ across multiple target hosts. Legitimate administrative tools typically access a small, consistent set of known system pipes. An account accessing 5+ distinct non-system pipes or reaching 3+ target hosts via IPC$ named pipes is a strong indicator of lateral movement using pipe-based C2 relay (HyperStack pattern) or automated credential-based access.

Hunting — KQL
kql 
// Hunt for accounts accessing an unusual breadth of named pipes over IPC$ (lateral movement pattern)
SecurityEvent
| where TimeGenerated > ago(7d)
| where EventID == 5145
| where ShareName contains "IPC$"
| where IpAddress !in ("127.0.0.1", "::1", "-", "0.0.0.0")
| where SubjectUserName !endswith "$"
| summarize
    TotalAccesses = count(),
    UniquePipes = dcount(RelativeTargetName),
    UniqueTargetHosts = dcount(Computer),
    PipeNames = make_set(RelativeTargetName, 20),
    TargetHosts = make_set(Computer, 10),
    FirstSeen = min(TimeGenerated),
    LastSeen = max(TimeGenerated)
    by SubjectUserName, SubjectDomainName, IpAddress
| where UniquePipes > 5 or UniqueTargetHosts >= 3
| sort by UniqueTargetHosts desc, UniquePipes desc
Hunting — SPL
spl 
index=wineventlog sourcetype="WinEventLog:Security" EventCode=5145
| rex field=_raw "Account Name:\\s+(?P<AccountName>[^\r\n]+)"
| rex field=_raw "Relative Target Name:\\s+(?P<PipeName>[^\r\n]+)"
| rex field=_raw "Source Address:\\s+(?P<SourceIP>[^\r\n]+)"
| rex field=_raw "Share Name:\\s+(?P<ShareName>[^\r\n]+)"
| where like(ShareName, "%IPC$%")
| where NOT (SourceIP="127.0.0.1" OR SourceIP="::1" OR SourceIP="-")
| where NOT match(AccountName, "\\$$")
| stats dc(PipeName) as UniquePipes, dc(host) as UniqueHosts, count as TotalAccess, values(PipeName) as PipeNames by AccountName, SourceIP
| where UniquePipes > 5 OR UniqueHosts >= 3
| sort - UniqueHosts

Hunt for processes generating unusually high volumes of named pipe operations or creating pipes across many distinct endpoints. Legitimate applications have predictable, low-volume pipe usage. C2 implants that beacon via named pipes (Cobalt Strike SMB beacon, Havoc SMB demon) create and destroy pipe instances on each check-in cycle, producing elevated PipeOps counts. An implant deployed to multiple hosts will show the same Image path creating pipes across many UniqueHosts.

Hunting — KQL
kql 
// Hunt for unusual processes creating high volumes of named pipes (C2 check-in or beacon pattern)
// Uses DeviceProcessEvents to find processes whose command lines reference pipe paths
DeviceProcessEvents
| where Timestamp > ago(7d)
| where ProcessCommandLine has "pipe" or ProcessCommandLine has "\\\\.\\pipe"
| where FileName !in~ ("cmd.exe", "powershell.exe", "pwsh.exe")  // Will catch many FPs; tune per env
| summarize
    Count = count(),
    Devices = dcount(DeviceName),
    Commands = make_set(ProcessCommandLine, 5),
    FirstSeen = min(Timestamp),
    LastSeen = max(Timestamp)
    by FileName, InitiatingProcessFileName, AccountName
| where Count > 10 or Devices > 3
| sort by Count desc
Hunting — SPL
spl 
index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" (EventCode=17 OR EventCode=18)
| stats count as PipeOps, dc(PipeName) as UniquePipes, dc(host) as UniqueHosts, values(PipeName) as PipeNames by Image
| eval SuspiciousVolume=if(PipeOps > 100 AND UniquePipes > 10, 1, 0)
| eval SuspiciousSpread=if(UniqueHosts > 5, 1, 0)
| where SuspiciousVolume=1 OR SuspiciousSpread=1
| sort - PipeOps

Hunt for Office applications and document readers creating unexpected named pipes. While legitimate Office inter-process communication uses known OfficeClickToRun and similar pipes, macros executing shellcode or exploits often stage their payloads via named pipes created in the context of the Office process. Finding winword.exe, excel.exe, or Acrobat creating pipe names that don't match known Office pipe patterns, or spawning scripting processes (cmd.exe, powershell.exe) that then create pipes, is a high-confidence indicator of malicious document exploitation.

Hunting — KQL
kql 
// Hunt for Office or PDF applications creating non-standard named pipes (macro/exploit execution via IPC)
let OfficeAndDocApps = dynamic([
    "winword.exe", "excel.exe", "powerpnt.exe", "outlook.exe",
    "acrord32.exe", "acrobat.exe", "mspub.exe", "onenote.exe"
]);
let KnownOfficePipes = dynamic([
    "OfficeClickToRun", "MicrosoftOffice", "GoogleUpdatePipe"
]);
DeviceProcessEvents
| where Timestamp > ago(7d)
| where InitiatingProcessFileName has_any (OfficeAndDocApps)
| where FileName in~ ("powershell.exe", "pwsh.exe", "cmd.exe", "wscript.exe",
                       "cscript.exe", "mshta.exe", "rundll32.exe", "regsvr32.exe")
| where InitiatingProcessCommandLine !has "OfficeClickToRun"
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine,
         InitiatingProcessFileName, InitiatingProcessCommandLine
| sort by Timestamp desc
Hunting — SPL
spl 
index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" (EventCode=17 OR EventCode=18)
| where match(lower(Image), "(winword\.exe|excel\.exe|powerpnt\.exe|outlook\.exe|acrord32\.exe|acrobat\.exe|onenote\.exe)")
| where NOT match(lower(PipeName), "(officeclicktorun|microsoftoffice|googleupdate)")
| table _time, host, Image, PipeName, ProcessId, User
| sort - _time

Atomic Red Team Tests

Test 1 Named Pipe Server Creation via PowerShell (Simulated C2 Listener)
windows

Creates a named pipe server using the .NET System.IO.Pipes.NamedPipeServerStream class directly from PowerShell. This simulates the pattern used by C2 frameworks and malware (Havoc SMB demon, Cyclops Blink, TONESHELL) that create named pipe listeners waiting for connections from other processes or from remote systems via IPC$. The pipe is created, held open for 5 seconds to allow Sysmon Event ID 17 to fire, then cleanly disposed.

Command

powershell 
powershell.exe -NoProfile -Command "$pipe = New-Object System.IO.Pipes.NamedPipeServerStream('argus_ipc_test_pipe', [System.IO.Pipes.PipeDirection]::InOut, 1, [System.IO.Pipes.PipeTransmissionMode]::Byte, [System.IO.Pipes.PipeOptions]::Asynchronous); Write-Host 'Pipe created: argus_ipc_test_pipe'; Start-Sleep -Seconds 5; $pipe.Dispose(); Write-Host 'Pipe disposed'"

Expected Telemetry

Sysmon Event ID 17 (PipeEvent - CreatePipe): Image=powershell.exe, PipeName=argus_ipc_test_pipe, ProcessId=<pid>, User=<current user>. Security Event 4688 (if process command line auditing is enabled) for the PowerShell invocation.

Expected Detection

SPL: EventCode=17, PipeName='argus_ipc_test_pipe', SuspiciousCreator=1 (powershell.exe), KnownSystemPipe=0, RiskScore=3 (SuspiciousCreator*2 + 1 for non-system pipe). KQL: Would appear in HighRiskSMBPipeConn if a subsequent SMB connection is made; the pipe creation itself requires Sysmon data in Sentinel via the SysmonEvent table or custom DCR ingestion.

Test 2 Named Pipe with Known C2 Framework Pattern (Cobalt Strike postex_ simulation)
windows

Creates a named pipe using the well-known 'postex_' prefix associated with Cobalt Strike post-exploitation named pipe beacons. Cobalt Strike's SMB listener creates pipes with names like 'postex_ssh_<random>' and 'postex_<random>'. This test exercises the SuspiciousPipeName detection path. The pipe is held for 8 seconds and then disposed. No real C2 payload is involved.

Command

powershell 
powershell.exe -NoProfile -Command "$pipe = New-Object System.IO.Pipes.NamedPipeServerStream('postex_ssh_8a3f', [System.IO.Pipes.PipeDirection]::InOut); Write-Host 'C2-style pipe created: postex_ssh_8a3f'; Start-Sleep -Seconds 8; $pipe.Dispose(); Write-Host 'Done'"

Expected Telemetry

Sysmon Event ID 17 (PipeEvent - CreatePipe): Image=powershell.exe, PipeName=postex_ssh_8a3f, ProcessId=<pid>. This is the highest-confidence detection trigger — the pipe name exactly matches the Cobalt Strike postex_ pattern.

Expected Detection

SPL: EventCode=17, SuspiciousPipeName=1 (matches 'postex_' pattern), SuspiciousCreator=1 (powershell.exe), RiskScore=7 (4+2+1). This should immediately trigger as the highest-confidence pipe-based C2 indicator. KQL: IsSuspiciousPipeName=true in NetworkIPCPipeAccess if accessed over the network.

Test 3 IPC$ Named Share Access via Net Use (Remote Pipe Connection Simulation)
windows

Uses the built-in 'net use' command to attempt an SMB connection to the local IPC$ share, simulating the first step an adversary takes when establishing a remote named pipe connection (as performed by HyperStack, PsExec-style lateral movement, and tools accessing the IPC$ share for named pipe tunneling). The connection attempt to localhost will succeed on most Windows systems. Also triggers via 'dir' against IPC$ which lists accessible named pipes.

Command

powershell 
net use \\127.0.0.1\IPC$ && dir \\127.0.0.1\IPC$

Cleanup

powershell 
net use \\127.0.0.1\IPC$ /delete /yes

Expected Telemetry

Windows Security Event ID 5145: ShareName=\\*\IPC$, IpAddress=127.0.0.1 (loopback — note: the detection filters loopback by default; modify the IpAddress filter to include 127.0.0.1 to capture this test). Security Event 4624 (logon) for the SMB session establishment. Sysmon Event ID 3 for the network connection on port 445 from cmd.exe.

Expected Detection

KQL: The HighRiskSMBPipeConn branch will NOT fire for 'net use' (net.exe is not in HighRiskProcesses list). The NetworkIPCPipeAccess branch will fire if the loopback filter is relaxed. To observe this detection at a non-loopback address, run the command targeting a different host where you have SMB access. The test validates that SMB session + IPC$ access telemetry is generated correctly.

Test 4 Anonymous Pipe Process Output Capture (OilBooster/ROADSWEEP Pattern)
windows

Uses PowerShell's ProcessStartInfo with RedirectStandardOutput=true to create an anonymous pipe connecting the calling process to a child process, then reads the command output via the pipe. This replicates the pattern used by OilBooster (reads cmd execution results via unnamed pipe) and ROADSWEEP (pipes command output to a targeted process). The anonymous pipe itself does not appear as a named object and will not trigger Sysmon Event ID 17, but the parent-child process relationship and the unusual output redirection pattern from a scripting engine is detectable via process creation events.

Command

powershell 
powershell.exe -NoProfile -Command "$pinfo = New-Object System.Diagnostics.ProcessStartInfo; $pinfo.FileName = 'whoami.exe'; $pinfo.RedirectStandardOutput = $true; $pinfo.UseShellExecute = $false; $pinfo.CreateNoWindow = $true; $p = New-Object System.Diagnostics.Process; $p.StartInfo = $pinfo; $p.Start() | Out-Null; $output = $p.StandardOutput.ReadToEnd(); $p.WaitForExit(); Write-Host ('IPC pipe output: ' + $output)"

Expected Telemetry

Sysmon Event ID 1 (Process Create): Parent Image=powershell.exe, Child Image=whoami.exe, ParentCommandLine contains 'RedirectStandardOutput'. Security Event 4688 (if command line auditing enabled) for whoami.exe creation with parent PID of the PowerShell process. Note: anonymous pipes do NOT generate Sysmon Event ID 17 — they are transient kernel objects with no name.

Expected Detection

This pattern is detected by parent-child process monitoring (T1059.001) rather than the named pipe SPL query. The KQL detection's HighRiskSMBPipeConn won't fire (no SMB connection). Detection relies on PowerShell process spawning unexpected children — covered by process creation detections. Documents the telemetry gap: anonymous pipes are NOT captured by Sysmon Event ID 17/18.

Test 5 Unix Domain Socket Listener (Linux IPC Abuse Simulation)
linux

Creates a Unix domain socket listener at /tmp/argus_uds_test.sock using Python3, simulating the pattern used by PITSTOP malware which listens on the Unix domain socket at /data/runtime/cockpit/wd.fd for command input. The socket is bound and set to listen, then held open for 10 seconds. This tests whether Unix domain socket creation by unexpected processes is detected via auditd or EDR telemetry.

Command

bash 
python3 -c "
import socket, os, time
sock_path = '/tmp/argus_uds_test.sock'
if os.path.exists(sock_path): os.unlink(sock_path)
s = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)
s.bind(sock_path)
s.listen(1)
print('Unix domain socket listening at', sock_path)
time.sleep(10)
s.close()
os.unlink(sock_path)
print('Socket closed')
"

Cleanup

bash 
rm -f /tmp/argus_uds_test.sock

Expected Telemetry

Linux auditd (if configured with AF_UNIX socket rules): SYSCALL record for socket() with a0=1 (AF_UNIX), SYSCALL record for bind() with the socket path, SYSCALL record for listen(). Syslog/EDR process creation event for python3 with the IPC-related command arguments. File creation event for /tmp/argus_uds_test.sock. Check with: 'lsof /tmp/argus_uds_test.sock' or 'ss -xln | grep argus' while the script is running.

Expected Detection

Detectable via auditd rules for AF_UNIX socket calls from non-standard processes. SPL: index=linux_secure or index=auditd sourcetype=linux_audit, looking for socket syscalls with AF_UNIX family from unexpected process images. The KQL and SPL main queries target Windows — Linux IPC detection requires separate auditd-based detection rules targeting socket(AF_UNIX) and shmget() syscalls.

Related Detections

Tactic Hub

TA0002Execution

Sub-techniques (3)

Related Techniques

T1559.001Component Object ModelT1559.002Dynamic Data ExchangeT1559.003XPC ServicesT1021.002SMB/Windows Admin SharesT1055Process InjectionT1090ProxyT1570Lateral Tool TransferT1134.001Token Impersonation/TheftT1543.003Windows ServiceT1047Windows Management Instrumentation

Same Tactic: Execution

Popular Detections