ESC9 vs. ESC16: stessa falla, raggio d'azione diverso

ESC9 e ESC16 sono due delle tecniche numerate di escalation (ESC) catalogate per Active Directory Certificate Services (AD CS), e rappresentano la stessa vulnerabilità a livelli diversi. Entrambe rimuovono l'estensione di sicurezza dell'identificatore di sicurezza (SID) dai certificati emessi, consentendo a un attaccante di impersonare un altro account tramite una mappatura debole dei certificati. ESC9 lo fa su un singolo modello di certificato. ESC16 lo fa su ogni certificato emesso da un'autorità di certificazione (CA).

Se hai risolto ESC9 un paio di anni fa, questo non ti dice nulla su ESC16.

Cos'è ESC9?

ESC9 è un'impostazione del modello. Quando CT_FLAG_NO_SECURITY_EXTENSION è impostato nell'attributo msPKI-Enrollment-Flag di un modello, i certificati emessi da quel modello non includono l'estensione SID (szOID_NTDS_CA_SECURITY_EXT). Questa estensione consente a un domain controller (DC) di associare un certificato a un account specifico. Senza di essa, il DC ricorre alla mappatura sul nome principale utente (UPN).

L'attacco richiede tre cose: un attaccante con accesso in scrittura all'UPN di un account vittima (GenericWrite è sufficiente), diritti di iscrizione su un modello di client-authentication con il flag impostato, e un DC che non applica un mapping forte dei certificati. L'attaccante cambia l'UPN della vittima per farlo corrispondere a un account privilegiato, si iscrive, ripristina l'UPN e si autentica con il certificato come utente privilegiato.

Oliver Lyak ha documentato ESC9 nell'agosto 2022, e molti scanner possono rilevarlo, incluso Netwrix PingCastle. La checklist qui sotto mostra come controllare i tuoi modelli.

Che cos'è ESC16?

ESC16 arriva allo stesso risultato senza modificare un modello. Se l'OID 1.3.6.1.4.1.311.25.2, che è l'estensione di sicurezza szOID_NTDS_CA_SECURITY_EXT SID, è elencato nel valore di registro DisableExtensionList del modulo di policy della CA, la CA smette di aggiungere l'estensione SID a tutto ciò che emette. Ogni modello dietro quella CA ora si comporta come se il flag ESC9 fosse impostato, inclusi modelli che nessuno ha revisionato da anni.

Un ambiente può avere questa impostazione per diversi motivi: una correzione di compatibilità per uno strumento di terze parti, una migrazione o un'applicazione legacy che non gestisce l'estensione. È una singola voce di registro facilmente trascurabile che annulla silenziosamente la protezione che hai costruito modello dopo modello.

L'impostazione non è un attributo del modello. È una configurazione CA, e molte revisioni dell'igiene dei certificati non aprono mai le impostazioni del modulo di policy della CA stessa. Un'organizzazione può essere pulita su ogni modello, avere il rapporto che lo dimostra e comunque essere esposta tramite la CA. Se hai eseguito la scansione per ESC9 anni fa e non hai più controllato le tue CA, un attaccante potrebbe ancora eseguire lo stesso attacco di impersonificazione tramite ESC16.

La mappatura forte dei certificati ti protegge?

In parte. Entrambe le tecniche dipendono dall'accettazione di mappature deboli da parte del DC, e i DC che applicano un binding forte dei certificati le neutralizzano entrambe. Dall'aggiornamento di Windows di settembre 2025, i DC aggiornati eseguono l'applicazione completa e l'impostazione della modalità compatibilità non è più supportata, quindi un dominio completamente aggiornato blocca ESC9 e ESC16 nudi. Rimangono però due lacune: qualsiasi DC che non ha ricevuto quegli aggiornamenti e le catene in cui l'attaccante può fornire il proprio SID nella richiesta del certificato, come ESC16 combinato con ESC6 o ESC15. Controlla l'applicazione su ogni DC e verifica comunque la CA.

Come controlli e risolvi entrambi?

Sono necessari due controlli, perché ESC9 risiede nei template e ESC16 nel CA.

Controlla ESC9 (modelli di certificati)

1. Esegui una scansione di PingCastle.
2. Apri il rapporto e cerca CT_FLAG_NO_SECURITY_EXTENSION (il rischio è A-CertTempNoSecurity). Cerca il testo "Almeno un modello di certificato ha impostato il flag CT_FLAG_NO_SECURITY_EXTENSION."
3. Se quel testo non c’è, nessuno dei modelli scansionati ha la bandiera. Se c’è, rimuovi la bandiera dai modelli interessati.

Controlla ESC16 (la CA)

Su ogni CA, eseguire:

      certutil -getreg policy\DisableExtensionList
      

Se l'OID 1.3.6.1.4.1.311.25.2 appare nell'output, quella CA sta rimuovendo l'estensione SID da tutto ciò che emette. Rimuovilo dalla lista a meno che tu non abbia una motivazione documentata.

Per risolvere, rimuovere l'OID e riavviare Certificate Services affinché la modifica abbia effetto:

      certutil -setreg policy\DisableExtensionList -1.3.6.1.4.1.311.25.2
net stop certsvc
net start certsvc
      

Esegui di nuovo certutil -getreg policy\DisableExtensionList per confermare che l'OID sia scomparso. I certificati già emessi senza l'estensione rimangono tali, quindi controllali se sospetti un uso improprio della configurazione. Se un'applicazione necessitava della configurazione, testala prima di distribuirla ampiamente.

Quindi conferma l'applicazione: verifica che i tuoi DC stiano applicando una mappatura forte dei certificati, poiché questo attenua entrambe le tecniche. Su un DC con aggiornamenti recenti, questa è l'impostazione predefinita. Per il resto dell'esposizione della tua CA, incluso ESC8 nell'iscrizione web, rivedi le impostazioni rischiose di AD CS che spesso si presentano insieme a queste due.

Come catturi la prossima modifica?

Per ESC9 in avanti: il flag del modello risiede in Active Directory, il che significa che una modifica a esso è una modifica a un oggetto AD. Netwrix Threat Prevention monitora le modifiche AD in tempo reale e può bloccarle, quindi chi imposta CT_FLAG_NO_SECURITY_EXTENSION su un modello può essere fermato prima che abbia effetto, non rilevato alla successiva valutazione.

Per ESC16 in avanti: l'impostazione si trova nel registro sul server CA, non in AD, quindi necessita di una copertura dedicata: auditing del registro sugli host CA che alimentano il tuo SIEM, oltre al controllo periodico sopra indicato. Netwrix inoltre correla gli accessi basati su certificato con l'emissione e segnala scenari di estensione SID mancanti, quindi l'abuso dell'impostazione viene rilevato anche se la modifica del registro sfugge.