Port 5986 – WSMAN-SSL (Windows Remote Management)

Port 5986 is the default port for WinRM over HTTPS (WSMAN-SSL) — the TLS-encrypted transport for Windows Remote Management and PowerShell Remoting, and the secure counterpart to plain WinRM on port 5985. Where 5985 carries the WS-Management (WS-Man) SOAP exchange over HTTP, 5986 wraps the entire session in TLS from the first byte — the same dedicated-TLS-port pattern as HTTPS on 443 or LDAPS on 636, where the secure variant gets its own port instead of upgrading in place. Microsoft’s guidance is to prefer 5986 precisely because it removes the cleartext-credential risk that Basic auth over 5985 can create. But TLS only protects you when the certificate is valid and actually validated: a self-signed cert that clients trust with -SkipCACheck/-SkipCNCheck turns the encryption into theater and reopens the door to man-in-the-middle. This page covers the HTTPS/WSMAN-SSL angle; for the full WinRM credentialed-RCE and lateral-movement playbook (Evil-WinRM, NetExec, pass-the-hash), see the combined WinRM page for ports 5985/5986.

Why It’s Open

WinRM is enabled by default on Windows Server 2012 and later and switched on across managed fleets by Group Policy, Enable-PSRemoting, or winrm quickconfig. By default that listener answers on 5985/HTTP; 5986/HTTPS appears the moment an administrator adds an HTTPS listener bound to a server certificate — done deliberately in security-conscious environments, pushed by hardening baselines (CIS, DISA STIG), or required by tooling like Ansible’s winrm connection configured for SSL. You’ll find 5986 on domain controllers, jump boxes, member servers, and build agents that have been told to run WinRM the encrypted way. Where 5986 answers, the rest of the Windows management surface is usually one scan away — RDP on 3389, SMB, Kerberos, and very often the plain WinRM/HTTP listener on 5985, which frequently stays open alongside 5986. The presence of 5986 is a good sign — someone chose encryption — but it is still a credentialed remote-execution service, so it earns the same scrutiny as any other admin channel.

Common Risks

• Certificate weaknesses enabling MITM. Self-signed, expired, or weak-key certificates on 5986 mean any client that skips validation can be man-in-the-middled — the “encrypted” session simply terminates at the attacker’s certificate. This is the most common way HTTPS WinRM becomes encryption theater.
• Skipped certificate validation. The convenience flags -SkipCACheck and -SkipCNCheck (via New-PSSessionOption) are extremely common in the field to make self-signed certs “just work.” They disable the exact protection 5986 exists to provide, making relay/MITM of the whole session possible.
• Weak TLS protocols and ciphers. SSLv3/TLS 1.0, RC4, or export ciphers on the 5986 listener open downgrade and decryption attacks against the transport.
• The same credentialed remote execution once authenticated. TLS protects the channel, not authorization. A valid credential or NT hash over 5986 still grants a full remote PowerShell session — identical to 5985. The complete lateral-movement and pass-the-hash tooling lives on the combined WinRM page; all of it applies here, just inside TLS.
• Shared http.sys attack surface. 5986 listens on the same Windows HTTP Protocol Stack (http.sys) as 5985, so the pre-auth http.sys RCEs reach it too (see CVEs below).
• Internet exposure. 5986 should never face the internet. HTTPS makes brute-force quieter but no less effective — an exposed listener is still a password-spraying target and a direct remote-code-execution path the instant a credential is found.

Want to save time on reporting?

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

Book a Demo

Enumeration & Testing

Detect the service

nmap -sV -p 5986 <target>

Nmap fingerprints the 5986 listener as SSL-wrapped Microsoft HTTPAPI httpd — the TLS twin of the 5985 http.sys listener.

Inspect the certificate and TLS configuration

openssl s_client -connect <target>:5986

nmap -p 5986 --script ssl-cert,ssl-enum-ciphers <target>

testssl.sh <target>:5986

openssl s_client prints the certificate chain, and this is where 5986 gives you free reconnaissance: the Subject/CN and SAN usually leak the Windows hostname and domain (WinRM HTTPS certs are typically issued to the machine’s FQDN), while the validity dates and issuer reveal self-signed vs CA-issued at a glance. ssl-enum-ciphers grades every protocol and cipher the listener accepts, exposing any SSLv3/TLS 1.0/RC4 support.

The key distinction from 5985: only the SOAP body is protected there (and only when Negotiate is used), whereas 5986 encrypts the entire transport — so on the wire you see a TLS handshake, not raw WS-Management SOAP.

Confirm it is really WinRM and test a credential

# native check, forcing SSL/5986
Test-WSMan -ComputerName <target> -UseSSL -Authentication Negotiate
Enter-PSSession -ComputerName <target> -UseSSL -Credential (Get-Credential)

# Evil-WinRM speaks to 5986 with -S (SSL)
evil-winrm -i <target> -u <user> -p <pass> -S

For the full authentication, spraying, and pass-the-hash workflow (NetExec/CrackMapExec, Metasploit’s winrm_auth_methods/winrm_login/winrm_cmd), use the combined WinRM page — it applies identically over 5986, you just add the SSL flag.

Record every 5986 host, its certificate (self-signed/expired?), the TLS versions it accepts, and any credential that works so the evidence lands in the pentest report instead of a scratch terminal.

What to Look For

Known CVEs and Exploits

Like plain WinRM, most real-world “attacks” on 5986 are credentialed feature-abuse, not exploits — a valid credential drives PowerShell remotely exactly as designed, and there is no CVE to patch for that. The genuine CVEs that reach 5986 sit in the shared HTTP stack, and the honest answer on the famous TLS bug is that it does not apply here:

• CVE-2021-31166 — HTTP Protocol Stack (http.sys) use-after-free giving unauthenticated, wormable remote code execution, CVSS 3.1 base 9.8 (Critical). Because WinRM’s HTTPS listener runs on the same http.sys as the HTTP one, 5986 reaches the vulnerable stack just as 5985 does (Windows 10 / Server 2004 and 20H2). Listed in CISA’s Known Exploited Vulnerabilities catalog.
• CVE-2022-21907 — the same wormable, pre-auth http.sys RCE class, CVSS 3.1 base 9.8 (Critical), reaching Windows 10/11 and Server 2019 / 2022 / 20H2. Any listener on http.sys, 5986 included, exposes the code path. These are HTTP-stack bugs, not WS-Management flaws — the combined WinRM page covers them in depth, so don’t double-count them per port.

On Heartbleed (CVE-2014-0160): it is worth stating plainly that Heartbleed does not apply to Windows WinRM over HTTPS. Heartbleed is an OpenSSL memory-disclosure bug, and Windows terminates TLS with Schannel, not OpenSSL — so a standard Windows 5986 listener is not exposed to it. The only way Heartbleed becomes relevant on 5986 is a non-Windows, OpenSSL-based WS-Management implementation (for example openwsman fronted by a vulnerable OpenSSL), which is rare in practice. Do not flag Heartbleed on a Windows host just because 5986 speaks TLS.

Note also: earlier versions of this reference listed CVE-2020-1472 (Zerologon) here — that is a Netlogon elevation-of-privilege flaw, unrelated to WinRM or TLS on 5986, and it has been removed as mislabeled.

Mitigation

• Use 5986/HTTPS with a valid, CA-issued certificate — and enforce validation. This is the entire point of the port. Issue the WinRM listener a certificate from your internal PKI that matches the host FQDN, and never let clients connect with -SkipCACheck/-SkipCNCheck in production — that silently discards the protection and hands an attacker a man-in-the-middle.
• Enforce TLS 1.2+ with strong ciphers. Disable SSLv3, TLS 1.0/1.1, RC4, and export ciphers on the Schannel stack, and confirm with ssl-enum-ciphers or testssl.sh.
• Prefer 5986 and close 5985 where you can. If the HTTPS listener is available, disable or firewall the HTTP listener so Basic-auth cleartext on 5985 isn’t even an option. Where 5985 must stay, at minimum set AllowUnencrypted="false" and Basic="false".
• Never expose WinRM to the internet. Firewall TCP 5985 and 5986 so they answer only from a dedicated management network or jump box.
• Restrict who can connect, and patch the stack. Tightly scope membership of the Remote Management Users and local Administrators groups, keep Windows current so the http.sys RCEs are closed, and layer Just Enough Administration (JEA), LAPS, and MFA on privileged accounts. The combined WinRM page has the full credential-hardening checklist.

Real-World Example

The classic 5986 failure is the same one that plagues LDAPS: encryption theater. A team is told to “run WinRM over HTTPS,” so an admin enables an HTTPS listener with a quickly generated self-signed certificate and moves on. To make connections succeed without deploying that certificate to every management client, they wire the automation to skip validation — New-PSSessionOption -SkipCACheck -SkipCNCheck, or Ansible’s ansible_winrm_server_cert_validation: ignore, or Evil-WinRM’s -S flag pointed at an untrusted cert. Now every session is encrypted — but to any certificate, because nothing is verified. An attacker positioned on the management path (ARP spoofing, a rogue DHCP/DNS answer, or a compromised switch) stands up their own 5986 listener, presents a certificate the client accepts blindly, and relays or reads the WS-Management exchange — credentials included — on the way through. The padlock is real and a passive sniffer sees only TLS, yet the session is fully exposed to an active man-in-the-middle. It’s the clearest reminder that 5986 protects you only when the certificate is CA-issued and validated — turning on HTTPS is step one, not the whole job. Separately, because 5986 shares the http.sys stack, when the wormable CVE-2021-31166 landed in 2021, HTTPS WinRM listeners were reachable for pre-auth exploitation just like the HTTP ones — another reason to keep 5986 firewalled and patched.

FAQ

What is port 5986 used for?

Port 5986 is the default port for WinRM (Windows Remote Management) over HTTPS — labeled WSMAN-SSL. It carries the same WS-Management and PowerShell Remoting traffic as port 5985, but wrapped in TLS from the first byte, so credentials and command output are encrypted on the wire. It is the secure, preferred transport for remotely administering Windows.

What is the difference between port 5985 and 5986?

Both carry WinRM. 5985 is WinRM over HTTP; 5986 is WinRM over HTTPS (TLS). On 5985 only the SOAP message body is protected — and only when Negotiate/Kerberos is used — so Basic auth with AllowUnencrypted=true can leak credentials in cleartext. 5986 wraps the entire transport in TLS and authenticates the endpoint with a certificate, which is why Microsoft recommends it. See the combined WinRM page for the full comparison and the credentialed-attack detail.

Is port 5986 TCP or UDP?

TCP. WinRM’s WS-Management traffic — HTTP on 5985 and HTTPS on 5986 — runs over TCP. There is no standard UDP equivalent.

Is WinRM over HTTPS on 5986 secure?

It is the secure option, but not automatically safe. 5986 is only as strong as its certificate and TLS configuration: a self-signed cert that clients accept with -SkipCACheck/-SkipCNCheck can be man-in-the-middled, and weak protocols invite downgrade attacks. TLS also protects the channel, not authorization — a valid credential or NT hash still grants a full remote shell over 5986. Prefer 5986 over 5985, but pair it with a validated CA-issued certificate and strict credential hygiene.

What is WSMAN-SSL?

WSMAN-SSL is the service label for WS-Management over SSL/TLS — Microsoft’s WinRM protocol running over HTTPS on port 5986. It is the encrypted counterpart to plain WS-Management (WinRM over HTTP) on 5985.

TL;DR

• Service: WinRM over HTTPS (WSMAN-SSL) — the TLS-encrypted transport for Windows Remote Management and PowerShell Remoting
• Default port: 5986 TCP (cleartext/HTTP sibling: WinRM on 5985; same dedicated-TLS-port pattern as 443 and 636)
• Biggest risk: certificate/validation weaknesses (self-signed + -SkipCACheck → MITM) plus the same credentialed remote PowerShell once authenticated, and the shared http.sys RCEs
• Mitigation: valid CA-issued cert with enforced validation, TLS 1.2+, keep WinRM off the internet, restrict Remote Management Users, patch http.sys, and see the combined WinRM page for full credential hardening