Skip to content
HackIndex logo

HackIndex

WinRM HTTPS TLS Validation

1 min read Mar 29, 2026

WinRM over HTTPS on 5986 is usually the preferred deployment. The vulnerability work is in the TLS layer: weak protocol support, weak ciphers, broken certificate trust, and name mismatches.

Start by pulling the certificate and handshake details.

┌──(kali㉿kali)-[~]
└─$ openssl s_client -connect $TARGET_IP:5986 -servername $DOMAIN </dev/null
Explain command
-connect $TARGET_IP:5986 Connects to the specified host and port for TLS/SSL testing
-servername $DOMAIN Specifies the SNI hostname to request from the server
</dev/null Redirects empty input to stdin, closing connection immediately

This gives you the server certificate, issuer, validity window, selected cipher, and handshake outcome. You are looking for anything that weakens identity or transport protection:

  • expired certificate

  • self-signed certificate where enterprise trust is expected

  • common name or subject alternative name mismatch

  • TLS 1.0 or 1.1 support

  • weak ciphers

Enumerate supported TLS versions and ciphers

Use Nmap to map the full HTTPS posture.

┌──(kali㉿kali)-[~]
└─$ nmap -Pn -p 5986 --script ssl-cert,ssl-enum-ciphers $TARGET_IP 
| ssl-enum-ciphers:
|   TLSv1.0:
|     ciphers:
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA
|   TLSv1.2:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
Explain command
-Pn Skip ping discovery; treat host as online
-p 5986 Scan only port 5986
--script ssl-cert,ssl-enum-ciphers Run NSE scripts to extract SSL cert and enumerate ciphers
$TARGET_IP Target IP address or hostname to scan

ssl-cert surfaces certificate details. ssl-enum-ciphers shows what protocol versions and cipher suites the listener accepts.

If TLS 1.0 is enabled or 3DES and static RSA suites are accepted, the service is behind current hardened baselines. That is enough to document even if stronger ciphers also exist.

Check certificate name and trust expectations

If the certificate does not match the hostname operators actually use, users often bypass warnings. That turns HTTPS into checkbox security.

Inspect the certificate fields directly:

┌──(kali㉿kali)-[~]
└─$ openssl s_client -connect $TARGET_IP:5986 -servername $DOMAIN </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltName
Explain command
-connect $TARGET_IP:5986 Connect to target IP and port 5986
-servername $DOMAIN Set SNI hostname for the connection
</dev/null Redirect stdin from /dev/null to close connection
2>/dev/null Discard stderr output
-noout Do not output the certificate itself
-subject Display certificate subject
-issuer Display certificate issuer
-dates Display certificate validity dates
-ext subjectAltName Display subject alternative names extension

What changes your next move:

  • If the certificate is self-signed on an internal lab host, note it but weigh the exposure realistically.

  • If the certificate is self-signed or mismatched on production admin infrastructure, document it as a trust-model failure.

  • If the certificate is expired, operators are likely ignoring validation errors already.

Confirm the listener is actually WinRM

Do not assume every HTTPS service on 5986 is configured correctly. Confirm it is the WSMan endpoint.

┌──(kali㉿kali)-[~]
└─$ curl -sk -i https://$TARGET_IP:5986/wsman
Explain command
-s Silent mode; do not show progress meter or error information.
-k Allow insecure SSL/TLS connections without certificate verification.
-i Include response headers in output.
$TARGET_IP:5986 Target IP address and port for the HTTPS request.
/wsman URI path for Windows Remote Management service endpoint.

A 401 or 405 with WinRM-style headers is enough. If the certificate is weak and the listener also advertises Basic authentication, combine both issues in one finding chain because the TLS weakness directly affects credential safety.

Fast protocol checks with OpenSSL

When you want a quick yes or no on legacy protocol support:

┌──(kali㉿kali)-[~]
└─$ openssl s_client -connect $TARGET_IP:5986 -tls1 </dev/null
┌──(kali㉿kali)-[~]
└─$ openssl s_client -connect $TARGET_IP:5986 -tls1_1 </dev/null
┌──(kali㉿kali)-[~]
└─$ openssl s_client -connect $TARGET_IP:5986 -tls1_2 </dev/null
Explain command
-connect Specifies the server hostname and port to connect to
$TARGET_IP:5986 Target IP address and WinRM-HTTPS port placeholder
-tls1 Forces TLS version 1.0 for the connection
-tls1_1 Forces TLS version 1.1 for the connection
-tls1_2 Forces TLS version 1.2 for the connection
</dev/null Redirects null input to stdin to close connection immediately

A successful handshake on -tls1 or -tls1_1 is usually enough to call out legacy protocol support.

What the output changes

If only TLS 1.2 or better is enabled and the certificate is valid:

  • HTTPS is probably not the weak point.

  • Move to authorization checks and auth method review.

If legacy TLS is enabled:

  • Document the protocol and any weak ciphers.

  • Check whether WinRM is exposed only internally or across broader network segments.

If the certificate is mismatched, expired, or self-signed in a place where enterprise trust should exist:

  • Document user validation bypass risk.

  • Re-check whether Basic authentication is also enabled.

Legacy scanners

┌──(kali㉿kali)-[~]
└─$ sslscan $TARGET_IP:5986

References