Skip to content
HackIndex.io

WinRM Configuration Enumeration

4 min read Created Jan 4, 2026 Last updated May 15, 2026

This is a post-access check to answer: which listeners are actually live, what auth is allowed, whether HTTP is unsafe, and which quotas will break large commands or long-running ops. Confirm the listener is reachable and auth methods are identified first: see WinRM Endpoint Exposure Check. For credential attacks against the discovered endpoint, see WinRM Brute Force and Password Spray.

WinRM Configuration Enumeration: Listeners

Run on the target inside your WinRM session:

┌──(kali㉿kali)-[~]
└─$ winrm enumerate winrm/config/listener 
Listener
    Address = *
    Transport = HTTP
    Port = 5985
    Enabled = true
    URLPrefix = wsman
Explain command
enumerate Lists all WinRM listeners and their configurations
winrm/config/listener Target resource path for WinRM listener configuration

You care about:

  • Transport and Port: HTTP 5985 vs HTTPS 5986, or non-standard listeners.

  • Address and ListeningOn: whether it’s bound broadly or limited.

  • URLPrefix: usually wsman, useful when an environment is weirdly proxied.

If you see only an HTTPS listener, stop wasting time on 5985 and use SSL options in your tooling.

Service auth and transport hardening

Run on the target:

┌──(kali㉿kali)-[~]
└─$ winrm get winrm/config/service
Explain command
get Retrieves the configuration value for the specified path
winrm/config/service Configuration path for WinRM service settings

Fast reads that change decisions:

  • AllowUnencrypted = true on an HTTP listener means traffic can be cleartext at the WinRM layer. Treat 5985 as hostile and prefer 5986 or a tunnel.

  • Auth block tells you what will work: Kerberos, Negotiate, NTLM, Basic, CredSSP, Certificate.

If Basic = true and AllowUnencrypted = true, that combo is operationally “easy mode” but also the kind of misconfig you document hard. If Basic = true but AllowUnencrypted = false, Basic is still possible but should be constrained to HTTPS.

Client config from the target

Run on the target:

┌──(kali㉿kali)-[~]
└─$ winrm get winrm/config/client
Explain command
get Retrieves configuration settings from the specified WinRM path.
winrm/config/client WinRM configuration path for client settings.

What you’re looking for:

  • TrustedHosts: if it’s * or wide, that host can WinRM to other hosts by IP without strict name constraints. That matters for lateral movement planning from a Windows foothold.

WinRS limits that break real work

Run on the target:

┌──(kali㉿kali)-[~]
└─$ winrm get winrm/config/winrs
┌──(kali㉿kali)-[~]
└─$ winrm get winrm/config
Explain command
get Retrieves the specified WinRM configuration
winrm/config/winrs Configuration path for WinRM remote shell settings
winrm/config Configuration path for WinRM general settings

Pay attention to:

  • MaxMemoryPerShellMB, MaxProcessesPerShell, MaxShellsPerUser: low values cause tools and larger scripts to fail unpredictably.

  • MaxTimeoutms and related service timeouts: long commands get cut off, output truncates, or sessions die mid-task.

If quotas are tight, switch to smaller, chunked commands and stage output to disk instead of trying to stream everything back.

PowerShell WSMan view when winrm get is noisy

If you prefer a navigable tree, use the WSMan provider:

PS C:\Users\Guest\Desktop> Get-ChildItem WSMan:\localhost\Listener
PS C:\Users\Guest\Desktop> Get-ChildItem WSMan:\localhost\Service\Auth
PS C:\Users\Guest\Desktop> Get-Item WSMan:\localhost\Service\AllowUnencrypted

This is often easier to eyeball and script against than the raw winrm get output.

Run the same checks remotely from Kali

If you don’t want an interactive shell, execute the target-side commands over WinRM.

┌──(kali㉿kali)-[~]
└─$ nxc winrm $TARGET_IP -u "$DOMAIN\\$USER" -p "$PASSWORD" -x "winrm enumerate winrm/config/listener"
┌──(kali㉿kali)-[~]
└─$ nxc winrm $TARGET_IP -u "$DOMAIN\\$USER" -p "$PASSWORD" -x "winrm get winrm/config/service"
┌──(kali㉿kali)-[~]
└─$ nxc winrm $TARGET_IP -u "$DOMAIN\\$USER" -p "$PASSWORD" -x "winrm get winrm/config/client"
┌──(kali㉿kali)-[~]
└─$ nxc winrm $TARGET_IP -u "$DOMAIN\\$USER" -p "$PASSWORD" -x "winrm get winrm/config/winrs"

If you want to run PowerShell directly:

┌──(kali㉿kali)-[~]
└─$ nxc winrm $TARGET_IP -u "$DOMAIN\\$USER" -p "$PASSWORD" -X "Get-ChildItem WSMan:\localhost\Listener | Format-List"
Explain command
winrm Protocol module for Windows Remote Management connections
$TARGET_IP Target IP address variable for the remote host
-u Username in DOMAIN\USER format for authentication
$DOMAIN\$USER Domain and username variables for WinRM authentication
-p Password for authentication
$PASSWORD Password variable for the specified user account
-X Execute PowerShell command on remote target
Get-ChildItem WSMan:\localhost\Listener | Format-List PowerShell command to list and format WinRM listeners

NetExec WinRM command execution supports -x and -X.

Edge cases

Access is denied when reading config

Some environments restrict reading WSMan config to admins. If winrm get fails, fall back to endpoint probing from your attacker box to at least learn auth schemes and ports, then escalate before re-checking config.

Config says one thing, behavior says another

If you’re behind a proxy or have multiple listeners, you can end up authenticating against a different front door than the one you’re reading locally. Correlate:

  • listener transport and port

  • what the endpoint actually offers in WWW-Authenticate

  • which URL you’re hitting (/wsman vs custom)

References