{"id":2430,"date":"2025-08-30T12:38:13","date_gmt":"2025-08-30T10:38:13","guid":{"rendered":"https:\/\/www.fabriziogiancola.eu\/?p=2430"},"modified":"2025-08-30T12:38:13","modified_gmt":"2025-08-30T10:38:13","slug":"sistemi-di-gestione-centralizzati-active-directory-e-kerberos-in-ambito-csirt-soc","status":"publish","type":"post","link":"https:\/\/www.fabriziogiancola.eu\/index.php\/2025\/08\/30\/sistemi-di-gestione-centralizzati-active-directory-e-kerberos-in-ambito-csirt-soc\/","title":{"rendered":"Sistemi di gestione centralizzati: Active Directory e Kerberos in ambito CSIRT\/SOC"},"content":{"rendered":"\n<p class=\"has-dark-gray-color has-very-light-gray-to-cyan-bluish-gray-gradient-background has-text-color has-background has-link-color has-medium-font-size wp-elements-fca6c723e75a650b57070530a54c6470\"><strong>Panoramica dei sistemi di gestione centralizzati<\/strong><\/p>\n\n\n\n<p>In ambito enterprise, i <strong>sistemi di gestione centralizzati<\/strong> (come i servizi di directory) svolgono un ruolo chiave nella sicurezza informatica. Forniscono un punto unico per gestire <strong>identit\u00e0, autenticazione e autorizzazione<\/strong> degli utenti su tutta l\u2019infrastruttura, semplificando l\u2019amministrazione e migliorando la consistenza delle policy di sicurezza. Ad esempio, <strong>Active Directory (AD)<\/strong> di Microsoft \u00e8 ampiamente utilizzato (oltre il 90% delle organizzazioni lo impiega in forma on-premises, cloud Azure AD o ibrida<a href=\"https:\/\/www.semperis.com\/it\/identity-security-glossary\/#:~:text=Active%20Directory%20,suo%20ruolo%20centrale%20nella%20gestione\">[1]<\/a>) come <strong>soluzione di identit\u00e0 principale<\/strong>. Grazie a questi sistemi, un team CSIRT\/SOC pu\u00f2 applicare controlli di sicurezza uniformi (es. criteri di password, restrizioni di accesso) e raccogliere centralmente gli eventi di sicurezza per il monitoraggio. Questo approccio <strong>riduce le vulnerabilit\u00e0<\/strong> dovute a configurazioni incoerenti e permette di reagire pi\u00f9 rapidamente agli incidenti. Al contempo, per\u00f2, la natura centralizzata rende questi sistemi un <strong>bersaglio privilegiato per i cyber attaccanti<\/strong>, poich\u00e9 comprometterli significa ottenere accesso esteso alla rete<a href=\"https:\/\/www.semperis.com\/it\/identity-security-glossary\/#:~:text=queste%20risorse%2C%20comprese%20le%20loro,suo%20ruolo%20centrale%20nella%20gestione\">[2]<\/a>.<\/p>\n\n\n\n<h2 class=\"wp-block-heading has-dark-gray-color has-very-light-gray-to-cyan-bluish-gray-gradient-background has-text-color has-background has-link-color has-medium-font-size wp-elements-7ab091806e57ad4e503237ffce833401\">Active Directory: Architettura e componenti principali<\/h2>\n\n\n\n<p><strong>Active Directory (AD)<\/strong> \u00e8 un servizio di directory per reti Windows domain che organizza e memorizza informazioni su utenti, computer e altre risorse in modo <strong>gerarchico<\/strong><a href=\"https:\/\/www.semperis.com\/it\/identity-security-glossary\/#:~:text=Active%20Directory%20,suo%20ruolo%20centrale%20nella%20gestione\">[1]<\/a>. L\u2019architettura logica di AD comprende i seguenti elementi fondamentali:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Domain (Dominio):<\/strong> Un dominio AD \u00e8 un <strong>contenitore amministrativo<\/strong> che raggruppa oggetti (utenti, computer, gruppi) sotto un unico database di directory e un unico spazio dei nomi DNS (es: azienda.local). Rappresenta un <strong>boundary di sicurezza e replicazione<\/strong>: tutti i controller di dominio di un dominio condividono il database e autenticano gli utenti di quel dominio.<\/li>\n\n\n\n<li><strong>Organizational Unit (OU):<\/strong> Sono unit\u00e0 organizzative, ovvero <strong>sottocontenitori<\/strong> all\u2019interno di un dominio, usati per organizzare gli oggetti (ad esempio per dipartimento o sede) e delegare autorizzazioni di amministrazione. Le OU facilitano l\u2019applicazione di Criteri di Gruppo specifici per gruppi di utenti\/computer.<\/li>\n\n\n\n<li><strong>Tree (Albero) e Forest (Foresta):<\/strong> Un albero \u00e8 un insieme di domini in relazione gerarchica (ad es. domini figlio europe.azienda.local sotto il dominio radice azienda.local). Pi\u00f9 alberi possono essere collegati in una <strong>foresta<\/strong>, che \u00e8 l\u2019insieme pi\u00f9 ampio: domini multipli che condividono la <strong>stessa struttura logica AD<\/strong> (schema comune, catalogo globale, configurazione) e instaurano trust bidirezionali transitivi fra di loro<a href=\"https:\/\/www.fortinet.com\/resources\/cyberglossary\/active-directory#:~:text=Active%20Directory%20establishes%20an%20organized,using%20domains%2C%20trees%2C%20and%20forests\">[3]<\/a><a href=\"https:\/\/www.fortinet.com\/resources\/cyberglossary\/active-directory#:~:text=,DNS%29%20structures\">[4]<\/a>. La <strong>foresta<\/strong> \u00e8 il boundary di sicurezza massimo di AD: tutti i domini in foresta si fidano reciprocamente. In genere la foresta coincide con l\u2019organizzazione complessiva, mentre i domini separano unit\u00e0 organizzative maggiori (es. divisioni aziendali o regioni).<\/li>\n\n\n\n<li><strong>Site (Sito):<\/strong> Configurazione opzionale che rappresenta la <strong>topologia fisica<\/strong> (es. sedi geografiche) per ottimizzare la replicazione e l\u2019autenticazione (i DC all\u2019interno di un sito replicano frequentemente tra loro e servono preferibilmente client locali).<\/li>\n<\/ul>\n\n\n\n<p><strong>Componenti fisici:<\/strong> i <strong>Domain Controller (DC)<\/strong> 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\u00f9 DC per <strong>ridondanza<\/strong> e <strong>alta disponibilit\u00e0<\/strong> (almeno due per tollerare guasti)<a href=\"https:\/\/www.fortinet.com\/resources\/cyberglossary\/active-directory#:~:text=Physical%20components%20represent%20the%20actual,infrastructure%20hosting%20Active%20Directory%20services\">[5]<\/a>. Tra i DC avviene una <strong>replica multi-master<\/strong> continua dei dati AD. Alcuni DC possono avere ruoli speciali (vedi FSMO sotto). Un altro componente chiave \u00e8 il <strong>Global Catalog (GC)<\/strong>: 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 <strong>Read-Only Domain Controller (RODC)<\/strong>, DC di sola lettura pensati per sedi periferiche meno sicure fisicamente, i quali mantengono una copia in sola lettura del database (nessuna modifica locale)<a href=\"https:\/\/www.fortinet.com\/resources\/cyberglossary\/active-directory#:~:text=,master%20domain%20controllers\">[6]<\/a>.<\/p>\n\n\n\n<p><strong>Database AD e schema:<\/strong> AD memorizza gli oggetti con i loro attributi in un database basato su <strong>Jet Database<\/strong>. Lo <strong>Schema AD<\/strong> 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 \u00e8 estensibile ma unico a livello di foresta, ed \u00e8 gestito centralmente (vedi ruolo Master schema).<\/p>\n\n\n\n<h2 class=\"wp-block-heading has-dark-gray-color has-very-light-gray-to-cyan-bluish-gray-gradient-background has-text-color has-background has-link-color has-medium-font-size wp-elements-81773ac693ebc9bb630882db79340463\"><strong>Protocolli utilizzati e ruoli FSMO in Active Directory<\/strong><\/h2>\n\n\n\n<p>Active Directory supporta diversi <strong>protocolli di rete standard<\/strong> per le sue funzioni: &#8211; <strong>LDAP (Lightweight Directory Access Protocol):<\/strong> 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. &#8211; <strong>Kerberos:<\/strong> protocollo predefinito per l\u2019<strong>autenticazione<\/strong> in un dominio AD (porta 88\/UDP\/TCP). Su Kerberos approfondiremo nelle sezioni successive. &#8211; <strong>NTLM:<\/strong> metodo di autenticazione legacy (challenge\/response) usato come <strong>fallback<\/strong> se Kerberos non \u00e8 disponibile (ad es. PC non in dominio o alcuni scenari particolari). \u00c8 meno sicuro e soggetto ad attacchi pass-the-hash, quindi AD ne limita l\u2019uso in favore di Kerberos. &#8211; <strong>RPC\/SMB:<\/strong> protocolli usati per funzioni interne come la <strong>replicazione<\/strong> tra DC, la gestione remota, l\u2019applicazione di policy, etc. Ad esempio il <strong>File Replication Service (FRS)<\/strong> 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).<\/p>\n\n\n\n<h3 class=\"wp-block-heading has-dark-gray-color has-very-light-gray-to-cyan-bluish-gray-gradient-background has-text-color has-background has-link-color has-medium-font-size wp-elements-a9019e7df16a11afb9bc757311eb6c7b\"><strong>Ruoli FSMO (Flexible Single Master Operations)<\/strong><\/h3>\n\n\n\n<p>In AD alcune operazioni critiche sono demandate a <strong>ruoli unici<\/strong> detti FSMO (o ruoli operazioni master flessibili) per evitare conflitti nella rete multi-master. I 5 ruoli FSMO in un\u2019infrastruttura Active Directory sono<a href=\"https:\/\/www.varonis.com\/it\/blog\/fsmo-roles#:~:text=I%205%20ruoli%20FSMO%20sono%3A\">[7]<\/a>:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Master schema<\/strong> \u2013 uno per foresta: detiene la <strong>unica copia scrivibile dello schema AD<\/strong>. Solo il DC con questo ruolo pu\u00f2 aggiornare lo schema (es. aggiunta di nuovi attributi o classi di oggetti).<\/li>\n\n\n\n<li><strong>Master per la denominazione dei domini<\/strong> \u2013 uno per foresta: responsabile di aggiungere\/rimuovere domini nella foresta e assicurare <strong>unicit\u00e0 dei nomi<\/strong> di dominio<a href=\"https:\/\/www.varonis.com\/it\/blog\/fsmo-roles#:~:text=Master%20per%20la%20denominazione%20dei,dominio%20con%20un%20altro%20ruolo\">[8]<\/a>. Previene la creazione di due domini con lo stesso nome.<\/li>\n\n\n\n<li><strong>Master RID (Relative ID)<\/strong> \u2013 uno per dominio: assegna blocchi di RID unici ai DC del dominio. Ogni oggetto in AD ha un SID (Security ID); il RID \u00e8 la parte finale variabile del SID. Questo ruolo garantisce che ogni DC usi RID diversi per creare nuovi oggetti, evitando SID duplicati<a href=\"https:\/\/www.varonis.com\/it\/blog\/fsmo-roles#:~:text=Master%20RID%3A%20il%20master%20ID,privilegio%20di%20assegnare%20determinati%20SID\">[9]<\/a>.<\/li>\n\n\n\n<li><strong>Emulatore PDC<\/strong> \u2013 uno per dominio: il DC che agisce da <strong>Primary Domain Controller Emulator<\/strong>. \u00c8 un ruolo chiave per retrocompatibilit\u00e0 e funzioni centralizzate: risponde alle richieste di sincronizzazione oraria, gestisce cambi password immediati, funge da <strong>server primario per le autenticazioni NTLM<\/strong> e coordina la distribuzione delle Group Policy. In pratica, \u00e8 considerato il DC di <strong>riferimento principale<\/strong> per il dominio (simulando il vecchio PDC di Windows NT)<a href=\"https:\/\/www.varonis.com\/blog\/fsmo-roles#:~:text=PDC%20Emulator%20FSMO%20Role\">[10]<\/a>. Inoltre, in un ambiente con pi\u00f9 DC, \u00e8 il PDC Emulator a essere contattato per operazioni come lock\/unlock account.<\/li>\n\n\n\n<li><strong>Master infrastrutture<\/strong> \u2013 uno per dominio: si occupa di mantenere <strong>riferimenti consistenti tra oggetti di domini differenti<\/strong> (in particolare converte SID e GUID di oggetti esterni in nomi canonici, aggiornando riferimenti nei gruppi qualora utenti vengano spostati tra domini)<a href=\"https:\/\/www.varonis.com\/blog\/fsmo-roles#:~:text=Infrastructure%20Master%20FSMO%20Role\">[11]<\/a>. In una singola foresta con un solo dominio, questo ruolo pu\u00f2 passare inosservato; in foreste multi-dominio evita problemi di referenze \u201corfane\u201d mostrando SID non risolti nelle ACL se non funzionasse.<\/li>\n<\/ul>\n\n\n\n<p>Tali ruoli possono essere spostati tra DC (tramite strumenti grafici o PowerShell) per bilanciare il carico o in caso di decommissionamento di un controller. \u00c8 fondamentale monitorare lo stato dei ruoli FSMO perch\u00e9, pur avendo AD un meccanismo flessibile (in caso di DC offline i ruoli possono essere <strong>sequestrati<\/strong> da un altro DC), la perdita prolungata di un FSMO pu\u00f2 impedire operazioni importanti (ad es. senza Master RID non si possono creare nuovi utenti quando i RID disponibili sui DC finiscono).<\/p>\n\n\n\n<h2 class=\"wp-block-heading has-dark-gray-color has-very-light-gray-to-cyan-bluish-gray-gradient-background has-text-color has-background has-link-color has-medium-font-size wp-elements-8a03e2d576dea055d8af3672589956a9\"><strong>Gestione della sicurezza in Active Directory<\/strong><\/h2>\n\n\n\n<h3 class=\"wp-block-heading has-medium-font-size\"><strong>Group Policy e controllo centralizzato<\/strong><\/h3>\n\n\n\n<p>Una delle funzionalit\u00e0 pi\u00f9 potenti di AD in ottica sicurezza \u00e8 la <strong>Group Policy<\/strong>. I <strong>Criteri di Gruppo (GPO)<\/strong> permettono di applicare impostazioni di configurazione e di sicurezza in modo centralizzato a gruppi di computer o utenti all\u2019interno 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\u2019avvio o login. Questo consente un <strong>controllo uniforme<\/strong>: invece di configurare manualmente ogni host, gli amministratori definiscono il criterio una volta in AD e assicurano conformit\u00e0 su larga scala. Ad esempio, tramite GPO si pu\u00f2 imporre che <em>tutte<\/em> le macchine del dominio abbiano <strong>login screen banner<\/strong> di avviso, che gli utenti non possano installare software non autorizzato, o che vengano eseguite specifiche configurazioni di auditing (vedi dopo). Un\u2019altra area critica gestibile via GPO \u00e8 la <strong>politica password<\/strong>: a livello di dominio si definisce lunghezza minima, complessit\u00e0 e durata delle password utente, nonch\u00e9 soglie di blocco account per tentativi falliti (mitigando brute force)<a href=\"https:\/\/www.semperis.com\/it\/identity-security-glossary\/#:~:text=Politica%20di%20blocco%20dell%27account\">[12]<\/a>. In contesti avanzati, AD supporta anche <strong>fine-grained password policies<\/strong> (PSO) per eccezioni su gruppi specifici, ma la policy di dominio resta fondamentale. Il vantaggio per il SOC \u00e8 chiaro: uniformit\u00e0 delle configurazioni di sicurezza e riduzione degli errori manuali.<\/p>\n\n\n\n<h3 class=\"wp-block-heading has-medium-font-size\"><strong>Autenticazione e autorizzazione centralizzate<\/strong><\/h3>\n\n\n\n<p>Active Directory gestisce in modo integrato <strong>autenticazione<\/strong> (verifica dell\u2019identit\u00e0) e <strong>autorizzazione<\/strong> (controllo degli accessi) in rete<a href=\"https:\/\/www.fortinet.com\/resources\/cyberglossary\/active-directory#:~:text=For%20enterprise%20networks%2C%20Active%20Directory,access%20permissions%20across%20the%20network\">[13]<\/a>. 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\u2019identit\u00e0 utente e i suoi gruppi di appartenenza (SIDs), che saranno usati per autorizzare l\u2019accesso alle risorse. L\u2019autenticazione 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\u2019<strong>Single Sign-On (SSO)<\/strong> \u00e8 un beneficio: un utente, autenticandosi al dominio una volta, riceve i ticket Kerberos per accedere a pi\u00f9 servizi senza dover reinserire credenziali per ognuno<a href=\"https:\/\/www.fortinet.com\/resources\/cyberglossary\/active-directory#:~:text=Consider%20an%20enterprise%20with%20hundreds,propagate%20automatically%20throughout%20the%20network\">[14]<\/a>.<\/p>\n\n\n\n<p>L\u2019<strong>autorizzazione<\/strong> 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 \u201cFinance\u201d gli d\u00e0 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 <strong>Delegation of Control<\/strong> (possibilit\u00e0 di delegare permessi amministrativi granulari su OU ad esempio a un IT locale, senza dare privilegi globali) e funzionalit\u00e0 di <strong>trust<\/strong> tra domini\/foreste per estendere l\u2019autenticazione federata (un utente di un dominio trusted pu\u00f2 essere autenticato nel dominio trusting).<\/p>\n\n\n\n<h3 class=\"wp-block-heading has-medium-font-size\"><strong>Auditing e monitoraggio<\/strong><\/h3>\n\n\n\n<p>Dal punto di vista di un SOC, <strong>monitorare Active Directory<\/strong> \u00e8 cruciale perch\u00e9 molte tracce di compromissione emergono negli eventi di sicurezza del dominio. Windows Server fornisce una serie di <strong>Security Auditing<\/strong> 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 <em>Default Domain Controllers Policy<\/em> per i DC) si possono attivare audit dettagliati: ad esempio <strong>Audit account logon events<\/strong>, <strong>Audit account management<\/strong> (creazione\/modifica utenti\/gruppi), <strong>Directory Service Access<\/strong> (accessi a oggetti AD), ecc. Una volta abilitati (spesso definendo sia <strong>Success<\/strong> che <strong>Failure<\/strong> per ottenere tracce di tentativi falliti) i Domain Controller iniziano a generare eventi nel registro di Sicurezza Windows.<\/p>\n\n\n\n<p>Per gestire l\u2019auditing AD: 1. Si attivano le categorie di audit via GPO (sotto Computer Configuration &gt; Windows Settings &gt; Security Settings &gt; Advanced Audit Policy Configuration<a href=\"https:\/\/www.lepide.com\/how-to\/enable-active-directory-security-auditing.html#:~:text=,Policy%20Configuration%20%E2%86%92%20Audit%20Policies\">[15]<\/a><a href=\"https:\/\/www.lepide.com\/how-to\/enable-active-directory-security-auditing.html#:~:text=,Check%20Both%20Success%20and%20Failure\">[16]<\/a>). 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 <strong>alert<\/strong> su eventi sensibili (es: molteplici lockout account possono indicare brute force; modifica di membership Domain Admins genera evento 4728 da attenzionare).<\/p>\n\n\n\n<p>L\u2019auditing nativo pu\u00f2 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, \u00e8 <strong>fondamentale<\/strong> che un CSIRT\/SOC <strong>abiliti e utilizzi l\u2019auditing AD<\/strong>: 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<a href=\"https:\/\/www.cyber.gc.ca\/en\/guidance\/practitioner-guidance-securing-microsoft-active-directory-services-your-organization-itsp60100#:~:text=,logged%2C%20monitored%20and%20audited\">[17]<\/a>. In sintesi, AD offre gli elementi per un controllo centralizzato, ma spetta all\u2019organizzazione implementare una robusta politica di <strong>logging, monitoring e auditing<\/strong> per trarne vantaggio.<\/p>\n\n\n\n<h2 class=\"wp-block-heading has-medium-font-size\"><strong>Kerberos: principio di funzionamento<\/strong><\/h2>\n\n\n\n<p><strong>Kerberos<\/strong> \u00e8 un protocollo di autenticazione di rete, progettato dal MIT, basato su un sistema di <strong>ticket<\/strong> 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 <strong>Key Distribution Center (KDC)<\/strong> centrale che funge da guardiano<a href=\"https:\/\/www.hackthebox.com\/blog\/what-is-kerberos-authentication#:~:text=The%20three%20heads%20of%20Kerberos,authentication%3A%20KDC%2C%20realms%2C%20%26%20tickets\">[18]<\/a><a href=\"https:\/\/www.hackthebox.com\/blog\/what-is-kerberos-authentication#:~:text=3,session%20keys%20in%20a%20realm\">[19]<\/a>. In ambiente Windows\/AD, il KDC \u00e8 implementato sui Domain Controller.<\/p>\n\n\n\n<p><em>Figura &#8211; Le \u201ctre teste\u201d di Kerberos: Principale (l\u2019entit\u00e0 che si autentica, ad es. un utente), Risorsa\/Servizio a cui vuole accedere, e KDC (Key Distribution Center) che media l\u2019autenticazione.<\/em><a href=\"https:\/\/www.hackthebox.com\/blog\/what-is-kerberos-authentication#:~:text=The%20three%20heads%20of%20Kerberos,authentication%3A%20KDC%2C%20realms%2C%20%26%20tickets\">[18]<\/a><\/p>\n\n\n\n<p>Kerberos opera secondo un meccanismo di fiducia centralizzata: il KDC possiede una chiave segreta condivisa con <strong>ogni utente<\/strong> (derivata dalla password) e con <strong>ogni servizio\/server<\/strong> (derivata dalla password dell\u2019account computer o account servizio registrato in AD). Il processo di autenticazione Kerberos (versione <strong>Kerberos V5<\/strong> usata in AD) avviene in pi\u00f9 fasi (detto <em>ticketing<\/em>):<\/p>\n\n\n\n<ol start=\"1\" class=\"wp-block-list\">\n<li><strong>Client richiede un Ticket-Granting Ticket (TGT)<\/strong> \u2013 Quando, ad esempio, un utente inserisce credenziali per accedere al dominio, il suo computer invia al KDC (servizio di <strong>Authentication Service<\/strong>, in esecuzione sul DC) un\u2019autenticazione iniziale <strong>AS-REQ<\/strong> con il proprio <strong>principal<\/strong> (es. nome utente). Il KDC verifica le credenziali (nel caso di AD, controlla l\u2019hash della password dell\u2019utente confrontandolo con quello memorizzato in AD) e, se corrette, genera un <strong>Ticket-Granting Ticket<\/strong>. Il <strong>TGT<\/strong> \u00e8 un ticket crittografato con la chiave segreta del KDC (nota solo al KDC stesso), contenente l\u2019identit\u00e0 dell\u2019utente, timestamp e una chiave di sessione. Il TGT viene restituito al client nell\u2019<strong>AS-REP<\/strong>, insieme a una copia della chiave di sessione cifrata con la chiave dell\u2019utente (cos\u00ec solo l\u2019utente \u2013 conoscendo la propria password \u2013 pu\u00f2 decifrarla). Da notare che a questo punto il KDC ha autenticato l\u2019utente, ma l\u2019utente non ha ancora accesso a nessun servizio di rete, solo al diritto di chiedere ticket ulteriori.<\/li>\n\n\n\n<li><strong>Client richiede un ticket di servizio (TGS)<\/strong> \u2013 Quando il client vuole accedere a una risorsa specifica (es. un file server o un\u2019applicazione web che supporta Kerberos), utilizza il TGT ottenuto per fare una richiesta <strong>TGS-REQ<\/strong> al <strong>Ticket-Granting Service<\/strong> (sempre sul KDC) per un ticket verso quel servizio. La richiesta include il TGT e indica il <strong>Service Principal Name (SPN)<\/strong> 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\u00f2 essere validato e considerato prova dell\u2019identit\u00e0 del client) e controlla nei propri database AD se l\u2019utente ha diritto di accedere al servizio richiesto. Se tutto ok, il KDC genera un <strong>Ticket di Servizio<\/strong> (detto anche <strong>service ticket<\/strong> o <strong>TGS<\/strong>), crittografato con la chiave segreta del servizio target (nota solo a quel server). Questo ticket contiene l\u2019identit\u00e0 del client, un nuovo session key client-server e le autorizzazioni (nel contesto AD, include il PAC \u2013 vedi dopo). Il KDC invia al client il ticket di servizio nell\u2019<strong>TGS-REP<\/strong>, insieme a una copia della session key client-server (cifrata con la chiave gi\u00e0 condivisa col client tramite il TGT). A questo punto il client ha un ticket valido per presentarsi al servizio.<\/li>\n\n\n\n<li><strong>Accesso al servizio (AP-REQ\/AP-REP)<\/strong> \u2013 Il client contatta il server target presentando il ticket di servizio (messaggio <strong>AP-REQ<\/strong>). Il server, che conosce la propria chiave segreta, decifra il ticket e ottiene cos\u00ec la session key e l\u2019identit\u00e0 del client. Pu\u00f2 opzionalmente inviare una risposta AP-REP per confermare al client la propria identit\u00e0 (mutua autenticazione). Da questo momento, client e server hanno stabilito una fiducia reciproca e possono comunicare in modo sicuro. Il client \u00e8 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\u2019utente nel PAC), pu\u00f2 effettuare il controllo di autorizzazione e concedere o negare l\u2019accesso alla risorsa richiesta.<\/li>\n<\/ol>\n\n\n\n<p>Questo sistema di ticket fa s\u00ec che le credenziali sensibili (password) non circolino mai sulla rete; inoltre i ticket hanno una <strong>durata limitata<\/strong> (tipicamente il TGT dura 8-10 ore, i ticket di servizio alcune ore) e includono timestamp per prevenire replay. Kerberos fornisce anche <strong>mutua autenticazione<\/strong> (il client si fida del server solo se quest\u2019ultimo dimostra di aver decifrato il ticket, quindi di essere legittimo). In Windows, Kerberos \u00e8 integrato: il processo avviene in gran parte in background quando un utente esegue il logon al dominio e quando accede a risorse domain-based.<\/p>\n\n\n\n<h3 class=\"wp-block-heading has-medium-font-size\"><strong>Crittografia e sicurezza in Kerberos<\/strong><\/h3>\n\n\n\n<p>Kerberos si basa su <strong>crittografia simmetrica forte<\/strong> per proteggere i ticket e le comunicazioni<a href=\"https:\/\/www.semperis.com\/it\/identity-security-glossary\/#:~:text=Il%20protocollo%20di%20sicurezza%20della,fa%2C%20il%20protocollo%20Kerberos%20ha\">[20]<\/a>. 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\u00f9 vecchie usavano DES o RC4-HMAC<a href=\"https:\/\/www.semperis.com\/it\/identity-security-glossary\/#:~:text=Kerberos%20%C3%A8%20il%20metodo%20di,il%20modo%20in%20cui%20i\">[21]<\/a>). Ogni principal (utente o servizio) ha in AD una <strong>chiave segreta<\/strong> derivata dalla password: per utenti \u00e8 l\u2019hash della password NT, per i computer\/servizi \u00e8 la password dell\u2019account macchina o service account. Il KDC conosce tutte queste chiavi, perci\u00f2 pu\u00f2 creare ticket cifrati destinati sia al client (cifrati con chiave dell\u2019utente) sia al servizio (cifrati con chiave del servizio).<\/p>\n\n\n\n<p>Alcuni dettagli di sicurezza: &#8211; <strong>Pre-autenticazione:<\/strong> Kerberos v5 in AD richiede che l\u2019utente provi di conoscere la propria chiave gi\u00e0 nella richiesta AS-REQ (inviando un timestamp cifrato con la propria chiave). Ci\u00f2 previene attacchi offline: senza pre-auth, un attacker potrebbe chiedere un TGT e riceverlo cifrato con la chiave dell\u2019utente, 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\u2019utente non dimostra prima la conoscenza della chiave. <strong>Nota:<\/strong> \u00e8 importante che tutti gli account AD mantengano abilitata la pre-auth (\u00e8 di default, ma pu\u00f2 essere disabilitata per compatibilit\u00e0): account senza pre-auth sono esposti ad attacchi di <strong>password guessing offline<\/strong><a href=\"https:\/\/www.semperis.com\/it\/identity-security-glossary\/#:~:text=Indovinare%20la%20password%20Kerberos%20%28AS,roasting\">[22]<\/a>. &#8211; <strong>Time synchronization:<\/strong> Kerberos dipende da orologi sincronizzati: i ticket hanno timestamp e scadenze. In AD \u00e8 tollerato tipicamente un <strong>skew di 5 minuti<\/strong>; se l\u2019orologio di un client differisce troppo, l\u2019autenticazione fallir\u00e0. Per questo, parte delle best practice \u00e8 assicurare NTP attivo su DC e client. &#8211; <strong>Session keys:<\/strong> 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\u00e0 e\/o confidenzialit\u00e0 dei dati scambiati dopo l\u2019autenticazione, se l\u2019applicazione lo supporta). Ci\u00f2 garantisce che anche se qualcuno intercettasse il ticket, non potrebbe usare la sessione senza la session key (che \u00e8 protetta). &#8211; <strong>PAC (Privilege Attribute Certificate):<\/strong> \u00e8 un campo aggiuntivo che Microsoft ha inserito nei ticket Kerberos in ambiente AD. Il PAC contiene gli identificatori di sicurezza e privilegi dell\u2019utente (SID utente, SID dei gruppi di appartenenza, attributi come il SIDHistory, ecc.). Quando un utente presenta un ticket a un server, quest\u2019ultimo pu\u00f2 (ed \u00e8 tenuto a) validare il PAC contattando un DC (procedura di PAC validation) per assicurarsi che non sia stato manomesso<a href=\"https:\/\/blog.netwrix.com\/2023\/01\/10\/what-is-the-kerberos-pac\/#:~:text=How%20Does%20the%20Kerberos%20PAC,AD%29%20domain\">[23]<\/a>. Il PAC consente al server di conoscere i gruppi e quindi applicare le ACL adeguate, ed \u00e8 firmato dal KDC per garantirne l\u2019integrit\u00e0. Attacchi sofisticati come Golden Ticket coinvolgono la falsificazione del PAC, come vedremo.<\/p>\n\n\n\n<h3 class=\"wp-block-heading has-medium-font-size\"><strong>Vulnerabilit\u00e0 note del protocollo Kerberos<\/strong><\/h3>\n\n\n\n<p>Nonostante Kerberos sia considerato un protocollo molto sicuro, esistono <strong>vulnerabilit\u00e0 e attacchi noti<\/strong> legati al suo utilizzo in Active Directory: &#8211; <strong>Kerberoasting:<\/strong> \u00e8 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\u2019account servizio. Un attacker che ha un accesso minimo al dominio (anche solo un account non privilegiato) pu\u00f2 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\u2019account servizio ha una password debole, l\u2019attaccante pu\u00f2 fare <strong>cracking offline<\/strong> del ticket per risalire alla password in chiaro del servizio<a href=\"https:\/\/www.semperis.com\/it\/identity-security-glossary\/#:~:text=match%20at%20L2575%20Kerberoasting%20%C3%A8,per%20ottenere%20la%20password%20dell%27account\">[24]<\/a><a href=\"https:\/\/www.semperis.com\/it\/identity-security-glossary\/#:~:text=Kerberos\">[25]<\/a>. Questo attacco prende di mira account di servizio privilegiati (es. con diritti amministrativi) con password non abbastanza robuste. &#8211; <strong>Golden Ticket:<\/strong> attacco devastante in cui un aggressore riesce a compromettere l\u2019account <strong>krbtgt<\/strong> (l\u2019account del servizio KDC in AD). Con la chiave di krbtgt, l\u2019attaccante pu\u00f2 generare arbitrariamente Ticket-Granting Ticket validi per qualsiasi identit\u00e0 nel dominio, essenzialmente <strong>impersonando chiunque<\/strong> (anche un Domain Admin) e ottenendo accesso illimitato<a href=\"https:\/\/www.semperis.com\/it\/identity-security-glossary\/#:~:text=Kerberos%20%C3%A8%20il%20metodo%20di,I%20sistemi%20operativi%20pi%C3%B9%20vecchi\">[26]<\/a><a href=\"https:\/\/www.semperis.com\/it\/identity-security-glossary\/#:~:text=Attacco%20al%20Golden%20Ticket\">[27]<\/a>. Il Golden Ticket consente accesso non autorizzato a <em>qualsiasi<\/em> sistema come utente privilegiato (Domain Admin) e pu\u00f2 restare valido per un lungo periodo senza essere rilevato se non si monitorano attentamente i ticket (l\u2019attaccante pu\u00f2 anche personalizzare durata e attributi del ticket). \u00c8 chiamato \u201cGolden\u201d perch\u00e9 garantisce controllo totale del \u201cregno\u201d AD. &#8211; <strong>Silver Ticket:<\/strong> simile al Golden, ma invece di compromettere krbtgt, l\u2019attaccante compromette la chiave di un singolo servizio (ad esempio rubando l\u2019hash di password di un account computer o account servizio). Con quella chiave pu\u00f2 falsificare ticket di servizio validi per quel particolare servizio solamente. Ad esempio, ottenendo la password di un server applicazioni, pu\u00f2 creare un ticket Kerberos per farsi passare per qualsiasi utente verso quel server. Non richiede contattare il KDC, quindi pu\u00f2 sfuggire pi\u00f9 facilmente al monitoraggio. \u00c8 limitato a uno specifico servizio, ma se quel servizio gira su un server membro, l\u2019attaccante pu\u00f2 usare il Silver Ticket per eseguire code injection e magari arrivare comunque a privilegi di sistema su quell\u2019host, poi muoversi lateralmente. &#8211; <strong>Pass-the-Ticket:<\/strong> attacco in cui un aggressore <strong>ruba un ticket Kerberos<\/strong> 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\u2019utente senza conoscere le credenziali<a href=\"https:\/\/www.semperis.com\/it\/identity-security-glossary\/#:~:text=Attacco%20%22pass\">[28]<\/a>. In pratica \u201cpassa\u201d il ticket rubato, potendo accedere a risorse di rete come se fosse l\u2019utente legittimo. Questo \u00e8 possibile se l\u2019attaccante ha compromesso una macchina e pu\u00f2 estrarre i ticket dalla sessione utente. &#8211; <strong>Overpass-the-Hash (Pass-the-Key):<\/strong> variante avanzata dove l\u2019attaccante usa l\u2019hash NTLM di un utente per ottenere un TGT Kerberos (convincendo il sistema a generare un ticket con quell\u2019hash). Combina tecniche di pass-the-hash con Kerberos, permettendo di trasformare un furto di hash in un ticket Kerberos valido<a href=\"https:\/\/www.semperis.com\/it\/identity-security-glossary\/#:~:text=match%20at%20L3994%20Attacco%20Overpass\">[29]<\/a>. &#8211; <strong>Delegation abuse:<\/strong> Kerberos supporta meccanismi di <strong>delegazione<\/strong> 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\u2019identit\u00e0 dell\u2019utente). Esistono la delega non vincolata, vincolata e vincolata alle risorse. Se mal configurate, un utente malintenzionato che compromette un servizio con delega pu\u00f2 ottenere ticket che gli consentono di impersonare utenti di alto livello verso altri servizi, realizzando escalation di privilegi<a href=\"https:\/\/www.semperis.com\/it\/identity-security-glossary\/#:~:text=La%20delega%20Kerberos%20%C3%A8%20una,muoversi%20lateralmente%20attraverso%20la%20rete\">[30]<\/a><a href=\"https:\/\/www.semperis.com\/it\/identity-security-glossary\/#:~:text=Abuso%20della%20delega%20Kerberos\">[31]<\/a>. In particolare, la <strong>unconstrained delegation<\/strong> \u00e8 pericolosa: qualsiasi account con delega non vincolata pu\u00f2 agire come qualsiasi utente che si autentichi su di esso, spesso includendo Domain Admin che accedono al servizio compromesso. &#8211; <strong>Vulnerabilit\u00e0 crittografiche:<\/strong> L\u2019uso di vecchi algoritmi (DES, RC4) \u00e8 oggi sconsigliato; Microsoft negli ultimi anni ha rilasciato patch per forzare l\u2019uso 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\u2019infrastruttura non \u00e8 aggiornata, un attacker potrebbe sfruttare debolezze note, come spoof del PAC signature (varie CVE 2021-2022) o attacchi brute force agevolati da DES abilitato.<\/p>\n\n\n\n<p>In generale, Kerberos in AD <strong>resta robusto<\/strong>, ma la <strong>sua sicurezza dipende dalla protezione delle chiavi segrete<\/strong> (password degli account, in primis quella di krbtgt e dei service account) e dalla corretta configurazione. Molti attacchi puntano a <strong>estrarre o riutilizzare ticket<\/strong> (pass-the-ticket) o <strong>falsificarli<\/strong> conoscendo le chiavi (Golden\/Silver). L\u2019evoluzione delle minacce e l\u2019uso scorretto di Kerberos in ambienti complessi ha portato ad una maggiore esposizione nel tempo<a href=\"https:\/\/www.semperis.com\/it\/identity-security-glossary\/#:~:text=client%20e%20il%20server%20possono,pi%C3%B9%20vulnerabile%20alle%20minacce%20informatiche\">[32]<\/a>, rendendo fondamentale l\u2019adozione di contromisure adeguate.<\/p>\n\n\n\n<h2 class=\"wp-block-heading has-medium-font-size\"><strong>Integrazione di Kerberos in Active Directory<\/strong><\/h2>\n\n\n\n<p>In un dominio Active Directory, Kerberos \u00e8 <strong>strettamente integrato<\/strong> e rappresenta la spina dorsale dell\u2019autenticazione. Ogni Domain Controller AD funge da <strong>KDC<\/strong> per il suo dominio: in particolare, sul DC girano i servizi <strong>Kerberos Authentication Service<\/strong> e <strong>Ticket-Granting Service<\/strong>. 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.<\/p>\n\n\n\n<p>L\u2019integrazione comporta alcuni aspetti tecnici importanti: &#8211; <strong>Account krbtgt:<\/strong> in ogni dominio AD esiste un account utente speciale chiamato krbtgt. Esso non ha login interattivo ma possiede la <strong>chiave segreta del KDC<\/strong>. Questa chiave (derivata dalla password random generata all\u2019installazione del dominio) \u00e8 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\u2019account krbtgt \u00e8 fondamentale: come detto, se un attaccante ne ottiene l\u2019hash, pu\u00f2 firmare Golden Ticket validi ovunque nel dominio. &#8211; <strong>Service Principal Name (SPN):<\/strong> 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\u00e0 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\u2019SPN (in questo caso l\u2019account computer DB01 se SQL gira sotto Local System, oppure un account utente dedicato se SQL ha un service account) e user\u00e0 la chiave di quell\u2019account per cifrare il ticket di servizio. La gestione corretta degli SPN \u00e8 essenziale per Kerberos: SPN duplicati o errati causano errori di autenticazione. Inoltre gli SPN sono sfruttati nell\u2019attacco Kerberoasting, come visto, per individuare account servizio. &#8211; <strong>PAC e autorizzazioni:<\/strong> Quando un DC AD emette un ticket Kerberos (TGT o service), vi include il <strong>Privilege Attribute Certificate<\/strong> con i SID dei gruppi e altri dettagli di privilegio dell\u2019utente. Ci\u00f2 significa che l\u2019autorizzazione alle risorse pu\u00f2 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\u2019utente e pu\u00f2 determinare se l\u2019ACL sulla cartella consente accesso. Questa integrazione rende Kerberos in AD pi\u00f9 di un semplice autenticatore: trasporta anche informazioni di autorizzazione. Il rovescio della medaglia \u00e8 che un PAC falsificato (come in Golden Ticket) pu\u00f2 ingannare i server facendogli credere che l\u2019utente abbia privilegi che non ha. Per mitigare, i server Windows possono convalidare i PAC chiedendo conferma a un DC (PAC validation). &#8211; <strong>Trust tra domini:<\/strong> In AD, se un dominio A ha un trust (bidirezionale, transitivo tipicamente) verso dominio B, Kerberos supporta l\u2019<strong>autenticazione inter-dominio<\/strong>. Un KDC del dominio A pu\u00f2 emettere un <strong>Referral Ticket<\/strong> che il client user\u00e0 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\u2019\u00e8 trust) consente SSO tra domini diversi. Dal punto di vista di un SOC, la fiducia tra domini estende la superficie d\u2019attacco (un attaccante in un dominio potrebbe muoversi su un dominio trusted se riesce a ottenere credenziali valide). \u00c8 importante quindi gestire con attenzione i trust (limitare quelli esterni non necessari, o usare trust con autenticazione selettiva). &#8211; <strong>Fallback NTLM:<\/strong> 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\u2019<strong>NTLM Authentication Service<\/strong> (tramite il servizio NETLOGON). In un\u2019ottica di sicurezza, <strong>ridurre l\u2019uso di NTLM<\/strong> \u00e8 consigliato perch\u00e9 \u00e8 meno sicuro; AD offre policy (per esempio via GPO) per rifiutare NTLM in vari scope, preferendo Kerberos.<\/p>\n\n\n\n<p>In sintesi, Active Directory <strong>\u00e8 costruito intorno a Kerberos<\/strong>: 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 \u2013 Event ID 4768, 4769, 4771 che indicano emissione di TGT, TGS o fallimenti). L\u2019integrazione consente anche funzionalit\u00e0 avanzate come <strong>Smartcard logon<\/strong> (Kerberos supporta autenticazione tramite certificati mappati a un utente AD) e protocollo <strong>Kerberos Armoring<\/strong> (Flexible Authentication Secure Tunneling \u2013 FAST \u2013 che mitiga alcuni attacchi come brute force su PA). Queste caratteristiche possono essere implementate per incrementare la sicurezza dell\u2019ambiente.<\/p>\n\n\n\n<h2 class=\"wp-block-heading has-dark-gray-color has-very-light-gray-to-cyan-bluish-gray-gradient-background has-text-color has-background has-link-color has-medium-font-size wp-elements-440b4d73d789c5dcf89c889cc892f628\"><strong>Esempio pratico: Implementazione di un dominio Active Directory con autenticazione Kerberos<\/strong><\/h2>\n\n\n\n<p>Di seguito descriviamo un esempio pratico di installazione e configurazione di un dominio Active Directory (su Windows Server) e come ci\u00f2 fornisce autenticazione Kerberos centralizzata:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>Installazione di Active Directory Domain Services:<\/strong> Si parte da un server Windows (es. Windows Server 2022). Tramite Server Manager, si aggiunge il ruolo <strong>Active Directory Domain Services (AD DS)<\/strong>. Completata l\u2019installazione, si esegue il <strong>promuovi a controller di dominio<\/strong> per creare una nuova foresta. Durante questa procedura si sceglie il nome del dominio (ad es. laboratorio.local), si imposta la modalit\u00e0 di funzionamento (livello funzionale), si definisce una password DSRM (per il ripristino di Directory Service). Dopo il riavvio, il server diventa il <strong>Domain Controller<\/strong> del dominio laboratorio.local. Automaticamente vengono configurati i servizi Kerberos KDC e DNS integrato.<\/li>\n\n\n\n<li><strong>Aggiunta di client e membri al dominio:<\/strong> Su una macchina client (Windows 10\/11) si esegue <strong>join al dominio<\/strong> (impostando nei dettagli di sistema il dominio laboratorio.local e fornendo credenziali di un amministratore del dominio). Una volta unito, all\u2019avvio l\u2019utente potr\u00e0 effettuare il logon scegliendo account di dominio. Questo processo implica che il client contatta il DC e utilizza Kerberos per autenticare l\u2019utente: se inseriamo le credenziali di un utente di dominio valido, il DC rilascer\u00e0 al client un TGT Kerberos e consentir\u00e0 l\u2019accesso. Da notare che se il DC non fosse raggiungibile, l\u2019utente potrebbe ancora loggarsi con cache delle credenziali (Cached Logon), ma non otterrebbe ticket aggiornati per risorse di rete.<\/li>\n\n\n\n<li><strong>Creazione di utenti, gruppi e unit\u00e0 organizzative:<\/strong> Tramite la console <strong>Active Directory Users and Computers<\/strong> (ADUC) si possono creare nuove OU (ad esempio \u201cUffici\u201d con sottocartelle \u201cVendite\u201d, \u201cIT\u201d), 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\u2019utente alice al gruppo VenditeTeam. Queste operazioni di fatto <strong>centralizzano la gestione<\/strong>: invece di creare account su ogni singolo server, abbiamo un unico account dominio per Alice che vale su tutte le macchine del dominio.<\/li>\n\n\n\n<li><strong>Configurazione dei permessi di accesso alle risorse:<\/strong> Supponiamo che su un file server membro del dominio vi sia una cartella riservata al team Vendite. Tramite le <strong>ACL NTFS<\/strong> di Windows, si pu\u00f2 assegnare i diritti di Lettura\/Scrittura al gruppo di dominio VenditeTeam su quella cartella. Cos\u00ec, quando Alice (membro del gruppo) accede al file server, il suo token (derivato dal ticket Kerberos con PAC) indicher\u00e0 l\u2019appartenenza a <em>VenditeTeam<\/em> e il server le conceder\u00e0 l\u2019accesso. Se invece Bob, che non \u00e8 nel gruppo, provasse, verrebbe negato. Questo mostra la comodit\u00e0: basta gestire i membri del gruppo in AD per controllare l\u2019accesso, senza dover definire utenti locali su ogni server o permessi individuali.<\/li>\n\n\n\n<li><strong>Implementazione di criteri di sicurezza via Group Policy:<\/strong> Tramite la console <strong>Group Policy Management<\/strong>, creiamo o modifichiamo per esempio la <strong>Default Domain Policy<\/strong> per applicare regole di sicurezza a tutti gli utenti del dominio. Si pu\u00f2 abilitare la complessit\u00e0 delle password, impostare il blocco dell\u2019account dopo 5 tentativi falliti, definire che i membri del gruppo \u201cDomain Admins\u201d 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\u2019OU \u201cIT\u201d che disabilita l\u2019uso di dispositivi USB per i computer IT e impone l\u2019MFA per gli account amministrativi (se infrastruttura ADFS\/Azure AD disponibile). Nell\u2019ambito Kerberos, attraverso i <strong>Kerberos Policy Settings<\/strong> (in Default Domain Policy > Account Policies > Kerberos Policy) possiamo regolare parametri come la <strong>durata massima dei ticket<\/strong> (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 \u00e8 importante sapere che esistono \u2013 ad esempio in ambienti ad alta sicurezza si potrebbe ridurre la durata dei ticket per mitigare il rischio di reuse.<\/li>\n\n\n\n<li><strong>Abilitazione dell\u2019auditing di sicurezza:<\/strong> Per assicurare la tracciabilit\u00e0, tramite GPO <strong>Default Domain Controllers Policy<\/strong> (che si applica ai DC), abilitiamo le audit policy: ad esempio in <em>Computer Configuration > Windows Settings > Security Settings > Advanced Audit Policy Configuration<\/em> abilitiamo <em>Account Logon<\/em>, <em>Account Management<\/em>, <em>Directory Service Access<\/em>, <em>Logon\/Logoff<\/em> sia Success che Failure<a href=\"https:\/\/www.lepide.com\/how-to\/enable-active-directory-security-auditing.html#:~:text=,Policy%20Configuration%20%E2%86%92%20Audit%20Policies\">[15]<\/a><a href=\"https:\/\/www.lepide.com\/how-to\/enable-active-directory-security-auditing.html#:~:text=,Check%20Both%20Success%20and%20Failure\">[16]<\/a>. 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\u2019utente admin-it aggiunge Alice al gruppo Domain Admins, sul DC verr\u00e0 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.<\/li>\n\n\n\n<li><strong>Test e verifica:<\/strong> Ora Alice pu\u00f2 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\u2019accesso Bob (non nel gruppo), Windows loggerebbe un evento di accesso negato.<\/li>\n\n\n\n<li><strong>Strumenti amministrativi aggiuntivi:<\/strong> L\u2019esempio pu\u00f2 includere l\u2019uso di <strong>Active Directory Administrative Center (ADAC)<\/strong> per gestione avanzata (con interfaccia pi\u00f9 moderna e PowerShell integrato), oppure l\u2019uso di <strong>PowerShell<\/strong> (modulo ActiveDirectory) per automatizzare operazioni (es: creare pi\u00f9 utenti da CSV). Inoltre, implementare <strong>LAPS (Local Administrator Password Solution)<\/strong> 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 <strong>account amministrativi separati<\/strong> per l\u2019amministrazione (es. admin-it) diversi dagli account personali (Alice), di posizionare gli amministratori in OU con policy pi\u00f9 restrittive (es. blocco login interattivo su workstation non amministrative, enforcement di MFA), ecc., tutte cose configurabili via AD.<\/li>\n<\/ol>\n\n\n\n<p>Questo scenario illustra come Active Directory centralizzi la gestione: un amministratore controlla da un unico punto utenti, gruppi, policy, e Kerberos fa s\u00ec che le autenticazioni e le autorizzazioni funzionino automaticamente su tutti i servizi membri del dominio. Per un SOC ci\u00f2 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 <strong>monitorare e proteggere AD<\/strong>.<\/p>\n\n\n\n<h2 class=\"wp-block-heading has-dark-gray-color has-very-light-gray-to-cyan-bluish-gray-gradient-background has-text-color has-background has-link-color has-medium-font-size wp-elements-9d15eed2d7998fc204e1498ae6c4ca9b\"><strong>Vulnerabilit\u00e0 e rischi in ambienti AD\/Kerberos (CSIRT\/SOC)<\/strong><\/h2>\n\n\n\n<p>Active Directory e Kerberos essendo componenti critici e diffusissimi, presentano un\u2019ampia <strong>superficie d\u2019attacco<\/strong>. Come notato, AD <strong>\u00e8 spesso un obiettivo<\/strong> primario dei cyber attacchi per via del suo ruolo centrale<a href=\"https:\/\/www.semperis.com\/it\/identity-security-glossary\/#:~:text=queste%20risorse%2C%20comprese%20le%20loro,suo%20ruolo%20centrale%20nella%20gestione\">[2]<\/a>. In un contesto CSIRT\/SOC, \u00e8 essenziale conoscere le principali tecniche di attacco che i malintenzionati utilizzano contro AD\/Kerberos e predisporre contromisure. Di seguito esaminiamo <strong>alcune delle tecniche di attacco comuni<\/strong> e i rischi associati, con relative <strong>contromisure<\/strong>:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Pass-the-Ticket:<\/strong> 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\u2019attaccante estrae il TGT dell\u2019utente corrente (in formato Kerberos Cache). Con quel <strong>TGT valido<\/strong> pu\u00f2 impersonare l\u2019utente su altri sistemi del dominio, ottenendo accesso non autorizzato senza conoscere la password<a href=\"https:\/\/www.semperis.com\/it\/identity-security-glossary\/#:~:text=Attacco%20%22pass\">[28]<\/a>. <em>Contromisure:<\/em> rendere difficile l\u2019estrazione di credenziali dalla memoria \u2013 abilitare <strong>LSA Protection<\/strong> 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\u2019adesione 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.<\/li>\n\n\n\n<li><strong>Golden Ticket:<\/strong> Come descritto, \u00e8 la capacit\u00e0 di generare TGT arbitrari dopo aver compromesso krbtgt. Il rischio qui \u00e8 <strong>massimo<\/strong>: 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\u00e0 di rinnovo infinito. Un attaccante con Golden Ticket pu\u00f2 continuare ad avere accesso anche se la violazione iniziale (es. un malware su un server) viene rimossa, perch\u00e9 pu\u00f2 crearsi nuovi TGT a piacimento. <em>Contromisure:<\/em> l\u2019unica difesa efficace \u00e8 prevenire la compromissione iniziale \u2013 quindi proteggere gli account con privilegi che potrebbero portare a Domain Admin e quindi a krbtgt. Ma se si sospetta un Golden Ticket, l\u2019azione da fare \u00e8 <strong>reimpostare due volte la password dell\u2019account krbtgt<\/strong> (due volte perch\u00e9 AD mantiene due chiavi attive per tollerare un cambio, la seconda rotazione invalida sicuramente tutti i ticket generati con la chiave vecchia). Questo \u00e8 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<a href=\"https:\/\/www.semperis.com\/it\/identity-security-glossary\/#:~:text=AD%20%C3%A8%20la%20ricerca%20di,gli%20aggressori%20falsificano%20un%20TGT\">[33]<\/a>. <strong>Best practice<\/strong>: cambiare l\u2019account krbtgt periodicamente (es. ogni 6-12 mesi) per limitare la finestra di abuso, e <em>soprattutto<\/em> evitare che un attacker ottenga Domain Admin in primo luogo.<\/li>\n\n\n\n<li><strong>Silver Ticket:<\/strong> Permette attacchi mirati a singoli servizi. Un aggressore con hash di un account computer pu\u00f2 autenticarsi presso quel servizio quanto vuole. <em>Contromisure:<\/em> proteggere gli hash degli account macchina e servizio. Questo significa principalmente <strong>mantenere i server al sicuro<\/strong> (se un attacker ottiene System su un server, ne estrae l\u2019hash e pu\u00f2 creare Silver Ticket per servizi offerti da quel server). L\u2019uso di <strong>Managed Service Accounts (MSA\/gMSA)<\/strong> 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\u00f2 abilitare l\u2019<strong>AES-only<\/strong> per Kerberos (evitando RC4 che \u00e8 pi\u00f9 facile da usare negli attacchi Silver Ticket in combinazione con pass-the-hash).<\/li>\n\n\n\n<li><strong>Kerberoasting:<\/strong> Punta alle password dei service account. <em>Contromisure:<\/em> adottare password <strong>molto robuste<\/strong> per tutti gli account con SPN (ideale >25 caratteri casuali) in modo che il <strong>cracking offline<\/strong> sia impraticabile in tempi ragionevoli. Meglio ancora, utilizzare <strong>gMSA<\/strong> 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 \u201cdeboli\u201d (es. con password semplici o mai cambiate) da mettere in sicurezza. <strong>Disabilitare la pre-auth<\/strong> \u00e8 sconsigliato, come gi\u00e0 detto, quindi verificare che <em>tutti<\/em> gli account utente abbiano \u201cDo not require Kerberos preauthentication\u201d <em>non<\/em> selezionato (solo rarissimi servizi legacy richiedono di toglierla). Un altro controllo: mettere account sensibili nel gruppo \u201c<strong>Protected Users<\/strong>\u201d di AD \u2013 i membri di questo gruppo non possono usare cifrature deboli n\u00e9 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.<\/li>\n\n\n\n<li><strong>Pass-the-Hash \/ Overpass-the-Hash:<\/strong> Queste tecniche spesso precedono o seguono quelle Kerberos. Un attaccante che ha l\u2019hash NTLM di un admin pu\u00f2 usarlo per autenticarsi (NTLM) o per generare ticket Kerberos (overpass). <em>Contromisure:<\/em> adottare misure di protezione credenziali sulle macchine (LsaProtect, CredentialGuard come gi\u00e0 detto) e <strong>minimizzare la presenza di hash di admin su sistemi meno sicuri<\/strong>. Microsoft consiglia il modello <strong>Tiered Administration<\/strong>: account amministratore del dominio usati <em>solo<\/em> sui DC o sistemi Tier-0; account admin di server solo su server, ecc. Cos\u00ec, anche se viene compromesso un PC di un utente, non dovrebbe trovarsi in RAM l\u2019hash di un Domain Admin (che non vi ha mai fatto login). Utilizzare soluzioni come <strong>Privileged Access Workstations<\/strong> dedicate agli amministratori per evitare di esporre credenziali alte su macchine esposte a internet o userland.<\/li>\n\n\n\n<li><strong>Attacchi alla delega Kerberos:<\/strong> Un attacker che compromette un servizio con delega non vincolata potrebbe impersonare utenti. <em>Contromisure:<\/em> evitare per quanto possibile la delega non vincolata; preferire la <strong>constrained delegation<\/strong> con protocol transition <em>solo<\/em> dove necessario e aggiungendo l\u2019opzione <strong>\u201cProtocolcTransition e Constrained only to specific services (Resource-based constrained delegation)\u201d<\/strong> 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.<\/li>\n\n\n\n<li><strong>Attacchi ai DC (DCSync, DCShadow):<\/strong> Un attaccante con privilegi di Domain Admin pu\u00f2 utilizzare tool come mimikatz per simulare il comportamento di un DC e <strong>estrarre tutti gli hash delle password<\/strong> (DCSync) o <strong>iniettare oggetti malevoli<\/strong> nel directory (DCShadow). Questi sono attacchi post-exploit avanzati. <em>Contromisure:<\/em> impedire di arrivare a Domain Admin \u00e8 la chiave. Inoltre, monitorare chiamate replicate anomale: un server che non \u00e8 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\u2019Advanced Auditing per <em>Directory Service Replication<\/em> aiuta a catturare questi eventi.<\/li>\n<\/ul>\n\n\n\n<p><strong>Riassumendo i rischi:<\/strong> se AD viene compromesso in uno dei modi sopra, l\u2019intera rete \u00e8 a rischio \u2013 l\u2019attaccante pu\u00f2 leggere email, rubare dati, distribuire malware tramite GPO, o distruggere il dominio. \u00c8 compito del SOC rilevare segnali precoci: ad esempio, un account che passa improvvisamente a membro di Domain Admin, o l\u2019utilizzo di un account <em>krbtgt<\/em> (che non dovrebbe mai eseguire logon), o ancora volumi anomali di ticket TGS richiesti (indicatore di Kerberoasting). La difesa \u00e8 in <strong>profondit\u00e0<\/strong>: prevenzione, durevoli misure di protezione e robusto monitoring.<\/p>\n\n\n\n<h3 class=\"wp-block-heading has-dark-gray-color has-very-light-gray-to-cyan-bluish-gray-gradient-background has-text-color has-background has-link-color has-medium-font-size wp-elements-097d8e08b6019f2728d0661c125a657b\"><strong>Contromisure e best practice di sicurezza<\/strong><\/h3>\n\n\n\n<p>La protezione di AD\/Kerberos richiede un insieme di <strong>best practice<\/strong> procedurali e tecniche. Elenchiamo le pi\u00f9 importanti che un team di sicurezza dovrebbe implementare:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Principio del minimo privilegio:<\/strong> 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\u00e0 specifiche (es. helpdesk pu\u00f2 reset password ma non aggiungere membri a Domain Admins). Questo limita l\u2019impatto di eventuali credenziali compromesse.<\/li>\n\n\n\n<li><strong>Account amministrativi protetti:<\/strong> Per gli amministratori di dominio, utilizzare account separati dall\u2019utenza 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\u2019uso per login interattivo su workstation utenti, forzare MFA, negare accesso da macchine non amministrative). Impiegare <strong>workstation sicure dedicate (PAW)<\/strong> per le operazioni amministrative, isolate da internet e da attivit\u00e0 a rischio.<\/li>\n\n\n\n<li><strong>Protezione delle credenziali e delle chiavi sensibili:<\/strong> Implementare strumenti come <strong>LAPS<\/strong> per gestire password locali univoche su ogni macchina (mitiga movimenti laterali via pass-the-hash). Abilitare <strong>Credential Guard<\/strong> sui sistemi client se possibile. Per gli account \u201ckrbtgt\u201d e quelli di <strong>servizio<\/strong> 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 <strong>pre-autenticazione Kerberos sia sempre abilitata<\/strong> per tutti gli account utente e servizio<a href=\"https:\/\/www.cyber.gc.ca\/en\/guidance\/practitioner-guidance-securing-microsoft-active-directory-services-your-organization-itsp60100#:~:text=interactively,Footnote%2021\">[34]<\/a>. Utilizzare <strong>Group Managed Service Accounts (gMSA)<\/strong> per i servizi: queste password lunghe e ruotate automaticamente riducono enormemente il rischio di Kerberoasting e la necessit\u00e0 di gestire manualmente credenziali di servizio<a href=\"https:\/\/www.cyber.gc.ca\/en\/guidance\/practitioner-guidance-securing-microsoft-active-directory-services-your-organization-itsp60100#:~:text=interactively,Footnote%2021\">[35]<\/a>.<\/li>\n\n\n\n<li><strong>Hardening dei Domain Controller:<\/strong> I DC dovrebbero essere trattati come <strong>sistemi altamente sensibili (Tier 0)<\/strong>. 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\u00e0). Mantenere i DC aggiornati con le <strong>patch di sicurezza<\/strong> di Windows senza eccezioni \u2013 molte patch critiche negli ultimi anni riguardavano Kerberos (es. vulnerabilit\u00e0 PAC, privilege escalation). Considerare di <strong>isolare la rete dei DC<\/strong> (segmentazione) cos\u00ec che solo gli host autorizzati possano comunicare con essi sulle porte LDAP\/Kerberos.<\/li>\n\n\n\n<li><strong>Adozione di misure avanzate Kerberos:<\/strong> Valutare l\u2019uso della funzionalit\u00e0 <strong>\u201cProtected Users\u201d<\/strong> in AD \u2013 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 <strong>policy di sicurezza Kerberos<\/strong>: ad esempio, abilitare \u201c<strong>Kerberos client supporta solo AES<\/strong>\u201d su client e server (impedisce fallback a RC4), e assicurarsi che \u201c<strong>PAC Signature Required<\/strong>\u201d sia attiva (ci sono stati aggiornamenti che ora lo rendono obbligatorio per evitare PAC spoofing).<\/li>\n\n\n\n<li><strong>Monitoraggio continuo e analisi dei log:<\/strong> 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 <em>Admins<\/em>, 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 <strong>monitoring continuo<\/strong> e proattivo \u00e8 essenziale per individuare tempestivamente attivit\u00e0 sospette<a href=\"https:\/\/www.varonis.com\/blog\/fsmo-roles#:~:text=It%E2%80%99s%20important%20to%20monitor%20AD,both%20insider%20and%20external%20threats\">[36]<\/a>. Microsoft offre strumenti come <strong>Defender for Identity<\/strong> (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\u00f2 essere fatto con il tuning dei log e script personalizzati.<\/li>\n\n\n\n<li><strong>Procedure di risposta e recovery pianificate:<\/strong> Un team CSIRT deve predisporre piani specifici per scenari di compromissione AD. Ad esempio, procedure per <strong>rotazione urgente di krbtgt<\/strong> (script predefiniti da eseguire su DC), per isolare un DC sospetto, per ripristinare AD da backup in caso di attacco distruttivo (ransomware su DC). <strong>Esercitazioni periodiche<\/strong> di recovery AD (incluse prove di <strong>Active Directory Forest Recovery<\/strong>) dovrebbero essere svolte, dato che AD \u00e8 critico (\u201cse AD non funziona, non funziona nulla\u201d<a href=\"https:\/\/www.semperis.com\/it\/identity-security-glossary\/#:~:text=Per%20il%2090,e%20dimostrare%20la%20resilienza%20informatica\">[37]<\/a>). Mantenere <strong>backup offline<\/strong> della foresta AD e testarne la validit\u00e0 regolarmente fa parte delle best practice.<\/li>\n\n\n\n<li><strong>Migliorare la postura di sicurezza continuamente:<\/strong> Effettuare regolarmente un <strong>AD Health Check<\/strong> e un <strong>security assessment<\/strong> dell\u2019AD<a href=\"https:\/\/www.semperis.com\/it\/identity-security-glossary\/#:~:text=Valutare%20regolarmente%20il%20rischio%20e,per%20migliorare%20la%20salute%20dell%27AD\">[38]<\/a>. Ci sono strumenti (es. <strong>PingCastle<\/strong>, <strong>Purple Knight<\/strong><a href=\"https:\/\/www.semperis.com\/it\/identity-security-glossary\/#:~:text=Valutare%20regolarmente%20il%20rischio%20e,per%20migliorare%20la%20salute%20dell%27AD\">[38]<\/a>) 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\u2019attacco. Documentare e aggiornare costantemente le policy di sicurezza AD, allineandosi alle linee guida Microsoft e CIS Benchmark<a href=\"https:\/\/www.cyber.gc.ca\/en\/guidance\/practitioner-guidance-securing-microsoft-active-directory-services-your-organization-itsp60100#:~:text=Microsoft%20has%20issued%20a%20set,3%20for%20more%20detailed%20information\">[39]<\/a><a href=\"https:\/\/www.cyber.gc.ca\/en\/guidance\/practitioner-guidance-securing-microsoft-active-directory-services-your-organization-itsp60100#:~:text=2,CIS\">[40]<\/a>.<\/li>\n\n\n\n<li><strong>User awareness e formazione amministratori:<\/strong> Non trascurare l\u2019aspetto 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 \u2013 tutto ci\u00f2 riduce le chance iniziali di compromissione che poi potrebbe propagarsi su AD. In caso di incidenti, un amministratore preparato sapr\u00e0 come controllare i DC, dove cercare gli indicatori (log di evento Kerberos, registro replicazione, etc.) e potr\u00e0 reagire tempestivamente.<\/li>\n<\/ul>\n\n\n\n<p>In conclusione, Active Directory con Kerberos offre una gestione centralizzata potentissima e conveniente, ma richiede <strong>disciplina di sicurezza elevata<\/strong>. Un proverbio in ambito AD dice: \u201cActive Directory detiene le chiavi del tuo regno, ma \u00e8 sicuro?\u201d<a href=\"https:\/\/www.hackthebox.com\/blog\/what-is-kerberos-authentication#:~:text=By%20now%2C%20we%20all%20know,kingdom%2C%20but%20is%20it%20secure%3F%E2%80%9D\">[41]<\/a>. Spetta all\u2019organizzazione implementare difese in profondit\u00e0: hardening, monitoring e readiness alla risposta. Con le giuste best practice, AD\/Kerberos pu\u00f2 rimanere un pilastro affidabile dell\u2019infrastruttura, offrendo i vantaggi del single sign-on e dell\u2019amministrazione centralizzata senza diventare il singolo punto di falla. Continuo scrutinio, patching e miglioramento dei controlli sono necessari poich\u00e9 anche le minacce evolvono e prendono di mira Kerberos ed AD in modi sempre nuovi. Con un\u2019adeguata messa in sicurezza, il team CSIRT\/SOC potr\u00e0 sfruttare al meglio le funzionalit\u00e0 di AD e Kerberos mantenendo l\u2019ambiente protetto e resiliente.<\/p>\n\n\n\n<p><\/p>\n","protected":false},"excerpt":{"rendered":"<p>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\u00e0, autenticazione e autorizzazione degli utenti su tutta l\u2019infrastruttura, semplificando l\u2019amministrazione e migliorando la consistenza delle policy di sicurezza. Ad esempio, Active Directory &hellip; <a href=\"https:\/\/www.fabriziogiancola.eu\/index.php\/2025\/08\/30\/sistemi-di-gestione-centralizzati-active-directory-e-kerberos-in-ambito-csirt-soc\/\" class=\"more-link\">Leggi tutto<span class=\"screen-reader-text\"> &#8220;Sistemi di gestione centralizzati: Active Directory e Kerberos in ambito CSIRT\/SOC&#8221;<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"iawp_total_views":10,"footnotes":""},"categories":[12,19],"tags":[43,59,60,61,63,42,62],"class_list":["post-2430","post","type-post","status-publish","format-standard","hentry","category-cyber-security","category-sistemi-operativi","tag-ad","tag-dc","tag-golden-ticket","tag-gpo","tag-kdc","tag-kerberos","tag-ntlm"],"_links":{"self":[{"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/posts\/2430","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/comments?post=2430"}],"version-history":[{"count":7,"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/posts\/2430\/revisions"}],"predecessor-version":[{"id":2437,"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/posts\/2430\/revisions\/2437"}],"wp:attachment":[{"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/media?parent=2430"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/categories?post=2430"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/tags?post=2430"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}