Child process spawned by the WinRM shell host wsmprovhost.exe

Siemphony@siemphonylowT1021.006verified in lab

Matches a process created with `wsmprovhost.exe` as its parent — the WS-Management provider host that WinRM launches to run every remote PowerShell or cmd session it hosts, so any child of it is evidence execution reached this box specifically over WinRM. That is the differentiator asked for: the published T1021.001 rule keys on port 3389 and the mstsc/msrdc clients, and T1021.002 keys on Security EventID 5140's `ShareName` field for ADMIN$/C$, while this rule keys on the one process that only exists on the WinRM path (5985/5986), whichever account or tool drove it. AN1313 also lists the Security EventID 4624/4648 logon pair and the WinRM Operational channel's EventID 6, but both only confirm a session opened, not what ran inside it — joining "session opened" to "process created" within a window is the correlation MITRE's `TimeWindow` knob describes, and Sigma has no construct for it, so this rule stays on the process-creation leg alone. `UserContext` and `KnownAdminHosts` remain manual triage once this fires. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0477, not hand-written and not tested by its author. Any lab result is on this rule's own page.Full description

The 4 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

Sentinel · KQL

Run this as a search.

DeviceProcessEvents| where InitiatingProcessFolderPath endswith "\\wsmprovhost.exe"

Splunk · SPL

Run this as a search.

index=* ParentImage="*\\wsmprovhost.exe"

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE TO_LOWER(process.parent.executable) LIKE "*\\\\wsmprovhost.exe"

Wazuh · XML rule

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

<group name="sigma,windows,process_creation,">  <!-- Rule ids must be unique on your manager; 100000+ is the user range. -->  <rule id="100000" level="5">    <!-- Set <if_sid> to the decoder/base rule for windows so this only evaluates relevant events. -->    <field name="ParentImage" type="pcre2">(?i)\\wsmprovhost\.exe$</field>    <description>Child process spawned by the WinRM shell host wsmprovhost.exe</description>    <mitre>      <id>T1021.006</id>    </mitre>  </rule></group>

At a glance

Logsource: process_creation / windows
Level: low
Category: lateral_movement_remote_exec
Sigma status: experimental
Backends: 4 of 4 rendered
Updated: 30 Aug 2026
Rule ID: 69a5b93a-35db-4be2-802e-f3142b7765d6

ATT&CKT1021.006

T1021.006Windows Remote Management

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.

Lessonlateral movement remote exec

lateral movement remote execAI draft — unreviewed

01 · What this rule detects

This rule catches WinRM-based lateral movement (T1021.006) by watching for wsmprovhost.exe as a parent process. WinRM launches this WS-Management provider host to run every remote PowerShell or cmd session it hosts on ports 5985/5986 — so any child process under it is proof that execution landed on this box specifically over WinRM, no matter which account or client tool drove it. That is a deliberate differentiator from sibling rules: T1021.001 (RDP) keys on port 3389 and the mstsc/msrdc clients, and T1021.002 (SMB/Admin Shares) keys on Security EventID 5140's ShareName field for ADMIN$/C$. This rule instead pins the one process that only exists on the WinRM code path.

02 · Telemetry you need

The rule itself runs on Sysmon EventID 1 (logsource: category: process_creation, product: windows), reading ParentImage. The brief for AN1313 lists two more sources this rule does not use: Security EventID 4624/4648 (logon session creation) and the WinRM Operational channel's EventID 6 (service metadata). Both are real telemetry worth collecting, but both only confirm that a remote session opened — not what ran inside it — so they cannot substitute for the process-creation leg this rule actually checks.

03 · How the logic works

The whole rule is one selection: ParentImage|endswith: '\wsmprovhost.exe', condition selection. No account, host, or command-line gate. MITRE's AN1313 description calls for a "detection chain" spanning service use, network activity, remote session logon, and process creation "within a short temporal window" — that is a join across three log sources bound by MITRE's TimeWindow knob. lib/sigma has no timeframe or cross-source aggregation construct, so this rule cannot express that join at all. What ships here is the process-creation leg alone: a single endswith match, nothing joined, nothing counted. That is the norm for this corpus, not a shortcut specific to this rule — treat any Sigma rule built from these briefs as precursor detection unless it says otherwise.

04 · Common false positives

review.json's one finding is the whole story: "no scoping beyond ParentImage — no CommandLine, account, or host gate — so it fires on every process WinRM spawns, malicious or not." The rule's own falsepositives list says the same thing plainly: legitimate admins and helpdesk staff running Enter-PSSession/Invoke-Command are named as "the dominant source of matches on any host with remoting enabled," alongside config-management tooling (Ansible's winrm connector, PowerShell DSC pulls, Server Manager) and scheduled monitoring agents polling over PowerShell Remoting. On any host where WinRM is in normal use, expect the bulk of hits to be exactly this — not the exception, the default population.

05 · Detection maturity

tier_1: UNVERIFIED — the lowest tier in this corpus. This rule has never been run against real data, so there is no false-positive rate or hit count to report here, invented or otherwise. What review.json does confirm is the calibration: level: low is set correctly, because it tracks the rule's own admitted top false positive (routine admin remoting) instead of contradicting it — the reviewer flagged this as the most cleanly calibrated of six rules checked in that batch.

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

MITRE's AN1313 names four knobs for this analytic — TimeWindow, UserContext, CommandLineAnomalyScore, KnownAdminHosts — but this rule populates none of them; it is a bare ParentImage precursor. Reviewer's suggested fix: pair the rule with an allowlist built from MITRE's KnownAdminHosts knob, which the reviewer calls close to mandatory before this is more than an audit trail. Scoping by UserContext (flag non-admin or service-account logons) and a CommandLineAnomalyScore-style check on the child process (encoded PowerShell, unusual binaries) are the other two levers worth adding by hand. Also know the blind spot: an adversary who never spawns a child process — staying entirely inside the hosted PowerShell runspace via in-memory or reflective execution — produces no Sysmon EventID 1 here at all, and this rule sees nothing.

Declared by the author

Legitimate PowerShell Remoting: administrators and helpdesk staff running Enter-PSSession or Invoke-Command against this host, which is the intended purpose of WinRM and is the dominant source of matches on any host with remoting enabled.
Configuration-management and orchestration tooling that targets Windows hosts over WinRM — Ansible's winrm connector, PowerShell DSC pulls, and Server Manager's multi-server console all spawn commands through wsmprovhost.exe as their normal operating mode.
Monitoring and inventory agents that poll a host over PowerShell Remoting on a fixed schedule, appearing as recurring wsmprovhost.exe children from the same service account.

Noise check0 of 30 fired

Fires on none of the 30 ordinary behaviours the baseline holds for this log type. That is not a precision guarantee: it means only not caught by these 30 behaviours, and the next ordinary behaviour nobody wrote down may still match.

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.

Verification2 runs

Verified in Siemphony lab

Security Datasets — PowerShell Remoting used for lateral movement (Empire)
passed
Siemphony IR · 3 Sept 2026
1 true · 0 false · 0.0% noise
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 T1021.006, evaluated against their process_creation events.

Share this rule

/u/siemphony/69a5b93a-35db-4be2-802e-f3142b7765d6

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.

No comments yet. Someone who deploys this will have something to say about it.

Child process spawned by the WinRM shell host wsmprovhost.exe

The detection

detection.yml

Sentinel · KQL

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Community

Verdicts from engineers who deployed it