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-Command or Enter-PSSession
  • Deploy additional tooling to remote hosts via Copy-Item over 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 sourceEvent IDsNotes
Windows Security4624 (Logon), 4648 (Explicit credential logon)Logon Type 3 (Network) at target
Microsoft-Windows-WinRM/Operational6, 91, 169Connection and session events
Microsoft-Windows-PowerShell/Operational4103, 4104Script block logging
SysmonEvent 3 (Network connection)WinRM port connections
Windows FirewallConnections 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

TechniqueIDDetection
Remote Services: Windows Remote ManagementT1021.006WinRM network connections, wsmprovhost child processes
Command and Scripting Interpreter: PowerShellT1059.001Script block logging Event 4104
Valid AccountsT1078Authentication anomalies, unusual account-host pairs
Lateral Tool TransferT1570Copy-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.