Rilevamento prevenzione kerberoasting: come individuare e proteggere gli account di servizio esposti al cracking offline

Rilevamento prevenzione kerberoasting parte da un fatto semplice: qualsiasi principal autenticato di Active Directory che possieda un TGT valido può richiedere ticket di servizio per SPN, e alcuni di questi ticket possono ancora essere sottoposti a cracking offline se l’account di servizio bersaglio è abbastanza debole. La parte difficile non è capire il nome dell’attacco. La parte difficile è dimostrare quali account legati a SPN restano davvero sfruttabili nel dominio, quale telemetria è realmente utile e quali azioni di remediation riducono il rischio in modo misurabile senza rompere la produzione.

Che cos’è il Kerberoasting?

Kerberoasting è l’abuso del meccanismo di emissione dei ticket di servizio Kerberos per ottenere materiale di ticket che può poi essere sottoposto a cracking offline contro il segreto di un account di servizio. MITRE classifica questo comportamento come T1558.003 Kerberoasting.

In Active Directory, Kerberos usa i Service Principal Name (SPN) per associare un’istanza di servizio all’account che esegue quel servizio. Microsoft documenta gli SPN come l’identificatore che Kerberos usa per individuare il principal target di un servizio. Quando un client richiede un ticket di servizio Kerberos per quello SPN, il ticket viene generato per l’account di servizio che lo possiede.

Questo non significa che ogni account con uno SPN abbia lo stesso livello di rischio. L’esposizione reale dipende da quattro fattori:

• se l’account dipende da una password gestita manualmente da un utente oppure da un’identità di servizio meglio gestita;
• se il segreto dell’account è vecchio, prevedibile o mai ruotato;
• quali tipi di cifratura Kerberos vengono effettivamente usati per emettere i ticket;
• quali accessi sblocca l’account se le sue credenziali vengono recuperate.

Per questo il Kerberoasting non è solo un problema Kerberos. È anche un problema di hygiene degli account di servizio, di policy crittografica e, spesso, di governance dei privilegi.

Perché il Kerberoasting conta ancora in Active Directory

Il Kerberoasting conta ancora perché molti domini trascinano una lunga coda di account di servizio legacy:

• account di servizio appoggiati a utenti creati anni fa;
• account con PasswordNeverExpires;
• account la cui password è stata impostata una volta e poi dimenticata;
• account che dipendono ancora da RC4 per ragioni di compatibilità;
• account che nel tempo hanno accumulato privilegi di admin locale, backup, SQL, orchestrazione o diritti delegati.

Questa combinazione è ciò che rende la tecnica praticabile. Il percorso della richiesta Kerberos è legittimo. Il cracking offline avviene fuori dal dominio. Il raggio d’impatto dipende da ciò che quell’account di servizio consente di fare dopo.

Questo spiega anche perché la sicurezza delle password in Active Directory e gli account obsoleti e sovraprivilegiati in AD sono così importanti qui. Un ticket di servizio non è il traguardo finale. Il traguardo è recuperare una credenziale che apra un percorso di privilegio più ampio.

Precondizioni per una reale esposizione al Kerberoasting

Una finding di Kerberoasting merita alta priorità quando la maggior parte dei punti seguenti è vera:

• l’account ha uno o più SPN registrati;
• l’account dipende da una password gestita manualmente invece che da un’identità di servizio gestita;
• la password è vecchia, ruotata raramente o esente da scadenza;
• RC4 è ancora in uso o ancora accettato dove dovrebbero già essere presenti tipi di cifratura più forti;
• l’account ha valore reale per movimento laterale o escalation di privilegio;
• l’ambiente non rivede regolarmente l’inventario SPN e l’ownership degli account di servizio.

La documentazione Microsoft su msDS-SupportedEncryptionTypes è direttamente rilevante qui. Il KDC usa questa informazione quando genera un ticket di servizio per l’account. L’attuale guidance Microsoft su Kerberos spiega anche che RC4 è insicuro, in fase di rimozione e da auditare e correggere dove siano disponibili tipi di cifratura più forti.

Questa è la differenza operativa tra un semplice elemento di inventario e una vera esposizione al Kerberoasting. Un account SPN a basso valore con un segreto lungo, casuale e ruotato di recente non è lo stesso problema di un account SQL appoggiato a un utente, ancora in RC4 e con ampi privilegi sui server.

Come funziona il Kerberoasting

Microsoft documenta gli SPN come il modo in cui Kerberos associa un’istanza di servizio all’account che si autentica per quel servizio. In pratica, questo significa che un principal di dominio con un TGT valido può richiedere un TGS per un account di servizio che possiede uno SPN.

MITRE descrive il Kerberoasting come l’ottenimento di un ticket TGS che può essere vulnerabile alla forza bruta. Il punto che interessa i difensori è che il cracking avviene offline. Una volta raccolto il materiale del ticket, l’attaccante non ha più bisogno di interagire continuamente con il dominio per testare ipotesi di password.

I punti difensivi chiave sono:

• il percorso della richiesta è traffico Kerberos legittimo;
• il ticket è legato al segreto dell’account di servizio, non a una sessione interattiva sull’host bersaglio;
• la sfruttabilità reale dipende dal tipo di cifratura e dalla robustezza della password;
• l’impatto dipende dai privilegi dell’account di servizio una volta recuperata la credenziale.

La domanda corretta quindi non è “il Kerberoasting può avvenire in questo dominio?”. La domanda corretta è: “quali account legati a SPN restano abbastanza crackabili da contare davvero, e cosa sbloccherebbero se venissero recuperati?”

Rilevamento prevenzione kerberoasting: che cosa devono davvero verificare i difensori

Il rilevamento del Kerberoasting deve essere costruito come correlazione, non come una teoria basata su un singolo evento.

Iniziare dall’Event ID 4769

Microsoft documenta 4769 come l’evento generato quando il KDC emette un ticket di servizio Kerberos. Viene registrato sui domain controller. Per analizzare il Kerberoasting, in genere è l’evento nativo più utile perché cattura direttamente il percorso della richiesta TGS.

Che cosa cercare:

• un burst di richieste TGS da parte dello stesso account o della stessa sorgente in un breve intervallo;
• richieste per molti SPN distinti che non corrispondono al comportamento normale del richiedente;
• TicketEncryptionType = 0x17 solo se RC4 non dovrebbe più essere necessario in quell’ambiente;
• richieste SPN provenienti da workstation o utenti che normalmente non interagiscono con quei servizi.

L’attuale guidance Microsoft sulla remediation di RC4 raccomanda esplicitamente di auditare l’uso di RC4 negli eventi 4768 e 4769, e spiega che RC4 è in fase di eliminazione. Questa telemetria è quindi utile, ma solo nel contesto. RC4 da solo non dimostra un Kerberoasting. In alcuni domini indica ancora un problema di compatibilità più che un’attività ostile.

Usare l’Event ID 4768 come contesto di correlazione

4768 documenta l’emissione del TGT, non la richiesta di ticket di servizio su cui si basa il Kerberoasting. Va quindi trattato come contesto di supporto, non come rilevatore principale.

Serve ad aiutare a rispondere a domande come:

• quale account ha ottenuto il TGT che ha preceduto un’attività TGS anomala?
• quali sistemi sorgente sono coinvolti?
• quando è disponibile lo schema evento arricchito, che cosa suggeriscono i campi relativi a chiavi supportate e fallback?

Questo contesto è utile quando si indaga un cluster anomalo di 4769. Non sostituisce 4769.

Mantenere un inventario continuo degli account legati a SPN

La qualità del rilevamento migliora molto se si mantiene un inventario continuo di:

• account con SPN;
• età delle password;
• PasswordNeverExpires;
• classificazione tra account utente classico e identità di servizio gestita;
• privilegi effettivi e portata dell’admin locale;
• postura crittografica quando è rilevante per l’ambiente.

Una semplice revisione difensiva dell’inventario può bastare a mettere in evidenza i candidati ad alto rischio prima ancora di dover investigare traffico sospetto.

Get-ADUser -LDAPFilter "(servicePrincipalName=*)" -Properties servicePrincipalName,pwdLastSet,PasswordNeverExpires,msDS-SupportedEncryptionTypes |
  Select-Object SamAccountName,ServicePrincipalName,PasswordNeverExpires,pwdLastSet,msDS-SupportedEncryptionTypes

L’obiettivo non è raccogliere tutti gli SPN e farsi prendere dal panico. L’obiettivo è identificare gli account che combinano esposizione SPN, scarsa hygiene del segreto e privilegi significativi.

Trattare il baselining come obbligatorio

Una postura seria di rilevamento del Kerberoasting richiede una baseline dei pattern normali di ticket di servizio. Questo significa sapere:

• quali host richiedono normalmente ticket per quali servizi;
• quali account di servizio vengono contattati in massa per comportamento applicativo legittimo;
• quali strumenti di amministrazione, scanning o gestione generano legittimamente traffico TGS esteso.

Senza questa baseline, “molti 4769” non è una strategia di rilevamento. È solo un punto di partenza.

Prevenzione e hardening

La prevenzione del Kerberoasting consiste soprattutto nel rendere gli account di servizio legati a SPN cattivi obiettivi per il cracking e cattivi obiettivi per l’escalation di privilegio.

1. Ridurre gli account di servizio appoggiati a utenti quando possibile

Microsoft documenta i group Managed Service Accounts (gMSA) come account di dominio gestiti che forniscono gestione automatica delle password e gestione semplificata degli SPN, anche su più server.

Questo non rende una gMSA magicamente fuori da Kerberos. La rende però una scelta difensiva molto migliore rispetto a un account utente gestito manualmente la cui password non cambia da anni.

Dove la piattaforma lo consente, migrare i servizi idonei dai classici account di servizio appoggiati a utenti verso gMSA è uno dei controlli preventivi più utili che si possano applicare.

2. Ruotare le password degli account di servizio legacy

La guidance Microsoft su RC4 osserva che account più vecchi potrebbero non avere chiavi AES se la password non è mai stata reimpostata dopo l’introduzione del supporto moderno a Kerberos. Questo conta perché un reset password non cambia solo il segreto: può anche aggiornare il materiale di chiave utilizzabile dall’account.

Per gli account di servizio legacy che non possono ancora migrare verso gMSA:

• ruotare la password;
• renderla lunga e casuale;
• verificare poi che il servizio continui a funzionare correttamente;
• documentare l’ownership in modo che l’account non torni a essere debito tecnico condiviso.

3. Ridurre RC4 con cautela, non alla cieca

Microsoft documenta ora esplicitamente RC4 come insicuro, in fase di eliminazione e qualcosa da auditare tramite telemetria Kerberos. Microsoft documenta anche modi concreti per limitare o disabilitare RC4, incluse le policy sui tipi di cifratura Kerberos consentiti.

La conclusione corretta non è “disabilitare RC4 ovunque subito”. La conclusione corretta è:

• identificare dove RC4 è ancora usato;
• capire se la dipendenza è reale o solo configurazione legacy non mantenuta;
• portare account e host idonei verso impostazioni compatibili con AES;
• monitorare eventuali errori di autenticazione durante il rollout.

La stessa documentazione Microsoft avverte che disabilitare RC4 può rompere dipendenze legacy se non vengono validate prima. Questo caveat deve essere parte di ogni piano serio di hardening contro il Kerberoasting.

4. Rivedere i privilegi dietro l’account di servizio

La prevenzione resta incompleta se si migliora solo la password e si ignorano i privilegi.

Verificare se l’account di servizio dispone di:

• admin locale su molti server;
• diritti delegati in AD;
• privilegi di backup, orchestrazione o deployment;
• accesso di alto valore a database o file;
• percorsi impliciti verso gruppi AD nidificati o deriva degli accessi privilegiati in Active Directory.

Un account di servizio hardenizzato ma sovraprivilegiato continua a trasformare il recupero di un segreto in un incidente grave.

5. Ripulire gli SPN che non rappresentano più servizi reali

Microsoft documenta setspn come lo strumento per leggere, aggiungere, rimuovere e interrogare gli SPN. Questo è importante operativamente perché SPN obsoleti o duplicati non sono solo un problema di hygiene. Confondono l’ownership e allargano inutilmente la superficie di revisione.

Se uno SPN non rappresenta più un servizio reale, rimuoverlo. Se un’applicazione non ha più bisogno di un’identità appoggiata a un utente, ritirare l’account invece di trascinarlo all’infinito.

Validazione dopo la remediation

Una remediation del Kerberoasting non è completa perché una password è stata ruotata una volta o perché un tipo di ticket è stato cambiato in laboratorio. La validazione deve dimostrare che l’esposizione in produzione si è davvero spostata.

Mantenere almeno un pacchetto minimo di evidenze come questo:

Le domande di validazione devono essere concrete:

• quali account SPN critici dipendono ancora da password gestite manualmente?
• quali mostrano ancora password troppo vecchie o eccezioni alla scadenza?
• quali servizi richiedono ancora RC4 e chi ha approvato questa dipendenza?
• quali account consentirebbero ancora movimento laterale significativo se recuperati?
• la baseline 4769 del dominio è migliorata in modo materiale dopo il lavoro di remediation?

Questa è la differenza tra “abbiamo cambiato alcune password di account di servizio” e “abbiamo ridotto in modo misurabile il rischio Kerberoasting”.

Come EtcSec misura il rischio di Kerberoasting

EtcSec deve descrivere le condizioni che rendono praticabile il Kerberoasting, non fingere di dimostrare un attacco in corso a partire da un singolo evento.

La finding centrale è KERBEROASTING_RISK, utile quando un account ha uno SPN e continua a presentare uno o più tratti che rendono il cracking offline materialmente più realistico.

Finding di contesto che aumentano la priorità includono:

• PASSWORD_NEVER_EXPIRES
• PASSWORD_POLICY_WEAK
• KERBEROS_RC4_FALLBACK

Usati insieme, questi check aiutano a strutturare una revisione ripetibile di:

• quali account di servizio sono esposti;
• quali restano abbastanza deboli da contare davvero;
• quali si trovano su percorsi di privilegio significativi;
• quali necessitano ancora di evidenze di remediation dopo i cambiamenti.

Controlli correlati

Il Kerberoasting va rivisto insieme a controlli identitari adiacenti che spesso amplificano lo stesso percorso di compromissione:

• AS-REP Roasting, perché entrambe le tecniche trasformano materiale Kerberos in rischio di cracking offline;
• Sicurezza delle password in Active Directory, perché qualità e rotazione delle password determinano la sfruttabilità;
• Account obsoleti e sovraprivilegiati in AD, perché gli account dimenticati spesso possiedono gli SPN più pericolosi;
• Attacchi di delega Kerberos, perché le identità di servizio spesso si sovrappongono all’esposizione della delega;
• Auditare la sicurezza di Active Directory, perché il Kerberoasting è solo un punto di un workflow AD più ampio, orientato alle evidenze;
• Monitoraggio sicurezza AD, perché 4769 diventa utile solo quando raccolta eventi e baselining sono già in funzione.

Riferimenti primari

• MITRE ATT&CK T1558.003: Kerberoasting
• 4769(S, F): A Kerberos service ticket was requested
• 4768(S, F): A Kerberos authentication ticket (TGT) was requested
• Detect and remediate RC4 usage in Kerberos
• Kerberos authentication overview in Windows Server
• Group Managed Service Accounts overview
• Service principal names
• Setspn
• ms-DS-Supported-Encryption-Types attribute
• Audit Directory Service Access