ESC17 - Beyond WSUS: Introduction and Threat Model

A research series by Alexis MARTIN (qu35t) and Alexis PARET (nnino). Every technique in this series was reproduced end to end in a fully patched lab environment.

Why this series

In January 2026, DigiTrace formalized a certificate template misconfiguration under the escalation number ESC17, building on Austin Coontz’s earlier work at TrustedSec on attacking WSUS over HTTPS. To date, the technique has essentially one publicly documented, end-to-end exploitation path: WSUS.

The problem, though, is not WSUS. WSUS is just the first service to have been taken apart in public. The root cause sits one layer lower, in Active Directory Certificate Services (ADCS) and, more precisely, in the implicit trust that every domain-joined machine places in certificates issued by the enterprise certification authority.

We recently revisited ESC17 from the ground up and asked a simple question: if the primitive is a malicious but fully trusted TLS identity for an arbitrary hostname, which other protocols inherit the same weakness? The answer turned out to be “a lot.” The next parts of this series document, protocol by protocol, how ESC17 can be weaponized against:

• HTTPS (internal web applications, intranets, admin interfaces)
• LDAP / LDAPS
• RDP

This list is not fixed: other protocols will be added to the research and to the tool over time, as we extend ESC17 coverage.

For each protocol, we walk through the concrete attack, the limitations imposed by Windows that shape (and sometimes break) exploitation, and how adecrypt, a tool we built specifically to automate ESC17 exploitation on a per-protocol basis, automates the attack.

This first article lays the foundations: what ESC17 is, why it exists, and why it is a PKI trust problem rather than a WSUS problem.

A refresher on ADCS and the domain PKI trust model

ADCS is Microsoft’s public key infrastructure (PKI). In most enterprises it runs as an enterprise CA: an online certification authority, integrated with Active Directory, that issues certificates for user authentication, machine authentication, TLS services, code signing, and more. What the CA is allowed to issue, and to whom, is governed by certificate templates.

The single most important property for this series is this: domain-joined Windows machines automatically trust the internal enterprise CA. When ADCS is deployed, the CA root certificate is published in Active Directory and pushed to the Trusted Root Certification Authorities store of every domain member through Group Policy (GPO). The practical consequence is that any certificate issued by that CA is trusted, by default, by every machine in the domain, with no additional prompt, warning, or user interaction.

This trust is exactly what makes ADCS such a rich attack surface. If an attacker can convince the CA to issue a certificate for an identity they do not legitimately own, that certificate is instantly trusted domain-wide.

ADCS misconfigurations are catalogued under an “ESC” nomenclature (for Escalation), numbered from ESC1 onward, each number describing a distinct abuse scenario. ESC17 follows that taxonomy, and to understand it you first have to go back to its starting point: ESC1.

Refresher: the ESC1 model

The classic ESC1 attack, introduced by SpecterOps in Certified Pre-Owned (2021), abuses a template that combines:

1. Enrollee Supplies Subject: the CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT flag (shown as “Supply in the request” in the UI), which lets the requester specify the subject / SAN themselves.
2. an Extended Key Usage (EKU) that permits domain authentication: typically Client Authentication (1.3.6.1.5.5.7.3.2), Smart Card Logon, PKINIT Client Authentication, or the catch-all Any Purpose.
3. permissive enrollment rights (for example, domain users can enroll).
4. no guardrails such as manager approval.

With those four ingredients, a low-privileged user requests a certificate while supplying a UPN they do not own, for example administrator@corp.local, and authenticates as that user. Full domain compromise, short chain, devastating impact.

ESC1 is now widely known and remediated in most environments. It is precisely from that remediation that ESC17 is born.

The ESC17 misconfiguration: an incompletely remediated ESC1

When teams remediate ESC1, they have several options: disable enrollee-supplied subjects, restrict enrollment, require manager approval, or change the EKU. That last one is tempting because it usually has the lowest business impact. These vulnerable templates are frequently used to issue web server certificates, which is exactly why the “supply in the request” flag was enabled in the first place (an administrator needs to request a certificate for webserver.corp.local, not for themselves).

The “obvious” fix, then, is to remove the authentication EKU and leave only the one a web server actually needs: Server Authentication (1.3.6.1.5.5.7.3.1). The template can no longer be used to authenticate as a user, ESC1 tooling stops flagging it, and everyone moves on.

This is the trap. A template that still lets an enrollee supply the subject/SAN, still grants permissive enrollment, and carries a Server Authentication EKU is not safe. It has simply traded the ability to impersonate a user for the ability to impersonate a server, and in a domain where every machine trusts the CA, impersonating a server is itself an escalation primitive.

This configuration, namely enrollee-supplied SAN + Server Authentication EKU + permissive enrollment (with no effective guardrail), is ESC17.

The distinction from ESC1 is subtle but decisive:

	ESC1	ESC17
Supplied identity	UPN (a user)	DNS name (a server)
EKU	Client Auth, Any Purpose, Smart Card Logon	Server Authentication
Direct effect	Authenticate as an arbitrary user	Present a trusted TLS identity for an arbitrary host
Escalation type	Direct (often immediate DA)	Indirect (via interception / manipulation of a trusted channel)

In certipy, a certificate that is exploitable for ESC17 is requested not with a forged -upn, but with a forged -dns value pointing to the FQDN of the target service. The CA happily signs it, and the resulting certificate is trusted by every domain-joined client for that hostname.

The mechanics of the attack

ESC17, on its own, does not forge an authentication. It forges a trusted server identity, which the attacker then leverages from a man-in-the-middle (MitM) position. The generic attack chain looks like this:

1. Enumerate templates and identify the one that is exploitable for ESC17 (supplies the subject + Server Authentication EKU + you can enroll).
2. Request a certificate for the DNS name of the target service (-dns target.corp.local). Because the CA is trusted domain-wide, so is this certificate.
3. Position yourself on the path between the victim client and the legitimate server. Common techniques include ARP spoofing, abusing IPv6 router advertisements (mitm6), DNS poisoning, or any control over the network infrastructure.
4. Impersonate the legitimate server by terminating the victim’s TLS session with your ADCS-issued certificate. No certificate warning is raised, because the certificate is genuinely valid and genuinely trusted.

From that position, three classes of capability open up:

• Passive interception: read data the victim believed was TLS-protected. Think session tokens, internal API data, credentials.
• Active manipulation: alter traffic on the fly. In the WSUS case, this means injecting a malicious “signed” update that runs with SYSTEM privileges, turning interception into direct code execution.
• Relaying: forward a coerced authentication (e.g. NTLM) from the victim to a target of the attacker’s choosing.

Whether the end result is lateral movement or a true domain escalation depends on the privileges of the impersonated service and on the identity of the victims caught in the interception, much like ESC8 (HTTP relay) and ESC11 (RPC relay), where impact is a function of which authentication you can coerce and where you can send it. That is precisely why the DigiTrace authors argued ESC17 deserved its own number: the escalation is real, but it is indirect, resting on an ADCS template misconfiguration.

Why this is a PKI problem, not a WSUS problem

The critical generalization is this: any protocol that relies on the machine’s system certificate store to establish trust, and does not enforce stricter verification such as certificate pinning, is a candidate for ESC17 abuse.

WSUS was only the first, and most spectacular, demonstration, because WSUS has no HSTS-style or trust-on-first-use protection and because a manipulated update leads to immediate SYSTEM-level code execution. But WSUS’s underlying assumption, “if the TLS certificate is issued by our trusted internal CA, then the endpoint is authentic”, is shared by a great many domain services.

The next parts tackle three of them, each with its own subtleties: internal HTTPS applications, LDAPS, and RDP. This is only a starting point: many other protocols rest on the same trust assumption and will join the series over time. Each behaves differently under attack, and that difference is largely dictated by the limitations imposed by Windows.

The limitations that really matter

ESC17 is not a magic wand, and a large part of this series is about the constraints that separate “theoretically vulnerable” from “reliably exploitable.” The recurring themes we examine per protocol include:

• Certificate pinning: when a client validates a specific certificate or key rather than “anything the trusted CA has signed,” ESC17 is neutralized regardless of template hygiene. Centrally managed client/server pairs are the natural place to expect this.
• Extended Protection for Authentication / channel binding: which can defeat a naive relay of authentication over TLS.
• Schannel quirks and EKU enforcement: how strictly a given Windows client checks the Server Authentication EKU, SAN matching, and name constraints.
• Coercion and polling requirements: some protocols do not initiate a connection on demand (WSUS polling can take up to a day), so timing and coercion are part of the attack.
• The MitM prerequisite itself: every ESC17 variant assumes a viable interception position, which is an operational constraint in its own right.

Everything we present was validated against a fully patched lab as of July 25, 2026, precisely so that these limitations are reflected accurately rather than assumed away.

Introducing adecrypt

Requesting the certificate is the easy part. Turning it into a working attack differs substantially from one protocol to the next: TLS encapsulation, coercion, payload, manipulation logic, and cleanup are all protocol-specific.

adecrypt is the tool we built to automate this per-protocol exploitation. Rather than hand-reimplement the same MitM-and-impersonation scaffolding for each service, adecrypt takes an ESC17-eligible certificate and drives the attack end to end for the selected protocol, handling the protocol-specific interception and manipulation so the operator can focus on the objective. Each subsequent article pairs the theory with the exact adecrypt workflow used to reproduce the result in the lab.

The rest of the series

Part	Topic
1	Introduction & threat model (this article)
2	Internal HTTPS applications: interception, credential capture, and NTLM relay
3	LDAP / LDAPS: credential capture and session hijacking
4	RDP
…	More protocols will be added over time

Each entry follows the same structure: the attack, the Windows limitations, and automation via adecrypt. The research and the tool are living: new protocols will join the series as we instrument them.

Credits & prior work

ESC17 builds on a large body of public research, and we want to name it clearly:

• SpecterOps: Certified Pre-Owned (2021), which introduced the ESC taxonomy and ESC1.
• Austin Coontz (TrustedSec): the original insight that an ADCS certificate could be used to attack WSUS over HTTPS, and the WSUS NTLM relay research it built on.
• Alexander Neff & Phil Knüfer (DigiTrace): who generalized the idea, proposed the ESC17 designation, and contributed the detection logic to certipy.

The takeaway for the rest of the series is simple, and it is the same warning DigiTrace closed on: stop trusting an EKU value to decide a template is safe. Any template that lets an untrusted party supply the subject and obtain a domain-trusted certificate deserves scrutiny, Server Authentication very much included.

Keep an eye on ESC17.