Detecting WinRM and PowerShell Remoting Lateral Movement

WinRM is the transport for Enter-PSSession, Invoke-Command and tools such as Evil-WinRM. On the target, every remote session is hosted by wsmprovhost.exe, which makes it an unusually clean anchor for detection. The logging that surrounds it adds the identity and source.

Signals at a Glance

wsmprovhost and Its Children

A remote PowerShell session runs inside wsmprovhost.exe. Interactive administration looks like script blocks in the PowerShell log; an attacker typically also launches child processes such as cmd.exe, whoami.exe or net.exe. Alert on the interpreter and reconnaissance children, then enrich with the connecting account:

title: Suspicious Child of wsmprovhost
logsource:
  product: windows
  category: process_creation
detection:
  parent:
    ParentImage|endswith: '\wsmprovhost.exe'
  suspicious_child:
    Image|endswith:
      - '\cmd.exe'
      - '\whoami.exe'
      - '\net.exe'
      - '\net1.exe'
      - '\nltest.exe'
      - '\rundll32.exe'
      - '\mshta.exe'
  condition: parent and suspicious_child
level: medium
# tune/validate: raise to high on servers with no remoting use; baseline configuration-management tools.

From the network side, WinRM is a small, well-defined surface. Inbound 5985/5986 to endpoints outside your server management VLAN is unusual:

// Microsoft Defender (KQL) - inbound WinRM to hosts from non-admin sources
DeviceNetworkEvents
| where ActionType == "InboundConnectionAccepted"
| where LocalPort in (5985, 5986)
| where RemoteIP !in (externaldata_admin_hosts)   // replace with a watchlist of approved sources
| summarize conns=count(), targets=dcount(DeviceName) by RemoteIP, bin(Timestamp, 1h)
| order by targets desc
// tune/validate: define the approved-sources watchlist first; the dynamic list name above is a placeholder.

Logging That Makes It Visible

• Enable PowerShell script block logging (4104), module logging (4103) and transcription. Remote sessions then show the commands that ran, not only the process tree.
• Collect Microsoft-Windows-WinRM/Operational: Event 91 (creating a WSMan shell), 168 and 169 (authentication, including the method used) tie a session to an account.
• Look for Evil-WinRM habits: connections from a non-Windows source, repeated session creation on 5985 with the same account, and in-memory script loading followed by AMSI bypass strings.
• Prefer HTTPS (5986) with certificates and Just Enough Administration endpoints for legitimate remoting, so any other session is an exception you can alert on.