TTechniqueActive Directory

Lateral Movement via WinRM

Lateral MovementintermediateT1021.00612 min

Lateral movement via WinRM uses the Windows Remote Management service to execute commands and access systems remotely with valid credentials. This lesson explains what WinRM provides operationally, what preconditions matter, what the attacker gains, where it fits in post-credential lateral movement, and how to communicate the risk clearly in interviews, reports, and stakeholder conversations.

This lesson builds on

NTLM Authentication

Why it matters

WinRM is a built-in Windows remote management protocol that is enabled by default on Windows Server and commonly enabled on workstations in managed environments.

Understanding WinRM-based lateral movement matters because it uses a legitimate administration channel that is difficult to distinguish from normal activity. Interviewers expect candidates to explain not just what WinRM does, but why an attacker would choose it over other movement methods and what makes it operationally valuable.

Key Concepts

WinRM is the transport for PowerShell Remoting — when an attacker uses Enter-PSSession or Invoke-Command against a remote host, WinRM carries the traffic; the attacker gets a full PowerShell session on the target
Enabled by default on servers — WinRM is enabled by default on Windows Server 2012+ and commonly pushed via GPO to workstations; many environments have WinRM reachable across the internal network without additional configuration
Uses standard authentication — WinRM authenticates via Kerberos (default in domain environments) or NTLM; Pass the Hash and Pass-the-Ticket both work against WinRM; the authentication is indistinguishable from legitimate admin access
No service creation required — unlike PsExec-style execution that creates a Windows service on the target, WinRM uses an existing service; this means less forensic footprint and fewer alertable events
Port 5985 (HTTP) and 5986 (HTTPS) — WinRM uses its own dedicated ports, which makes it filterable by network policy but also means it may be overlooked in monitoring focused on SMB (445) or RDP (3389)
Remote Management Users group — accounts do not need full local admin to use WinRM; membership in the Remote Management Users group grants WinRM access with that user's privilege level, which may be sufficient for enumeration and data access

Theory

Preconditions

WinRM-based lateral movement requires valid credentials (password, NT hash, or Kerberos ticket) for an account that has remote management access on the target system. By default, this means membership in the local Administrators group or the Remote Management Users group on the target.

WinRM must be enabled and reachable on the target; it listens on TCP port 5985 (HTTP) or 5986 (HTTPS). WinRM is enabled by default on Windows Server 2012 and later, and is commonly enabled via Group Policy on managed workstations. The attacker also needs network connectivity to the target's WinRM port, which may be filtered by host-based firewalls.

Why it works

WinRM is the transport layer for PowerShell Remoting (PSRemoting), which provides a full interactive or non-interactive command execution channel over HTTP or HTTPS. When an attacker authenticates to WinRM with valid credentials, they receive a PowerShell session on the target system with whatever privileges the authenticated account holds.

The connection uses standard Windows authentication, standard ports, and a standard protocol, making it functionally identical to legitimate remote administration. The operating system does not distinguish between an administrator using WinRM for management and an attacker using the same channel for lateral movement, because the authentication and protocol are the same.

Attacker gain

Successful WinRM access gives the attacker an interactive or scripted command execution channel on the remote system. This provides the ability to execute commands, read and write files, access the registry, manage services, and interact with the system as the authenticated user. If the credentials belong to a local administrator, the attacker has full administrative control.

WinRM access also enables LSASS credential extraction on the target, enumeration of the local system, and pivoting to additional hosts. The interactive PowerShell session is operationally valuable because it supports complex multi-step actions without the file-drop footprint of tools like PsExec.

Where it fits

WinRM-based movement sits in the lateral movement phase, after the attacker has obtained valid credentials through spraying, LSASS extraction, Kerberoasting, or any other credential access technique. It is one of several protocols an attacker can use for host-to-host movement, alongside SMB (PsExec-style execution), RDP, and WMI.

The choice of protocol depends on what is available and monitored in the target environment. WinRM is often preferred when the attacker wants a lightweight, interactive session without creating new services (unlike PsExec) or opening a graphical session (unlike RDP). In a typical chain: credential access → WinRM to target → LSASS extraction on target → further movement.

Tools / examples

Evil-WinRM -i target -u user -p password: interactive WinRM shell from Linux; supports NTLM hash authentication with -H flag
Enter-PSSession -ComputerName target -Credential $cred: native PowerShell remote session from a Windows host
Invoke-Command -ComputerName target -ScriptBlock { command }: non-interactive command execution via WinRM
CrackMapExec winrm targets -u user -p password: tests WinRM access across multiple hosts with credential validation
Evil-WinRM -i target -u user -H NThash: WinRM access using Pass the Hash; useful when only the NT hash is available

Defender view

Restrict WinRM access to authorized administrative hosts only. Use Windows Firewall rules or GPO to limit which source IP addresses can connect to WinRM ports (5985, 5986).
Limit membership in the Remote Management Users group and local Administrators group to accounts that require remote management access.
Enable PowerShell Script Block Logging and Module Logging to capture the commands executed through WinRM sessions. These logs provide visibility into what the attacker does after connecting.
Monitor for WinRM connections from unexpected source hosts. Unusual source-to-destination pairs for WinRM traffic are a strong lateral movement indicator.
Consider using Just Enough Administration (JEA) to constrain what authenticated WinRM users can execute, limiting the blast radius even when valid credentials are compromised.

Communication

Explain it to a stakeholder

WinRM is a built-in Windows remote management service that lets administrators manage computers remotely.

An attacker with stolen employee credentials can use this same service to connect to computers across your network, run commands, and access data, and the connection looks identical to normal administrative activity. The service is enabled by default on servers and often on workstations. The risk is that it provides a ready-made remote access channel that requires no special tools or exploits, just valid credentials. Defenses include restricting which computers can connect to this service, monitoring for unusual connection patterns, and logging all remote commands for forensic visibility.

Report language

Finding: Lateral Movement via WinRM Using Compromised Credentials. During the assessment, the operator used credentials obtained through password spraying to authenticate to WinRM (port 5985) on HOST-SRV02 and HOST-SRV03. The interactive PowerShell sessions provided local administrator access on both servers. The operator extracted additional credentials from LSASS on HOST-SRV02, including an NT hash for a Domain Admin account. WinRM was enabled on all assessed servers with no source IP restrictions. No PowerShell Script Block Logging was configured.

Severity: High.

Recommendation: Restrict WinRM access to designated administrative jump hosts via Windows Firewall rules. Enable PowerShell Script Block Logging and Module Logging. Monitor WinRM connections for unexpected source hosts.

Common weak answers

Describing WinRM as 'just PowerShell remoting' without explaining why it matters operationally: its value is in being a built-in, standard authentication channel that creates less forensic footprint than alternatives like PsExec.
Not mentioning that WinRM is enabled by default on servers. This is why it is commonly available across enterprise environments without the attacker needing to enable anything.
Comparing WinRM to PsExec without explaining the key differences: WinRM uses an existing service (no service creation), uses its own ports (5985/5986 vs 445), and provides an interactive PowerShell session.
Treating WinRM as purely a lateral movement tool without connecting it to the credential access that precedes it. WinRM access requires valid credentials; the technique depends on prior credential compromise.
Not mentioning detection approaches. The protocol itself is legitimate, so detection depends on connection pattern monitoring, PowerShell logging, and source IP restrictions, not protocol-level blocking.

Interview answer

WinRM is the Windows Remote Management service that provides an authenticated command execution channel using standard Windows authentication, Kerberos or NTLM, over HTTP on port 5985 or HTTPS on port 5986. An attacker with valid credentials can use WinRM to open a PowerShell session on a remote host, execute commands, access files, and extract further credentials.

It is operationally valuable because it uses an existing service (no new service creation like PsExec), supports standard authentication (Pass the Hash and Pass-the-Ticket both work), and provides a full interactive shell. The connection is functionally identical to legitimate remote administration, which makes it difficult to detect based on protocol alone.

Detection depends on monitoring source-destination patterns, PowerShell logging, and restricting which hosts can connect to WinRM.

Follow-up questions

What credentials can be used to authenticate to WinRM, and how does this relate to Pass the Hash and Pass-the-Ticket?
Why might an attacker choose WinRM over PsExec or RDP for lateral movement?
What defensive controls would you recommend to limit WinRM-based lateral movement without disabling the service entirely?
What is the difference between the Remote Management Users group and the local Administrators group in terms of WinRM access?
How would you detect WinRM-based lateral movement if the attacker is using valid administrator credentials?

Study Kit