Each feed is checked for new posts. Every post is read, and those that belong here join the catalog. What Trove read and did not keep stays on file, not shown.
A researcher reverse-engineers Windows NCSI (ncsi.dll, running under the Network List Service/netprofm as NETWORK SERVICE) to explain how a manual proxy or WPAD/PAC URL set by an unprivileged user gets applied to NCSI's active-probe HTTP request, causing the service account to NTLM-authenticate to an attacker-controlled proxy. On domain-joined hosts this cross-context proxy authentication can be captured/relayed (e.g. via ntlmrelayx) toward ADCS, Shadow Credentials, or RBCD; the finding was submitted to ZDI as ZDI-26-708 and Microsoft declined to assign a CVE, classifying it Moderate-Spoofing. Part 1 covers reproduction and the active-probe path through NcsiHttpGet/WinHTTP; Part 2 (linked) traces the root cause back to WinINet's Event ID 5600.
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.
pgj11.comwriteup