# ESC17 - Beyond WSUS: Introduction and Threat Model
> ESC17 is not a WSUS bug but a PKI trust problem in ADCS. The first part of a research series that maps out its attack surface.
Date: 2026-07-26
Tags: adcs, active-directory, pki, esc17
URL: https://research.qu35t.pw/en/blog/esc17-introduction-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:
:::note[The primitive in one sentence]
ESC17 turns a plain enrollment right into a malicious, valid, domain-wide trusted TLS certificate for **any** hostname of your choosing.
:::
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.**