Nelle valutazioni di sicurezza di Active Directory (AD) si tende spesso a focalizzarsi sugli account (Domain Admin, service account) e sulle tecniche di compromesso note (phishing, Kerberoast, Pass-the-Hash). Meno attenzione viene dedicata ai componenti di infrastruttura fortemente integrati con AD — ad esempio Certificate Authority (CA / AD CS), Microsoft System Center Configuration Manager (SCCM), e altri servizi con privilegi di dominio. Questi elementi, se compromessi o mal configurati, possono offrire a un attaccante leve che possono portare fino alla completa compromissione del dominio.
(AD CS) La fiducia “certificata” per l’escalation di dominio
In un’infrastruttura Active Directory, Active Directory Certificate Services (AD CS) rappresenta il cuore della fiducia digitale: rilascia certificati che attestano identità, cifrano comunicazioni e abilitano l’autenticazione sicura tra sistemi.
Ma se la custodia dei nostri sigilli emessi dall’autorità è negligente, l’intero dominio può diventare vulnerabile.
Durante i nostri assessment nell’ambito Active Directory abbiamo spesso evidenziato come configurazioni errate di AD CS possano consentire a un attaccante di passare da un account a basso privilegio fino al controllo completo del dominio, sfruttando i certificati come chiavi d’accesso legittime.
A differenza di molte tecniche di escalation che richiedono catene di exploit e interazioni multiple, una sola configurazione errata in AD CS può abbattere tutte le barriere di sicurezza.
Un template troppo permissivo, un’autorità che emette certificati senza approvazione manuale, o un endpoint web esposto, possono bastare per permettere a un utente comune di autenticarsi come Domain Admin, senza mai rubare una password.
Una volta ottenuto un certificato fraudolento, l’attaccante può usarlo con strumenti come Certipy per richiedere ticket Kerberos (TGT/TGS) come un utente privilegiato o effettuare attacchi “Pass-the-Certificate”, bypassando i controlli sulle credenziali tradizionali.
Template vulnerabili (ESC1)
Questa tipologia di attacco sfrutta template di certificati mal configurati per ottenere un certificato che permette all’attaccante di autenticarsi come un account ad alto privilegio, ad esempio un Domain Admin.
Se un template permette a gruppi troppo ampi (es. Domain Computers o Authenticated Users) di richiedere certificati ed è configurato in modo da consentire a chiunque di specificare manualmente il nome dell’account (campo SAN), allora anche un utente con pochi privilegi può ottenere un certificato che lo identifica come un account amministrativo.
Una volta ottenuto quel certificato “apparente e legittimo”, l’attaccante può usarlo per autenticarsi come l’account preso di mira e, da lì, compromettere l’intero dominio.
CA auto-issuance e SAN utente (ESC6)
Questa tipologia di attacco sfrutta una erronea configurazione dell’autorità di certificazione (CA) che risulta abilitata per l’impostazione EDITF_ATTRIBUTESUBJECTALTNAME2. In pratica, la CA è impostata in modo da permettere ai richiedenti di inserire liberamente nel certificato il campo SAN (cioè il nome dell’account che il certificato rappresenta) e, allo stesso tempo, la CA è configurata per emettere automaticamente le richieste (request disposition = Issue) senza ulteriori controlli.
In queste condizioni, un utente con pochi privilegi può chiedere e ottenere un certificato che dichiara come soggetto un account privilegiato (ad esempio administrator@dominio.local) senza che nessuno lo verifichi. Il risultato è che l’attaccante si ritrova con una credenziale apparentemente legittima che gli permette di autenticarsi con privilegi elevati (ad es. ottenere ticket Kerberos o eseguire attacchi pass-the-certificate) e muoversi nella rete come se fosse quell’account.
NTLM relay su Web Enrollment (ESC8)
Questo attacco prende di mira la funzione web di emissione certificati di AD CS (web enrollment), ossia la pagina che le organizzazioni usano per richiedere o rinnovare i certificati digitali.
L’attaccante induce il Domain Controller a inviare un’autenticazione verso di lui (ad esempio sfruttando strumenti come PetitPotam) e poi rilancia quell’autenticazione verso il servizio web di emissione certificati. Il servizio interpreta la richiesta come legittima e rilascia un certificato per il Domain Controller.
Con quel certificato l’attaccante può fingersi il Domain Controller e ottenere i permessi necessari per muoversi nella rete: in pratica ottiene una “credenziale” apparentemente legittima che gli conferisce accesso elevato all’intera infrastruttura.
Conclusione e prossimi passi
AD CS non è solo una comodità operativa: è uno dei pilastri della fiducia all’interno di un dominio Active Directory. Come abbiamo visto, singole impostazioni (template troppo permissivi, auto-emissione della CA, web enrollment non protetto) possono consentire escalation rapide e difficili da rilevare.
La buona notizia è che si tratta di rischi concreti e rimediabili: bastano controlli mirati, auditing attivo e qualche modifica alle policy per chiudere le leve più pericolose.
Anticipazione — Parte 2: SCCM come leva di attacco
Nella seconda parte dell’articolo esamineremo SCCM (System Center Configuration Manager), un altro “vicino” di Active Directory che spesso viene sottovalutato. Tratteremo i casi più frequenti di misconfiguration— credenziali Network Access Account, account di domain-join troppo potenti, file di deployment con password in chiaro e l’accesso al database SCCM, mostrando come questi errori possano trasformare uno strumento di gestione in un vettore per la compromissione.
Il nostro contributo alla sicurezza di Active Directory
Crediamo che condurre assessment mirati sugli elementi cardine dell’infrastruttura integrata con Active Directory offra una fotografia più realistica della resilienza di un’organizzazione.
Analizzare non solo gli account, ma anche componenti come AD CS o SCCM, permette di comprendere fino a dove un attaccante potrebbe spingersi e quali elementi dell’ambiente verrebbero coinvolti nel suo movimento laterale verso l’obiettivo finale: il controllo del dominio.
Scopri di più su come il team Kokishin può supportare la tua azienda nel valutare e migliorare la sicurezza di Active Directory e dei suoi componenti critici.
