5986
Summary
- // if you see it open
- A successful WinRM authentication grants an interactive PowerShell session — effectively remote code execution as the authenticated user. Internet-facing WinRM (5985/5986) is actively fingerprinted by mass scanners and indexed by Shodan (labeled as a TLS-wrapped WinRM service). Risk centers on credential strength/brute-force and authentication method rather than a flaw in the TLS wrapper of 5986 itself. Community pentest guidance: prefer 5986 (TLS) over plaintext 5985, restrict source IPs/firewall the port, avoid Basic auth without TLS. Sourced to third-party pentest/community write-ups (VeryLazyTech, HackTricks, PentestPad), not vendor security advisories.
- // analyst note
- An internet-exposed 5986 is a Windows-management surface; prefer it over 5985, firewall it to trusted sources, and treat exposure as a credential-strength/brute-force concern rather than a TLS flaw.
About port 5986/tcp.
Port 5986/tcp is registered with IANA as wsmans with the description "WBEM WS-Management HTTP over TLS/SSL," assignee and contact [Jim_Davis], a registration date of 2006-11, and a blank reference field (dual-registered on TCP and UDP). In practice this port is best known as the default endpoint for Windows Remote Management (WinRM) over HTTPS — Microsoft's implementation of the DMTF WS-Management (WS-Man) protocol, the TLS-encrypted counterpart to plaintext WinRM on port 5985. It is the transport behind PowerShell Remoting (Enter-PSSession, Invoke-Command, New-PSSession) and behind remote Windows configuration and automation tooling such as Ansible's winrm connection plugin, Chef, and CI/CD systems (for example Azure DevOps Windows deployment tasks) that run remote scripts against Windows hosts. Enabling WinRM on 5986 is not merely hardening: Microsoft documents that HTTPS listeners require a locally installed Server Authentication certificate whose CN/SAN matches the target hostname, so a valid TLS certificate is a configuration prerequisite rather than an option. From an analyst's perspective, the security story on 5986 is not a flaw in the TLS wrapper itself but the consequence of what lies behind it: a successful WinRM authentication grants an interactive PowerShell session — effectively remote code execution as the authenticated user — so internet-exposed listeners are actively fingerprinted by mass scanners and indexed by Shodan (labeled as a TLS-wrapped WinRM service). Community pentest write-ups (VeryLazyTech, HackTricks, PentestPad — not vendor advisories) consistently recommend preferring 5986 over plaintext 5985, restricting source IPs, and avoiding Basic authentication without TLS; these are general community observations, not verified incident statistics. Note the registration date is recorded from the IANA CSV as 2006-11 (year-month granularity as stored, verified against IANA CSV row 10210).
- IANA assignment
wsmans— "WBEM WS-Management HTTP over TLS/SSL"; reference (blank — no RFC cited in IANA registry); assignee/contact [Jim_Davis]; registration 2006-11; dual-registered 5986/tcp + 5986/udp [Confirmed] — IANA Service Name and Transport Protocol Port Number Registry (the IANA Service Name and Transport Protocol Port Number Registry)- Range class
- registered (1024–49151)
- Registration date
- 2006-11 (year-month granularity as stored in the IANA CSV) [Confirmed] — the IANA Service Name and Transport Protocol Port Number Registry (row 10210, wsmans/5986/tcp)
- IANA reference (RFC)
- blank in source — no protocol-specific RFC surfaced; not fabricated [Confirmed] — IANA registry
- Related ports
- 5985/tcp (WinRM over plaintext HTTP) — the plaintext counterpart to this TLS endpoint
Primary use
WinRM (Windows Remote Management) over HTTPS/TLS — Microsoft's WS-Management implementation; default secure endpoint (contrast plaintext 5985)
Common software
built-in Windows WinRM service; PowerShell Remoting; Ansible winrm plugin, Chef, and CI/CD deployment tooling (e.g., Azure DevOps)
Security implications
successful WinRM auth yields an interactive PowerShell session (effective RCE as that user); internet-facing listeners are fingerprinted/indexed by Shodan; risk is credential-strength/auth-method driven, not a TLS-layer flaw in 5986 itself
- TLS certificate requirement
- HTTPS listener requires a local Server Authentication certificate whose CN/SAN matches the hostname (documented prerequisite, not optional) [Confirmed] — Microsoft Learn (Configure WinRM for HTTPS)
- Analyst note
- An internet-exposed 5986 is a Windows-management surface; prefer it over 5985, firewall it to trusted sources, and treat exposure as a credential-strength/brute-force concern rather than a TLS flaw.
About port 5986/udp.
Port 5986/udp is registered with IANA under the service name wsmans, described as "WBEM WS-Management HTTP over TLS/SSL," with assignee and contact [Jim_Davis], a registration date of 2006-11, and a blank Reference (RFC) field. The same service name and description are dual-registered on 5986/tcp at the adjacent registry row, sharing the identical assignee and registration date — the paired tcp/udp reservation is a common IANA convention rather than proof of a live UDP service. In real-world deployment, port 5986 is used almost exclusively over TCP: it is the default HTTPS listener for Windows Remote Management (WinRM) / WS-Management, carrying encrypted PowerShell Remoting and remote WMI/CIM management of Windows hosts, and serving as the TLS companion to plaintext 5985/tcp. Microsoft's WinRM documentation and multiple independent pentesting references describe only TCP-based operation on this port. No verified, commonly deployed UDP service was found on 5986 — Microsoft docs, WinRM configuration guides, and port-activity trackers consistently describe TCP behavior, and the udp registration appears to be a registry artifact of the paired reservation. For an analyst, a claim of active 5986/udp usage should be treated as unconfirmed: the honest verdict is that the TCP side (WinRM-HTTPS) is the operationally significant one, and any UDP-specific protocol behavior remains Unknown.
- IANA assignment
wsmans— "WBEM WS-Management HTTP over TLS/SSL"; assignee/contact[Jim_Davis]; registration 2006-11; Reference field blank (no RFC cited in registry); dual-registered 5986/tcp + 5986/udp [Confirmed] — the IANA Service Name and Transport Protocol Port Number Registry line 10211; IANA Service Name and Transport Protocol Port Number Registry (https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=5986)- Range class
- registered (1024–49151) [Confirmed]
- Dual registration
- 5986/tcp is registered identically — same service name
wsmans, same description, same assignee[Jim_Davis], same 2006-11 date, Reference also blank [Confirmed] — the IANA Service Name and Transport Protocol Port Number Registry line 10210
Primary use (TCP, for context)
default HTTPS listener for Windows Remote Management (WinRM) / WS-Management — encrypted PowerShell Remoting and remote WMI/CIM management; TLS companion to plaintext 5985/tcp [Likely] — https://learn.microsoft.com/en-us/windows/win32/winrm/installation-and-configuration-for-windows-remote-management ; https://learn.microsoft.com/en-us/troubleshoot/windows-client/system-management-components/configure-winrm-for-https
Common software (TCP)
WinRM / WS-Management stack on Windows Server and client; PowerShell Remoting (Enter-PSSession / Invoke-Command over HTTPS); remote CIM/WMI tooling; RMM/PAM products using WinRM-over-HTTPS (e.g. CyberArk SIA, Lansweeper). All operate over TCP [Likely] — https://learn.microsoft.com/en-us/windows/win32/winrm/installation-and-configuration-for-windows-remote-management ; https://community.lansweeper.com/t5/requirements/ports-scanned-or-used-by-lansweeper/ta-p/64273/
Security implications (TCP)
WinRM-HTTPS is an internal-network pentest target and should not be internet-exposed; brute-force credential attacks against WinRM/PowerShell Remoting are the typical risk. Sources discuss 5986 broadly (tcp/udp together) but describe only TCP exploitation paths; no distinct udp attack surface documented
- UDP-specific use
- no verified real-world UDP service found; udp registration appears to be an IANA paired-reservation artifact rather than a live protocol [Likely] — https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=5986
- Reference / RFC
- blank in the IANA registry — none cited (left blank, not fabricated) [Confirmed] — the IANA Service Name and Transport Protocol Port Number Registry line 10211
- Analyst note
- The operationally meaningful side of 5986 is TCP (WinRM-HTTPS). Treat any claim of active 5986/udp usage as unconfirmed; UDP-specific behavior is Unknown.
Service assignments.
| Name | Protocol | Description | Open frequency |
|---|---|---|---|
| wsmans | TCP | WBEM WS-Management HTTP over TLS/SSL | 0.04% |
| wsmans | UDP | WBEM WS-Management HTTP over TLS/SSL | 0.00% |
Service assignments from the IANA Service Name and Transport Protocol Port Number Registry, with open-frequency data from nmap-services.