Percorsi di attacco ADCS spiegati

Percorsi di attacco ADCS: che cosa conta davvero come percorso

Se stai cercando una spiegazione pratica di percorsi di attacco ADCS, bisogna partire dalla catena e non dall’etichetta. Un percorso di attacco in AD CS non è solo un template debole. È la combinazione di regole di emissione, diritti di enrollment, controllo sulla configurazione del template o della CA, endpoint di enrollment raggiungibili e comportamento di autenticazione basato su certificato che consente a un’identità poco privilegiata di diventare più privilegiata o di riaprire quel percorso in seguito.

Per questo una review di AD CS non può fermarsi a un singolo screenshot di Certificate Templates. Bisogna rispondere insieme a cinque domande:

Quali Enterprise CAs esistono nella foresta?
Quali template sono pubblicati e utilizzabili per l’autenticazione?
Chi può enroll, auto-enroll o modificare questi template?
Quali impostazioni globali della CA ampliano l’abuso di subject o SAN?
Quali endpoint di enrollment e quali percorsi di autenticazione rendono questi certificati realmente utilizzabili in produzione?

Nella ricerca Certified Pre-Owned di SpecterOps, le etichette ESC descrivono pattern ricorrenti di abuso. In una review reale sono percorsi di attacco perché collegano la configurazione PKI all’escalation di identità.

Perché i percorsi di attacco ADCS contano ancora in Active Directory

Microsoft documenta AD CS come il ruolo Windows Server che emette e gestisce certificati PKI per autenticazione, cifratura, smart card sign-in, TLS, VPN e altri flussi di sicurezza. Lo stesso ruolo diventa una superficie di identità ad alto impatto quando le regole di emissione dei certificati e di autenticazione tramite certificato si allontanano dal principio di minimo privilegio.

I percorsi AD CS contano perché non tutti assomigliano a un classico abuso amministrativo. Alcuni consentono a un attaccante di richiedere un certificato che autentica come un’altra identità. Altri consentono di modificare prima il piano di controllo e solo dopo creare le condizioni pericolose sul template. Altri ancora dipendono dal relay di autenticazione verso endpoint di enrollment invece che dalla modifica diretta delle impostazioni del template. E altri fanno parte di catene di escalation più ampie con i percorsi di attacco AD o ACL abuse e DCSync, invece di agire da soli.

Un secondo motivo sono i punti ciechi operativi. I team di sicurezza monitorano spesso meglio reset di password, gli errori critici di password in Active Directory e delega Kerberos rispetto all’emissione dei certificati. Se l’audit della CA, la visibilità sui cambiamenti dei template o le baseline di autenticazione tramite certificato sono deboli, un percorso PKI vulnerabile può rimanere attivo molto tempo dopo che altri percorsi di escalation sono già stati esaminati.

Minimum evidence pack

Evidenza	Perché conta
Inventario delle Enterprise CA	Conferma quali CAs e quali role services esistono davvero nella foresta
Template pubblicati	Un template non pubblicato non può essere richiesto tramite quella CA
Diritti di enrollment e auto-enrollment	Mostra se identità a basso privilegio possono ottenere certificati
ACL dei template	Determina chi può manomettere il template
Controlli di subject e SAN	Identifica se i richiedenti possono fornire valori di identità pericolosi
CA edit flags	Rivela impostazioni globali come `EDITF_ATTRIBUTESUBJECTALTNAME2`
Stato di web enrollment, HTTPS ed EPA	Determina se endpoint relayabili restano esposti
Telemetria di emissione e autenticazione tramite certificato	Dimostra se il monitoraggio vede davvero richieste, emissione e autenticazione basata su certificato

Percorsi di abuso dei template: ESC1 e template di autenticazione pubblicati

ESC1 è l’esempio più chiaro di un percorso di abuso del template. Microsoft Defender for Identity descrive la condizione pericolosa così: se un certificate template ha attivo Supply in the request e il certificato è valido anche per l’autenticazione, gli attaccanti potrebbero enrollare un certificato valido per utenti arbitrari.

In pratica, un percorso ESC1 nasce spesso da queste condizioni:

il template è pubblicato su una CA
identità a basso privilegio possono enrollarvi
il template consente valori di subject o SAN forniti dal richiedente
il certificato può essere usato per l’autenticazione, ad esempio con un EKU compatibile con client authentication
nessun controllo più forte, come manager approval o required authorized signatures, blocca l’emissione

Il punto chiave è che il flag da solo non basta. Un template può avere un comportamento di naming rischioso e comunque non essere un percorso attivo se non è pubblicato o se è limitato a una popolazione di enrollment strettamente governata. Al contrario, un template di autenticazione pubblicato, con scope debole e controlli di emissione deboli, è già un percorso di identità e non solo un problema di igiene del template.

Per questo la review dovrebbe parlare di template di autenticazione pubblicati, non solo di “template vulnerabili” in astratto. La pubblicazione determina l’exploitabilità.

Percorsi di piano di controllo: ESC4 ed ESC6

ESC4 ed ESC6 sono percorsi di piano di controllo. Sono pericolosi perché permettono a un attaccante di creare o ampliare un comportamento di emissione sfruttabile anche se il template non è partito in uno stato manifestamente insicuro.

Con ESC4, il problema è l’ACL dell’oggetto template. I certificate template sono oggetti di Active Directory e le loro ACL controllano non solo l’enrollment ma anche chi può modificare l’oggetto. Microsoft Defender for Identity evidenzia esplicitamente il rischio quando gruppi non privilegiati ricevono permessi che consentono di cambiare le impostazioni del template, come Full Control o WriteDACL. In altre parole, l’attaccante non ha bisogno che il template parta già come ESC1: può modificarlo fino a farlo diventare tale.

Con ESC6, il problema si sposta dal template alla CA. Se la CA ha il flag EDITF_ATTRIBUTESUBJECTALTNAME2 abilitato, Microsoft Defender for Identity osserva che gli utenti possono specificare impostazioni SAN nelle richieste di certificato e che ciò influisce sui template indipendentemente dal fatto che abbiano o meno abilitato Supply in the request. Questo non significa che ogni template diventi automaticamente un pulsante diretto per Domain Admin. Significa che la CA ha ampliato la superficie di controllo del subject, rendendo molto più pericoloso qualunque template di autenticazione pubblicato nel scope sbagliato.

Questi due percorsi appartengono alla stessa review di abuso dei permessi e diritti di replica, perché in sostanza sono problemi di governance sul piano di controllo PKI.

Percorsi di relay: ESC8 ed endpoint di enrollment

ESC8 è diverso dall’abuso dei template. Il percorso dipende da endpoint di enrollment relayabili, non solo da flag del template.

Microsoft documenta AD CS web enrollment e certificate enrollment web services come superfici di enrollment basate su HTTP. Il supporto Microsoft KB5005413 spiega perché è importante: se gli attaccanti possono fare relay dell’autenticazione NTLM verso endpoint AD CS vulnerabili, possono ottenere certificati che poi verranno usati per estendere la compromissione. La valutazione ESC8 di Microsoft Defender for Identity restringe ulteriormente la condizione evidenziando endpoint IIS che accettano autenticazione NTLM senza HTTPS forzato o senza Extended Protection for Authentication (EPA).

Questo rende ESC8 un problema di endpoint e di protocollo tanto quanto un problema PKI. La review deve quindi includere:

se CA Web Enrollment o relativi enrollment web services sono installati
se restano accessibili via HTTP
se EPA è realmente imposto
se NTLM è ancora accettato dove Microsoft raccomanda di disabilitarlo o limitarlo

Questo percorso va letto anche accanto all’hardening generale contro il relay, come gli attacchi NTLM relay e SMB signing disabilitato, perché l’endpoint dei certificati è spesso solo un anello della catena.

Dove si colloca weak certificate mapping

Weak certificate mapping conta, ma non è lo stesso problema di ESC1, ESC4, ESC6 o ESC8.

Il nucleo dei percorsi AD CS sopra descritti riguarda come viene emesso un certificato o come può essere riaperto il percorso di emissione. KB5014754 tratta un altro livello: come i domain controller valutano i mapping dell’autenticazione basata su certificato e come evolvono verso un binding più forte. Per questo weak mapping deve essere trattato come controllo adiacente e collegato al post dedicato Weak Certificate Mapping in AD CS: Why Strong Binding Matters, non fuso qui come se fosse già rappresentato dai quattro vuln tag ADCS del gruppo.

In pratica, una review AD CS solida deve distinguere due domande:

un attaccante può ottenere un certificato pericoloso?
se esiste un certificato pericoloso, come lo legheranno i domain controller a un account?

Sono temi collegati, ma non sono lo stesso percorso di attacco.

Rilevamento

Il rilevamento deve correlare emissione, cambiamenti del piano di controllo e telemetria di autenticazione. Nessun singolo evento prova da solo un abuso AD CS.

Telemetria di emissione e configurazione della CA

Le linee guida Microsoft su advanced audit policy e monitoraggio PKI mettono l’audit della CA al centro. Come minimo, il team di sicurezza deve sapere se la CA produce telemetria di richiesta ed emissione come:

4886 per le richieste di certificato
4887 per l’emissione dei certificati
4882 per le modifiche ai permessi di sicurezza di Certificate Services
4890, 4891 o 4892 per modifiche di gestione e configurazione in Certificate Services

Questi eventi sono utili perché mostrano che una richiesta, un’emissione o un cambiamento di configurazione è avvenuto. Non provano da soli che la richiesta fosse malevola. Serve ancora correlare il richiedente, il template, il subject previsto e il flusso operativo atteso.

Telemetria dei cambiamenti agli oggetti Active Directory

I template sono oggetti AD, quindi 5136 conta quando l’auditing è configurato e le SACL rilevanti esistono. Microsoft documenta 5136 come l’evento generato quando un oggetto di Active Directory viene modificato. In una review AD CS è importante per cambi ACL sui template, cambi nello stato di pubblicazione e altre modifiche di oggetto che trasformano un template normale in un percorso di attacco.

Telemetria di autenticazione

Sul domain controller, 4768 registra le richieste di TGT. Questo lo rende utile per correlare l’emissione dei certificati con successivi pattern di autenticazione, soprattutto per account o macchine che normalmente non usano autenticazione basata su certificato. Ma 4768 non è un detector AD CS. È una fonte di correlazione tra più fonti, e diventa molto più utile quando viene combinato con gli eventi di emissione della CA e con una baseline del comportamento atteso di autenticazione tramite certificato.

Evidenze di configurazione ed esposizione

Non tutto il rilevamento utile è event-driven. Alcuni dei finding più importanti in AD CS sono finding di stato:

un template di autenticazione pubblicato resta enrollabile da utenti a basso privilegio
un’ACL di template continua a concedere diritti di scrittura pericolosi
EDITF_ATTRIBUTESUBJECTALTNAME2 resta abilitato
un endpoint di enrollment continua ad accettare condizioni NTLM relayabili via HTTP o senza EPA

Questo è uno dei motivi per cui il monitoraggio sicurezza AD e gli Event ID che contano deve essere combinato con una review di configurazione ripetibile, e non trattato come risposta completa.

Remediation: priorità di correzione

L’ordine corretto è rompere prima i percorsi di emissione attivi, poi indurire il piano di controllo, chiudere i gap degli endpoint e infine validare separatamente la postura di mapping.

1. Rompere i percorsi di emissione attivi

Inizia de-pubblicando o restringendo i template che oggi creano il percorso. Microsoft Defender for Identity raccomanda esplicitamente di rimuovere dalla pubblicazione un template pericoloso quando non dovrebbe essere richiedibile. Se un template deve restare disponibile, riduci prima lo scope di enrollment prima di fare pulizia cosmetica.

Poi rimuovi o limita i comportamenti di subject e SAN forniti dal richiedente quando non sono strettamente necessari. Per i template che devono continuare a supportare flussi speciali, applica controlli di emissione più forti, come approval o authorized signatures, invece di lasciare un enrollment ampio a identità poco privilegiate.

2. Eliminare le condizioni di abuso del piano di controllo

Per ESC4, indurisci le ACL dei template affinché gruppi non privilegiati non possano modificare permessi o impostazioni. Per ESC6, rimuovi EDITF_ATTRIBUTESUBJECTALTNAME2 salvo esista una dipendenza operativa giustificata e revisionata.

Rivedi anche chi può gestire configurazioni della CA, pubblicare template o delegare l’amministrazione PKI. Una correzione sul template non è duratura se un altro operatore o gruppo delegato può ripristinare silenziosamente lo stato pericoloso in seguito.

3. Chiudere le superfici di enrollment relayabili

Per ESC8, applica le mitigazioni Microsoft di KB5005413:

disabilitare i ruoli web di enrollment non usati, dove possibile
imporre HTTPS
abilitare EPA
ridurre o disabilitare l’esposizione NTLM sugli endpoint IIS di enrollment dove Microsoft lo raccomanda

Se web enrollment non è necessario in produzione, rimuoverlo è spesso una riduzione del rischio migliore rispetto al tentativo di conservarlo con controlli parziali.

4. Trattare weak certificate mapping come hardening adiacente

Non confondere l’hardening dei template con l’hardening del mapping. Se l’ambiente dipende ancora da mapping deboli, tratta KB5014754 come una linea di remediation separata e valida esplicitamente questi cambiamenti lato domain controller.

Validazione dopo la remediation

Non chiudere una remediation AD CS finché non puoi dimostrare che il percorso di attacco è stato davvero rotto dalla stessa prospettiva usata nella review di sicurezza.

La validazione deve includere:

prova che i template vulnerabili non sono più pubblicati o non restano più enrollabili da identità poco privilegiate
prova che le entry ACL pericolose sono state rimosse
prova che la CA non espone più EDITF_ATTRIBUTESUBJECTALTNAME2
prova che gli endpoint di enrollment non restano esposti via HTTP o senza EPA quando il percorso dipendeva da quelle condizioni
prova che l’audit della CA ora cattura richieste ed emissioni di certificati
prova che il monitoraggio AD vede i cambiamenti ai template dove conta
prova che i certificati rischiosi già emessi sono stati rivisti e revocati quando necessario

È qui che un flusso più ampio come auditare la sicurezza di Active Directory diventa utile. La validazione AD CS non riguarda un singolo flag: deve dimostrare che percorso di emissione, piano di controllo e percorso di monitoraggio sono cambiati davvero in produzione.

Come EtcSec mappa i percorsi di attacco ADCS

EtcSec deve restare stretto qui: misura le condizioni che creano il percorso.

Per i percorsi centrali, questo significa mappare finding come:

ESC1_VULNERABLE_TEMPLATE
ESC4_VULNERABLE_TEMPLATE_ACL
ESC6_EDITF_FLAG
ESC8_HTTP_ENROLLMENT

La stessa review può anche far emergere finding adiacenti che spiegano perché il percorso esiste o come può concatenarsi più avanti:

ADCS_WEAK_PERMISSIONS
PATH_CERTIFICATE_ESC

Il punto importante non è promettere un rilevamento magico degli attacchi. Il valore sta nel misurare ripetutamente scope dei template, ACL dei template, flag della CA ed esposizione degli endpoint di enrollment, così che il drift PKI diventi visibile prima di trasformarsi di nuovo in una catena di escalation.

Percorsi di attacco ADCS: come errori nei certificati diventano percorsi di escalation in Active Directory