Estrazione delle password degli account di servizio con Kerberoasting

Nel nostro articolo su LDAP reconnaissance post, abbiamo esplorato come un attaccante possa eseguire attività di ricognizione per scoprire account di servizio da prendere di mira in un dominio Active Directory (AD). Ora esaminiamo un metodo che un attaccante può utilizzare per compromettere quegli account e sfruttarne i privilegi: il Kerberoasting. Questa tecnica è particolarmente preoccupante perché non richiede privilegi di amministratore nel dominio, è molto facile da eseguire ed è praticamente indetectable.

Kerberoasting: Panoramica

Kerberoasting è un attacco che abusa di una funzionalità del protocollo Kerberos per raccogliere gli hash delle password degli account utente di Active Directory: qualsiasi utente di dominio autenticato può richiedere biglietti di servizio per un account specificando il suo Service Principal Name (SPN), e il servizio di emissione dei biglietti (TGS) sul controller di dominio restituirà un biglietto che è criptato utilizzando l'hash NTLM della password dell'account.

Pertanto, una volta che un avversario ha scoperto gli SPN degli account di servizio utilizzando una tattica come il reconnaissance LDAP, possono raccogliere i ticket per tutti quegli account. Portando offline tali dati, possono eseguire un attacco brute force per decifrare la password in chiaro di ogni account di servizio - senza alcun rischio di rilevamento o blocco dell'account.

Ci vogliono solo pochi minuti perché un attaccante possa accedere a un dominio, raccogliere ticket e iniziare il processo di cracking. Da lì, è solo una questione di attesa fino a quando non avranno compromesso uno o più account di servizio, che possono utilizzare per rubare o criptare dati sensibili o causare altri danni.

Gli avversari si concentrano sugli account di servizio per diversi motivi. Primo, questi account spesso dispongono di privilegi molto più estesi rispetto ad altri account utente di AD, quindi comprometterli concede all'attaccante un accesso maggiore. Inoltre, le password degli account di servizio cambiano raramente, quindi è probabile che l'avversario mantenga l'accesso per un lungo periodo. Per comprendere i tipi di accesso che possono essere ottenuti utilizzando Kerberoasting, guarda la lista degli SPN di Active Directory mantenuta da Sean Metcalf.

Kerberoasting: Come funziona

Passo 1. Ottenere gli SPN degli account di servizio.

. Ci sono molti modi per ottenere questi SPN, tra cui:

• Query di PowerShell e ricognizione LDAP
• Modulo Active Directory per PowerShell
• Script GetUserSPNs nel Kerberoast toolkit
• Comando Get-NetUser di PowerSploit

Passaggio 2. Richiedi ticket di servizio per gli SPN degli account di servizio.

Eseguire semplicemente un paio di righe di PowerShell, e un ticket di servizio verrà restituito e memorizzato nella memoria del sistema.

      Add-Type –AssemblyName System.IdentityModel
New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken –ArgumentList ‘MSSQLSvc/jefflab-sql02.jefflab.local:1433’
      

Passaggio 3. Estrai i ticket di servizio utilizzando Mimikatz.

Mimikatz estrarrà i ticket locali e li salverà sul disco per il cracking offline. Basta installare Mimikatz e impartire un singolo comando:

Passaggio 4. Decifrare i ticket.

I ticket Kerberos sono criptati con la password dell'account di servizio associato allo SPN specificato nella richiesta del ticket. Gli strumenti di Kerberoasting forniscono uno script Python per decifrare i ticket e fornire le loro password in chiaro eseguendo un dizionario di hash delle password contro di essi. Può richiedere una certa configurazione per assicurarsi di avere l'ambiente richiesto per eseguire lo script, ma questo blog copre quei dettagli.

In alternativa, puoi raccogliere i ticket Kerberos utilizzando lo script GetUserSPNs e decifrarli con lo strumento di recupero password Hashcat.

Protezione contro gli attacchi di Kerberoasting

La mitigazione primaria degli attacchi di Kerberoasting consiste nell'assicurarsi che tutti gli account di servizio utilizzino password lunghe e complesse che sono più difficili da decifrare e ruotarle regolarmente per minimizzare il tempo in cui l'account potrebbe essere utilizzato da un avversario che riesce a decifrare una password. L'utilizzo di account di servizio gestiti a livello di gruppo è considerata una prassi ottimale per l'assegnazione di password casuali e complesse che possono essere ruotate automaticamente.

Poiché gli avversari decifrano i ticket offline, il processo non genera traffico di rete, rendendo quella parte dell'attacco non rilevabile. Tuttavia, è possibile individuare le fasi precedenti monitorando Active Directory con una soluzione di sicurezza solida. In particolare, gli account di servizio vengono normalmente utilizzati dagli stessi sistemi negli stessi modi, quindi è importante osservare le richieste di autenticazione anomale. Inoltre, monitorare gli incrementi nelle richieste di ticket di servizio.

Infine, gli specialisti della sicurezza raccomandano anche di disabilitare la crittografia basata su RC4. Altrimenti, anche se un account utente supporta la crittografia AES, un attaccante può richiedere un ticket criptato con RC4, che è più facile da decifrare rispetto a uno creato utilizzando la crittografia AES.

Kerberoasting consente a un attaccante con un account di dominio standard di richiedere ticket crittografati per account di servizio e poi decifrare le loro password offline, dove non si applica alcuna politica di blocco e il controller di dominio non è coinvolto.

Cos'è il Kerberoasting?

Ha successo contro account debolmente protetti, e il 76% delle organizzazioni non gestisce né monitora completamente le identità non umane, inclusi gli account di servizio, secondo il Netwrix 2026 Data and Identity Security Report.

L'attacco inizia con un elenco di quegli account, che un attaccante può creare tramite LDAP reconnaissance.

Kerberoasting è un attacco ad Active Directory (AD) che trasforma una normale funzionalità di Kerberos in un'opportunità per decifrare password. Kerberos consente a qualsiasi utente autenticato di richiedere un ticket di servizio da un controller di dominio, e il ticket è crittografato con una chiave derivata dalla password dell'account di servizio.

Come gli aggressori estraggono le password degli account di servizio con Kerberoasting

L'estrazione avviene in quattro fasi, e Rubeus e GetUserSPNs.py di Impacket combinano le prime tre in un unico comando mentre Hashcat gestisce la quarta.

1. Trova gli account che hanno SPN

2. Richiedi ticket di servizio per gli SPN

Un attaccante che raccoglie quei ticket può indovinare le password offline finché uno non viene decriptato. Gli obiettivi sono account utente con service principal names (SPNs), inclusi la maggior parte dei service accounts. L'attacco non richiede diritti elevati per iniziare.

Un attaccante con qualsiasi account di dominio può elencare gli account con SPN tramite una query LDAP, una query PowerShell o il modulo Active Directory per PowerShell. Rubeus e GetUserSPNs.py enumerano anche autonomamente gli account kerberoastabili, e Rubeus può fornire statistiche su di essi senza inviare richieste di ticket.

Un SPN identifica un'istanza di servizio in tre parti, come in MSSQLSvc/jefflab-sql02.jefflab.local:1433Expand, che indica la classe di servizio, l'host e la porta. La classe di servizio suggerisce a cosa può accedere un account compromesso, come l'accesso al database per MSSQLSvc.

Due righe di PowerShell richiedono un ticket per un SPN nominato, e Windows lo memorizza in memoria.

Rubeus automatizza la richiesta per ogni account kerberoastable e può scrivere i risultati in un file.

Kerberos verifica l'identità e lascia l'autorizzazione al servizio (RFC 4120), quindi il controller di dominio non verifica se il richiedente può usare il servizio prima di emettere un ticket. Qualsiasi utente autenticato riceve quindi un ticket crittografato con una chiave derivata dalla password dell'account del servizio.

3. Estrarre i ticket di servizio

Impacket's GetUserSPNs.py fa lo stesso con l’opzione -request, che produce i ticket in un formato accettato da John the Ripper e Hashcat.

Quando esiste un account con la pre-autenticazione Kerberos disabilitata, l'opzione /nopreauth di Rubeus richiede i ticket di servizio inviando messaggi AS-REQ (Authentication Service Request) tramite esso.

4. Rompi i ticket

Un ticket richiesto con le righe PowerShell sopra rimane in memoria finché l'attaccante non lo esporta. Mimikatz elenca i ticket nella sessione corrente e li scrive su file per il cracking offline con un solo comando.

Rubeus e GetUserSPNs.py con -request saltano questo passaggio, perché producono direttamente hash crackabili.

Perché il tipo di crittografia del ticket è importante

Il cracking viene eseguito sull'hardware dell'attaccante, quindi non si applica alcuna politica di blocco e il controller di dominio non vede nulla dopo la richiesta del ticket. Hashcat testa le password ipotizzate contro ogni ticket e recupera la password in chiaro quando un'ipotesi la decripta. Accetta il formato prodotto da GetUserSPNs.py e ha una modalità separata per ogni tipo di crittografia.

Netwrix Threat Prevention blocca in tempo reale gli attacchi DCSync, Kerberoasting e Pass-the-Hash su Active Directory. Richiedi una demo.

I ticket RC4 si decifrano più velocemente

Il tipo di crittografia di un ticket, RC4 (Rivest Cipher 4) o AES (Advanced Encryption Standard), determina la velocità con cui un attaccante può indovinarlo, e Microsoft ha cambiato i valori predefiniti nel 2026.

Gli aggressori possono richiedere RC4 per account che supportano AES

I ticket AES rallentano l'indovinamento ma cedono ancora a password deboli

La chiave di un ticket RC4 è l'hash NT LAN Manager (NTLM) dell'account, un hash della password senza salt (RFC 4757). Senza salt, la stessa password produce la stessa chiave per ogni account, e ogni tentativo costa un calcolo hash.

Rubeus richiede per impostazione predefinita il tipo di crittografia più elevato supportato da ogni account, ma l'opzione /usetgtdeleg richiede ticket RC4 per gli account che supportano AES, e l'opzione /rc4opsec salta gli account abilitati per AES.

GetUserSPNs.py di Impacket richiede RC4 per impostazione predefinita a meno che non sia impostato -no-rc4. Rimuovere RC4 dai tipi di crittografia supportati dall'account di servizio chiude quella via di downgrade.

Tutti e tre i tipi sono violabili, quindi la lunghezza e la casualità della password decidono l'esito.

L'aggiornamento di aprile 2026 ha modificato il controller di dominio predefinito

Protezione degli account di servizio da Kerberoasting

Le chiavi AES derivano da una derivazione di chiave salata che esegue 4.096 iterazioni per impostazione predefinita (RFC 3962), rendendo ogni tentativo più costoso. L'opzione /aes di Rubeus prende di mira gli account abilitati AES e richiede i loro ticket AES, e Hashcat ha una modalità separata per ogni tipo di crittografia del ticket.

La modifica non interessa gli account che consentono esplicitamente RC4 tramite quell'attributo, e un valore predefinito di dominio impostato esplicitamente viene rispettato così com'è scritto. Quegli account possono ancora ricevere ticket RC4, quindi sono quelli da trovare per primi.

L'aggiornamento KB5073381 di Microsoft è iniziato con eventi di audit a gennaio 2026. Il 14 aprile 2026 ha modificato il valore predefinito del controller di dominio in modo che gli account senza un valore esplicito di msDS-SupportedEncryptionTypes siano considerati supportare solo AES-SHA1, e gli aggiornamenti rilasciati da luglio 2026 in poi non supportano più il valore di registro che consentiva agli amministratori di annullare la modifica.

Ogni controllo limita una parte diversa dell’attacco e tutti utilizzano funzionalità native di Active Directory e Windows.

Sposta gli account di servizio su account gestiti

Imposta password lunghe e casuali per gli altri

Reimposta le password e applica AES

La ricerca di Netwrix sull'attacco BadSuccessor, che sfrutta dMSA per l'escalation dei privilegi, consiglia di verificare chi detiene i diritti CreateChild, WriteProperty, WriteDACL, GenericAll e WriteOwner sulle unità organizzative prima di implementarli.

Gli account di servizio gestiti di gruppo (gMSAs) utilizzano password casuali di 120 caratteri che Active Directory ruota, quindi gli aggressori non hanno nulla di debole da indovinare. Gli account di servizio gestiti delegati (dMSAs) hanno anche Active Directory che gestisce le credenziali.

Per gli account che non possono essere spostati, MITRE ATT&CK raccomanda password idealmente di 25 o più caratteri. La generazione casuale conta tanto quanto la lunghezza, perché le wordlist per il cracking sono costruite dalle password scelte dalle persone.

Le chiavi AES vengono generate quando una password viene impostata o modificata, quindi un account la cui password precede il supporto AES non ne ha finché non viene reimpostata, e un account solo AES senza di esse non può ricevere ticket.

Rimuovere gli SPN che gli account non necessitano

Testa ogni servizio prima di limitarlo, perché i servizi che non supportano AES, inclusi alcuni dispositivi non Windows, smettono di autenticarsi una volta rimosso RC4.

Reimposta prima la password, quindi controlla l'attributo msDS-SupportedEncryptionTypes dell'account per impostazioni esplicite RC4 e limitane l'uso a AES128 e AES256 (valore 24).

Ogni SPN su un account utente rende quell'account richiedibile, quindi elencali tutti e confrontali con un servizio in esecuzione.

Controlla chi può aggiungere SPN

Limitare i privilegi dell'account di servizio

Registra le richieste di ticket di assistenza

L'account krbtgt appare nei risultati per progettazione e non è qualcosa da modificare. Per qualsiasi altro SPN che punti a un host dismesso o a un'applicazione ritirata, controllalo con setspn -L <account>Expand ed eliminalo con setspn -D <SPN> <account>Expand.

In targeted Kerberoasting, un attaccante con diritti GenericAll, GenericWrite, WriteProperty o Validated Write su Service Principal Name di un account aggiunge un SPN, rendendo l'account vulnerabile al roast. Controlla le liste di controllo accessi sugli account di servizio e rimuovi tali diritti da chi non gestisce l'account. Solitamente li detengono i membri del gruppo integrato Account Operators.

Abilita la sottocategoria Audit Kerberos Service Ticket Operations sui controller di dominio, che registra ogni richiesta come Evento ID 4769. MITRE consiglia di monitorare richieste anomale che utilizzano RC4, indicato come Ticket Encryption Type 0x17, mentre i ticket AES mostrano 0x11 o 0x12.

Il roasting tramite un account senza pre-autenticazione invia invece messaggi AS-REQ, quindi tali richieste vengono registrate come Evento ID 4768, e su di esse si applica lo stesso controllo RC4.

Una password compromessa consente a un attaccante di fare tutto ciò che può fare l’account. Rimuovi gli account di servizio dai gruppi privilegiati come Domain Admins e concedi solo i diritti utilizzati dal servizio, secondo il principio del minimo privilegio. Questo lavoro fa parte di un più ampio rafforzamento della sicurezza di Active Directory.

Il repository Kerberos-Crypto di Microsoft include uno script Get-KerbEncryptionUsage.ps1 che legge entrambi i tipi di eventi, e eseguirlo con -Encryption RC4 e -SearchScope AllKdcs elenca le richieste RC4 su ogni controller di dominio.

Come Netwrix aiuta a difendersi da Kerberoasting

Blocca i tentativi di Kerberoasting in tempo reale

I prodotti Netwrix aggiungono tre controlli oltre alle impostazioni native di Windows: bloccare l’attacco, rilevare cosa succede dopo e valutare Active Directory per le vulnerabilità che sfrutta.

Rilevare attacchi basati sull'identità

Netwrix Threat Prevention blocca i tentativi di Kerberoasting, DCSync e Pass-the-Hash contro Active Directory prima che abbiano successo. Questo offre ai team un punto di applicazione al momento dell’attacco, che la revisione dei log non può fornire.

Valutare la postura di sicurezza di Active Directory

Inizia con gli account che consentono ancora RC4

Netwrix Threat Manager identifica il furto di credenziali, il movimento laterale e l’escalation dei privilegi, che sono attacchi basati sull’identità che possono seguire una password di account di servizio compromessa. Rileva anche quando un SPN viene aggiunto a un account privilegiato, la fase di configurazione del Kerberoasting mirato.

Kerberoasting richiede solo una password debole dell’account di servizio, quindi la difesa funziona meglio come una sequenza applicata account per account.

Netwrix PingCastle valuta la sicurezza di Active Directory e identifica configurazioni errate, percorsi di attacco ed esposizione dei privilegi.

Gli account che non possono diventare account gestiti necessitano di password lunghe e casuali per resistere ai tentativi di indovinare offline. La richiesta del ticket è l’unico passaggio che i difensori possono ancora osservare, quindi registrarla copre ciò che l’igiene delle password non può.

Dopo la modifica predefinita di Microsoft di aprile 2026, gli account che consentono esplicitamente RC4, sia sull'account che tramite un valore predefinito di dominio esplicitamente impostato, possono ancora ricevere ticket RC4, quindi vengono prima. Sposta ciò che può essere spostato su account gestiti, quindi reimposta il resto e limitane l'uso a AES.

Richiedi una demo per vedere come Netwrix Threat Prevention blocca i tentativi di Kerberoasting contro gli account di servizio Active Directory prima che abbiano successo.