# WinRM Configuration Enumeration

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

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](https://hackindex.io/services/winrm/vulnerability-discovery/winrm-endpoint-exposure-check). For credential attacks against the discovered endpoint, see [WinRM Brute Force and Password Spray](https://hackindex.io/services/winrm/exploitation/brute-force-password-spray).

## WinRM Configuration Enumeration: Listeners

Run on the target inside your WinRM session:

```bash
winrm enumerate winrm/config/listener
# Listener
#     Address = *
#     Transport = HTTP
#     Port = 5985
#     Enabled = true
#     URLPrefix = wsman
#
```

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:

```bash
winrm get winrm/config/service
```

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:

```bash
winrm get winrm/config/client
```

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:

```bash
winrm get winrm/config/winrs
winrm get winrm/config
```

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:

```powershell
Get-ChildItem WSMan:\localhost\Listener
Get-ChildItem WSMan:\localhost\Service\Auth
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.

```bash
nxc winrm $TARGET_IP -u "$DOMAIN\\$USER" -p "$PASSWORD" -x "winrm enumerate winrm/config/listener"
nxc winrm $TARGET_IP -u "$DOMAIN\\$USER" -p "$PASSWORD" -x "winrm get winrm/config/service"
nxc winrm $TARGET_IP -u "$DOMAIN\\$USER" -p "$PASSWORD" -x "winrm get winrm/config/client"
nxc winrm $TARGET_IP -u "$DOMAIN\\$USER" -p "$PASSWORD" -x "winrm get winrm/config/winrs"
```

If you want to run PowerShell directly:

```bash
nxc winrm $TARGET_IP -u "$DOMAIN\\$USER" -p "$PASSWORD" -X "Get-ChildItem WSMan:\localhost\Listener | Format-List"
```

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

- [Installation and configuration for WinRM](https://learn.microsoft.com/en-us/windows/win32/winrm/installation-and-configuration-for-windows-remote-management) - Documents winrm enumerate winrm/config/listener and listener concepts
- [Configure WinRM for HTTPS](https://learn.microsoft.com/en-us/troubleshoot/windows-client/system-management-components/configure-winrm-for-https) - Confirms default ports and validating listeners
- [about_WSMan_Provider](https://learn.microsoft.com/en-us/powershell/module/microsoft.wsman.management/about/about_wsman_provider) - WSMan drive structure for enumerating WSMan configuration
- [about_Remote_Troubleshooting](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_remote_troubleshooting) - Notes on WSMan quotas and timeouts that impact remoting reliability
- [NetExec WinRM Command Execution](https://www.netexec.wiki/winrm-protocol/command-execution) - -x and -X remote execution patterns