Named pipe created with a known command-relay pipe name

Siemphony@siemphonymediumT1559unverified

Windows named pipes are the one IPC mechanism in AN1357 that has no sub-technique of its own — COM is T1559.001 and DDE is T1559.002 — so the pipe leg is where a parent-level rule belongs. This matches Sysmon pipe events (EventID 17 creation and 18 connection — the selection carries no EventID constraint, so both are captured, and the connecting client is often the more interesting half for a relay pipe) on two families of pipe name. selection_cmd_relay covers pipes whose purpose is to relay a remotely executed command's stdin/stdout back to the caller: the post-exploitation job pipes of a widely deployed offensive framework (postex_, status_), and PsExec's own service pipe (PSEXESVC). PSEXESVC is dual-filed — the SMB service install that creates it is T1569.002 with T1021.002 for the transport — but the pipe itself carries the executed command's I/O, which is the local IPC behaviour this rule is filed under, so it stays. selection_peer_channel covers msagent_ and MSSE-, the same framework's SMB peer-to-peer beacon channel; this is C2 traffic riding a named pipe rather than command relay and is dual-filed under T1090.001/T1572 — a hit on this arm should be triaged as a beacon channel, not as local command execution. paexec, remcom_ and csexecsvc were dropped from an earlier draft: they are the same class of service-based remote-execution pipe as svcctl and atsvc, which this rule already excludes on the grounds that their abuse is the observable of remote service execution rather than local IPC — the same reasoning now applies consistently across all of them. MITRE names the PipeNamePattern knob and offers only the svcctl example, which this rule does not use for that reason; every prefix below was assembled here, not taken from the brief. The status_ prefix is a generic word matched with nothing beyond startswith, so an unrelated product that names a pipe that way will also match — that is a precision limit on selection_cmd_relay, not a false positive, since no real benign source can be named for it. Two further limits are structural. A pipe name is a default, so an operator who changes it leaves nothing here, and this rule therefore ages out rather than generalising. The other two Windows log sources in the analytic cannot substitute: the brief maps Security 4663 onto the Sysmon-shaped file_event category, whose TargetFilename cannot carry a pipe object, and the 4656/4670 leg needs a SACL on the named-pipe device that no default or CIS baseline sets. Sysmon must also be configured with a PipeEvent section — pipe creation is not logged by a stock or minimal configuration, and a silent rule here means blind, not quiet. UNVERIFIED — derived from MITRE ATT&CK DET0493 and never executed against logs.Full description

The 3 SIEM queries below are previews produced by Siemphony’s own translator, not pySigma, and none has been executed against a real backend — review before you deploy.

detection.yml

Splunk · SPL

Run this as a search.

index=* ((PipeName="\\postex_*" OR PipeName="\\status_*" OR PipeName="\\PSEXESVC*") OR (PipeName="\\msagent_*" OR PipeName="\\MSSE-*"))

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE ((TO_LOWER(file.name) LIKE "\\\\postex_*" OR TO_LOWER(file.name) LIKE "\\\\status_*" OR TO_LOWER(file.name) LIKE "\\\\psexesvc*") OR (TO_LOWER(file.name) LIKE "\\\\msagent_*" OR TO_LOWER(file.name) LIKE "\\\\msse-*"))

Wazuh · XML rule

Deploy to your manager — this is a rule, not a search.

<group name="sigma,windows,pipe_created,">  <!-- Rule ids must be unique on your manager; 100000+ is the user range. -->  <rule id="100000" level="7">    <!-- Set <if_sid> to the decoder/base rule for windows so this only evaluates relevant events. -->    <field name="PipeName" type="pcre2">(?i)((^\\postex_|^\\status_|^\\PSEXESVC)|(^\\msagent_|^\\MSSE-))</field>    <description>Named pipe created with a known command-relay pipe name</description>    <mitre>      <id>T1559</id>    </mitre>  </rule></group>

Sentinel · KQL

Run this as a search.

Sentinel cannot express this construct. No Sentinel table is modelled for this logsource ({"category":"pipe_created","product":"windows"}), so there is nothing honest to query. Pick a logsource this translator maps, or write the KQL by hand. The Sigma source is on the first tab, unchanged.

At a glance

Logsource: pipe_created / windows
Level: medium
Category: covert_c2_channels
Sigma status: experimental
Backends: 3 of 4 rendered
Updated: 3 Sept 2026
Rule ID: 70a46951-2fa4-40ad-a3f0-8bf411e30211

ATT&CKT1559

T1559Inter-Process Communication

ATT&CK® is a registered trademark of The MITRE Corporation. These mappings are the rule author’s, and are neither reviewed nor endorsed by MITRE.

Lessoncovert c2 channels

covert c2 channels

01 · What this rule detects

Command-and-control plumbing built to avoid the obvious network telemetry: a tunnel that wraps one protocol inside another, a socket-filter implant acquiring raw packet visibility so it can hear a trigger below the TCP stack, or a named pipe relaying a remote operator's commands between processes and hosts.

02 · Telemetry you need

Process creation with full command lines — the argv that sets a tunnel up (ssh -L/-R/-D, netsh portproxy) is the one place the intent is written down
Module load events, to see a process acquire capture capability (wpcap.dll, packet.dll) it has no business holding
Named pipe creation and connection events (Sysmon Event IDs 17 and 18) carrying the pipe name — the connecting client is often the more interesting half
Network flow metadata as the correlation layer: a tunnel's inner protocol is invisible, but the outer connection's duration and byte profile is not

03 · How the logic works

Each channel is caught where it must surface. A tunnel has to be configured: ssh or plink with -L, -R or -D immediately followed by a port number — the digit, not the letter, is what separates a forward spec from ssh -l username under case-insensitive matching — or netsh interface portproxy with a connectaddress. A socket-filter backdoor has to obtain raw packet visibility before it can hear its trigger, and the user-mode route on Windows is loading the capture libraries: match the module load and subtract only processes running from a genuine capture-tool install directory, anchored on the path rather than the file name, because a name-only allowlist is defeated by copying the implant to tshark.exe and publishes exactly the names an attacker should use. A command relay has to carry stdin and stdout somewhere, and the pipes that do it have recognisable names — PsExec's PSEXESVC and the default prefixes of a widely deployed offensive framework. All three rules read low-level plumbing rather than traffic content, which is the point: these channels are designed so the traffic itself looks like nothing.

04 · Common false positives

Developers and administrators tunnelling to a database, web console or RDP host through a bastion with ssh -L — routine daily activity and the dominant match on the tunnel arm
Wireshark, Nmap or monitoring agents run from a non-default path — a USB stick, a user profile — which acquire capture capability exactly the way an implant does
Sanctioned PsExec inside software distribution and break-fix tooling, creating the PSEXESVC pipe on every target it touches
Purple-team and licensed red-team exercises using the framework whose default pipe prefixes are matched — indistinguishable from an intrusion at the level of a pipe name

05 · Detection maturity

Tier 1 — starting point: Matches tunnel flags, capture-library loads and known relay pipe names fleet-wide, with only the default install-path exclusions.
Tier 2 — tuned: Adds the site's own allowlists — sanctioned capture tooling by image path, tunnel users by account, PsExec by deploying host — and separates exercise windows from production time.
Tier 3 — correlated: Correlates the plumbing event with the flow record of the connection it serves, and alerts on the combination of an unlisted image acquiring capture capability and any outbound connection from the same process.

Tuning & false positivesexperimental · 3 declared

experimental (current stage)
test
stable

Written and reasoned about, but not yet run against real telemetry. Expect to tune it before trusting it.

Tuning tips

Write the site-specific allowlists first: which images may load capture libraries, which accounts may configure portproxy, which hosts still legitimately run PsExec — none of these can be written in advance for someone else's fleet
A renamed PsExec clone keeps the default pipe name, so a PSEXESVC pipe from a non-standard service path is worth more, not less
Treat netsh portproxy as near-audit: Docker Desktop, WSL and some VPN clients add entries at install time; human hands rarely do afterwards
When a match survives the allowlist, pivot to the outer connection's flow record — long-lived, low-volume, fixed-interval traffic is the shape of a tunnel

Declared by the author

Sanctioned use of Sysinternals PsExec, a standard administration tool embedded in software distribution scripts, remote-support tooling, imaging task sequences and ad hoc break-fix work; every invocation creates the PSEXESVC pipe on the target and matches selection_cmd_relay. In an estate that still permits PsExec this is the dominant match on that arm, which is why this rule is scored medium rather than higher.
Purple-team and control-validation runs, and licensed red-team engagements, using the offensive framework whose default pipe prefixes are listed here. These produce clean matches on every exercise and are indistinguishable from an intrusion at the level of a pipe name.
Monitoring, backup and patch agents that ship a bundled copy of Sysinternals PsExec to run a command on a peer, so the PSEXESVC pipe appears on a schedule from a service account rather than from an interactive session.

Noise check0 of 1 fired

The baseline holds exactly one ordinary behaviour for this log type, and the rule does not fire on it. One event is close to no evidence: this says the rule is not caught by that one behaviour, and nothing more.

Run live against 65 hand-written events of ordinary corporate activity — backup agents, software distribution, patching, helpdesk scripts, EDR. It says nothing about how often the rule would fire in production, which is the number that actually exhausts an analyst.

Verification1 run

Not verified

Siemphony benign baseline
completed
Siemphony IR · 3 Sept 2026
No events matched, so this run proves nothing either way.

Test it yourselfin your browser

Runs here in your browser against public attack recordings. A preview — not the verification badge.

Recordings of T1559, evaluated against their pipe_created events.

Share this rule

/u/siemphony/70a46951-2fa4-40ad-a3f0-8bf411e30211

More from this repertoire

All compositions

Verdicts · reactions · comments

Community

Verdicts from engineers who actually deployed it, and the conversation around it.

Not yet reported on

Nobody has run this in a real environment and said what happened.

Verdicts from engineers who deployed it

0 cast

No verdicts reported yet. The first one is worth more than the tenth — say what you ran it against.

2 threads

@priya-raman
24 Aug 2026
Every operator worth worrying about renames these — the prefixes here are framework defaults, and defaults are what you get from the people who did not read the docs. That is not an argument against the rule, it is an argument for the medium it already carries: a hit is worth looking at, a miss proves nothing at all. The failure mode to avoid is someone putting this on a coverage map and calling the technique covered.
@nadia-brandt
24 Aug 2026
PSEXESVC will fire every time your software distribution tooling touches a host, so we pulled that prefix into its own rule with an allowlist of source accounts and left postex_ and msagent_ in the one that pages. They answer different questions: one is "did somebody use an admin tool", the other is "is there an implant". Merging them means the second one is muted by the noise of the first.

Named pipe created with a known command-relay pipe name

The detection

detection.yml

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Sentinel · KQL

Community

Verdicts from engineers who deployed it

2 threads