ADCS ESC2, ESC3, ESC5, ESC7: escalation dei certificati tra le tecniche più note

Cosa sono i percorsi di escalation dei certificati ADCS ESC2 ESC3 ESC5 ESC7

I percorsi di escalation dei certificati ADCS ESC2 ESC3 ESC5 ESC7 si trovano nello spazio tra due estremità ben coperte della superficie di attacco di Active Directory Certificate Services (AD CS). La ricerca Certified Pre-Owned di SpecterOps ha nominato otto tecniche, da ESC1 a ESC8, e ricerche successive hanno aggiunto ESC9, ESC10 ed ESC11. Questo corpus copre già entrambe le estremità: Percorsi di attacco ADCS: come errori nei certificati diventano percorsi di escalation in Active Directory copre ESC1, ESC4, ESC6 ed ESC8, e ADCS ESC9, ESC10, ESC11: escalation dei certificati oltre ESC1-ESC8 copre le tecniche del livello di mapping pubblicate dopo KB5014754. ESC2, ESC3, ESC5 ed ESC7 sono le quattro tecniche della numerazione originale di SpecterOps che nessuno dei due articoli copre.

Questo divario conta perché queste quattro tecniche non sono un residuo casuale, e si concatenano negli stessi percorsi di attacco di Active Directory che l'analisi in stile BloodHound mappa per ogni altra tecnica Tier 0. ESC2 ed ESC3 sono tecniche a livello di template, come ESC1, ma invece di un template che rivela chi un certificato può autenticare, rivelano a cosa un certificato può servire una volta emesso — sia per qualsiasi scopo, sia per lo scopo specifico di richiedere certificati per conto di qualcun altro. ESC5 ed ESC7 sono tecniche di controllo degli accessi, come ESC4, ma invece di un'ACL su un singolo template di certificato, agiscono sugli oggetti e sui permessi che controllano ogni template e ogni certificato che la CA emetterà mai: il controllo degli accessi della CA stessa, e i contenitori PKI in Active Directory che ospitano i template, le registrazioni delle CA, e l'elenco delle CA di cui i controller di dominio si fidano per l'autenticazione.

Un ambiente che ha già rimediato ogni riscontro ESC1, ESC4, ESC6 ed ESC8, e ogni riscontro ESC9, ESC10 ed ESC11, può comunque conservare un percorso attivo verso Domain Admin tramite queste quattro tecniche — perché nessuno degli altri controlli verifica l'ambito degli EKU, la delega dell'agente di iscrizione, o il controllo degli accessi a livello di oggetti PKI e di CA.

Come funziona

ESC2 — Template Any Purpose o senza EKU

ESC2 è un template di certificato il cui Extended Key Usage (EKU) è l'OID Any Purpose (2.5.29.37.0) oppure non definisce alcun EKU, il che Windows tratta come un template equivalente a una CA subordinata utilizzabile per qualsiasi scopo. Secondo la documentazione Certify di SpecterOps, sfruttare questa condizione richiede simultaneamente: che il principal dell'attaccante disponga di diritti di iscrizione a livello di CA, che lo stesso principal disponga di diritti di iscrizione sul template specifico, che il template non richieda l'approvazione di un manager, che il template non richieda firme autorizzate (co-firmate), e che l'EKU del template sia Any Purpose o del tutto assente.

Quando queste condizioni si allineano, l'attaccante si iscrive con un certificato dal template e ottiene una credenziale che Windows accetterà per qualsiasi scopo che consumi certificati — incluso, secondo la documentazione di SpecterOps, lo stesso ruolo di "Certificate Request Agent" da cui dipende ESC3. In altre parole, un template ESC2 può essere usato per avviare un attacco di agente di iscrizione di tipo ESC3 anche se non dichiara mai esplicitamente l'EKU Certificate Request Agent. Per questo i riscontri ESC2 vanno sempre verificati rispetto agli altri template pubblicati della CA prima di scartarli come poco gravi: un certificato Any Purpose è pericoloso solo quanto ciò che la CA permette di farne.

ESC3 — Template agente di iscrizione (catena a due template)

ESC3 è una catena a due template, non un singolo errore di configurazione. Il primo template deve portare l'EKU Certificate Request Agent (OID 1.3.6.1.4.1.311.20.2.1) — lo stesso OID che Microsoft documenta come l'estensione di application policy dell'agente di iscrizione usata per l'emissione di smart card. Secondo la documentazione di SpecterOps, il template di primo stadio richiede gli stessi prerequisiti di iscrizione di ESC2 (diritti di iscrizione a livello di CA e di template, nessuna approvazione manager, nessuna firma autorizzata) più quell'EKU specifico.

Una volta che l'attaccante possiede quel certificato di agente di iscrizione, gli serve un secondo template: uno che non limiti chi può agire come agente di iscrizione, in cui l'attaccante possa iscriversi, che non richieda approvazione manager, e il cui EKU sia compatibile con il ruolo di agente — autenticazione client, PKINIT, accesso tramite smart card, Any Purpose, o nessun EKU. Con entrambi i pezzi in posizione, l'attaccante richiede un certificato dal secondo template per conto di un'identità target, come un Domain Admin, usando il certificato di agente di iscrizione per firmare la richiesta. Il certificato risultante si autentica come il target, non come l'attaccante.

La documentazione Microsoft sulla funzione Restricted Enrollment Agent, introdotta in Windows Server 2008 Enterprise, descrive con precisione perché questo è pericoloso di default: prima di quella funzione, "non è possibile consentire a un agente di iscrizione di iscrivere solo un determinato gruppo di utenti", quindi qualsiasi certificato di agente di iscrizione valido poteva essere usato per richiedere un certificato per conto di qualsiasi utente dell'organizzazione, inclusi i Domain Admin. Restricted Enrollment Agent consente a un amministratore di CA di delimitare quali template e quali gruppi di sicurezza target ogni certificato di agente di iscrizione può usare — ma solo su una CA in edizione Enterprise, e solo se la funzione è stata effettivamente configurata.

ESC5 — Controllo degli accessi vulnerabile sugli oggetti PKI

ESC5 non è affatto un problema di template. È un problema di ACL di Active Directory sugli oggetti che rendono affidabile l'intera PKI. Secondo la documentazione di SpecterOps, gli oggetti coinvolti sono:

• l'oggetto computer AD del server CA stesso
• il server RPC/DCOM del server CA
• l'albero del contenitore Public Key Services nel contesto di denominazione Configuration (CN=Public Key Services,CN=Services,CN=Configuration,DC=...), inclusi i sottocontenitori Certificate Templates, Certification Authorities ed Enrollment Services
• l'oggetto NTAuthCertificates all'interno di quel contenitore

Secondo la documentazione del protocollo [MS-WCCE] di Microsoft, l'oggetto NTAuthCertificates contiene un attributo multivalore di certificati di firma CA codificati in DER — in pratica, l'elenco delle CA di cui i controller di dominio si fidano per l'autenticazione basata su certificati (incluso l'accesso tramite smart card). Se un attaccante può scrivere su quell'oggetto, può aggiungere una CA malevola all'elenco di fiducia; ogni certificato firmato successivamente da quella CA malevola diventa quindi attendibile per l'autenticazione di dominio. La documentazione di SpecterOps fornisce un esempio concreto del rischio generale: Domain Users con GenericAll sul contenitore Certificate Templates e sui suoi discendenti — controllo totale su ogni definizione di template di certificato della foresta, da un gruppo con ambito predefinito.

La gravità di un riscontro ESC5 dipende interamente da quale oggetto è esposto e a chi. L'accesso in scrittura al contenitore Certificate Templates permette a un attaccante di creare o modificare template fino a dar loro una forma ESC1/ESC2/ESC3 da zero, aggirando qualsiasi hardening già effettuato sui template esistenti. L'accesso in scrittura all'oggetto computer della CA o al suo server RPC/DCOM può portare alla compromissione dell'host CA stesso, e con esso, della chiave privata della CA — la stessa classe di impatto documentata in Certighost CVE-2026-54121 ADCS: utenti con pochi privilegi possono impersonare un controller di dominio, dove una diversa falla AD CS permetteva a un utente con pochi privilegi di impersonare un controller di dominio.

ESC7 — Controllo degli accessi vulnerabile sull'autorità di certificazione

ESC7 risiede nel descrittore di sicurezza dell'oggetto CA stesso, non su oggetti AD — e a differenza di ESC6, non è un indicatore di registro. Le CA Windows supportano la separazione dei ruoli tramite due diritti di accesso configurabili nella scheda Sicurezza della console Autorità di certificazione: ManageCA (ruolo di amministratore CA) e ManageCertificates (ruolo di gestore/ufficiale dei certificati).

Secondo la documentazione di SpecterOps, possedere ManageCA consente a un principal di modificare la configurazione della CA a livello globale — incluso attivare il flag EDITF_ATTRIBUTESUBJECTALTNAME2 da cui dipende ESC6, riattivare template vulnerabili precedentemente disabilitati, e abilitare le condizioni da cui dipendono ESC11 ed ESC16. Questo significa che un attaccante che possiede solo ManageCA — senza alcun errore di configurazione del template in vista — può fabbricare condizioni ESC6 o ESC11 a piacimento. La documentazione di SpecterOps descrive anche un abuso più diretto di ManageCA: richiedere un certificato da un template che richiede approvazione manager, lasciare che la richiesta fallisca e rimanga in sospeso, quindi usare ManageCA insieme a ManageCertificates per forzare l'emissione di quella richiesta in sospeso, indipendentemente dal requisito di approvazione che avrebbe dovuto bloccarla.

ManageCertificates da solo consente a un principal di gestire ed emettere certificati in attesa di approvazione. Secondo la documentazione di SpecterOps, questo abilita un bypass di tipo ESC1 tramite issuance policy collegate a gruppi: richiedere un certificato da un template soggetto ad approvazione, usare ManageCertificates per iniettare un OID di issuance policy collegato a un gruppo nella richiesta in sospeso, quindi emetterlo — ottenendo un certificato la cui issuance policy corrisponde a un gruppo privilegiato, senza mai soddisfare il controllo di approvazione manager che il template era configurato per imporre.

La catena di attacco

Lo schema comune a tutte e quattro le tecniche: ESC2 ed ESC3 abusano di ciò che un template è autorizzato a fare una volta che ne esce un certificato; ESC5 ed ESC7 abusano di chi è autorizzato a controllare i template e la CA in primo luogo. Questa seconda categoria spiega perché rimediare ogni singolo template segnalato da ESC1, ESC2, ESC3, ESC4 o ESC6 non chiude la porta — un attaccante con accesso ESC5 o ESC7 può semplicemente ricreare la condizione vulnerabile dopo che la revisione è terminata.

🚨 Pericolo: sia ESC3 sia le varianti in scrittura di ESC5 terminano nello stesso risultato di ESC1 — un certificato che si autentica come un'identità target, convertibile in un TGT Kerberos e utilizzabile per impersonare quell'identità, incluso un Domain Admin. L'escalation verso l'ACL di un oggetto PKI inizia spesso come ricognizione ordinaria di abuso ACL e DCSync piuttosto che come tecnica specifica di AD CS.

Rilevamento

Rimedio

1. Rimuovere i template di autenticazione Any Purpose e senza EKU (ESC2). Limitate l'elenco EKU di ogni template pubblicato a ciò di cui ha realmente bisogno. Se un template deve genuinamente rimanere riutilizzabile per più scopi, mantenete i requisiti di approvazione manager e di firma autorizzata invece di affidarvi solo a un EKU ristretto.
2. Limitare i template agente di iscrizione (ESC3). Configurate Restricted Enrollment Agent su ogni CA in edizione Enterprise che emette certificati Certificate Request Agent, delimitando ogni agente di iscrizione a template specifici e gruppi di sicurezza target specifici invece di lasciarlo senza restrizioni. Dove Restricted Enrollment Agent non è disponibile, limitate chi può iscriversi al template dell'agente di iscrizione al gruppo più piccolo e meglio gestito possibile.
3. Irrobustire le ACL degli oggetti PKI (ESC5). Rivedete le ACL sui contenitori Certificate Templates, Certification Authorities ed Enrollment Services, sull'oggetto NTAuthCertificates, e sull'oggetto computer AD di ogni server CA. Rimuovete GenericAll, WriteDacl, WriteOwner, e diritti equivalenti da qualsiasi principal al di fuori del gruppo di amministrazione PKI Tier 0 previsto.
4. Stringere la separazione dei ruoli della CA (ESC7). Rivedete la scheda Sicurezza di ogni CA e confermate che Manage CA e Issue and Manage Certificates siano posseduti solo dagli account che ne hanno bisogno. Trattate entrambi come privilegi equivalenti a Tier 0, non come impostazioni predefinite di amministrazione IT generica — vedete Messa in sicurezza Active Directory: cosa bloccare prima e come validarlo per capire come questo si inserisce in una revisione dei privilegi Tier 0 più ampia.
5. Rivedere la gestione delle richieste in sospeso. Confermate che forzare l'emissione di una richiesta di certificato negata o in sospeso non sia disponibile di routine agli stessi principal che possono anche richiedere certificati — questa combinazione è esattamente ciò che rende possibile il bypass di approvazione di ESC7.
6. Ritestare dopo ogni modifica. Le restrizioni dell'agente di iscrizione e le modifiche alle ACL PKI possono interrompere flussi legittimi di emissione di smart card e amministrazione delegata. Validate con un gruppo pilota rappresentativo prima di applicare le modifiche a livello di CA, e mantenete attiva la revisione del log di audit della CA della sezione di rilevamento durante il rollout.

Dove si colloca: ANSSI R36, R37, e il resto del corpus ADCS

La guida ANSSI sull'amministrazione sicura di Active Directory (ANSSI-PA-099) tratta il rischio PKI sul Tier 0 come una propria raccomandazione numerata, indipendente dall'igiene generale dei certificati. R36 stabilisce che ogniqualvolta una PKI possa generare certificati utilizzabili per l'autenticazione verso il Tier 0, quella PKI "non deve offrire percorsi di attacco verso il Tier 0 da livelli di fiducia inferiori, che sia tramite l'amministrazione dei sistemi che la ospitano, tramite la delega di diritti sulle capacità di generazione dei certificati, o tramite i template di certificati pubblicati" — una descrizione quasi esatta di ciò che ESC5 ed ESC7 abusano (il controllo delegato sulla capacità di generazione dei certificati, cioè la CA e i suoi oggetti PKI) e di ciò che ESC2 abusa (template pubblicati che concedono più capacità del previsto). La stessa guida menziona separatamente R37, che riguarda la robustezza crittografica dei certificati (vietando le firme DSA, richiedendo hash SHA-2/SHA-3, e imponendo dimensioni minime della chiave RSA) — una preoccupazione reale ma distinta dagli errori di configurazione di EKU e ACL trattati qui, da verificare insieme a queste quattro tecniche piuttosto che al loro posto.

Questo articolo non ripropone deliberatamente ESC1, ESC4, ESC6 o ESC8 — vedete Percorsi di attacco ADCS: come errori nei certificati diventano percorsi di escalation in Active Directory per quelli — né ESC9, ESC10, ESC11, che appartengono al livello di mapping dei certificati e di cifratura RPC trattato in ADCS ESC9, ESC10, ESC11 e nel suo articolo complementare sulla mappatura debole dei certificati. Una revisione completa di AD CS richiede tutti e tre gli articoli, oltre alla checklist Tier 0 più ampia in Auditare la sicurezza di Active Directory: cosa verificare per prima e come dimostrare la remediation, perché nessuna delle undici tecniche sostituisce le altre.

Come EtcSec rileva questo

I controlli di audit AD di EtcSec corrispondono direttamente a ciascuna tecnica trattata qui: ESC2_ANY_PURPOSE segnala i template capaci di autenticazione con un EKU Any Purpose o vuoto e senza controllo di approvazione, ESC3_ENROLLMENT_AGENT segnala i template Certificate Request Agent e i loro target a valle non limitati, ESC5_PKI_OBJECT_ACL rivede le ACL sull'albero del contenitore Public Key Services, NTAuthCertificates, e gli oggetti computer delle CA, e ESC7_CA_VULNERABLE_ACL rivede la separazione dei ruoli a livello di CA alla ricerca di concessioni troppo ampie di ManageCA e ManageCertificates. I riscontri di tutte e quattro le tecniche confluiscono in PATH_CERTIFICATE_ESC quando formano un percorso attivo verso Domain Admin, così che un segnale di template o una voce di ACL venga prioritizzato in base alla sua reale raggiungibilità — non segnalato in isolamento.

Riferimenti principali

• SpecterOps / Certify — Escalation Techniques Overview
• SpecterOps / Certify — ESC2: Misconfigured Any Purpose
• SpecterOps / Certify — ESC3: Misconfigured Certificate Request Agent
• SpecterOps / Certify — ESC5: Vulnerable PKI Object Access Control
• SpecterOps / Certify — ESC7: Vulnerable Certificate Authority Access Control
• Certified Pre-Owned: Abusing Active Directory Certificate Services
• Microsoft: AD CS Restricted Enrollment Agent
• Microsoft: [MS-WCCE] NTAuthCertificates Object
• ANSSI-PA-099: Recommandations relatives à l'administration sécurisée des systèmes d'information reposant sur Microsoft Active Directory