Kerberos e Kerberoasting

Kerberos è un protocollo di autenticazione basato sui ticket. Invece di inviare password, i client presentano ticket crittografici emessi dal Key Distribution Center (KDC), in esecuzione su ogni Domain Controller.

• L'Authentication Server (AS) emette un Ticket Granting Ticket (TGT).
• Il Ticket Granting Server (TGS) emette i ticket di servizio.
• I servizi convalidano i ticket senza contattare il DC.

Kerberos prevede tre scambi di messaggi. Comprenderli permette di capire dove si collocano gli attacchi.

• AS-REQ / AS-REP: il client dimostra la propria identità (pre-autenticazione) e riceve un TGT crittografato con la chiave di krbtgt.
• TGS-REQ / TGS-REP: il client presenta il TGT per richiedere un ticket di servizio (TGS).
• AP-REQ / AP-REP: il client presenta il TGS al servizio.

AS-REP roasting attacca il primo scambio; Kerberoasting attacca il secondo.

Un Service Principal Name (SPN) associa un'istanza di servizio all'account che lo esegue. Quando si richiede un TGS per uno SPN, il ticket risultante è parzialmente crittografato con l'hash della password dell'account di servizio.

Questo è il punto centrale del Kerberoasting: qualsiasi utente autenticato può richiedere ticket per gli account di servizio e poi sottoporli a cracking offline per recuperare la password in chiaro.

Il Kerberoasting genera poco rumore perché richiedere un TGS è un comportamento normale. I passaggi dell'attacco sono:

• Enumerare gli account utente con SPN.
• Richiedere i ticket TGS per tali SPN.
• Estrarre i blob dei ticket crittografati.
• Craccarli offline con una wordlist; durante il cracking non è necessaria alcuna interazione con il DC.

Il ticket acquisito usa la password dell'account di servizio come chiave. Il cracking offline prova password candidate finché una non consente di decrittografare correttamente il ticket.

Gli account di servizio hanno spesso password deboli che non vengono mai ruotate, perciò possono essere craccati rapidamente.

Il cifrario usato per il ticket influisce sulla velocità del cracking.

• RC4 (etype 23) è rapido da craccare e rappresenta un segnale d'allarme se è ancora consentito.
• AES (etype 17/18) è molto più lento da sottoporre a forza bruta.
• Gli attaccanti possono effettuare il downgrade delle richieste a RC4 abusando di /tgtdeleg o di msDS-SupportedEncryptionTypes.

È consigliabile disabilitare RC4 in tutto il dominio e imporre AES.

Un attacco correlato prende di mira gli account con la pre-autenticazione Kerberos disabilitata (DONT_REQ_PREAUTH). Senza pre-autenticazione, l'AS-REP contiene dati crittografati con l'hash della password dell'utente, ottenibili senza alcuna credenziale.

Il Kerberoasting ha successo a causa di debolezze strutturali, non di difetti del protocollo.

• Per progettazione, qualsiasi entità autenticata può richiedere un ticket per qualsiasi servizio.
• Gli account di servizio vengono spesso configurati una sola volta con una password debole e non vengono mai ruotati.
• Molti vengono eseguiti con privilegi elevati (ad esempio, account di servizio SQL nel gruppo Domain Admins).
• Il cracking avviene completamente offline, quindi il blocco dell'account non scatta mai.

I team difensivi possono rilevare il roasting tramite la telemetria delle richieste TGS.

• Monitorare l'evento 4769 per le richieste di ticket RC4 (0x17), soprattutto se si verificano in rapida successione da uno stesso account.
• Segnalare quando una singola entità richiede rapidamente molti SPN distinti.
• Implementare account SPN honeypot che nessun servizio legittimo utilizza; qualsiasi richiesta è malevola.

La soluzione duratura consiste nel rimuovere le condizioni che rendono i ticket vulnerabili al cracking.

• Utilizzare Group Managed Service Accounts (gMSA) con password di almeno 120 caratteri, ruotate automaticamente.
• Imporre password lunghe e complesse per gli eventuali account di servizio classici rimasti.
• Disabilitare RC4 e richiedere i tipi di cifratura AES.
• Rimuovere gli SPN non necessari e applicare il principio del privilegio minimo agli account.

Durante i test autorizzati, esegua il cracking dei ticket in un ambiente isolato e non esfiltri mai credenziali in chiaro al di fuori dell'ambito dell'incarico. Segnali per quali account il cracking è riuscito e in quanto tempo, così il cliente può dare priorità alla migrazione a gMSA.

Tratti le password crackate come dati sensibili: le conservi cifrate e le elimini dopo aver redatto il report.

Ha imparato come Kerberos emette i ticket e come questo meccanismo viene sfruttato.

• I ticket SPN sono cifrati con gli hash degli account di servizio, consentendo il cracking offline.
• I ticket RC4 vengono crackati rapidamente; AES e gMSA sono le difese.
• L'AS-REP roasting non richiede credenziali quando la preautenticazione è disabilitata.
• Gli SPN honeypot e il monitoraggio dei ticket RC4 nell'evento 4769 rilevano l'attacco.

Nel prossimo modulo vedremo come riutilizzare le credenziali rubate con Pass-the-Hash e Pass-the-Ticket.