Power in Active Directory, much like power in Westeros, often changes hands not through force, but through misplaced trust.
”Expanding the Kingdom: When Trust Knows No Bounds
In Part 1 of this series, An Introduction to Active Directory Certificate Services (AD CS), I introduced how AD CS integrates directly with Active Directory authentication and why misconfigured certificate templates can lead to privilege escalation and full domain compromise.
In Part 2, ESC1 – No One, Yet Everyone, we examined a misconfiguration that allows a low-privileged user to request a certificate that represents a different account. That path focused on identity control and how subject manipulation can lead to privilege escalation.
In this post, we shift to ESC2. Unlike ESC1, which focused on controlling identity in a certificate request, ESC2 is about controlling capability. When a template is configured with the Any Purpose EKU or no EKU at all, it creates a certificate that can be used for far more than intended. If low-privileged users can enroll in that template, that flexibility can be turned into authentication power and, ultimately, privilege escalation.
When the Crown Bears Every Sigil: What Is ESC2?
ESC2 is an AD CS misconfiguration where a certificate template defines the Any Purpose EKU or no EKU and is enrollable by low-privileged users. In properly designed PKI environments, EKUs restrict how a certificate can be used. A certificate issued for one purpose should not automatically function in unrelated authentication or security contexts.
Where ESC1 manipulates who a certificate represents, ESC2 broadens the authority granted to the certificate itself. The identity may remain unchanged, but the scope of trust increases dramatically. When that expanded trust intersects with additional template capabilities, it can be leveraged into escalation.
When a template is configured with Any Purpose, or when EKU restrictions are missing entirely, those boundaries disappear. The certificate still represents the requesting account; there is no impersonation here. What changes is the scope of authentication tied to that certificate, instead of being limited to a specific role, it carries broader trust across the environment. That removal of purpose constraints is what defines ESC2.
On its own, ESC2 expands authentication. The certificate can be used across multiple authentication and security contexts, but it still represents only the requesting account. There is no impersonation or delegated control introduced by ESC2 alone.
While ESC2 does not introduce escalation on its own, it often appears alongside other misconfigurations. In those cases, the expanded certificate capabilities can amplify or enable additional attack paths that ultimately lead to privilege escalation.
While the initial certificate is obtained from a template vulnerable to ESC2, the escalation to Domain Admin relies on Enrollment Agent functionality. The expanded EKU scope allows the certificate to operate broadly, but the ability to request certificates on behalf of another user is what enables the identity shift that leads to full compromise.
Surveying the Realm: Enumerating AD CS
As mentioned in previous posts from this series, I’ll be using the Game of Active Directory (GOAD) lab environment provided by Orange CyberDefense to walk through these attack paths. While GOAD is intentionally vulnerable, the misconfigurations closely resemble those found in real enterprise environments.
Before exploiting anything, the first step remains the same, confirm AD CS exists and understand how it is configured. From an attacker’s perspective, this means identifying the Certificate Authorities, the templates they publish, and determining whether any of those templates are vulnerable.
From our Kali Linux host, using the previously compromised sql_svc account, we enumerate enabled templates with Certipy:
certipy-ad find -u sql_svc -hashes :84a5092f53390ea48d660be52b93b804 -dc-ip 192.168.56.12 -enabled
Among the returned templates, ESC2 stands out:
The template is enabled and published to ESSOS-CA, which means the Certificate Authority (CA) will actively issue certificates under these conditions. Because Domain Users are granted enrollment rights, any standard account can request a certificate based on this configuration.
That makes the configuration operational, not just theoretical. The CA will sign and distribute certificates exactly as defined in the template.
Why These Settings Matter
Looking at the highlighted portions of the template, several settings directly enable the escalation path.
- Enrollment Rights: ESSOS.LOCAL\Domain Users - Any low-privileged user can request a certificate from this template. No elevated privileges are required to begin the process.
- Extended Key Usage: Any Purpose - The certificate is not restricted to a single application policy. It is broadly trusted across authentication and security contexts.
- Client Authentication: True - Certificates issued from this template can be used for domain authentication through PKINIT, making them viable for obtaining Kerberos tickets.
- Enrollment Agent: True - This is the setting that turns expanded capability into escalation. The issued certificate includes the Certificate Request Agent EKU, allowing the holder to request certificates on behalf of other users.
- Requires Manager Approval: False
Authorized Signatures Required: 0 - There is no approval workflow. Certificates are issued automatically without oversight.
When these conditions exist together, a standard domain user can obtain a broadly trusted certificate and use it to request additional certificates representing privileged accounts.
Identifying the Crown: Revisiting Domain Admins
In the previous ESC1 post, we enumerated members of the Domain Admins group from our low-privileged foothold. The targets remain unchanged.
nxc ldap 192.168.56.12 -u sql_svc -H 84a5092f53390ea48d660be52b93b804 -d essos.local --groups "Domain Admins"
This returned the following Domain Admin members in the ESSOS domain:
- daenerys.targaryen
- QueenProtector
- Administrator
For consistency with the previous post, we will continue using daenerys.targaryen as the target account. However, the technique demonstrated here would work against any of the Domain Admin accounts.
Unlike ESC1, we are not injecting identity into a certificate. Instead, we will leverage certificate capability to act in the name of the crown.
Forging the First Seal: Requesting the ESC2 Certificate
Using the sql_svc account, we request a certificate from the ESC2 template:
certipy-ad req -u sql_svc -hashes :84a5092f53390ea48d660be52b93b804 -dc-ip 192.168.56.12 -target braavos.essos.local -ca ESSOS-CA -template ESC2
The CA issues a certificate representing sql_svc and returns a PFX file. Because Enrollment Agent is True, this certificate contains the Certificate Request Agent capability.
At this stage, we still operate as sql_svc. The escalation depends on how this certificate can now be used.
Speaking With the King’s Authority: Requesting On Behalf of Another
With the Enrollment Agent certificate in hand, the scope of what we can request changes. The first certificate represents sql_svc, however the next one does not have to.
This is because the ESC2 template issued a certificate that includes the Certificate Request Agent capability. While that certificate still represents sql_svc, it expands what the account is permitted to request. Instead of being limited to its own identity, it can submit certificate requests on-behalf-of other users when the CA and target template allow it.
However, this is where the distinction becomes important. The ESC2 template itself is not the template that will issue the Domain Admin certificate, it simply gives us the authority to act as an agent. To convert agent authority into privilege escalation, we must identify a second certificate template that satisfies two conditions:
- It supports Client Authentication
- It grants Enrollment Rights to Domain Users
The first condition ensures that any certificate issued can be used for domain authentication. The second condition ensures that our low-privileged account is permitted to submit the request. Even when operating as an Enrollment Agent, the requesting account must still have permission to enroll against the target template. If Domain Users are not permitted to enroll, the request fails regardless of agent capability.
Before attempting that second request, we need to determine which templates are eligible targets. Using Certipy again, we enumerate enabled templates in the ESSOS domain:
certipy-ad find -u sql_svc -hashes :84a5092f53390ea48d660be52b93b804 -dc-ip 192.168.56.12 -enabled
In the ESSOS domain, the User template satisfies these conditions. It supports Client Authentication and allows Domain Users to enroll. Because the certificate we created with our sql_svc account contains the Certificate Request Agent capability, we can now submit a certificate request on behalf of another account using that template.
At this stage, all of the required pieces are in place:
- A vulnerable template that allows Domain Users to enroll
- Enrollment Agent capability embedded in the issued certificate
- A published and reachable CA
- A target account holding Domain Admin privileges
With those conditions satisfied, we can submit a new request to the CA, this time specifying the target account.
certipy-ad req -u sql_svc -hashes :84a5092f53390ea48d660be52b93b804 -dc-ip 192.168.56.12 -target braavos.essos.local -ca ESSOS-CA -template User -on-behalf-of essos\\daenerys.targaryen -pfx sql_svc.pfx
If the request succeeds, the CA issues a certificate representing daenerys.targaryen, allowing us to authenticate as a Domain Admin. The initial ESC2 certificate expanded what we were permitted to request, and this second certificate converts that expanded capability into actual privilege within the domain.
Laying Claim to the Throne: Domain Admin Access
With the Domain Admin certificate issued, the next step is to determine whether it truly holds authority within the domain. Using Certipy, we can authenticate with the PFX file and request a Kerberos ticket for the target account. If the domain controller accepts the certificate and issues a Kerberos ticket, it confirms that the certificate is trusted for authentication and is recognized as representing the target Domain Admin account.
certipy-ad auth -pfx daenerys.targaryen.pfx -dc-ip 192.168.56.12
Certipy retrieves a valid Kerberos ticket and the NTLM hash associated with daenerys.targaryen. At this point, the certificate-derived identity is no longer theoretical. It is recognized and trusted by the domain.
To validate the level of access, we perform an LDAP bind using the recovered NTLM hash:
nxc ldap 192.168.56.12 -u daenerys.targaryen -H 34534854d33b398b66684072224bb47a -d essos.local
A successful bind confirms that the privileges tied to the Domain Admin account are fully accessible. What began as a low-privileged enrollment request has now resulted in complete administrative control of the domain.
The crown has changed hands.
The Crown Is Claimed: Wrapping Up
In this post, we followed an ESC2 abuse path that began with a low-privileged Domain User and ended with full Domain Admin control. The escalation did not rely on manipulating identity as it did with ESC1, but on expanding certificate capability and leveraging that authority.
When a certificate template removes EKU restrictions, enables Client Authentication, grants Enrollment Agent capability, and requires no approval, the boundaries meant to separate subjects from rulers begin to weaken. The CA does not resist the request because, according to its own laws, the request is legitimate.
What begins as a simple enrollment from a common account becomes something far more powerful. The first seal broadens access. The second carries the authority of the crown. And once the domain accepts that authority, the throne is no longer protected by passwords or privilege boundaries, but by trust that has already been misplaced.
In the next post, we will isolate ESC3 and examine Certificate Request Agent abuse more directly, particularly in environments where Any Purpose is not present and escalation depends solely on delegated authority rather than expanded scope.
