Tag: NTLM

Sistemi di gestione centralizzati: Active Directory e Kerberos in ambito CSIRT/SOC

Panoramica dei sistemi di gestione centralizzati

In ambito enterprise, i sistemi di gestione centralizzati (come i servizi di directory) svolgono un ruolo chiave nella sicurezza informatica. Forniscono un punto unico per gestire identità, autenticazione e autorizzazione degli utenti su tutta l’infrastruttura, semplificando l’amministrazione e migliorando la consistenza delle policy di sicurezza. Ad esempio, Active Directory (AD) di Microsoft è ampiamente utilizzato (oltre il 90% delle organizzazioni lo impiega in forma on-premises, cloud Azure AD o ibrida[1]) come soluzione di identità principale. Grazie a questi sistemi, un team CSIRT/SOC può applicare controlli di sicurezza uniformi (es. criteri di password, restrizioni di accesso) e raccogliere centralmente gli eventi di sicurezza per il monitoraggio. Questo approccio riduce le vulnerabilità dovute a configurazioni incoerenti e permette di reagire più rapidamente agli incidenti. Al contempo, però, la natura centralizzata rende questi sistemi un bersaglio privilegiato per i cyber attaccanti, poiché comprometterli significa ottenere accesso esteso alla rete[2].

Active Directory: Architettura e componenti principali

Active Directory (AD) è un servizio di directory per reti Windows domain che organizza e memorizza informazioni su utenti, computer e altre risorse in modo gerarchico[1]. L’architettura logica di AD comprende i seguenti elementi fondamentali:

  • Domain (Dominio): Un dominio AD è un contenitore amministrativo che raggruppa oggetti (utenti, computer, gruppi) sotto un unico database di directory e un unico spazio dei nomi DNS (es: azienda.local). Rappresenta un boundary di sicurezza e replicazione: tutti i controller di dominio di un dominio condividono il database e autenticano gli utenti di quel dominio.
  • Organizational Unit (OU): Sono unità organizzative, ovvero sottocontenitori all’interno di un dominio, usati per organizzare gli oggetti (ad esempio per dipartimento o sede) e delegare autorizzazioni di amministrazione. Le OU facilitano l’applicazione di Criteri di Gruppo specifici per gruppi di utenti/computer.
  • Tree (Albero) e Forest (Foresta): Un albero è un insieme di domini in relazione gerarchica (ad es. domini figlio europe.azienda.local sotto il dominio radice azienda.local). Più alberi possono essere collegati in una foresta, che è l’insieme più ampio: domini multipli che condividono la stessa struttura logica AD (schema comune, catalogo globale, configurazione) e instaurano trust bidirezionali transitivi fra di loro[3][4]. La foresta è il boundary di sicurezza massimo di AD: tutti i domini in foresta si fidano reciprocamente. In genere la foresta coincide con l’organizzazione complessiva, mentre i domini separano unità organizzative maggiori (es. divisioni aziendali o regioni).
  • Site (Sito): Configurazione opzionale che rappresenta la topologia fisica (es. sedi geografiche) per ottimizzare la replicazione e l’autenticazione (i DC all’interno di un sito replicano frequentemente tra loro e servono preferibilmente client locali).

Componenti fisici: i Domain Controller (DC) sono i server Windows che ospitano Active Directory Domain Services (AD DS) e contengono ciascuno una copia replicata del database AD (file NTDS.dit). I DC gestiscono le richieste di autenticazione (login utenti) e le query al directory. In un dominio vi sono tipicamente più DC per ridondanza e alta disponibilità (almeno due per tollerare guasti)[5]. Tra i DC avviene una replica multi-master continua dei dati AD. Alcuni DC possono avere ruoli speciali (vedi FSMO sotto). Un altro componente chiave è il Global Catalog (GC): un DC (o insieme di DC) che ospita una copia parziale di tutti gli oggetti della foresta, rendendo possibili ricerche rapide su oggetti in qualsiasi dominio. Inoltre, AD supporta Read-Only Domain Controller (RODC), DC di sola lettura pensati per sedi periferiche meno sicure fisicamente, i quali mantengono una copia in sola lettura del database (nessuna modifica locale)[6].

Database AD e schema: AD memorizza gli oggetti con i loro attributi in un database basato su Jet Database. Lo Schema AD definisce la struttura dei dati, ovvero i tipi di oggetti e attributi ammessi (es: utenti con attributi come nome, telefono, gruppi con elenco membri, computer con nome host, ecc.). Lo schema è estensibile ma unico a livello di foresta, ed è gestito centralmente (vedi ruolo Master schema).

Protocolli utilizzati e ruoli FSMO in Active Directory

Active Directory supporta diversi protocolli di rete standard per le sue funzioni: – LDAP (Lightweight Directory Access Protocol): protocollo directory su porta 389/TCP (o 636/LDAPS cifrato) utilizzato per interrogare e modificare il database AD. Client e applicazioni usano LDAP per cercare utenti, gruppi, autenticare su servizi (LDAP bind) ecc. – Kerberos: protocollo predefinito per l’autenticazione in un dominio AD (porta 88/UDP/TCP). Su Kerberos approfondiremo nelle sezioni successive. – NTLM: metodo di autenticazione legacy (challenge/response) usato come fallback se Kerberos non è disponibile (ad es. PC non in dominio o alcuni scenari particolari). È meno sicuro e soggetto ad attacchi pass-the-hash, quindi AD ne limita l’uso in favore di Kerberos. – RPC/SMB: protocolli usati per funzioni interne come la replicazione tra DC, la gestione remota, l’applicazione di policy, etc. Ad esempio il File Replication Service (FRS) o DFS-R per replicare le Sysvol (che contengono script di login e Group Policy) usano SMB, mentre molte operazioni di amministrazione AD usano RPC (porta 135 e porte dinamiche).

Ruoli FSMO (Flexible Single Master Operations)

In AD alcune operazioni critiche sono demandate a ruoli unici detti FSMO (o ruoli operazioni master flessibili) per evitare conflitti nella rete multi-master. I 5 ruoli FSMO in un’infrastruttura Active Directory sono[7]:

  • Master schema – uno per foresta: detiene la unica copia scrivibile dello schema AD. Solo il DC con questo ruolo può aggiornare lo schema (es. aggiunta di nuovi attributi o classi di oggetti).
  • Master per la denominazione dei domini – uno per foresta: responsabile di aggiungere/rimuovere domini nella foresta e assicurare unicità dei nomi di dominio[8]. Previene la creazione di due domini con lo stesso nome.
  • Master RID (Relative ID) – uno per dominio: assegna blocchi di RID unici ai DC del dominio. Ogni oggetto in AD ha un SID (Security ID); il RID è la parte finale variabile del SID. Questo ruolo garantisce che ogni DC usi RID diversi per creare nuovi oggetti, evitando SID duplicati[9].
  • Emulatore PDC – uno per dominio: il DC che agisce da Primary Domain Controller Emulator. È un ruolo chiave per retrocompatibilità e funzioni centralizzate: risponde alle richieste di sincronizzazione oraria, gestisce cambi password immediati, funge da server primario per le autenticazioni NTLM e coordina la distribuzione delle Group Policy. In pratica, è considerato il DC di riferimento principale per il dominio (simulando il vecchio PDC di Windows NT)[10]. Inoltre, in un ambiente con più DC, è il PDC Emulator a essere contattato per operazioni come lock/unlock account.
  • Master infrastrutture – uno per dominio: si occupa di mantenere riferimenti consistenti tra oggetti di domini differenti (in particolare converte SID e GUID di oggetti esterni in nomi canonici, aggiornando riferimenti nei gruppi qualora utenti vengano spostati tra domini)[11]. In una singola foresta con un solo dominio, questo ruolo può passare inosservato; in foreste multi-dominio evita problemi di referenze “orfane” mostrando SID non risolti nelle ACL se non funzionasse.

Tali ruoli possono essere spostati tra DC (tramite strumenti grafici o PowerShell) per bilanciare il carico o in caso di decommissionamento di un controller. È fondamentale monitorare lo stato dei ruoli FSMO perché, pur avendo AD un meccanismo flessibile (in caso di DC offline i ruoli possono essere sequestrati da un altro DC), la perdita prolungata di un FSMO può impedire operazioni importanti (ad es. senza Master RID non si possono creare nuovi utenti quando i RID disponibili sui DC finiscono).

Gestione della sicurezza in Active Directory

Group Policy e controllo centralizzato

Una delle funzionalità più potenti di AD in ottica sicurezza è la Group Policy. I Criteri di Gruppo (GPO) permettono di applicare impostazioni di configurazione e di sicurezza in modo centralizzato a gruppi di computer o utenti all’interno del dominio (ad es. impostare la policy password complessa, i limiti di lockout, le impostazioni del firewall client, restrizioni software, etc.). Le GPO possono essere collegate a livello di sito, dominio o OU e vengono applicate automaticamente ai sistemi/utenti interessati all’avvio o login. Questo consente un controllo uniforme: invece di configurare manualmente ogni host, gli amministratori definiscono il criterio una volta in AD e assicurano conformità su larga scala. Ad esempio, tramite GPO si può imporre che tutte le macchine del dominio abbiano login screen banner di avviso, che gli utenti non possano installare software non autorizzato, o che vengano eseguite specifiche configurazioni di auditing (vedi dopo). Un’altra area critica gestibile via GPO è la politica password: a livello di dominio si definisce lunghezza minima, complessità e durata delle password utente, nonché soglie di blocco account per tentativi falliti (mitigando brute force)[12]. In contesti avanzati, AD supporta anche fine-grained password policies (PSO) per eccezioni su gruppi specifici, ma la policy di dominio resta fondamentale. Il vantaggio per il SOC è chiaro: uniformità delle configurazioni di sicurezza e riduzione degli errori manuali.

Autenticazione e autorizzazione centralizzate

Active Directory gestisce in modo integrato autenticazione (verifica dell’identità) e autorizzazione (controllo degli accessi) in rete[13]. Quando un utente si logga a un computer membro del dominio, le sue credenziali vengono verificate dal Domain Controller usando Kerberos (per default). AD quindi emette token contenenti l’identità utente e i suoi gruppi di appartenenza (SIDs), che saranno usati per autorizzare l’accesso alle risorse. L’autenticazione centralizzata garantisce che solo utenti validi (presenti nel database AD) possano accedere e che la loro password sia verificata secondo le policy del dominio. L’Single Sign-On (SSO) è un beneficio: un utente, autenticandosi al dominio una volta, riceve i ticket Kerberos per accedere a più servizi senza dover reinserire credenziali per ognuno[14].

L’autorizzazione nelle risorse Windows avviene tramite ACL che contengono SID di utenti/gruppi AD; grazie a AD, i gruppi possono essere usati per gestire ruoli e permessi (es: mettere un utente nel gruppo “Finance” gli dà automaticamente accesso alle cartelle riservate a Finance se le ACL sono configurate di conseguenza). La centralizzazione AD consente di modificare un membership di gruppo e influenzare immediatamente i privilegi su molte risorse. AD fornisce anche meccanismi avanzati come il Delegation of Control (possibilità di delegare permessi amministrativi granulari su OU ad esempio a un IT locale, senza dare privilegi globali) e funzionalità di trust tra domini/foreste per estendere l’autenticazione federata (un utente di un dominio trusted può essere autenticato nel dominio trusting).

Auditing e monitoraggio

Dal punto di vista di un SOC, monitorare Active Directory è cruciale perché molte tracce di compromissione emergono negli eventi di sicurezza del dominio. Windows Server fornisce una serie di Security Auditing che, se abilitati tramite policy, registrano eventi come logon riusciti e falliti, utilizzo di credenziali, modifiche a utenti o gruppi, cambi ACL, ecc. Tramite Group Policy (es. configurando la Default Domain Controllers Policy per i DC) si possono attivare audit dettagliati: ad esempio Audit account logon events, Audit account management (creazione/modifica utenti/gruppi), Directory Service Access (accessi a oggetti AD), ecc. Una volta abilitati (spesso definendo sia Success che Failure per ottenere tracce di tentativi falliti) i Domain Controller iniziano a generare eventi nel registro di Sicurezza Windows.

Per gestire l’auditing AD: 1. Si attivano le categorie di audit via GPO (sotto Computer Configuration > Windows Settings > Security Settings > Advanced Audit Policy Configuration[15][16]). 2. Si raccolgono i log di sicurezza dai DC centralmente (tipicamente inviandoli a un SIEM o aggregatore) per analisi. Ad esempio, un evento 4625 (logon failed) su un DC con codice errore indica un tentativo di accesso fallito, un 4720 indica creazione di un nuovo account utente, un 4723 tentativo di cambio password, 4728 aggiunta a gruppo privilegiato, ecc. 3. Si configurano alert su eventi sensibili (es: molteplici lockout account possono indicare brute force; modifica di membership Domain Admins genera evento 4728 da attenzionare).

L’auditing nativo può essere complesso (molti eventi verbosi), ma esistono soluzioni che aiutano (strumenti Microsoft come Advanced Threat Analytics/Defender for Identity, o soluzioni terze) per individuare anomalie. Indipendentemente dagli strumenti, è fondamentale che un CSIRT/SOC abiliti e utilizzi l’auditing AD: modifiche anomale su AD spesso sono segnale di compromissione in atto. Come raccomandato da guide specializzate, tutte le azioni privilegiate dovrebbero essere tracciate e riviste regolarmente[17]. In sintesi, AD offre gli elementi per un controllo centralizzato, ma spetta all’organizzazione implementare una robusta politica di logging, monitoring e auditing per trarne vantaggio.

Kerberos: principio di funzionamento

Kerberos è un protocollo di autenticazione di rete, progettato dal MIT, basato su un sistema di ticket che permettono a nodi (client e server) di autenticarsi reciprocamente su una rete insicura senza trasmettere password in chiaro. Il nome deriva da Cerbero, il cane a tre teste della mitologia greca, ad indicare le sue tre componenti principali: un client (principal), un servizio richiesto e un Key Distribution Center (KDC) centrale che funge da guardiano[18][19]. In ambiente Windows/AD, il KDC è implementato sui Domain Controller.

Figura – Le “tre teste” di Kerberos: Principale (l’entità che si autentica, ad es. un utente), Risorsa/Servizio a cui vuole accedere, e KDC (Key Distribution Center) che media l’autenticazione.[18]

Kerberos opera secondo un meccanismo di fiducia centralizzata: il KDC possiede una chiave segreta condivisa con ogni utente (derivata dalla password) e con ogni servizio/server (derivata dalla password dell’account computer o account servizio registrato in AD). Il processo di autenticazione Kerberos (versione Kerberos V5 usata in AD) avviene in più fasi (detto ticketing):

  1. Client richiede un Ticket-Granting Ticket (TGT) – Quando, ad esempio, un utente inserisce credenziali per accedere al dominio, il suo computer invia al KDC (servizio di Authentication Service, in esecuzione sul DC) un’autenticazione iniziale AS-REQ con il proprio principal (es. nome utente). Il KDC verifica le credenziali (nel caso di AD, controlla l’hash della password dell’utente confrontandolo con quello memorizzato in AD) e, se corrette, genera un Ticket-Granting Ticket. Il TGT è un ticket crittografato con la chiave segreta del KDC (nota solo al KDC stesso), contenente l’identità dell’utente, timestamp e una chiave di sessione. Il TGT viene restituito al client nell’AS-REP, insieme a una copia della chiave di sessione cifrata con la chiave dell’utente (così solo l’utente – conoscendo la propria password – può decifrarla). Da notare che a questo punto il KDC ha autenticato l’utente, ma l’utente non ha ancora accesso a nessun servizio di rete, solo al diritto di chiedere ticket ulteriori.
  2. Client richiede un ticket di servizio (TGS) – Quando il client vuole accedere a una risorsa specifica (es. un file server o un’applicazione web che supporta Kerberos), utilizza il TGT ottenuto per fare una richiesta TGS-REQ al Ticket-Granting Service (sempre sul KDC) per un ticket verso quel servizio. La richiesta include il TGT e indica il Service Principal Name (SPN) del servizio desiderato (ad es. HTTP/nomeServer per un sito web, o cifs/fileserver1 per un file share SMB). Il KDC verifica il TGT (che essendo firmato dalla sua chiave può essere validato e considerato prova dell’identità del client) e controlla nei propri database AD se l’utente ha diritto di accedere al servizio richiesto. Se tutto ok, il KDC genera un Ticket di Servizio (detto anche service ticket o TGS), crittografato con la chiave segreta del servizio target (nota solo a quel server). Questo ticket contiene l’identità del client, un nuovo session key client-server e le autorizzazioni (nel contesto AD, include il PAC – vedi dopo). Il KDC invia al client il ticket di servizio nell’TGS-REP, insieme a una copia della session key client-server (cifrata con la chiave già condivisa col client tramite il TGT). A questo punto il client ha un ticket valido per presentarsi al servizio.
  3. Accesso al servizio (AP-REQ/AP-REP) – Il client contatta il server target presentando il ticket di servizio (messaggio AP-REQ). Il server, che conosce la propria chiave segreta, decifra il ticket e ottiene così la session key e l’identità del client. Può opzionalmente inviare una risposta AP-REP per confermare al client la propria identità (mutua autenticazione). Da questo momento, client e server hanno stabilito una fiducia reciproca e possono comunicare in modo sicuro. Il client è autenticato presso il servizio senza aver trasmesso la password in rete (solo ticket cifrati). Il servizio, grazie alle informazioni nel ticket (come i gruppi di appartenenza dell’utente nel PAC), può effettuare il controllo di autorizzazione e concedere o negare l’accesso alla risorsa richiesta.

Questo sistema di ticket fa sì che le credenziali sensibili (password) non circolino mai sulla rete; inoltre i ticket hanno una durata limitata (tipicamente il TGT dura 8-10 ore, i ticket di servizio alcune ore) e includono timestamp per prevenire replay. Kerberos fornisce anche mutua autenticazione (il client si fida del server solo se quest’ultimo dimostra di aver decifrato il ticket, quindi di essere legittimo). In Windows, Kerberos è integrato: il processo avviene in gran parte in background quando un utente esegue il logon al dominio e quando accede a risorse domain-based.

Crittografia e sicurezza in Kerberos

Kerberos si basa su crittografia simmetrica forte per proteggere i ticket e le comunicazioni[20]. Nel contesto Active Directory, le versioni moderne usano algoritmi AES (Advanced Encryption Standard) per cifrare ticket e chiavi (Windows Server 2008+ supporta AES, mentre versioni più vecchie usavano DES o RC4-HMAC[21]). Ogni principal (utente o servizio) ha in AD una chiave segreta derivata dalla password: per utenti è l’hash della password NT, per i computer/servizi è la password dell’account macchina o service account. Il KDC conosce tutte queste chiavi, perciò può creare ticket cifrati destinati sia al client (cifrati con chiave dell’utente) sia al servizio (cifrati con chiave del servizio).

Alcuni dettagli di sicurezza: – Pre-autenticazione: Kerberos v5 in AD richiede che l’utente provi di conoscere la propria chiave già nella richiesta AS-REQ (inviando un timestamp cifrato con la propria chiave). Ciò previene attacchi offline: senza pre-auth, un attacker potrebbe chiedere un TGT e riceverlo cifrato con la chiave dell’utente, tentando poi di crackare offline la password da quel ticket (attacco AS-REP Roasting). Con la pre-auth attiva, il KDC non risponde se l’utente non dimostra prima la conoscenza della chiave. Nota: è importante che tutti gli account AD mantengano abilitata la pre-auth (è di default, ma può essere disabilitata per compatibilità): account senza pre-auth sono esposti ad attacchi di password guessing offline[22]. – Time synchronization: Kerberos dipende da orologi sincronizzati: i ticket hanno timestamp e scadenze. In AD è tollerato tipicamente un skew di 5 minuti; se l’orologio di un client differisce troppo, l’autenticazione fallirà. Per questo, parte delle best practice è assicurare NTP attivo su DC e client. – Session keys: per ogni autenticazione a un servizio, Kerberos genera chiavi di sessione uniche che il client e il server useranno per cifrare la sessione (ad esempio integrità e/o confidenzialità dei dati scambiati dopo l’autenticazione, se l’applicazione lo supporta). Ciò garantisce che anche se qualcuno intercettasse il ticket, non potrebbe usare la sessione senza la session key (che è protetta). – PAC (Privilege Attribute Certificate): è un campo aggiuntivo che Microsoft ha inserito nei ticket Kerberos in ambiente AD. Il PAC contiene gli identificatori di sicurezza e privilegi dell’utente (SID utente, SID dei gruppi di appartenenza, attributi come il SIDHistory, ecc.). Quando un utente presenta un ticket a un server, quest’ultimo può (ed è tenuto a) validare il PAC contattando un DC (procedura di PAC validation) per assicurarsi che non sia stato manomesso[23]. Il PAC consente al server di conoscere i gruppi e quindi applicare le ACL adeguate, ed è firmato dal KDC per garantirne l’integrità. Attacchi sofisticati come Golden Ticket coinvolgono la falsificazione del PAC, come vedremo.

Vulnerabilità note del protocollo Kerberos

Nonostante Kerberos sia considerato un protocollo molto sicuro, esistono vulnerabilità e attacchi noti legati al suo utilizzo in Active Directory: – Kerberoasting: è una tecnica di attacco che sfrutta il fatto che i ticket di servizio Kerberos per account di servizio AD (spesso associati a SPN) sono cifrati con hash derivati dalla password dell’account servizio. Un attacker che ha un accesso minimo al dominio (anche solo un account non privilegiato) può richiedere un ticket di servizio per un determinato SPN (operazione consentita a chiunque), ottenendo un ticket TGS cifrato con la chiave del servizio. Se l’account servizio ha una password debole, l’attaccante può fare cracking offline del ticket per risalire alla password in chiaro del servizio[24][25]. Questo attacco prende di mira account di servizio privilegiati (es. con diritti amministrativi) con password non abbastanza robuste. – Golden Ticket: attacco devastante in cui un aggressore riesce a compromettere l’account krbtgt (l’account del servizio KDC in AD). Con la chiave di krbtgt, l’attaccante può generare arbitrariamente Ticket-Granting Ticket validi per qualsiasi identità nel dominio, essenzialmente impersonando chiunque (anche un Domain Admin) e ottenendo accesso illimitato[26][27]. Il Golden Ticket consente accesso non autorizzato a qualsiasi sistema come utente privilegiato (Domain Admin) e può restare valido per un lungo periodo senza essere rilevato se non si monitorano attentamente i ticket (l’attaccante può anche personalizzare durata e attributi del ticket). È chiamato “Golden” perché garantisce controllo totale del “regno” AD. – Silver Ticket: simile al Golden, ma invece di compromettere krbtgt, l’attaccante compromette la chiave di un singolo servizio (ad esempio rubando l’hash di password di un account computer o account servizio). Con quella chiave può falsificare ticket di servizio validi per quel particolare servizio solamente. Ad esempio, ottenendo la password di un server applicazioni, può creare un ticket Kerberos per farsi passare per qualsiasi utente verso quel server. Non richiede contattare il KDC, quindi può sfuggire più facilmente al monitoraggio. È limitato a uno specifico servizio, ma se quel servizio gira su un server membro, l’attaccante può usare il Silver Ticket per eseguire code injection e magari arrivare comunque a privilegi di sistema su quell’host, poi muoversi lateralmente. – Pass-the-Ticket: attacco in cui un aggressore ruba un ticket Kerberos valido dalla macchina di un utente (tipicamente un TGT in cache, estraendolo dalla memoria con strumenti come Mimikatz) e lo riutilizza su un altro sistema per impersonare quell’utente senza conoscere le credenziali[28]. In pratica “passa” il ticket rubato, potendo accedere a risorse di rete come se fosse l’utente legittimo. Questo è possibile se l’attaccante ha compromesso una macchina e può estrarre i ticket dalla sessione utente. – Overpass-the-Hash (Pass-the-Key): variante avanzata dove l’attaccante usa l’hash NTLM di un utente per ottenere un TGT Kerberos (convincendo il sistema a generare un ticket con quell’hash). Combina tecniche di pass-the-hash con Kerberos, permettendo di trasformare un furto di hash in un ticket Kerberos valido[29]. – Delegation abuse: Kerberos supporta meccanismi di delegazione che consentono a un servizio di impersonare gli utenti verso altri servizi (utile, ad esempio, per frontend web che devono accedere a un database usando l’identità dell’utente). Esistono la delega non vincolata, vincolata e vincolata alle risorse. Se mal configurate, un utente malintenzionato che compromette un servizio con delega può ottenere ticket che gli consentono di impersonare utenti di alto livello verso altri servizi, realizzando escalation di privilegi[30][31]. In particolare, la unconstrained delegation è pericolosa: qualsiasi account con delega non vincolata può agire come qualsiasi utente che si autentichi su di esso, spesso includendo Domain Admin che accedono al servizio compromesso. – Vulnerabilità crittografiche: L’uso di vecchi algoritmi (DES, RC4) è oggi sconsigliato; Microsoft negli ultimi anni ha rilasciato patch per forzare l’uso di AES e migliorare la protezione del PAC (es. CVE-2021-42287/42278 e aggiornamenti 2022/2023 che richiedono PAC signature sempre valida). Se l’infrastruttura non è aggiornata, un attacker potrebbe sfruttare debolezze note, come spoof del PAC signature (varie CVE 2021-2022) o attacchi brute force agevolati da DES abilitato.

In generale, Kerberos in AD resta robusto, ma la sua sicurezza dipende dalla protezione delle chiavi segrete (password degli account, in primis quella di krbtgt e dei service account) e dalla corretta configurazione. Molti attacchi puntano a estrarre o riutilizzare ticket (pass-the-ticket) o falsificarli conoscendo le chiavi (Golden/Silver). L’evoluzione delle minacce e l’uso scorretto di Kerberos in ambienti complessi ha portato ad una maggiore esposizione nel tempo[32], rendendo fondamentale l’adozione di contromisure adeguate.

Integrazione di Kerberos in Active Directory

In un dominio Active Directory, Kerberos è strettamente integrato e rappresenta la spina dorsale dell’autenticazione. Ogni Domain Controller AD funge da KDC per il suo dominio: in particolare, sul DC girano i servizi Kerberos Authentication Service e Ticket-Granting Service. Quando un client Windows parte di un dominio esegue il logon, di default contatta un DC per ottenere un TGT Kerberos; analogamente, ogni volta che accede a una risorsa di rete (file server, SQL, web app) in grado di Kerberos, utilizza Kerberos con il DC per ottenere i relativi ticket.

L’integrazione comporta alcuni aspetti tecnici importanti: – Account krbtgt: in ogni dominio AD esiste un account utente speciale chiamato krbtgt. Esso non ha login interattivo ma possiede la chiave segreta del KDC. Questa chiave (derivata dalla password random generata all’installazione del dominio) è usata da ogni DC per cifrare e firmare i TGT che emette. Tutti i DC del dominio condividono la stessa chiave krbtgt (replicata come parte di AD). Proteggere l’account krbtgt è fondamentale: come detto, se un attaccante ne ottiene l’hash, può firmare Golden Ticket validi ovunque nel dominio. – Service Principal Name (SPN): AD tiene traccia di tutti i servizi di rete registrati per Kerberos tramite gli SPN associati agli account computer o servizio. Ad esempio, un server SQL di nome DB01 avrà un SPN del tipo MSSQLSvc/DB01.dominio.local. Quando un client chiede un ticket per MSSQLSvc/DB01.dominio.local, il KDC cerca in AD quale account ha quell’SPN (in questo caso l’account computer DB01 se SQL gira sotto Local System, oppure un account utente dedicato se SQL ha un service account) e userà la chiave di quell’account per cifrare il ticket di servizio. La gestione corretta degli SPN è essenziale per Kerberos: SPN duplicati o errati causano errori di autenticazione. Inoltre gli SPN sono sfruttati nell’attacco Kerberoasting, come visto, per individuare account servizio. – PAC e autorizzazioni: Quando un DC AD emette un ticket Kerberos (TGT o service), vi include il Privilege Attribute Certificate con i SID dei gruppi e altri dettagli di privilegio dell’utente. Ciò significa che l’autorizzazione alle risorse può essere valutata dai server immediatamente leggendo il PAC nel ticket presentato. Un file server, ad esempio, quando riceve un ticket da un utente, estrae dal PAC i gruppi dell’utente e può determinare se l’ACL sulla cartella consente accesso. Questa integrazione rende Kerberos in AD più di un semplice autenticatore: trasporta anche informazioni di autorizzazione. Il rovescio della medaglia è che un PAC falsificato (come in Golden Ticket) può ingannare i server facendogli credere che l’utente abbia privilegi che non ha. Per mitigare, i server Windows possono convalidare i PAC chiedendo conferma a un DC (PAC validation). – Trust tra domini: In AD, se un dominio A ha un trust (bidirezionale, transitivo tipicamente) verso dominio B, Kerberos supporta l’autenticazione inter-dominio. Un KDC del dominio A può emettere un Referral Ticket che il client userà per farsi riconoscere da un KDC del dominio B, ottenendo poi ticket per servizi nel dominio B. Questo meccanismo cross-realm (multi-foresta se c’è trust) consente SSO tra domini diversi. Dal punto di vista di un SOC, la fiducia tra domini estende la superficie d’attacco (un attaccante in un dominio potrebbe muoversi su un dominio trusted se riesce a ottenere credenziali valide). È importante quindi gestire con attenzione i trust (limitare quelli esterni non necessari, o usare trust con autenticazione selettiva). – Fallback NTLM: Nonostante Kerberos sia predefinito, AD consente fallback a NTLM in scenari come: client non domain-joined che accedono a risorse tramite credenziali, alcuni protocolli legacy che non supportano Kerberos, o casi di errori (es. orologio fuori sync). Il Domain Controller dunque gestisce anche l’NTLM Authentication Service (tramite il servizio NETLOGON). In un’ottica di sicurezza, ridurre l’uso di NTLM è consigliato perché è meno sicuro; AD offre policy (per esempio via GPO) per rifiutare NTLM in vari scope, preferendo Kerberos.

In sintesi, Active Directory è costruito intorno a Kerberos: senza Kerberos (o NTLM come riserva), gli utenti non potrebbero autenticarsi nel dominio. Per questo la compromissione di componenti Kerberos (come krbtgt o account servizio) equivale alla compromissione di AD stesso. Viceversa, solide policy su AD (password forti, account protetti) rafforzano Kerberos. Un amministratore AD deve avere competenza di Kerberos per capire fenomeni come errori di SPN, scadenza di ticket, e un analista SOC deve sapere interpretare eventi Kerberos (ad esempio i log di Kerberos su DC – Event ID 4768, 4769, 4771 che indicano emissione di TGT, TGS o fallimenti). L’integrazione consente anche funzionalità avanzate come Smartcard logon (Kerberos supporta autenticazione tramite certificati mappati a un utente AD) e protocollo Kerberos Armoring (Flexible Authentication Secure Tunneling – FAST – che mitiga alcuni attacchi come brute force su PA). Queste caratteristiche possono essere implementate per incrementare la sicurezza dell’ambiente.

Esempio pratico: Implementazione di un dominio Active Directory con autenticazione Kerberos

Di seguito descriviamo un esempio pratico di installazione e configurazione di un dominio Active Directory (su Windows Server) e come ciò fornisce autenticazione Kerberos centralizzata:

  1. Installazione di Active Directory Domain Services: Si parte da un server Windows (es. Windows Server 2022). Tramite Server Manager, si aggiunge il ruolo Active Directory Domain Services (AD DS). Completata l’installazione, si esegue il promuovi a controller di dominio per creare una nuova foresta. Durante questa procedura si sceglie il nome del dominio (ad es. laboratorio.local), si imposta la modalità di funzionamento (livello funzionale), si definisce una password DSRM (per il ripristino di Directory Service). Dopo il riavvio, il server diventa il Domain Controller del dominio laboratorio.local. Automaticamente vengono configurati i servizi Kerberos KDC e DNS integrato.
  2. Aggiunta di client e membri al dominio: Su una macchina client (Windows 10/11) si esegue join al dominio (impostando nei dettagli di sistema il dominio laboratorio.local e fornendo credenziali di un amministratore del dominio). Una volta unito, all’avvio l’utente potrà effettuare il logon scegliendo account di dominio. Questo processo implica che il client contatta il DC e utilizza Kerberos per autenticare l’utente: se inseriamo le credenziali di un utente di dominio valido, il DC rilascerà al client un TGT Kerberos e consentirà l’accesso. Da notare che se il DC non fosse raggiungibile, l’utente potrebbe ancora loggarsi con cache delle credenziali (Cached Logon), ma non otterrebbe ticket aggiornati per risorse di rete.
  3. Creazione di utenti, gruppi e unità organizzative: Tramite la console Active Directory Users and Computers (ADUC) si possono creare nuove OU (ad esempio “Uffici” con sottocartelle “Vendite”, “IT”), quindi creare utenti (es. utente alice in OU Vendite e utente admin-it in OU IT) e gruppi globali (es. gruppo VenditeTeam). Quindi si aggiunge l’utente alice al gruppo VenditeTeam. Queste operazioni di fatto centralizzano la gestione: invece di creare account su ogni singolo server, abbiamo un unico account dominio per Alice che vale su tutte le macchine del dominio.
  4. Configurazione dei permessi di accesso alle risorse: Supponiamo che su un file server membro del dominio vi sia una cartella riservata al team Vendite. Tramite le ACL NTFS di Windows, si può assegnare i diritti di Lettura/Scrittura al gruppo di dominio VenditeTeam su quella cartella. Così, quando Alice (membro del gruppo) accede al file server, il suo token (derivato dal ticket Kerberos con PAC) indicherà l’appartenenza a VenditeTeam e il server le concederà l’accesso. Se invece Bob, che non è nel gruppo, provasse, verrebbe negato. Questo mostra la comodità: basta gestire i membri del gruppo in AD per controllare l’accesso, senza dover definire utenti locali su ogni server o permessi individuali.
  5. Implementazione di criteri di sicurezza via Group Policy: Tramite la console Group Policy Management, creiamo o modifichiamo per esempio la Default Domain Policy per applicare regole di sicurezza a tutti gli utenti del dominio. Si può abilitare la complessità delle password, impostare il blocco dell’account dopo 5 tentativi falliti, definire che i membri del gruppo “Domain Admins” ricevano auditing speciale, ecc. Queste impostazioni vengono automaticamente applicate dai DC a tutti i sistemi. Possiamo anche creare GPO mirate: ad esempio una GPO collegata all’OU “IT” che disabilita l’uso di dispositivi USB per i computer IT e impone l’MFA per gli account amministrativi (se infrastruttura ADFS/Azure AD disponibile). Nell’ambito Kerberos, attraverso i Kerberos Policy Settings (in Default Domain Policy > Account Policies > Kerberos Policy) possiamo regolare parametri come la durata massima dei ticket (es. 4 ore per TGT e 8 ore per ticket di servizio), il tempo massimo di skew, e il numero massimo di rinnovi. Di solito si lasciano i default, ma è importante sapere che esistono – ad esempio in ambienti ad alta sicurezza si potrebbe ridurre la durata dei ticket per mitigare il rischio di reuse.
  6. Abilitazione dell’auditing di sicurezza: Per assicurare la tracciabilità, tramite GPO Default Domain Controllers Policy (che si applica ai DC), abilitiamo le audit policy: ad esempio in Computer Configuration > Windows Settings > Security Settings > Advanced Audit Policy Configuration abilitiamo Account Logon, Account Management, Directory Service Access, Logon/Logoff sia Success che Failure[15][16]. Applichiamo la GPO ed eseguiamo gpupdate. Da questo momento i Domain Controller inizieranno a loggare eventi come logon utente, creazione account, ecc. Per esempio, se l’utente admin-it aggiunge Alice al gruppo Domain Admins, sul DC verrà generato un evento ID 4728 (A member was added to a security-enabled global group) con i dettagli; un SOC potrebbe ricevere un alert immediato su questo.
  7. Test e verifica: Ora Alice può loggarsi su qualsiasi PC del dominio con il suo account unico. Quando lo fa, il PC contatta il DC e (trasparentemente) ottiene un TGT Kerberos per Alice. Se Alice accede alla cartella condivisa del file server, il suo PC utilizza il TGT per richiedere al DC un ticket di servizio per cifs/fileserver; DC glielo fornisce, e Alice accede senza reinserire credenziali (SSO). Possiamo verificare con il comando klist sul PC di Alice che nella cache Kerberos ci sono i ticket ottenuti (TGT e ticket per il file server). Sul file server, se tentasse l’accesso Bob (non nel gruppo), Windows loggerebbe un evento di accesso negato.
  8. Strumenti amministrativi aggiuntivi: L’esempio può includere l’uso di Active Directory Administrative Center (ADAC) per gestione avanzata (con interfaccia più moderna e PowerShell integrato), oppure l’uso di PowerShell (modulo ActiveDirectory) per automatizzare operazioni (es: creare più utenti da CSV). Inoltre, implementare LAPS (Local Administrator Password Solution) su client e server membri garantisce che ogni macchina abbia password amministratore locale univoca e archiviata in AD, migliorando la sicurezza (mitiga pass-the-hash su account locali). Le migliori pratiche suggeriscono di usare account amministrativi separati per l’amministrazione (es. admin-it) diversi dagli account personali (Alice), di posizionare gli amministratori in OU con policy più restrittive (es. blocco login interattivo su workstation non amministrative, enforcement di MFA), ecc., tutte cose configurabili via AD.

Questo scenario illustra come Active Directory centralizzi la gestione: un amministratore controlla da un unico punto utenti, gruppi, policy, e Kerberos fa sì che le autenticazioni e le autorizzazioni funzionino automaticamente su tutti i servizi membri del dominio. Per un SOC ciò significa anche che la compromissione di AD (ad esempio un DC violato, o un account admin rubato) ha impatto ovunque, quindi grande attenzione va posta nel monitorare e proteggere AD.

Vulnerabilità e rischi in ambienti AD/Kerberos (CSIRT/SOC)

Active Directory e Kerberos essendo componenti critici e diffusissimi, presentano un’ampia superficie d’attacco. Come notato, AD è spesso un obiettivo primario dei cyber attacchi per via del suo ruolo centrale[2]. In un contesto CSIRT/SOC, è essenziale conoscere le principali tecniche di attacco che i malintenzionati utilizzano contro AD/Kerberos e predisporre contromisure. Di seguito esaminiamo alcune delle tecniche di attacco comuni e i rischi associati, con relative contromisure:

  • Pass-the-Ticket: Consente a un attaccante di rubare ticket Kerberos dalla memoria di una macchina compromessa e riutilizzarli altrove. Ad esempio, tramite malware o tool post-exploitation (es. Mimikatz) l’attaccante estrae il TGT dell’utente corrente (in formato Kerberos Cache). Con quel TGT valido può impersonare l’utente su altri sistemi del dominio, ottenendo accesso non autorizzato senza conoscere la password[28]. Contromisure: rendere difficile l’estrazione di credenziali dalla memoria – abilitare LSA Protection su sistemi Windows (protezione dei processi LSA), usare Windows Defender Credential Guard sulle workstation (che isola i ticket Kerberos in un ambiente virtualizzato), limitare l’adesione di macchine non sicure al dominio. Inoltre, implementare rigorosi controlli sugli account privilegiati (che non dovrebbero lavorare su macchine esposte dove un malware potrebbe rubarne i ticket) e monitorare eventi di autenticazione anomali, ad esempio TGT usati da device insoliti.
  • Golden Ticket: Come descritto, è la capacità di generare TGT arbitrari dopo aver compromesso krbtgt. Il rischio qui è massimo: un Golden Ticket consente di impersonare qualsiasi account (anche non esistente) e dura fino a 10 anni di default se non specificato diversamente, con possibilità di rinnovo infinito. Un attaccante con Golden Ticket può continuare ad avere accesso anche se la violazione iniziale (es. un malware su un server) viene rimossa, perché può crearsi nuovi TGT a piacimento. Contromisure: l’unica difesa efficace è prevenire la compromissione iniziale – quindi proteggere gli account con privilegi che potrebbero portare a Domain Admin e quindi a krbtgt. Ma se si sospetta un Golden Ticket, l’azione da fare è reimpostare due volte la password dell’account krbtgt (due volte perché AD mantiene due chiavi attive per tollerare un cambio, la seconda rotazione invalida sicuramente tutti i ticket generati con la chiave vecchia). Questo è distruttivo (tutti i TGT esistenti diventano invalidi, forzando ri-autenticazione globale) ma necessario in caso di compromissione. Inoltre, monitorare i DC per segni di Golden Ticket: ad esempio ticket con durata anomala o ID fuori range (il Golden Ticket spesso ha un SID 500 amministratore o attributi anomali). Strumenti di detection come Microsoft ATA/Defender Identity segnalano pattern noti di Golden Ticket[33]. Best practice: cambiare l’account krbtgt periodicamente (es. ogni 6-12 mesi) per limitare la finestra di abuso, e soprattutto evitare che un attacker ottenga Domain Admin in primo luogo.
  • Silver Ticket: Permette attacchi mirati a singoli servizi. Un aggressore con hash di un account computer può autenticarsi presso quel servizio quanto vuole. Contromisure: proteggere gli hash degli account macchina e servizio. Questo significa principalmente mantenere i server al sicuro (se un attacker ottiene System su un server, ne estrae l’hash e può creare Silver Ticket per servizi offerti da quel server). L’uso di Managed Service Accounts (MSA/gMSA) aiuta: queste speciali tipologie di account servizio hanno password lunghe gestite automaticamente da AD e non recuperabili in chiaro dagli admin, riducendo il rischio di furto hash. Inoltre, su servizi critici si può abilitare l’AES-only per Kerberos (evitando RC4 che è più facile da usare negli attacchi Silver Ticket in combinazione con pass-the-hash).
  • Kerberoasting: Punta alle password dei service account. Contromisure: adottare password molto robuste per tutti gli account con SPN (ideale >25 caratteri casuali) in modo che il cracking offline sia impraticabile in tempi ragionevoli. Meglio ancora, utilizzare gMSA per i servizi: le gMSA randomizzano automaticamente la password ogni 30 giorni e di solito hanno 120 caratteri, virtualmente impossibili da crackare. Inoltre, eseguire periodicamente un audit degli SPN registrati in AD e individuare account “deboli” (es. con password semplici o mai cambiate) da mettere in sicurezza. Disabilitare la pre-auth è sconsigliato, come già detto, quindi verificare che tutti gli account utente abbiano “Do not require Kerberos preauthentication” non selezionato (solo rarissimi servizi legacy richiedono di toglierla). Un altro controllo: mettere account sensibili nel gruppo “Protected Users” di AD – i membri di questo gruppo non possono usare cifrature deboli né essere soggetti a Kerberoasting in quanto non ottengono ticket TGS rilasciati con chiavi RC4 (usano sempre AES) e hanno TGT con vita breve non rinnovabile.
  • Pass-the-Hash / Overpass-the-Hash: Queste tecniche spesso precedono o seguono quelle Kerberos. Un attaccante che ha l’hash NTLM di un admin può usarlo per autenticarsi (NTLM) o per generare ticket Kerberos (overpass). Contromisure: adottare misure di protezione credenziali sulle macchine (LsaProtect, CredentialGuard come già detto) e minimizzare la presenza di hash di admin su sistemi meno sicuri. Microsoft consiglia il modello Tiered Administration: account amministratore del dominio usati solo sui DC o sistemi Tier-0; account admin di server solo su server, ecc. Così, anche se viene compromesso un PC di un utente, non dovrebbe trovarsi in RAM l’hash di un Domain Admin (che non vi ha mai fatto login). Utilizzare soluzioni come Privileged Access Workstations dedicate agli amministratori per evitare di esporre credenziali alte su macchine esposte a internet o userland.
  • Attacchi alla delega Kerberos: Un attacker che compromette un servizio con delega non vincolata potrebbe impersonare utenti. Contromisure: evitare per quanto possibile la delega non vincolata; preferire la constrained delegation con protocol transition solo dove necessario e aggiungendo l’opzione “ProtocolcTransition e Constrained only to specific services (Resource-based constrained delegation)” introdotta in Windows 2012+; monitorare gli account configurati con delega (sono un potenziale rischio se compromessi). Microsoft offre comandi PowerShell (Get-ADObject -Filter {TrustedForDelegation -eq $True}) per elencarli.
  • Attacchi ai DC (DCSync, DCShadow): Un attaccante con privilegi di Domain Admin può utilizzare tool come mimikatz per simulare il comportamento di un DC e estrarre tutti gli hash delle password (DCSync) o iniettare oggetti malevoli nel directory (DCShadow). Questi sono attacchi post-exploit avanzati. Contromisure: impedire di arrivare a Domain Admin è la chiave. Inoltre, monitorare chiamate replicate anomale: un server che non è DC non dovrebbe mai richiedere replicazioni come se fosse un DC. I log di Directory Service Event ID 4662 con operazioni sospette possono rivelare DCSync (accesso a repliche di segreti). Abilitare l’Advanced Auditing per Directory Service Replication aiuta a catturare questi eventi.

Riassumendo i rischi: se AD viene compromesso in uno dei modi sopra, l’intera rete è a rischio – l’attaccante può leggere email, rubare dati, distribuire malware tramite GPO, o distruggere il dominio. È compito del SOC rilevare segnali precoci: ad esempio, un account che passa improvvisamente a membro di Domain Admin, o l’utilizzo di un account krbtgt (che non dovrebbe mai eseguire logon), o ancora volumi anomali di ticket TGS richiesti (indicatore di Kerberoasting). La difesa è in profondità: prevenzione, durevoli misure di protezione e robusto monitoring.

Contromisure e best practice di sicurezza

La protezione di AD/Kerberos richiede un insieme di best practice procedurali e tecniche. Elenchiamo le più importanti che un team di sicurezza dovrebbe implementare:

  • Principio del minimo privilegio: Limitare rigorosamente il numero di utenti con diritti amministrativi sul dominio. Gli account privilegiati (Domain Admins, Enterprise Admins) dovrebbero essere pochissimi e utilizzati solo quando necessario. Creare ruoli amministrativi delegati per attività specifiche (es. helpdesk può reset password ma non aggiungere membri a Domain Admins). Questo limita l’impatto di eventuali credenziali compromesse.
  • Account amministrativi protetti: Per gli amministratori di dominio, utilizzare account separati dall’utenza normale (es. Mario Rossi usa account standard per email/browsing e un account admin dedicato solo per AD). Tali account vanno collocati in OU con GPO restrittive (es. impedirne l’uso per login interattivo su workstation utenti, forzare MFA, negare accesso da macchine non amministrative). Impiegare workstation sicure dedicate (PAW) per le operazioni amministrative, isolate da internet e da attività a rischio.
  • Protezione delle credenziali e delle chiavi sensibili: Implementare strumenti come LAPS per gestire password locali univoche su ogni macchina (mitiga movimenti laterali via pass-the-hash). Abilitare Credential Guard sui sistemi client se possibile. Per gli account “krbtgt” e quelli di servizio ad alto privilegio, prevedere un cambio password periodico (per krbtgt, come detto, idealmente 2 cambi consecutivi ogni tot mesi) e monitorare il suo utilizzo. Assicurarsi che la pre-autenticazione Kerberos sia sempre abilitata per tutti gli account utente e servizio[34]. Utilizzare Group Managed Service Accounts (gMSA) per i servizi: queste password lunghe e ruotate automaticamente riducono enormemente il rischio di Kerberoasting e la necessità di gestire manualmente credenziali di servizio[35].
  • Hardening dei Domain Controller: I DC dovrebbero essere trattati come sistemi altamente sensibili (Tier 0). Eseguirli su hardware/VM dedicate, con accesso fisico/logico limitato. Disattivare sui DC qualsiasi software o servizio non necessario (niente navigazione internet, niente software di produttività). Mantenere i DC aggiornati con le patch di sicurezza di Windows senza eccezioni – molte patch critiche negli ultimi anni riguardavano Kerberos (es. vulnerabilità PAC, privilege escalation). Considerare di isolare la rete dei DC (segmentazione) così che solo gli host autorizzati possano comunicare con essi sulle porte LDAP/Kerberos.
  • Adozione di misure avanzate Kerberos: Valutare l’uso della funzionalità “Protected Users” in AD – mettendo gli account amministrativi in questo gruppo si applicano restrizioni automatiche: niente NTLM, niente ticket TGT longevi (max 4 ore), richiesta AES obbligatoria, nessuna delega Kerberos consentita, etc. Questo mitiga diversi attacchi. Attivare inoltre le policy di sicurezza Kerberos: ad esempio, abilitare “Kerberos client supporta solo AES” su client e server (impedisce fallback a RC4), e assicurarsi che “PAC Signature Required” sia attiva (ci sono stati aggiornamenti che ora lo rendono obbligatorio per evitare PAC spoofing).
  • Monitoraggio continuo e analisi dei log: Implementare una soluzione SIEM per raccogliere centralmente i log di sicurezza da DC, server e magari anche workstation chiave. Configurare regole di correlazione per eventi AD: ad esempio, alert se un account viene aggiunto ai gruppi Admins, se vengono creati utenti con privilegi, se compaiono autenticazioni di computer fuori orario o da IP insoliti, se un singolo utente richiede tanti ticket per servizi diversi (pattern di Kerberoasting), ecc. Il monitoring continuo e proattivo è essenziale per individuare tempestivamente attività sospette[36]. Microsoft offre strumenti come Defender for Identity (ex Azure ATP) che analizzano in tempo reale i domain controller alla ricerca di indicatori noti (tentativi di DCSync, Golden Ticket, ecc.). Anche senza soluzioni commerciali, molto può essere fatto con il tuning dei log e script personalizzati.
  • Procedure di risposta e recovery pianificate: Un team CSIRT deve predisporre piani specifici per scenari di compromissione AD. Ad esempio, procedure per rotazione urgente di krbtgt (script predefiniti da eseguire su DC), per isolare un DC sospetto, per ripristinare AD da backup in caso di attacco distruttivo (ransomware su DC). Esercitazioni periodiche di recovery AD (incluse prove di Active Directory Forest Recovery) dovrebbero essere svolte, dato che AD è critico (“se AD non funziona, non funziona nulla”[37]). Mantenere backup offline della foresta AD e testarne la validità regolarmente fa parte delle best practice.
  • Migliorare la postura di sicurezza continuamente: Effettuare regolarmente un AD Health Check e un security assessment dell’AD[38]. Ci sono strumenti (es. PingCastle, Purple Knight[38]) che analizzano la configurazione AD evidenziando configurazioni deboli (account con SPN senza pre-auth, deleghe pericolose, permessi ACL anomali, trust deboli, ecc.). Dare seguito a queste raccomandazioni aiuta a ridurre la superficie d’attacco. Documentare e aggiornare costantemente le policy di sicurezza AD, allineandosi alle linee guida Microsoft e CIS Benchmark[39][40].
  • User awareness e formazione amministratori: Non trascurare l’aspetto umano. Formare gli amministratori e i membri del SOC sulle minacce AD (attacchi Golden Ticket, pass-the-hash, ecc.) e sulle procedure di sicurezza (es. non inserire credenziali Domain Admin su prompt sospetti, attenzione al phishing mirato agli admin, etc.). Erogare anche agli utenti awareness sul non installare software non autorizzato, riconoscere email di phishing – tutto ciò riduce le chance iniziali di compromissione che poi potrebbe propagarsi su AD. In caso di incidenti, un amministratore preparato saprà come controllare i DC, dove cercare gli indicatori (log di evento Kerberos, registro replicazione, etc.) e potrà reagire tempestivamente.

In conclusione, Active Directory con Kerberos offre una gestione centralizzata potentissima e conveniente, ma richiede disciplina di sicurezza elevata. Un proverbio in ambito AD dice: “Active Directory detiene le chiavi del tuo regno, ma è sicuro?”[41]. Spetta all’organizzazione implementare difese in profondità: hardening, monitoring e readiness alla risposta. Con le giuste best practice, AD/Kerberos può rimanere un pilastro affidabile dell’infrastruttura, offrendo i vantaggi del single sign-on e dell’amministrazione centralizzata senza diventare il singolo punto di falla. Continuo scrutinio, patching e miglioramento dei controlli sono necessari poiché anche le minacce evolvono e prendono di mira Kerberos ed AD in modi sempre nuovi. Con un’adeguata messa in sicurezza, il team CSIRT/SOC potrà sfruttare al meglio le funzionalità di AD e Kerberos mantenendo l’ambiente protetto e resiliente.