Skip to content

Back to the catalog

pgj11.comwriteup

Microsoft Windows NCSI Cross-Context Proxy Authentication Coercion - ZDI-26-708 - Part 2

Part 2 of a research series on ZDI-26-708, a Windows Network Connectivity Status Indicator (NCSI) flaw where a proxy configured in an unprivileged user's HKCU ends up used by the NETWORK SERVICE-owned netprofm process. The author reverse-engineers ncsi.dll and winhttp.dll with IDA/WinDbg to show the value actually arrives via a Windows Event Log subscription to Event ID 5600 (Microsoft-Windows-WinINet-Config) rather than the WNF notification initially suspected, is stored in NCSI's user-proxy state, and is later applied to a WinHttpSetOption(38) call for an active connectivity probe. It documents why option 193 (WINHTTP_OPTION_DISABLE_PROXY_AUTH_SCHEMES) fails to disable NTLM (wrong bitmask, 0x100 vs 0x04), and demonstrates cross-context NTLM proxy authentication capture/relay with impacket-ntlmrelayx toward ADCS, since the request runs under the netprofm/NETWORK SERVICE machine-account context.

TL;DR Deep-dive tracing how Windows NCSI leaks an unprivileged user's proxy config into a NETWORK SERVICE-context WinHTTP request, enabling NTLM machine-account relay (ZDI-26-708).
Open original ↗
Document

What it is

Part 2 of the ZDI-26-708 write-up on Windows NCSI cross-context proxy authentication coercion. It nails down the data path the summary describes and — more usefully for a decision — bounds the actual impact and lists mitigations available before any Microsoft fix.

Preconditions / Affected

An unprivileged interactive user sets a WinINet proxy in their own HKCU. That change emits Event ID 5600 (Microsoft-Windows-WinINet-Config); NCSI's netprofm service, running as NETWORK SERVICE, consumes it via EvtSubscribe/EvtRender and stores it as user-proxy metadata with no user/session identity attached. A later WNF notification triggers a probe type 4/5 that applies the stored proxy via WinHttpSetOption(38). The request then authenticates (NTLM) as the service principal, not the user who supplied the proxy.

What to do

No patch is referenced (pre-disclosure ZDI advisory). Defensive levers the page identifies:

  • Set proxy configuration machine-wide instead of per-user. NCSI's LoadManualProxies reads HKLM\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters\Internet\ManualProxies — an administrator-controlled source that avoids the coerced per-user path.
  • Watch for NETWORK SERVICE / machine-account NTLM authenticating to proxies, especially loopback/local proxy addresses (the 0x100 local-service flag path).

Caveats

The machine-account relay (e.g. to ADCS) is environment-dependent, not a universal chain. On a domain-joined host NETWORK SERVICE authenticates as the computer account, and the 0x100 (WINHTTP_PROXY_DISABLE_AUTH_LOCAL_SERVICE) flag NCSI passes to option 193 specifically forces local-machine-account use for local/loopback proxies. So relayability depends on the target and configuration.

Note also the author's own corrections: option 193 does not "ignore" an NTLM-disable bit — NCSI simply never sets 0x04; the call succeeds, and its failure-only log message says nothing about whether NTLM was actually disabled. WNF carries the trigger, never the proxy string.

Organisations named here

  • Event ID 5600
  • Windows Notification Facility

Technologies named here

  • Microsoft Windows NCSI
  • IDA
  • Windows netprofm service
  • WinDbg
  • WinHTTP
  • ChatGPT
  • WinINet
  • Event Viewer
  • impacket-ntlmrelayx
  • Windows Event Log API
  • Windows
  • Impacket

Techniques named here

  • Cross-context proxy authentication coercion
  • Event Log subscription abuse
  • WNF as trigger, not data carrier
  • NTLM relay to proxy authentication
  • Failure to disable NTLM proxy auth scheme
  • NTLM relay

Also named here

  • ZDI-26-708

Related in Offensive Security