Listen to this Post
Introduction:
The common belief that HTTPS automatically secures Windows Server Update Services (WSUS) deployments has been definitively shattered. New research extends previous NTLM relay attacks by weaponizing misconfigured Active Directory Certificate Services (ADCS) templates to spoof legitimate WSUS servers and achieve remote code execution on clients, even over encrypted HTTPS channels. This technique, dubbed ESC17, represents a critical escalation in privilege escalation and lateral movement attacks within Active Directory environments.
Learning Objectives:
- Understand the vulnerability chain linking ADCS template misconfigurations to WSUS compromise.
- Learn how to identify vulnerable ADCS certificate templates (ESC17) within an enterprise.
- Implement defensive strategies to harden WSUS, ADCS, and client configurations against this attack.
You Should Know:
1. The Core Vulnerability: ADCS Template Misconfigurations
The attack exploits ADCS certificate templates with overly permissive settings, particularly the `ENROLLEE_SUPPLIES_SUBJECT` setting. This allows an attacker to request a certificate where they can arbitrarily specify the Subject Alternative Name (SAN), a critical field used to verify a server’s identity.
Step-by-step guide explaining what this does and how to use it.
An attacker first identifies a vulnerable certificate template. Using tools like `Certify` or Certipy, they can enumerate all templates and their permissions from a low-privileged context.
Enumeration Command (Certipy):
certipy find -u [email protected] -p Password123 -dc-ip 10.10.10.1 -vulnerable
This command lists templates where the current user has enrollment rights and highlights misconfigurations like ENROLLEE_SUPPLIES_SUBJECT. Once a vulnerable template is found, the attacker requests a certificate, specifying the SAN as the fully qualified domain name (FQDN) of the target WSUS server (e.g., wsus.corp.local). The ADCS server, due to the misconfiguration, will issue a seemingly valid certificate for that service.
- Spoofing the WSUS Server and Capturing Client Authentication
With a spoofed certificate in hand, the attacker sets up a malicious WSUS server impersonating the legitimate one. WSUS clients communicate over HTTPS using the Windows Update Agent (WUA), which employs Windows HTTP Services (WinHTTP). Crucially, WinHTTP automatically uses the machine’s computer account for NTLM authentication when prompted by a server.
Step-by-step guide explaining what this does and how to use it.
The attacker configures a tool like `WSUX` or a modified version of `PyWSUS` to present the spoofed certificate and host a fake WSUS endpoint. When a client connects (triggered by a group policy update or a manual wuauclt /detectnow), the fake server requests NTLM authentication.
Triggering Client Check-in (on victim, via attack simulation):
On a Windows client, this forces communication with the WSUS server wuauclt.exe /detectnow /reportnow
The client automatically responds with an NTLM authentication attempt using its machine account credentials, which the attacker’s server captures.
3. Relaying to ADCS for Machine Account Compromise
The captured NTLM authentication is not used against the WSUS service itself. Instead, it is relayed to the ADCS server’s Certificate Authority (CA) web enrollment interface (/certsrv/).
Step-by-step guide explaining what this does and how to use it.
Using a tool like `ntlmrelayx` from the Impacket suite, the attacker relays the captured machine account NTLM authentication to the ADCS web interface to request a machine certificate.
Relay Configuration (ntlmrelayx):
ntlmrelayx.py -t https://adcs.corp.local/certsrv/certfnsh.asp -smb2support --adcs --template Machine
This command sets up the relay server. When the WSUS client’s authentication is captured, it is forwarded to the ADCS endpoint. The ADCS server, seeing the authentication from a legitimate machine account, issues a machine certificate to the attacker. This certificate is a golden ticket for Kerberos authentication, granting the attacker persistent control over the client machine account.
4. From Certificate to Code Execution
Owning the machine account via its certificate allows for full compromise. The attacker can now use the certificate to request a Kerberos Ticket-Granting Ticket (TGT) for the machine account, enabling any Kerberos-based action, such as Service Principal Name (SPN) modification, Silver Ticket creation, or direct lateral movement via SMB or WinRM.
Step-by-step guide explaining what this does and how to use it.
Using `Certipy` or Rubeus, the attacker converts the ADCS-issued certificate into usable Kerberos tickets.
Auth using Certificate (Certipy):
certipy auth -pfx wsusclient.pfx -dc-ip 10.10.10.1
This command authenticates to the Domain Controller and fetches a TGT. With this ticket, the attacker can use tools like `NetExec` or `Impacket’s psexec` to execute code.
Code Execution (NetExec):
netexec smb 10.10.10.20 -k --no-bruteforce -x 'whoami'
The `-k` flag uses the Kerberos ticket for authentication, executing the command on the target WSUS client as the machine account (SYSTEM privileges).
5. Defensive Hardening and Mitigation Strategies
Mitigating ESC17 requires a multi-layered approach addressing ADCS, WSUS, and client configurations.
Step-by-step guide explaining what this does and how to use it.
1. Harden ADCS Templates: Audit and remove the `ENROLLEE_SUPPLIES_SUBJECT` setting from all certificate templates where it is not absolutely necessary. Restrict enrollment rights to specific security groups, not `Domain Computers` or `Authenticated Users` broadly.
2. Enable EPA for ADCS: Enforce Extended Protection for Authentication (EPA) on the ADCS CA web enrollment endpoints. This prevents NTLM relay attacks by binding the SSL channel to the authentication message.
IIS Configuration: In IIS Manager, select the `/certsrv` application, open Authentication > Windows Authentication, click Advanced Settings, and ensure `Require Extended Protection` is enabled.
3. WSUS Server Pinning: Implement SSL Certificate Pinning for WSUS clients via Group Policy. This ensures clients only communicate with WSUS servers presenting a specific, whitelisted certificate.
GPO Path: Computer Configuration > Administrative Templates > Windows Components > Windows Update > Specify intranet Microsoft update service location. Enable and set the HTTPS URL. Then, use the `Allow signed updates from an intranet Microsoft update service location` policy to enable pinning.
4. Network Segmentation: Restrict network traffic so that client machines can only initiate HTTPS connections to the designated, legitimate WSUS server IP address, not to arbitrary servers.
What Undercode Say:
- HTTPS is Not a Silver Bullet: This research is a stark reminder that encryption (HTTPS) without proper certificate validation and service authentication is just a false sense of security. The chain of trust must be meticulously managed.
- The ADCS Attack Surface is Vast: ESC17 adds to the growing list of ADCS abuses (ESC1-ESC11, etc.). It highlights that any service accepting machine-level NTLM authentication can be a vector for relaying to ADCS, making ADCS hardening a top-tier priority for blue and red teams alike.
Prediction:
The ESC17 technique will rapidly become a staple in the advanced penetration tester’s and adversary’s toolkit due to its high impact and reliance on common, “feature-rich” configurations. It will accelerate the enterprise shift away from NTLM and towards pure Kerberos-based authentication wherever possible. Furthermore, it will push Microsoft and the community to develop more robust default configurations for ADCS and more accessible certificate pinning solutions for internal services like WSUS, potentially leading to these hardening measures becoming baseline security configurations in future Windows Server releases.
▶️ Related Video (86% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Alexander Neff – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
