ADCS ESC9, ESC10, ESC11: escalation dei certificati oltre ESC1-ESC8

Cos'è l'escalation dei certificati ADCS ESC9, ESC10, ESC11

L'escalation dei certificati ADCS ESC9, ESC10, ESC11 è l'insieme delle tecniche di privilege escalation di Active Directory Certificate Services (AD CS) pubblicate dopo la ricerca originale "Certified Pre-Owned" che ha introdotto ESC1-ESC8. Mentre i primi otto percorsi si concentrano su errate configurazioni dei template, impostazioni pericolose della CA e web enrollment HTTP, ESC9, ESC10 ed ESC11 colpiscono il livello che decide se un certificato viene effettivamente mappato all'account corretto: l'estensione di sicurezza incorporata nel certificato, la configurazione di mapping dei certificati del domain controller e l'applicazione della crittografia sull'interfaccia RPC di enrollment della CA.

Tutte e tre le tecniche esistono a causa dello stesso cambiamento sottostante: l'aggiornamento Microsoft di maggio 2022 (KB5014754) ha introdotto l'estensione di sicurezza szOID_NTDS_CA_SECURITY_EXT, che incorpora il SID del principal richiedente nel certificato emesso in modo che il KDC possa vincolare fortemente quel certificato a un unico account. ESC9, ESC10 ed ESC11 sono tre modi diversi in cui questo binding può non riuscire a proteggere un ambiente — uno a livello di template, uno a livello di domain controller/Schannel e uno a livello di trasporto RPC.

Come funziona

ESC9 — Nessuna estensione di sicurezza

ESC9 esiste quando il msPKI-Enrollment-Flag di un template di certificato include il bit CT_FLAG_NO_SECURITY_EXTENSION (0x80000). La documentazione Certify di SpecterOps descrive questo come la soppressione dell'estensione szOID_NTDS_CA_SECURITY_EXT su qualsiasi certificato emesso da quel template. L'effetto è che il processo di mapping del certificato si comporta come se StrongCertificateBindingEnforcement fosse impostato su 0, indipendentemente dal suo valore effettivo nel registro del domain controller, perché non c'è alcun SID nel certificato da verificare.

Da solo, quel flag non è sfruttabile. Diventa ESC9 quando combinato con una seconda condizione che gli attaccanti già cercano su template adiacenti a ESC1-ESC8: un principal a basso privilegio che detiene GenericWrite (o equivalente) su un altro account. Un attaccante con GenericWrite su un account vittima può modificare lo userPrincipalName di quell'account per farlo corrispondere a un target privilegiato (ad esempio lo sAMAccountName di un amministratore), effettuare l'enrollment di un certificato dal template contrassegnato ESC9 come account vittima, e autenticarsi come il target impersonato — perché il certificato risultante non porta alcuna estensione SID che contraddica l'UPN falsificato.

ESC10 — Mapping debole dei certificati (a livello di dominio)

ESC10 produce lo stesso risultato pratico di ESC9 — un'autenticazione che si risolve verso l'account sbagliato — ma la configurazione errata risiede nel domain controller o in Schannel, non su un singolo template di certificato. SpecterOps e la ricerca della community (incluso il wiki di Certify e analisi indipendenti su ADCS) descrivono due varianti:

• Caso A — Il valore di registro CertificateMappingMethods di Schannel sul domain controller include il mapping UPN. Un attaccante in grado di scrivere sullo userPrincipalName di un account vittima (di nuovo tramite GenericWrite o simile) lo imposta in modo che corrisponda a un principal target, quindi si autentica via Schannel (autenticazione client TLS) con qualsiasi certificato il cui subject o SAN rifletta l'UPN falsificato.
• Caso B — StrongCertificateBindingEnforcement sul domain controller è impostato esplicitamente su 0 (modalità Compatibilità) anziché sul valore predefinito applicato, per cui un'estensione SID mancante o non corrispondente viene accettata anziché rifiutata, per ogni template e ogni principal — non solo per un template contrassegnato come in ESC9.

La differenza operativa chiave rispetto a ESC9: ESC10 non è limitato a un singolo template di certificato, quindi tipicamente amplia il pool di account sfruttabili all'intero dominio.

ESC11 — Relay NTLM verso l'interfaccia RPC della CA

ESC11 è l'equivalente a livello di trasporto RPC di ESC8 (relay NTLM verso il web enrollment HTTP). Le Certificate Authority espongono l'interfaccia RPC ICertPassage (MS-ICPR) per le richieste di certificati. Secondo la documentazione Certify di SpecterOps e la ricerca indipendente di Compass Security, se quell'interfaccia applica la crittografia a livello di pacchetto è controllato dal flag di interfaccia IF_ENFORCEENCRYPTICERTREQUEST sulla CA. Quel flag è abilitato per impostazione predefinita ma viene spesso disabilitato per compatibilità con client più vecchi che non riescono a negoziare RPC_C_AUTHN_LEVEL_PKT_PRIVACY.

Quando il flag è disattivato, un attaccante che costringe una vittima (ad esempio l'account macchina di un domain controller) ad autenticarsi via NTLM può fare relay di quell'autenticazione verso l'interfaccia RPC della CA — aggirando le stesse protezioni di web enrollment coperte da ESC8, ma via RPC anziché HTTP, e indipendentemente dal fatto che il web enrollment sia anche installato.

La catena di attacco

🚨 Pericolo: tutte e tre le tecniche possono concludersi con lo stesso esito di ESC1-ESC8 — un certificato utilizzabile per l'autenticazione Kerberos PKINIT come Domain Admin o domain controller. L'escalation via GenericWrite si concatena direttamente con Abuso di ACL e DCSync: i percorsi silenziosi verso Domain Admin. Il passaggio di relay di ESC11 utilizza le stesse primitive di coercizione/relay trattate in Attacchi di relay NTLM: dirottamento dell'autenticazione in AD.

Rilevamento

Remediation

1. Rimuovere CT_FLAG_NO_SECURITY_EXTENSION dai template (ESC9). Verifica il msPKI-Enrollment-Flag di ogni template di certificato. Qualsiasi template capace di autenticazione con questo flag impostato dovrebbe averlo rimosso, salvo un motivo documentato e verificato — e quel motivo non dovrebbe includere diritti di enrollment non privilegiati.
2. Portare i domain controller in Full Enforcement (ESC10, Caso B). Conferma che StrongCertificateBindingEnforcement non sia bloccato su 0. Secondo la timeline del KB5014754 di Microsoft, i domain controller senza un valore di registro esplicito sono passati alla modalità Full Enforcement con l'aggiornamento di febbraio 2025, e la chiave di registro stessa ha smesso di essere considerata dopo l'aggiornamento di settembre 2025 — uno 0 esplicito lasciato in essere è quindi un downgrade deliberato che deve essere individuato e giustificato.
3. Disabilitare i metodi di mapping Schannel deboli (ESC10, Caso A). Rivedi CertificateMappingMethods su ogni domain controller e su qualsiasi server che termina l'autenticazione TLS con certificato client. I metodi deboli (Subject/Issuer, Solo Issuer, UPN) dovrebbero restare disabilitati; dovrebbero essere consentiti solo i metodi forti (S4U2Self, S4U2Self esplicito), salvo che un'applicazione legacy specifica e documentata lo richieda.
4. Applicare la crittografia RPC su ogni CA (ESC11). Esegui certutil -setreg CA\InterfaceFlags +IF_ENFORCEENCRYPTICERTREQUEST su ogni CA, quindi riavvia il servizio Certificate Services (net stop certsvc && net start certsvc). Valida in seguito con certutil -config "<CA>" -getreg CA\InterfaceFlags e conferma che 0x200 sia presente.
5. Chiudere l'esposizione GenericWrite sottostante. Sia ESC9 che ESC10 Caso A richiedono che un attaccante possieda già accesso in scrittura allo userPrincipalName di un account vittima. Rivedi le ACL alla ricerca di concessioni troppo ampie di GenericWrite, GenericAll, WriteProperty, o equivalenti a Validated-SPN sugli oggetti utente, in particolare da gruppi di helpdesk o provisioning, nella stessa fase di remediation.
6. Ritestare dopo ogni modifica. Le modifiche al mapping dei certificati e alla crittografia RPC possono interrompere client legacy (versioni Windows meno recenti, client RPC non Windows, middleware smart card datato). Distribuisci le modifiche tramite un gruppo pilota rappresentativo prima di applicarle a livello di dominio, e mantieni attiva la revisione degli eventi KDC/Schannel della sezione rilevamento durante il rollout per confermare che nessuna autenticazione legittima inizi a fallire.

✅ Azione rapida: se il tempo consente una sola azione oggi, esegui il controllo certutil -config "<CA>" -getreg CA\InterfaceFlags su ogni CA. ESC11 non richiede alcun privilegio di directory per essere sfruttato — solo accesso di rete e una primitiva di coercizione — il che lo rende il percorso con la barriera più bassa tra i tre.

Come EtcSec rileva questa esposizione

I controlli di audit AD di EtcSec corrispondono direttamente a ciascuna tecnica: ESC9_NO_SECURITY_EXTENSION segnala i template di certificato che presentano CT_FLAG_NO_SECURITY_EXTENSION su un template capace di autenticazione, ESC10_WEAK_CERTIFICATE_MAPPING rivede la configurazione di mapping dei certificati del domain controller e di Schannel alla ricerca di impostazioni in modalità compatibilità, e ESC11_ICERT_REQUEST_ENFORCEMENT verifica l'applicazione della crittografia RPC su ogni CA rilevata. Poiché sia ESC9 che ESC10 Caso A dipendono da un prerequisito di tipo GenericWrite, EtcSec correla anche questi rilevamenti con la superficie di esposizione ACL più ampia, in modo che un flag di template o un'impostazione di registro venga prioritizzato in base al fatto che un attaccante abbia effettivamente un percorso per sfruttarlo — non segnalato in isolamento.

Se stai costruendo una revisione AD CS completa anziché controllare una tecnica alla volta, abbina questo articolo a Come auditare la sicurezza di Active Directory: cosa rivedere per primo e come dimostrare la remediation per la checklist Tier 0 completa in cui rientrano questi percorsi.

Riferimenti principali

• SpecterOps / Certify — ESC9: No Security Extension
• SpecterOps / Certify — ESC10: Weak Certificate Mapping
• SpecterOps / Certify — ESC11: NTLM Relay to AD CS RPC Interfaces
• Microsoft Support: KB5014754 — Certificate-based authentication changes on Windows domain controllers
• Microsoft Defender for Identity: Enforce encryption for RPC certificate enrollment interface (ESC11)
• Compass Security: Relaying to AD Certificate Services over RPC