Full Report
0/ TL;DR
Analysis Summary
# Vulnerability: NTLM Relay to Unhardened WinRM HTTPS Endpoint (Lack of Channel Binding)
## CVE Details
- CVE ID: N/A (This appears to be a novel post-exploitation technique/configuration issue rather than a formally assigned CVE at the time of writing/summary.)
- CVSS Score: N/A (Severity is derived from RCE potential, likely High/Critical if exploited successfully against a hardened system configuration.)
- CWE: CWE-290 (Improper Neutralization of Special Elements Used in an URL) or potentially CWE-287 (Improper Authentication) in the context of the NTLM protocol handling when receiving relayed requests.
## Affected Systems
- Products: Microsoft Windows operating systems utilizing the WinRM service.
- Versions: Any version where the WinRM HTTPS listener is configured but Channel Binding is not set to 'Strict' enforcement.
- Configurations: Systems where administrators have disabled the HTTP endpoint (Port 5985) but left the HTTPS endpoint (Port 5986) enabled *without* enforcing NTLM Channel Binding Token (CBT).
## Vulnerability Description
The vulnerability lies in the configuration default of the WinRM HTTPS listener (Port 5986). While communication is encapsulated in TLS, the NTLM authentication layer within that TLS tunnel does not strictly enforce Channel Binding Token (CBT). When CBT is set to "Relaxed" (the operational default when using self-signed or certain certificates without strict configuration), an attacker can relay NTLM credentials (e.g., captured via HTTP coercion) over the network to the WinRM HTTPS endpoint. Because CBT is optional in this state, the server accepts the relayed authentication, allowing the attacker to execute commands remotely via XML-based WinRM shell creation payloads. This threat is particularly relevant on systems hardened against standard NTLMRelay attacks by disabling HTTP listeners, as this forces attackers towards the less protected WinRMS configuration.
## Exploitation
- Status: PoC available (Implied through integration into NTLMRelayX and demonstration videos/references mentioned in the original article).
- Complexity: Low (Requires an attacker to coerce NTLM authentication from a target machine that can reach the vulnerable WinRM listener, often facilitated by existing internal network relays/tools like NTLMRelayX.)
- Attack Vector: Network (Requires network reachability to the target WinRM endpoint).
## Impact
- Confidentiality: High (Can lead to execution under the identity of the relayed user, potentially accessing sensitive data).
- Integrity: High (Successful exploitation allows for remote command execution (RCE)).
- Availability: High (Attacker can disrupt services via command execution).
## Remediation
### Patches
- No CVE-specific patch is detailed, as the issue is primarily configuration-based. Ensure the operating system is fully patched, though the fix primarily relies on configuration hardening.
### Workarounds
The primary workaround is to configure the WinRM service to strictly enforce Channel Binding for all authentication:
1. **Enable Strict Channel Binding Enforcement:**
Execute the following PowerShell command on the affected server:
powershell
winrm set winrm/config/service/auth '@{CbtHardeningLevel="Strict"}'
2. **Firewall Configuration:** Ensure port 5986 is properly restricted if not needed, though hardening CBT prevents successful relay even if the port is open.
## Detection
- **Indicators of Compromise:** Look for unusual WinRM XML traffic directed at the server over port 5986, specifically involving `wsman:Shell/Cmd` requests originating from unexpected internal hosts immediately following an NTLM challenge response.
- **Detection Methods and Tools:** Monitoring network traffic or endpoint logs for the initiation of WinRM shell creation sequences without corresponding legitimate administrative interaction. Security solutions should detect NTLM relay attempts targeting WinRM services.
## References
- [Vendor advisories]: N/A (Implied configuration setting adjustments).
- [Relevant links - defanged]:
- Proof of concept foundation mentioned: hxxps://github.com/jmk-foofus/impacket/issues/1
- NTLMRelayX Pull Request: hxxps://github.com/fortra/impacket/pull/1947
- Original blog post source: hxxps://blog.whiteflag.io