Skip to content
HackIndex logo

HackIndex

WinRM Basic Auth Detection

4 min read Mar 29, 2026

Basic authentication over HTTP on WinRM means credentials are transmitted base64-encoded with no transport protection. Anyone with access to the network path can capture and decode them. This is a direct credential exposure finding, not just a configuration observation. It enables password capture via network interception and can be combined with any technique that sends a login attempt over the channel.

The Microsoft default for the WinRM service has Basic authentication disabled (False). When it is enabled, it is almost always a deliberate or misconfigured change. Confirming it is present and active is the goal here.

Detect Basic Auth from Headers

The fastest check is a raw request to the WSMan endpoint:

┌──(kali㉿kali)-[~]
└─$ curl -s -D - -o /dev/null http://$TARGET_IP:5985/wsman 
HTTP/1.1 405 Method Not Allowed
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
WWW-Authenticate: Basic realm="WSMAN"
Server: Microsoft-HTTPAPI/2.0
Explain command
-s Silent mode; suppresses progress meter and error messages.
-D - Dumps HTTP headers to stdout for inspection.
-o /dev/null Writes response body to /dev/null, effectively discarding it.
$TARGET_IP:5985 Target IP address and port 5985 (WinRM HTTP endpoint).
/wsman WinRM web services management endpoint path.

Basic realm="WSMAN" in the WWW-Authenticate header confirms Basic is enabled on the HTTP listener. This is sufficient to document the finding.

Use http-auth-finder to get structured output suitable for reporting:

┌──(kali㉿kali)-[~]
└─$ nmap -Pn -p 5985 --script http-auth-finder $TARGET_IP 
5985/tcp open  http
| http-auth-finder:
|   url                              method
|_  http://10.10.10.5:5985/wsman    HTTP: Negotiate, NTLM, Basic
Explain command
-Pn Skip ping discovery; treat host as online
-p 5985 Scan only port 5985 (WinRM HTTP)
--script http-auth-finder Run http-auth-finder NSE script to find HTTP auth pages
$TARGET_IP Target IP address to scan

Validate That the Service Accepts Basic Credentials

Advertising Basic and actually accepting it are not always the same. If you have valid credentials in scope, confirm the service processes a Basic authentication attempt:

┌──(kali㉿kali)-[~]
└─$ curl -s -i --basic --user "$USER:$PASSWORD" http://$TARGET_IP:5985/wsman
Explain command
-s Silent mode; do not show progress meter or error information.
-i Include response headers in output.
--basic Use HTTP Basic authentication method.
--user Set authentication credentials in format username:password.
$USER:$PASSWORD Variable placeholder for username and password credentials.
$TARGET_IP:5985 Variable placeholder for target IP address and WinRM service port.

A 200 or SOAP fault response confirms the service accepted the Basic credential. A 401 response with the same WWW-Authenticate header means the credentials are wrong, but Basic is still enabled. A 401 response that drops Basic from the header means the service advertises it but does not accept it for the /wsman path, which is rare.

Testing with NTLM for comparison:

┌──(kali㉿kali)-[~]
└─$ curl -s -i --ntlm --user "$USER:$PASSWORD" http://$TARGET_IP:5985/wsman
Explain command
-s Silent mode; suppress progress meter and error messages
-i Include response headers in output
--ntlm Use NTLM authentication mechanism
--user Provide credentials in format username:password
$USER:$PASSWORD Variable placeholder for username and password credentials
$TARGET_IP:5985 Variable placeholder for target IP and WinRM port

If both Basic and NTLM succeed, Basic is the priority finding because of the plaintext exposure. If only NTLM succeeds, document WinRM over unencrypted HTTP with NTLM as a separate but lower-severity issue.

Basic over HTTPS

Basic authentication over HTTPS is not the same finding. TLS provides transport protection, so credentials are not exposed in cleartext. It becomes a concern when the certificate is self-signed, expired, or mismatched, because clients that ignore certificate warnings still receive no real protection. Check the TLS configuration separately if 5986 is open and advertising Basic.

┌──(kali㉿kali)-[~]
└─$ curl -sk -D - -o /dev/null https://$TARGET_IP:5986/wsman
Explain command
-s Silent mode; don't show progress meter or error information.
-k Allow insecure SSL/TLS connections without certificate verification.
-D - Dump HTTP response headers to stdout.
-o /dev/null Write response body to /dev/null (discard output).
$TARGET_IP:5986 Target IP address and port for HTTPS connection.
/wsman URI path for WS-Management protocol endpoint.

If Basic appears here but not on 5985, the risk depends entirely on TLS quality. See the WinRM HTTPS TLS Validation page.

What AllowUnencrypted Means

Basic over HTTP only works when the WinRM service has AllowUnencrypted set to True. By default it is False, meaning the service requires encrypted transport even when other authentication methods are in use. Finding Basic on HTTP confirms AllowUnencrypted is active on this listener, which is the root misconfiguration.

From the target's perspective, this setting is visible in the WinRM configuration:

┌──(kali㉿kali)-[~]
└─$ winrm get winrm/config/service
Explain command
get Retrieves the specified WinRM configuration setting
winrm/config/service Path to the WinRM service configuration object

You cannot run this without access to the target, but the HTTP header confirms the state externally.

Next Steps

If Basic is confirmed on 5985, the logical follow-on is credential testing via Evil-WinRM or nxc to establish whether valid credentials produce a shell. That is exploitation territory and covered in the WinRM exploitation pages.

References