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 Part 3, ESC2 – The Seal of Any Purpose, we moved from identity manipulation to capability expansion. Instead of changing who a certificate represents, ESC2 focuses on what the certificate can do. When a template includes the Any Purpose EKU or lacks EKU restrictions, the resulting certificate can be trusted across multiple authentication contexts, creating opportunities for privilege escalation when combined with other misconfigurations.
ESC3 delegates authority. When Enrollment Agent capability is exposed to low-privileged users, that authority can be used to request certificates representing other identities.
When Authority Is Delegated: What Is ESC3?
ESC3 is an AD CS misconfiguration where a certificate template includes the Certificate Request Agent EKU and allows enrollment by low-privileged users. Enrollment Agent certificates are normally restricted to trusted certificate management roles, such as PKI administrators or help desk personnel responsible for issuing certificates on behalf of others. When that capability is exposed to untrusted accounts, the boundary between requesting a certificate for oneself and requesting one for another identity effectively disappears.
Rather than expanding certificate capability as seen in ESC2, ESC3 introduces delegated enrollment authority. The certificate issued from the vulnerable template still represents the requesting account, but it grants the ability to request certificates on behalf of other identities. This effectively allows the holder to operate as a certificate enrollment agent within the PKI environment.
When a template exposes the Certificate Request Agent capability without appropriate restrictions, the certificate issuance process becomes accessible to accounts that should not possess that authority. The attacker does not directly impersonate another identity; instead, they gain the ability to request certificates that represent other users when the CA and target template permit it.
On its own, ESC3 does not automatically lead to privilege escalation. The delegated enrollment authority must make use of another template that supports authentication and allows enrollment by the requesting account.
In many environments, this condition is satisfied by permissive authentication templates such as the default User template. When these templates support Client Authentication and allow enrollment by Domain Users, an attacker holding an Enrollment Agent certificate can submit certificate requests representing other identities, including privileged accounts.
In this scenario, the Enrollment Agent capable certificate provides the authority to submit the request, while the authentication template determines the identity embedded in the issued certificate. If the CA approves the request and issues a certificate representing a privileged user, that identity can then be used for domain authentication, ultimately leading to privilege escalation.
Surveying the Realm: Enumerating AD CS
For this walkthrough, the demonstrations again take place in the Game of Active Directory (GOAD) lab environment developed by Orange CyberDefense. GOAD is intentionally configured with a number of security weaknesses, but the types of misconfigurations present in the lab closely mirror those frequently encountered in real-world, enterprise environments.
Before moving into exploitation, the first objective is to verify that Active Directory Certificate Services (AD CS) is present and understand how it is deployed. From an attacker's perspective, this means identifying the Certificate Authorities operating in the environment, reviewing the certificate templates they publish, and evaluating whether any of those templates expose conditions that can be abused.
Using our Kali Linux host and the previously compromised sql_svc account, we begin by enumerating the enabled certificate templates with Certipy:
certipy-ad find -u sql_svc -hashes :84a5092f53390ea48d660be52b93b804 -dc-ip 192.168.56.12 -enabled
Among the returned templates, both the ESC3-CRA and ESC3 templates stand out:
The ESC3-CRA template is enabled and published to ESSOS-CA , meaning the Certificate Authority will actively issue certificates based on this configuration. Because Domain Users are granted enrollment rights, any standard account in the domain can request a certificate from this template.
Certificates issued from ESC3-CRA contain the Certificate Request Agent extended key usage. This allows the certificate holder to submit certificate requests on behalf of other users, effectively granting delegated enrollment authority.
The ESC3 template represents the second half of the attack path. Unlike ESC3-CRA, this template supports Client Authentication, meaning certificates issued from it can be used for domain authentication through PKINIT. However, the template requires one authorized signature and specifies Certificate Request Agent as the required application policy.
This configuration means the template will only issue certificates if the request is signed by a valid Enrollment Agent certificate. In this case, the certificate obtained from ESC3-CRA is used to provide that signature.
Why These Settings Matter
Looking at the highlighted portions of both templates, several settings combine to enable the escalation path.
- ESC3-CRA
- Enrollment Rights: ESSOS.LOCAL\Domain Users
- Any low-privileged domain user can obtain an Enrollment Agent certificate.
- Extended Key Usage: Certificate Request Agent
- The issued certificate grants the ability to submit certificate requests on behalf of other users.
- The issued certificate grants the ability to submit certificate requests on behalf of other users.
- Enrollment Rights: ESSOS.LOCAL\Domain Users
- ESC3
- Client Authentication: True
- Certificates issued from this template can be used for domain authentication through PKINIT, making them valid for obtaining Kerberos tickets.
- Authorized Signatures Required: 1
- The template requires a signature from an Enrollment Agent before issuing a certificate.
- Application Policies: Certificate Request Agent
- Only a certificate containing the Enrollment Agent EKU can authorize requests for this template.[GC1]
- Client Authentication: True
With both templates identified, the attack path is in place. A standard domain user can first request an Enrollment Agent certificate from ESC3-CRA. That certificate can then be used to sign a certificate request against the ESC3 template on behalf of another user, including privileged accounts.
If the request is accepted, the Certificate Authority will issue a certificate representing that account, which can then be used for authentication within the domain.
Identifying the Crown: Revisiting Domain Admins
In previous walkthroughs, we identified the members of the Domain Admins group from our initial foothold. Those accounts remain the potential targets for this attack path.
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
As in the previous walkthroughs, daenerys.targaryen will remain our prime target. However, it should be noted that any of the above listed accounts could be targeted for this attack.
Unlike ESC2, which expanded certificate capability, ESC3 allows us to use delegated enrollment authority to request a certificate in the name of the crown. Let's obtain the certificate needed to do that now.
Earning the Crown's Voice: Gaining Enrollment Agent Authority
With access to the sql_svc account, we request a certificate from the ESC3-CRA template:
certipy-ad req -u sql_svc -hashes :84a5092f53390ea48d660be52b93b804 -dc-ip 192.168.56.12 -target braavos.essos.local -ca ESSOS-CA -template ESC3-CRA
The Certificate Authority issues a certificate associated with sql_svc and returns it as a PFX file. At a glance, this appears to be a routine enrollment. The difference is in what the certificate now allows.
Because the template includes the Certificate Request Agent extended key usage, the issued certificate carries the ability to approve certificate requests for other users. This does not change the identity tied to the certificate, but it changes the role that the identity can play in the enrollment process.
At this stage, no escalation has occurred. We are still operating as sql_svc, and the certificate cannot yet be used to authenticate as another account.
However, the account now holds delegated authority within the Certificate Authority workflow. That authority becomes relevant when paired with a template that requires an Enrollment Agent signature.
When such a template is available, this certificate can be used to authorize a request on behalf of another user, including privileged accounts.
Acting in the Crown's Name: Requesting on Behalf of Another
The certificate obtained from ESC3-CRA changes the position and authority of the sql_svc account within the Certificate Authority workflow. While the identity tied to the certificate remains the same, the account is no longer limited to requesting certificates for itself.
The presence of the Certificate Request Agent capability allows sql_svc to take part in how certificates are issued for other users. Instead of being confined to its own identity, the account can now authorize a request that names a different subject, provided the target template is configured to accept that authorization.
This is where the second template becomes critical.
The ESC3-CRA template alone does not produce a certificate that can be used for authentication as another user. Its role is only to grant influence over the issuance process. To translate that influence into access, a second template must be identified, one that will issue a certificate based on a request approved by an Enrollment Agent.
That target template must meet the following two conditions:
- It supports Client Authentication
- It enforces or honors a Certificate Request Agent signature.
In the GOAD environment, the ESC3 template satisfies both of those conditions. It requires an authorized signature tied to the Certificate Request Agent policy and produces certificates that are valid for domain authentication.
The sql_svc account can now submit a certificate request that specifies a different user, sign that request using the Enrollment Agent certificate obtained from ESC3-CRA, and rely on the CA to issue a certificate for the chosen identity.
Using the Enrollment Agent certificate obtained from ESC3-CRA , we can submit a request against the ESC3 template on behalf of 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 ESC3 -on-behalf-of essos\\daenerys.targaryen -pfx sql_svc.pfx
If the request is accepted, the Certificate Authority will then issue a certificate representing daenerys.targaryen.
Unlike the initial certificate tied to the sql_svc account, this certificate reflects the identity specified in the request. The authority granted by the Enrollment Agent certificate has now been used to influence how the CA assigns identity during issuance.
If the request succeeds, the CA issues a certificate representing daenerys.targaryen, allowing us to authenticate as a Domain Admin. The initial certificate granted the authority to approve requests, and this second certificate turns that authority into actual access 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 is accepted for authentication within the domain.
Using Certipy, we authenticate with the PFX file and request a Kerberos ticket for the target account:
certipy-ad auth -pfx daenerys.targaryen.pfx -dc-ip 192.168.56.12
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 returns a valid Kerberos ticket along with the NTLM hash associated with daenerys.targaryen. At this point, the identity embedded in the certificate is no longer theoretical. It is recognized and trusted by the domain.
To validate the level of access, we can perform LDAP authentication 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 Domain Admin privileges are fully available. The domain is now under our control.
The Crown Is Claimed: Wrapping Up
In this post, we followed an ESC3 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 or expanding certificate capability. Instead, it was made possible through delegated authority that should never have been exposed.
When Enrollment Agent capability is granted to untrusted users, the certificate issuance process itself becomes the weakness. The CA does not resist the request, because it has been properly authorized. From the system's perspective, everything is functioning as intended.
What begins as a standard enrollment leads to something far more impactful. The first certificate granted the ability to approve requests. The second reflected the identity specified in that request. Once issued, that identity is accepted by the domain without question.
In the next post, we will move into ESC6 and examine how SAN injection and certificate mapping behavior allow attackers to influence authentication at a different layer, shifting the focus from enrollment authority to how identities are resolved during authentication.
