Windows Remote Management (WinRM) is Microsoft’s implementation of the WS-Management protocol, providing a standards-based interface for remote administration of Windows hosts. It is enabled by default on Windows Server 2012 R2 and above, and is the transport layer for PowerShell Remoting. It is also MITRE ATT&CK T1021.006 — one of the most commonly observed lateral movement techniques in ransomware intrusions.
Operators from LockBit, Akira, Black Basta, and numerous APT groups have used WinRM-based lateral movement precisely because it blends with legitimate administrative traffic, uses authenticated connections that bypass many perimeter controls, and enables direct execution of PowerShell on remote hosts. This guide covers the detection logic.
How Attackers Abuse WinRM
Attackers with valid credentials — often harvested via credential dumping from LSASS, Kerberoasting, or NTLM relay — use WinRM to:
- Execute commands on remote hosts via
Invoke-CommandorEnter-PSSession - Deploy additional tooling to remote hosts via
Copy-Itemover PSSessions - Move laterally without touching SMB (evading SMB-focused detections)
- Establish persistent remote access via scheduled tasks or services invoked over WinRM
The protocol operates on TCP 5985 (HTTP) and TCP 5986 (HTTPS). Lateral movement via WinRM typically produces a well-defined sequence of events that — when the right logging is enabled — provide high-fidelity detection opportunities.
Required Logging Prerequisites
Detection quality depends heavily on what telemetry is available:
| Log source | Event IDs | Notes |
|---|---|---|
| Windows Security | 4624 (Logon), 4648 (Explicit credential logon) | Logon Type 3 (Network) at target |
| Microsoft-Windows-WinRM/Operational | 6, 91, 169 | Connection and session events |
| Microsoft-Windows-PowerShell/Operational | 4103, 4104 | Script block logging |
| Sysmon | Event 3 (Network connection) | WinRM port connections |
| Windows Firewall | — | Connections to 5985/5986 |
Script block logging (PowerShell Event 4104) is the highest-value source for WinRM lateral movement. Without it, you lose visibility into what commands were executed after the connection was established.
Detection 1 — Sigma: WinRM Network Connections to Non-Default Hosts
This rule fires when Sysmon captures outbound WinRM connections from non-administrative tooling. The Image filter helps exclude legitimate RMM and admin tools in your environment — tune it accordingly.
title: WinRM Lateral Movement — Outbound Connection to TCP 5985/5986
id: 8f1a3c7e-4b29-4f8d-9e2a-1d6c5b8a0f3e
status: experimental
description: Detects outbound connections to WinRM ports that may indicate lateral movement.
references:
- https://attack.mitre.org/techniques/T1021/006/
author: SOC Analyst Hub
date: 2026-06-12
tags:
- attack.lateral_movement
- attack.t1021.006
logsource:
category: network_connection
product: windows
detection:
selection:
Initiated: 'true'
DestinationPort:
- 5985
- 5986
filter_admin:
Image|endswith:
- '\wsmprovhost.exe'
- '\svchost.exe'
condition: selection and not filter_admin
falsepositives:
- Legitimate remote administration tools
- Ansible/Windows automation
level: medium
Detection 2 — Sigma: WinRM-Spawned Child Process
When WinRM executes commands on the target host, wsmprovhost.exe is the provider host process that spawns child processes. Unusual children from wsmprovhost.exe — particularly cmd.exe, powershell.exe, wscript.exe, or reconnaissance binaries — are a strong lateral movement indicator.
title: Suspicious Process Spawned by WinRM Provider Host
id: 2c9d4e1f-7a38-4b2c-8f5e-3a7d6c1b9e4f
status: experimental
description: Detects suspicious processes spawned under wsmprovhost.exe, indicating remote command execution via WinRM.
references:
- https://attack.mitre.org/techniques/T1021/006/
author: SOC Analyst Hub
date: 2026-06-12
tags:
- attack.lateral_movement
- attack.t1021.006
- attack.execution
- attack.t1059.001
logsource:
category: process_creation
product: windows
detection:
selection:
ParentImage|endswith: '\wsmprovhost.exe'
Image|endswith:
- '\cmd.exe'
- '\powershell.exe'
- '\pwsh.exe'
- '\wscript.exe'
- '\cscript.exe'
- '\mshta.exe'
- '\net.exe'
- '\net1.exe'
- '\nltest.exe'
- '\whoami.exe'
- '\ipconfig.exe'
- '\systeminfo.exe'
condition: selection
falsepositives:
- Legitimate remote management scripts
- Configuration management (Ansible WinRM, SaltStack)
level: high
Detection 3 — KQL: WinRM Lateral Movement Chain (Microsoft Sentinel)
This KQL query correlates the full lateral movement chain across Security event log and Windows Firewall logs. It surfaces hosts that received a WinRM connection followed by child process execution under wsmprovhost.exe within a 10-minute window.
let winrm_connections = SecurityEvent
| where TimeGenerated > ago(24h)
| where EventID == 4624
| where LogonType == 3
| where ProcessName endswith "wsmprovhost.exe" or TargetUserName != "ANONYMOUS LOGON"
| project ConnectionTime = TimeGenerated, TargetComputer = Computer,
LogonUser = TargetUserName, SourceIP = IpAddress;
let wsmprov_children = Event
| where TimeGenerated > ago(24h)
| where Source == "Microsoft-Windows-Sysmon"
| where EventID == 1
| extend ParentImage = tostring(extract(@'ParentImage: (.+)', 1, RenderedDescription))
| extend ChildImage = tostring(extract(@'Image: (.+)', 1, RenderedDescription))
| where ParentImage endswith "wsmprovhost.exe"
| project ChildTime = TimeGenerated, TargetComputer = Computer, ChildImage;
winrm_connections
| join kind=inner wsmprov_children on TargetComputer
| where ChildTime between (ConnectionTime .. (ConnectionTime + 10m))
| project ConnectionTime, TargetComputer, LogonUser, SourceIP, ChildImage
| order by ConnectionTime desc
Detection 4 — Script Block Logging for Encoded Commands
Attackers frequently encode PowerShell payloads delivered over WinRM using Base64 (-EncodedCommand). Script block logging (Event 4104) captures the decoded content before execution — this is your primary visibility into what was actually run.
Event
| where TimeGenerated > ago(24h)
| where Source == "Microsoft-Windows-PowerShell"
| where EventID == 4104
| where RenderedDescription has_any (
"Invoke-Command",
"Enter-PSSession",
"New-PSSession",
"Invoke-Expression",
"-EncodedCommand",
"FromBase64String",
"IEX",
"DownloadString",
"WebClient"
)
| project TimeGenerated, Computer, RenderedDescription
| order by TimeGenerated desc
Hunting: Unusual WinRM Source Hosts
Administrative WinRM connections should originate from a predictable set of management hosts — jump servers, Ansible controllers, SCCM servers. This hunt identifies WinRM connections from hosts that do not normally initiate such connections.
let baseline_period = ago(30d);
let hunt_period = ago(24h);
let normal_sources = SecurityEvent
| where TimeGenerated between (baseline_period .. ago(24h))
| where EventID == 4624 and LogonType == 3
| summarize by IpAddress;
SecurityEvent
| where TimeGenerated > hunt_period
| where EventID == 4624 and LogonType == 3
| where not (IpAddress in (normal_sources))
| summarize count() by IpAddress, TargetUserName, Computer
| where count_ > 2
| order by count_ desc
Reducing False Positives
WinRM is legitimately used in many environments, and detection rules will fire on real administrative activity. Effective tuning requires:
Allowlisting management hosts. Build and maintain a list of authorised management hosts (jump servers, Ansible/SCCM infrastructure) and filter them from your detections. Update this list when infrastructure changes.
Correlating with asset context. A WinRM connection from a workstation to another workstation is high fidelity. A WinRM connection from your Ansible controller to a server fleet is expected. Enriching detections with asset type (server/workstation/management) dramatically improves signal quality.
Baselining logon accounts. Administrative service accounts that legitimately use WinRM have predictable source/destination pairs. Alerting on new account-to-host combinations catches credential abuse even when the source IP is expected.
Chaining with authentication anomalies. WinRM lateral movement with harvested credentials typically shows logon anomalies upstream — off-hours activity, new source-destination pairs, or accounts logging on to hosts they haven’t touched before. Chaining WinRM detections with authentication baseline deviations reduces noise.
MITRE ATT&CK Coverage
| Technique | ID | Detection |
|---|---|---|
| Remote Services: Windows Remote Management | T1021.006 | WinRM network connections, wsmprovhost child processes |
| Command and Scripting Interpreter: PowerShell | T1059.001 | Script block logging Event 4104 |
| Valid Accounts | T1078 | Authentication anomalies, unusual account-host pairs |
| Lateral Tool Transfer | T1570 | Copy-Item over PSSession to remote host |
WinRM lateral movement is rarely the first indicator in an intrusion — it typically follows credential access and is followed by execution and impact. Placing WinRM detections in a broader timeline view, rather than treating individual alerts as standalone signals, improves both detection rate and analyst context for triage.