By Peter Gabaldon (X / LinkedIn)
From Low-Priv to Local Admin: Weaponizing Windows NCSI for Proxy Coercion and AD CS Relay
In the world of internal network penetration testing, the holy grail is often finding a way to bridge the gap between a low-privileged initial foothold and full administrative control. While we often look for unquoted service paths or vulnerable drivers, sometimes the most devastating attack paths hide in plain sight—inside the everyday mechanisms Windows uses to keep us connected.
In a recent engagement, we leveraged a vulnerability in the Windows Network Connectivity Status Indicator (NCSI) to pull off a complete local privilege escalation (LPE). By exploiting a “confused deputy” flaw in how Windows handles proxy configurations, we coerced the machine account into authenticating to our relay, chained it with an Active Directory Certificate Services (AD CS) misconfiguration, and ultimately forged a Silver Ticket to achieve full local takeover.
Here is the story of how we chained this proxy coercion vulnerability into a seamless escalation path.
This vulnerability is not yet patched and that despite this being a security vulnerability, Microsoft declined to assign it a CVE. ZDI published then it as a 0day advisory:
Under the Microsoft Windows Security Servicing Criteria, this scenario is classified as Moderate - Spoofing because an authenticated attacker can induce an endpoint to authenticate to an attacker-controlled system, enabling the endpoint’s identity to be relayed or presented to another service. Moderate severity vulnerabilities are not a priority for Microsoft to fix.
The following blog post shows how this vulnerability was leveraged in a recent pentest to elevate privileges locally. For full details and analysis of the root cause refer to my personal blog:
- https://pgj11.com/posts/Windows-NCSI-Proxy-Auth-Coercion-Part-1/
- https://pgj11.com/posts/Windows-NCSI-Proxy-Auth-Coercion-Part-2/
The Core Concept: The “Confused Deputy”
Every time you connect to a network, Windows runs a background check to see if you have internet access. This is the job of the Network Connectivity Status Indicator (NCSI), which operates under the Network List Service (netprofm) in Windows 11. In Windows 10 the service that implemented NCSI was nlasvc.
The vulnerability we abused relies on a simple trust failure. When a user modifies their proxy settings (for example, pointing their web traffic to an explicit IP), Windows propagates that change. NCSI, wanting to test if the new network configuration works, happily consumes this proxy setting and fires off a WinHTTP probe to check for internet connectivity.
The catch? The user who configured the proxy is a low-privileged standard user, but NCSI runs as NT AUTHORITY\NETWORK SERVICE.
When the service reaches out to the proxy to perform its internet check, it does so in the security context of the machine itself (e.g., MACHINE$). Even better, the WinHTTP session fails to properly disable NTLM authentication scheme. If the proxy demands authentication, the service will readily hand over the machine account’s credentials.
By simply pointing our user-level proxy to an attacker-controlled relay, we can coerce the computer account and relay its security context.
The Attack Path: From Foothold to Silver Ticket
During our recent engagement, we landed had compromised a workstation as a standard, unprivileged user. We needed local admin to dump credentials and pivot further into the network.
Here is how the attack unfolded:
1. Setting the Trap
From our low-privileged shell, we modified the user proxy settings using the UI. It is also possible to modify HKEY_CURRENT_USER registry keys. We configured the proxy address to point to an ntlmrelayx listener running locally.
2. Triggering the Coercion
The moment the registry was updated, the Windows notification subsystem woke up the NCSI service. Eager to test the new “proxy,” the NETWORK SERVICE initiates an outbound HTTP request to our listener after some minutes.
Impacket’s ntlmrelayx responds with a 407 Proxy Authentication Required challenge, advertising the Negotiate scheme. The Windows machine happily obliged, seamlessly passing the MACHINE$ authentication to us.
3. Relaying to AD CS (ESC8)
Instead of just capturing the hash, our ntlmrelayx server was configured to relay this authentication attempt directly to the organization’s vulnerable AD CS Web Enrollment HTTP endpoint.
Because the web enrollment endpoint didn’t enforce EPA (Extended Protection for Authentication) or require HTTPS, it accepted the relayed authentication. We successfully requested and enrolled a client authentication certificate on behalf of the compromised workstation’s machine account (MACHINE$).
4. UnPAC-ing the Hash
Armed with the machine account’s shiny new certificate, we used PKINIT to request a Ticket Granting Ticket (TGT) from the Domain Controller. In this case, certipy was used.
5. Forging the Silver Ticket
With the machine account’s NT hash in hand, the game was over. The machine account hash is essentially the master key for the local machine. We used it to forge a Silver Ticket (a Service Ticket). When forging the ticket, we injected the Domain Admins SID into the PAC.
Remote code was executed through WMI and our controlled user was added to the Administrators group.
Note: Impacket’s scripts was used directly in the Windows machine, but also a qemu-emulated Debian system was leveraged.
Conclusion
This attack chain is a brutal reminder of why defense-in-depth is critical. The NCSI vulnerability itself is an elegant bypass of authentication boundaries, but its real danger shines when it interacts with classic environmental misconfigurations like AD CS ESC8.
To protect against this specific chain, organizations must enforce Extended Protection for Authentication (EPA) and require HTTPS on all AD CS web endpoints. Additionally, maintaining strict visibility into unexpected proxy changes and anomalous outbound HTTP traffic from svchost.exe processes can help catch this coercion technique before the attacker ever mints their certificate. It could also be leveraged RBCD, Shadow Credentials or other similar attacks insted of ESC8, so that is why it is important to protect AD environments about these misconfigurations.
