ESC2
Any Purpose Certificate Template
Description
"ESC2 vulnerabilities arise from certificate templates configured with an "Any Purpose" EKU or, equivalently, templates with no EKU specified at all. The "Any Purpose" EKU is identified by the OID 2.5.29.37.0. A certificate issued from such a template can technically be used for any purpose allowed by its key and constraints, including client authentication, server authentication, code signing, and, most importantly for this escalation, as a Certificate Request Agent (also known as an Enrollment Agent).
The vulnerability materializes when these conditions are met:
Template with "Any Purpose" or No EKU: The template either explicitly contains the "Any Purpose" EKU or has no EKUs defined (which implies any purpose).
Permissive Enrollment Rights: Low-privileged users (e.g., members of "Domain Users" or "Authenticated Users") are granted enrollment permissions for this template.
While a certificate from such a template issued to an attacker would normally only allow them to authenticate as themselves, the "Any Purpose" nature implicitly grants the "Certificate Request Agent" capability (OID 1.3.6.1.4.1.311.20.2.1). This allows the attacker to use their "Any Purpose" certificate to request another certificate on behalf of a different user, potentially a Domain Administrator. This is the primary privilege escalation path for ESC2, effectively turning the "Any Purpose" certificate into an Enrollment Agent certificate, thereby leveraging an attack path similar to ESC3.
Exploitation of ESC2 typically involves two key components:
Obtaining an Any Purpose Certificate: The attacker first enrolls for and obtains a certificate from the misconfigured template that grants "Any Purpose" (or has no EKU).
A Target Certificate Template Allowing Agent Enrollment: A second certificate template (the "target template") must exist with the following characteristics:
It issues certificates suitable for client authentication (e.g., it contains the "Client Authentication" EKU).
It is configured to allow an Enrollment Agent to request certificates on behalf of other users. Many default templates, particularly Schema Version 1 templates like the built-in "User" or "Machine" template, inherently permit this without specific enrollment agent restrictions in their issuance policy.
The intended victim (e.g., a Domain Administrator) must have enrollment rights on this target template.
Once an attacker possesses an "Any Purpose" certificate (acting as an agent certificate) and identifies a suitable target template, they can submit a certificate request "on behalf of" their victim. The CA, recognizing the request as coming from a valid Enrollment Agent (due to the "Any Purpose" nature of the attacker's certificate), will issue a certificate for the victim to the attacker.
It's important to note the distinction for Schema Version 2 (or newer) target templates: these templates, if configured to require authorized signatures for enrollment agent requests, must explicitly list the "Any Purpose" EKU (or the specific "Certificate Request Agent" EKU) in their "Application Policy" issuance requirements for the agent's certificate to be accepted. However, many environments retain Schema Version 1 templates (like "User" or "Machine") which do not have this granular check, making them common targets for ESC2/ESC3 exploitation.
Administrators might create "Any Purpose" templates inadvertently for reasons like simplifying certificate deployment for diverse applications or by duplicating templates without fully understanding the broad capabilities granted by an unrestricted or empty EKU field." — Oliver Lyak
Configuration
Back into the "Certificate Templates Console" window, we can again duplicate the "User" template and name it "ESC2". Go to the "Extensions" tab and select "Application Policies" and hit edit:
Enable the template, and it should be visible in Certipy.
We can see it is also vulnerable to ESC3 since "Any Purpose" includes "Enrollment Agent".
Written by ruycr4ft
Last updated