Skip to content
HackIndex logo

HackIndex

WinRM Credential Validation

6 min read May 15, 2026

The goal is to confirm: does WinRM accept these creds, on 5985/5986, with NTLM/Kerberos/Basic, and whether you’re authenticating as domain or local. Once you have a clean “works”, you can pivot into execution or an interactive shell.

Fast path

If you already know WinRM is up:

┌──(kali㉿kali)-[~]
└─$ nxc winrm $TARGET_IP -u $USER -p $PASSWORD 
WINRM       192.168.255.131 5985   ROGER            [*] http://192.168.255.131:5985/wsman
WINRM       192.168.255.131 5985   ROGER            [+] GOLD\user:password (Pwn3d!)
Explain command
winrm Protocol module for Windows Remote Management connections
$TARGET_IP Target IP address variable
-u Username for authentication
$USER Username variable placeholder
-p Password for authentication
$PASSWORD Password variable placeholder

Expected signals:

  • (+)... (Pwn3d!) means auth succeeded and you have usable access via WinRM.

  • (-) ... Failed to authenticate ... means creds are wrong, blocked, or the offered auth method doesn’t match what the service accepts.

If you suspect HTTPS WinRM:

┌──(kali㉿kali)-[~]
└─$ nxc winrm $TARGET_IP -u $USER -p $PASSWORD --port 5986
Explain command
$TARGET_IP Target host IP address to scan
-u $USER Username for authentication
-p $PASSWORD Password for authentication
--port 5986 Specify WinRM port (HTTPS)

If your target uses a non-standard port:

┌──(kali㉿kali)-[~]
└─$ nxc winrm $TARGET_IP --port $PORT -u $USER -p $PASSWORD
Explain command
winrm Protocol module for Windows Remote Management authentication/exploitation
$TARGET_IP Target host IP address or hostname to connect to
--port Specify custom port for the WinRM service connection
$PORT Port number variable for WinRM service (typically 5985 or 5986)
-u Username for authentication
$USER Variable containing the username credential
-p Password for authentication
$PASSWORD Variable containing the password credential

Domain vs local user format

If you have a domain, be explicit:

┌──(kali㉿kali)-[~]
└─$ nxc winrm $TARGET_IP -u "$DOMAIN\\$USER" -p $PASSWORD
Explain command
winrm Protocol to target for exploitation/enumeration
$TARGET_IP IP address or hostname of the target system
-u Username for authentication, in domain\user format
$DOMAIN\$USER Domain and username credentials for the target
-p Password for authentication
$PASSWORD Password value for the specified user account

If you’re testing local accounts, also be explicit:

┌──(kali㉿kali)-[~]
└─$ nxc winrm $TARGET_IP -u ".\\$USER" -p $PASSWORD
Explain command
winrm Protocol to use for connection (Windows Remote Management)
$TARGET_IP Target IP address or hostname to connect to
-u Username for authentication
.\$USER Local user account in domain\user format
-p Password for authentication
$PASSWORD Password value for the specified user

What to do with results:

  • If "$DOMAIN\\$USER" fails but ".\\$USER" works, you’re in local-account land. Don’t assume AD paths for this identity.

  • If you only get success when the domain is included, lock $DOMAIN in and reuse that format across other protocols.

SMB is closed or filtered

NetExec often tries to pull extra context via SMB. If 445 is closed or filtered, avoid the SMB dependency by setting the domain explicitly:

┌──(kali㉿kali)-[~]
└─$ nxc winrm $TARGET_IP -u $USER -p $PASSWORD -d $DOMAIN
Explain command
winrm Specifies WinRM protocol for remote Windows management connections
$TARGET_IP Target host IP address to connect to
-u $USER Username for authentication
-p $PASSWORD Password for authentication
-d $DOMAIN Domain name for domain-based authentication

This matters when WinRM is exposed but SMB isn’t, common on segmented networks or hardened hosts.

Password spraying over WinRM

One password across many users — for a dedicated spraying workflow see WinRM Brute Force and Password Spray:

┌──(kali㉿kali)-[~]
└─$ nxc winrm $TARGET_IP -u users.txt -p $PASSWORD --no-bruteforce --continue-on-success
Explain command
winrm Specifies WinRM protocol as the target service
$TARGET_IP Target IP address variable placeholder
-u users.txt Specifies file containing usernames for authentication
-p $PASSWORD Specifies password or password variable placeholder
--no-bruteforce Disables brute-force attack mode
--continue-on-success Continues execution after finding valid credentials

Userlist + passwordlist combo (still keep it controlled to avoid lockouts):

┌──(kali㉿kali)-[~]
└─$ nxc winrm $TARGET_IP -u users.txt -p passwords.txt --no-bruteforce 
WINRM  $TARGET_IP 5985  HOSTNAME  [-] $DOMAIN\$USER:$PASSWORD "Failed to authenticate ... with ntlm"
WINRM  $TARGET_IP 5985  HOSTNAME  [+] $DOMAIN\alice:Winter2026! (Pwn3d!)
Explain command
$TARGET_IP Target IP address or hostname to attack
-u users.txt File containing list of usernames to test
-p passwords.txt File containing list of passwords to test
--no-bruteforce Disable bruteforce mode; use only provided credentials

Next move:

  • Any (Pwn3d!) result is a green light to attempt command exec or an interactive session via Evil-WinRM.

  • Repeated failures with a known-good password elsewhere often means WinRM auth method mismatch, policy restrictions, or the account isn’t allowed WinRM logon.

Pass-the-hash validation

If you have an NT hash and want to see if it’s usable over WinRM, validate with Evil-WinRM first. It’s a clean “does this hash open a WinRM session” test.

┌──(kali㉿kali)-[~]
└─$ evil-winrm -i $TARGET_IP -u $USER -H <NTHASH>
Explain command
-i $TARGET_IP Specifies the target IP address to connect to
-u $USER Specifies the username for authentication
-H <NTHASH> Specifies the NTLM hash for pass-the-hash authentication

If WinRM is on 5986:

┌──(kali㉿kali)-[~]
└─$ evil-winrm -i $TARGET_IP -u $USER -H <NTHASH> -S
Explain command
-i Specify target IP address
$TARGET_IP Placeholder for target IP address
-u Specify username for authentication
$USER Placeholder for username
-H Specify NTLM hash for authentication
<NTHASH> Placeholder for NTLM hash value
-S Use SSL/TLS for secure connection

Interpretation:

  • If the session opens, the hash is good for WinRM lateral movement.

  • If it fails but works on SMB elsewhere, WinRM may be restricted or only allowing Kerberos, or the listener is behind a proxy that behaves differently.

Kerberos credential validation

Kerberos only makes sense if you can resolve the target properly and have realm config. Use the FQDN for Kerberos auth whenever possible.

Get a ticket:

C:\Users\Guest\Desktop> kinit $USER@$DOMAIN
C:\Users\Guest\Desktop> klist
Explain command
$USER@$DOMAIN Principal name (username and realm) for Kerberos authentication
klist Lists cached Kerberos credentials and ticket information

Then use Evil-WinRM with Kerberos, passing the realm:

┌──(kali㉿kali)-[~]
└─$ evil-winrm -i $TARGET_IP -r $DOMAIN
Explain command
-i $TARGET_IP Specify the target IP address to connect to
-r $DOMAIN Specify the domain for authentication

If you have a ticket cache file (ccache/kirbi):

┌──(kali㉿kali)-[~]
└─$ evil-winrm -i $TARGET_IP -r $DOMAIN -K /path/to/ticket.ccache
Explain command
-i $TARGET_IP Target IP address to connect to
-r $DOMAIN Domain name for authentication
-K /path/to/ticket.ccache Path to Kerberos ticket cache file for authentication

What to do with results:

  • Kerberos success is your “cleanest” auth path in AD environments. Prefer it when you can, especially if NTLM is restricted.

  • If Kerberos fails but NTLM succeeds, you likely have DNS/SPN/realm issues, not bad creds.

Validate the WinRM endpoint you’re hitting

If you’re seeing inconsistent behavior, set the explicit endpoint path (common default is /wsman):

┌──(kali㉿kali)-[~]
└─$ evil-winrm -i $TARGET_IP -u $USER -p $PASSWORD -U /wsman
Explain command
-i $TARGET_IP Target IP address to connect to
-u $USER Username for authentication
-p $PASSWORD Password for authentication
-U /wsman URI path for WinRM endpoint

If the port is not 5985:

┌──(kali㉿kali)-[~]
└─$ evil-winrm -i $TARGET_IP -u $USER -p $PASSWORD -P $PORT -U /wsman
Explain command
-i $TARGET_IP Specify the target IP address to connect to
-u $USER Username for authentication
-p $PASSWORD Password for authentication
-P $PORT Port number for WinRM connection
-U /wsman URI path for WinRM endpoint

What to do next

If creds validate cleanly:

  • Move straight into WinRM execution or an interactive shell workflow.

  • If it’s a domain account, reuse the same identity format across SMB/LDAP/RDP checks.

If creds fail but you’re confident they’re correct:

  • Re-check which auth schemes are offered on the endpoint and whether you’re testing the right port and path.

  • If only 5986 is open, stop testing 5985.

  • If SMB is blocked, make sure you used -d $DOMAIN with nxc winrm.

References