Negli ultimi report di Microsoft Threat Intelligence emerge uno schema d’attacco che dovrebbe far riflettere chiunque gestisca un’infrastruttura Active Directory: non serve più un exploit zero-day per arrivare a un Domain Admin. Basta una chat su Teams ben recitata, una sessione di Quick Assist concessa in buona fede da un utente, e la strada verso Active Directory Certificate Services (AD CS) è spianata. In due intrusioni documentate da Microsoft a fine ottobre 2026, gli attaccanti hanno trasformato un semplice help desk scam in un accesso privilegiato al dominio, abusando di due classiche debolezze di configurazione dei template dei certificati: ESC1 ed ESC8. Per chi amministra ambienti Windows Server con una PKI interna, è un promemoria pratico: un certificato di autenticazione equivale a una password che non scade e che nessun reset può revocare automaticamente.
La catena d’attacco: dal social engineering al certificato
Il punto di ingresso non ha nulla di sofisticato dal punto di vista tecnico, ma è estremamente efficace dal punto di vista umano. Gli attaccanti si sono spacciati per il personale IT/help desk aziendale contattando le vittime via Microsoft Teams, spesso da tenant esterni con nomi di dominio onmicrosoft.com costruiti per sembrare plausibili. Convinta la vittima della legittimità della richiesta, l’attaccante la guida ad aprire Quick Assist e a condividere il codice di connessione, ottenendo così il controllo remoto della sessione.
Nel primo caso documentato da Microsoft, una prima ondata di messaggi ha raggiunto 3 utenti compromettendone una workstation; circa 90 minuti dopo una seconda ondata, più ampia, ha coinvolto 16 utenti e un’ulteriore workstation. Durante la sessione remota, l’attaccante deposita un archivio nella cartella Downloads e lo estrae in una directory di staging creata sotto il profilo utente, con un nome che imita un aggiornamento KB di Windows (percorso del tipo AppData\Roaming\KB<numero>) per confondersi con l’attività legittima di patching.
Il payload viene poi eseguito tramite runtime portabili — Python, Bun (JavaScript) o Java — spesso con l’eseguibile rinominato per nascondere la sua reale natura (ad esempio un binario Bun che conserva i metadati originali ma un nome diverso). Questo è un dettaglio importante per chi fa detection: bloccare “i file .exe sospetti” non basta, bisogna correlare contesto, percorso scrivibile dall’utente e provenienza da una sessione di supporto remoto non autorizzata.
# Esempi di comandi di discovery osservati durante la fase di ricognizione
systeminfo
ipconfig /all
tasklist
Caso 1: abuso del template ESC1
La vulnerabilità ESC1 nasce da una combinazione di permessi troppo generosi su un template di certificato: il template consente l’autenticazione client, permette al richiedente di specificare liberamente il Subject Alternative Name (quindi di “dichiarare” di essere chiunque, incluso un account privilegiato) e concede diritti di enrollment a un gruppo troppo ampio (spesso Domain Users o Authenticated Users), senza richiedere approvazione del manager della CA.
Nell’intrusione analizzata, l’attaccante ha ottenuto certificati per 3 account privilegiati nella prima ondata e per altri 8 nella seconda, semplicemente richiedendoli specificando l’identità desiderata nella richiesta. Una volta in possesso di un certificato legato a un account con diritti elevati, l’attaccante ha eseguito un DCSync contro un domain controller nel giro di pochi secondi, estraendo gli hash delle password di tutto il dominio. È il percorso di escalation che tool pubblici come Certify e Certipy automatizzano da anni: identificare template vulnerabili, richiedere un certificato per un account target, autenticarsi con quel certificato (PKINIT per Kerberos) e usare i diritti ottenuti per il dump delle credenziali.
Un dettaglio operativo interessante: uno degli account compromessi era stato escluso dalla risposta automatica di contenimento — probabilmente per non bloccare un service account critico — e ciò ha permesso all’attaccante di continuare a operare indisturbato, con logon di rete e interattivi, accesso a un file server ed esfiltrazione dati tramite Rclone (rinominato “SearchApp.exe”) verso una destinazione SFTP esterna, con fino a 20 trasferimenti concorrenti filtrati per tipo e data del file.
Caso 2: PetitPotam e l’abuso ESC8
Il secondo caso è concettualmente più elegante e mostra perché gli endpoint di AD CS Web Enrollment (/certsrv) vanno trattati con la stessa cura di un controller di dominio. La tecnica PetitPotam sfrutta il protocollo EFSRPC per costringere il domain controller ad autenticarsi, con il proprio account macchina, verso un endpoint controllato dall’attaccante. L’autenticazione NTLM intercettata viene quindi inoltrata (relay) verso l’endpoint Web Enrollment di AD CS, che — se non protetto — accetta la richiesta e rilascia un certificato basato sul template Domain Controller.
Con quel certificato in mano, l’attaccante può ottenere un ticket Kerberos (TGT) tramite PKINIT impersonando l’account del domain controller stesso: è di fatto equivalente a una compromissione totale del dominio. In questo caso specifico, però, Microsoft Defender ha generato correttamente un alert ESC8 e il cliente ha isolato la workstation coinvolta prima che l’attacco proseguisse, un buon esempio di come il rilevamento tempestivo possa fare la differenza anche su tecniche molto conosciute.
Come proteggere il proprio ambiente AD CS
Le raccomandazioni che emergono da questo caso sono applicabili a qualsiasi ambiente con una PKI interna, indipendentemente dal fatto che siate mai stati presi di mira:
- Audit dei template ESC1: individuate i template che abilitano l’autenticazione client e permettono al richiedente di specificare il subject. Rimuovete questa possibilità, restringete i gruppi con diritti di enrollment e richiedete l’approvazione manuale del manager della CA dove sensato.
- Hardening degli endpoint Web Enrollment (ESC8): inventariate tutti gli endpoint
/certsrvesposti e rimuovete quelli non necessari. Imponete HTTPS, abilitate Extended Protection for Authentication (EPA) e, validato il funzionamento di Kerberos, disabilitate NTLM sul servizio (KB5005413). - Auditing della CA: abilitate la sottocategoria “Certification Services” (successi e fallimenti) e il filtro di audit della CA per ogni richiesta ed emissione. Senza questi log, un’escalation ESC1/ESC8 passa inosservata.
- Politiche su Quick Assist e supporto remoto: trattate ogni richiesta non sollecitata come potenzialmente ostile finché non verificata via canale interno noto. Limitate gli strumenti di assistenza remota a prodotti e operatori approvati, e rivedete le policy di accesso esterno su Teams.
- Application control ed EDR: usate App Control for Business (o equivalente) per limitare runtime portabili (Python, Bun, Java) da percorsi scrivibili dall’utente. Valutate i file per firma, nome originale, metadati e processo padre, non solo per estensione.
- Defender for Identity: attivate, se disponibile, le valutazioni di postura dedicate ad AD CS, che segnalano automaticamente template ESC1 vulnerabili ed endpoint ESC8 esposti.
- Risposta agli incidenti: revocate i certificati non autorizzati e aggiornate le informazioni di revoca — ma la revoca non invalida i ticket Kerberos già emessi (PKINIT), quindi verificate anche le sessioni attive. Trattate ogni esclusione dalla risposta automatica come una decisione di incidente a sé.
Conclusione
AD CS è uno dei componenti più potenti e, storicamente, meno controllati delle infrastrutture Active Directory. Il caso descritto da Microsoft dimostra che l’anello debole raramente è la crittografia in sé, quanto la combinazione tra ingegneria sociale (impersonazione help desk su Teams, abuso di Quick Assist) e configurazioni di default o storiche dei template di certificato che nessuno ha mai rivisto. Un audit periodico dei template con strumenti come Certify o Certipy, un logging adeguato della CA e una policy chiara sul supporto remoto restano, ancora nel 2026, le difese più efficaci ed economiche contro questa classe di attacchi.