Named pipe created with a known command-relay pipe name

Siemphony@siemphonymediumT1559unverifiedPlaybook · Command and control

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

1title: Named pipe created with a known command-relay pipe name2id: 70a46951-2fa4-40ad-a3f0-8bf411e302113status: experimental4description: |5  Windows named pipes are the one IPC mechanism in AN1357 that has no6  sub-technique of its own — COM is T1559.001 and DDE is T1559.002 — so the pipe7  leg is where a parent-level rule belongs. This matches Sysmon pipe events8  (EventID 17 creation and 18 connection — the selection carries no EventID9  constraint, so both are captured, and the connecting client is often the more10  interesting half for a relay pipe) on two families of pipe name.11  selection_cmd_relay covers pipes whose purpose is to relay a remotely12  executed command's stdin/stdout back to the caller: the post-exploitation job13  pipes of a widely deployed offensive framework (postex_, status_), and14  PsExec's own service pipe (PSEXESVC). PSEXESVC is dual-filed — the SMB15  service install that creates it is T1569.002 with T1021.002 for the transport16  — but the pipe itself carries the executed command's I/O, which is the local17  IPC behaviour this rule is filed under, so it stays. selection_peer_channel18  covers msagent_ and MSSE-, the same framework's SMB peer-to-peer beacon19  channel; this is C2 traffic riding a named pipe rather than command relay and20  is dual-filed under T1090.001/T1572 — a hit on this arm should be triaged as21  a beacon channel, not as local command execution. paexec, remcom_ and22  csexecsvc were dropped from an earlier draft: they are the same class of23  service-based remote-execution pipe as svcctl and atsvc, which this rule24  already excludes on the grounds that their abuse is the observable of remote25  service execution rather than local IPC — the same reasoning now applies26  consistently across all of them. MITRE names the PipeNamePattern knob and27  offers only the svcctl example, which this rule does not use for that reason;28  every prefix below was assembled here, not taken from the brief. The status_29  prefix is a generic word matched with nothing beyond startswith, so an30  unrelated product that names a pipe that way will also match — that is a31  precision limit on selection_cmd_relay, not a false positive, since no real32  benign source can be named for it. Two further limits are structural. A pipe33  name is a default, so an operator who changes it leaves nothing here, and34  this rule therefore ages out rather than generalising. The other two Windows35  log sources in the analytic cannot substitute: the brief maps Security 466336  onto the Sysmon-shaped file_event category, whose TargetFilename cannot carry37  a pipe object, and the 4656/4670 leg needs a SACL on the named-pipe device38  that no default or CIS baseline sets. Sysmon must also be configured with a39  PipeEvent section — pipe creation is not logged by a stock or minimal40  configuration, and a silent rule here means blind, not quiet.41  UNVERIFIED — derived from MITRE ATT&CK DET0493 and never executed against logs.42references:43  - https://attack.mitre.org/techniques/T155944  - https://attack.mitre.org/detectionstrategies/DET049345author: Siemphony pipeline (machine-derived from MITRE ATT&CK v19.2)46date: 2026-08-1647tags:48  - attack.execution49  - attack.t155950logsource:51  category: pipe_created52  product: windows53detection:54  selection_cmd_relay:55    PipeName|startswith:56      - '\postex_'57      - '\status_'58      - '\PSEXESVC'59  selection_peer_channel:60    PipeName|startswith:61      - '\msagent_'62      - '\MSSE-'63  condition: 1 of selection_*64falsepositives:65  - "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."66  - "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."67  - "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."68level: medium

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.

Evidence

Verification1 run

Not verified

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

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.

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.

Using it

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

Add additional filters to exclude known legitimate pipe names, such as \PSEXESVC when used by PsExec
Filter on the process or user creating the pipe to exclude system or administrative accounts
Monitor the pipe's usage and behavior to determine if it is being used for malicious purposes, such as unusual network activity or suspicious process execution

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.

Lessoncovert c2 channels

covert c2 channelsAI draft — unreviewed

01 · What this rule detects

This Sigma rule detects the creation of named pipes with specific names that are commonly used by attackers to establish covert command and control (C2) channels. The rule identifies pipes with names starting with certain prefixes, such as \postex_, \status_, \PSEXESVC, \msagent_, and \MSSE-, which are known to be used by malicious actors for command relay and peer-to-peer communication.

02 · Telemetry you need

Log source: pipe_created
Product: windows
Specific fields: PipeName
Audit setting: The Windows Audit Policy must be configured to log pipe creation events, which may be off by default.

03 · How the logic works

The rule uses two selections, selection_cmd_relay and selection_peer_channel, to identify named pipes with suspicious names. The selection_cmd_relay selection checks if the PipeName starts with specific prefixes, such as \postex_, \status_, or \PSEXESVC, which are commonly used for command relay. The selection_peer_channel selection checks for pipes with names starting with \msagent_ or \MSSE-, which are often used for peer-to-peer communication. The condition is met if either of these selections matches, indicating that a potentially malicious named pipe has been created.

04 · Common false positives

Legitimate system administration tools, such as SysInternals' PsExec, which uses a pipe named \PSEXESVC
Microsoft's own system services, such as the Microsoft Agent service, which uses pipes with names starting with \msagent_
Other legitimate software that uses named pipes for inter-process communication, such as database or messaging applications

05 · Detection maturity

tier_1: The rule as written may generate a high volume of false positives due to its broad matching criteria and lack of contextual filtering.
tier_2: With additional tuning, such as excluding known legitimate pipe names and filtering on process or user context, the rule can become more effective at detecting malicious activity while reducing noise.
tier_3: Correlating this rule with other signals, such as network traffic or process execution, can provide a more comprehensive view of potential C2 channel activity and improve detection accuracy.

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