Testing Windows Remote Management (WinRM / WS-Management) during authorized engagements. WinRM exposes an HTTP(S) SOAP interface for WMI/PowerShell remoting on 5985/tcp (HTTP) and 5986/tcp (HTTPS). Covers service detection with Test-WSMan and netexec, credential validation and brute force, interactive shells with evil-winrm (password, pass-the-hash, Kerberos, certificate auth), command execution, NTLM relay to WS-MAN, and the OMIGOD (CVE-2021-38647) RCE.
Testing Windows Remote Management (WinRM / WS-Management) during authorized engagements. WinRM exposes an HTTP(S) SOAP interface for WMI/PowerShell remoting on 5985/tcp (HTTP) and 5986/tcp (HTTPS). Covers service detection with Test-WSMan and netexec, credential validation and brute force, interactive shells with evil-winrm (password, pass-the-hash, Kerberos, certificate auth), command execution, NTLM relay to WS-MAN, and the OMIGOD (CVE-2021-38647) RCE.
During authorized Windows/AD assessments when 5985 (HTTP) or 5986 (HTTPS) is open
When you hold valid credentials or an NT hash and want an interactive remote shell
When testing for NTLM relay opportunities against an unencrypted WinRM (HTTP) listener
When assessing Azure Linux hosts running OMI (OMIGOD, CVE-2021-38647)
When validating credentials at scale and checking which grant remote-exec
Quick Enumeration
# Port presence implies WinRM is configured
nmap -p5985,5986 -sV <IP>
# 5985/tcp Microsoft-HTTPAPI ; 5986/tcp is HTTPS# From Windows: confirm a target is WinRM-configured
Test-WSMan <target-ip> # returns protocol version + wsmid if configured# netexec / crackmapexec credential check (no interactive shell)
crackmapexec winrm <IP> -u <user> -p <password> -x "whoami"
crackmapexec winrm <IP> -d <Domain> -u <user> -H <HASH> -X '$PSVersionTable'# Shodan-style discovery# port:5985 Microsoft-HTTPAPI
Critical: Checks Most Often Missed
Valid creds ≠ WinRM access — a user must be in the Remote Management Users group (or local admins). Always confirm with crackmapexec winrm before assuming evil-winrm will work; a green (+) with (Pwn3d!) indicates exec.
Unencrypted HTTP listener (5985) → NTLM relay — since impacket 0.11, ntlmrelayx.py can relay captured NTLM to WS-MAN/WinRM for SYSTEM-level code execution. Combine with mitm6/Responder coercion.
OMIGOD (CVE-2021-38647) — Azure Linux agents run OMI exposing WS-MAN on 5985/5986; a logic flaw allows unauthenticated RCE as root by omitting the auth header.
Pass-the-Hash works — evil-winrm authenticates with an NT hash (-H), no cleartext needed.
Kerberos / certificate auth — evil-winrm 3.x supports -k/--spn (Kerberos) and --cert-pem/--key-pem (certificate) for NTLM-disabled or cert-required environments.
Brute force locks accounts — WinRM brute forcing increments the bad-password counter; coordinate with the client and prefer validated single attempts.
How to CONFIRM: WinRM is confirmed configured when Test-WSMan returns protocol/wsmid data, or crackmapexec winrm <IP> responds. Remote-exec capability is confirmed by (Pwn3d!) in crackmapexec output or a successful evil-winrm prompt.
Workflow
Step 1: Enumerate (detect + validate)
nmap -p5985,5986 -sV <IP>
Test-WSMan <IP> # from a Windows host
crackmapexec winrm <IP> -u <user> -p <password> # validate creds
Interactive shell with password/PtH/Kerberos/cert auth, file transfer
impacket ntlmrelayx.py
Relay NTLM to WS-MAN for SYSTEM exec
pypsrp
WinRM/PS-Remoting from Linux (CredSSP, Kerberos)
mitm6 / Responder
Coerce authentication to feed the relay
Common Scenarios
Scenario 1: PtH Interactive Shell
A dumped local admin NT hash is reused: evil-winrm -i <IP> -u Administrator -H <hash> drops an interactive PowerShell shell, confirming lateral movement.
Scenario 2: Remote Management Users Foothold
A low-priv user isn't a local admin but is in Remote Management Users. crackmapexec winrm <IP> -u user -p pass shows (Pwn3d!), and evil-winrm yields a shell for further escalation.
Scenario 3: NTLM Relay to WinRM
An HTTP (5985) listener with no EPA is targeted. mitm6 coerces a victim, and ntlmrelayx.py -t wsman://<IP> relays the auth to add a local admin account.
Scenario 4: OMIGOD on Azure Linux
An Azure VM runs a vulnerable OMI. A crafted WS-MAN request with no auth header executes commands as root (CVE-2021-38647), reported as critical.
Output Format
## WinRM Finding
**Service**: Windows Remote Management (WS-Management)
**Severity**: <Critical|High|Medium>
**Host**: <IP>:5985/5986
**Listener**: <HTTP|HTTPS> **Access**: <none|user|admin/SYSTEM>
### Summary
<What was found: valid creds w/ remote-exec, PtH shell, NTLM relay, OMIGOD>
### Evidence
- Command: <crackmapexec / evil-winrm / ntlmrelayx>
- Output: <(Pwn3d!), shell prompt, relay success, whoami output>
### Access Obtained
| Method | Result |
|--------|--------|
| evil-winrm PtH | PowerShell shell as <user> |
| ntlmrelayx | local admin account created |
### Recommendation
1. Disable the unencrypted HTTP listener; force HTTPS with EPA enabled
2. Restrict Remote Management Users membership to required accounts
3. Patch/remove OMI (>= 1.6.8-1) on Azure Linux and block 5985/5986 from the Internet
4. Enforce strong credentials and monitor Microsoft-Windows-WinRM/Operational (events 91/163/182)
5. Restrict WinRM access to management subnets
