AS-REP Roasting — Rilevamento & Remediation

Cos'è l'AS-REP Roasting?

L'AS-REP Roasting è un attacco Active Directory contro account che hanno la pre-autenticazione Kerberos disabilitata.

Quando il flag DONT_REQ_PREAUTH è abilitato su un utente o su un account di servizio, il KDC può restituire una AS-REP senza chiedere prima una prova che il richiedente conosca la password. Un attaccante che conosce o indovina un nome account valido può richiedere quella risposta, estrarre la parte cifrata e tentare il cracking offline.

È questo che rende l'impostazione pericolosa: trasforma un account di dominio in un bersaglio di cracking della password prima che l'autenticazione abbia avuto esito positivo.

La differenza operativa rispetto al Kerberoasting è chiara:

il Kerberoasting richiede un'identità di dominio valida per richiedere service ticket
l'AS-REP Roasting non richiede credenziali valide per richiedere una AS-REP su un account noto

Questo non significa che LDAP anonimo sia aperto per impostazione predefinita. Microsoft ha disabilitato di default le operazioni LDAP anonime sui controller di dominio Active Directory fin da Windows Server 2003, salvo operazioni limitate come rootDSE e bind. La scoperta dei nomi utente è quindi un problema separato dalla raccolta AS-REP.

Come cambia il flusso Kerberos

In un normale scambio AS di Kerberos, il client invia una AS-REQ con dati di pre-autenticazione, in genere un timestamp cifrato. È questo passaggio che dimostra al KDC che il client conosce la password dell'account.

Se DONT_REQ_PREAUTH è attivo, il KDC salta quel controllo e restituisce subito una AS-REP. La parte cifrata della risposta è protetta con la chiave Kerberos di lungo periodo dell'account, derivata dalla password.

Per un lettore tecnico contano due aspetti:

l'attacco funziona perché la risposta cifrata viene consegnata prima che l'autenticazione sia completata
quella risposta è utilizzabile per cracking offline, quindi lunghezza e qualità della password cambiano direttamente l'impatto

Non bisogna assumere che ogni account roastable restituisca lo stesso tipo di cifratura. In ambienti Windows moderni ci si aspetta spesso tipi AES; in ambienti più vecchi può ancora comparire RC4. Il modello corretto non è “RC4 di default”, ma “il materiale restituito dipende dalla configurazione Kerberos e dai tipi di cifratura consentiti in quell'ambiente”.

Cosa serve davvero a un attaccante

Per un AS-REP Roasting riuscito bastano tre elementi:

Connettività di rete verso un domain controller che risponda alle richieste Kerberos AS.
Nomi account candidati.
Almeno un account con DONT_REQ_PREAUTH attivato.

È per questo che la tecnica è così attraente. L'attaccante non deve prima compromettere una sessione Windows o rubare un primo account per iniziare la raccolta.

In pratica, i nomi utente provengono spesso da:

convenzioni email e directory pubbliche
un foothold precedente a basso privilegio nel dominio
export, script o inventari storici
enumerazione AD autenticata fatta da un account di dominio ordinario

LDAP anonimo è quindi un errore aggiuntivo, non un prerequisito dell'attacco.

La catena di attacco

Fase 1 - Identificare gli account roastable

Con accesso autenticato, questo si interroga direttamente in AD:

Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} -Properties DoesNotRequirePreAuth, PasswordLastSet |
    Select-Object SamAccountName, PasswordLastSet

Senza credenziali, un attaccante può comunque testare nomi noti inviando richieste AS e osservando quali account restituiscono materiale sfruttabile.

Fase 2 - Richiedere risposte AS-REP

# Richiedere materiale AS-REP per un elenco di nomi noti
impacket-GetNPUsers corp.local/ -usersfile users.txt -no-pass -dc-ip 10.10.0.1

Con un account di dominio valido, l'enumerazione può essere più diretta:

impacket-GetNPUsers corp.local/user:password -request -dc-ip 10.10.0.1

Su Windows, Rubeus produce lo stesso risultato:

.\Rubeus.exe asreproast /format:hashcat /outfile:asrep_hashes.txt

Fase 3 - Crackare offline

Da quel momento il domain controller non è più nel loop. I tentativi di password avvengono offline, alla velocità dell'attaccante.

È per questo che vecchie password di account di servizio, segreti scelti manualmente e password che non scadono mai sono particolarmente rischiosi in questo scenario.

Fase 4 - Usare la credenziale recuperata

Se la password viene recuperata, l'account può essere usato come qualsiasi altra identità compromessa:

accesso interattivo, se consentito
LDAP e PowerShell per ampliare la visibilità
movimento laterale verso sistemi dove l'account ha privilegi locali o delegati
escalation se l'account è collegato a gruppi privilegiati, servizi, task schedulati o applicazioni critiche

Una singola eccezione lasciata per una vecchia applicazione può quindi diventare il primo passo di un percorso di identità molto più ampio.

Rilevamento

Il miglior punto di rilevamento resta il domain controller.

Event 4768 è il segnale principale

La documentazione Microsoft su Event ID 4768 rende particolarmente utili due campi:

Pre-Authentication Type = 0 significa che la richiesta di TGT è avvenuta senza pre-autenticazione Kerberos.
Ticket Encryption Type mostra quale tipo di cifratura Kerberos è stato realmente usato.

Per AS-REP Roasting, il segnale da prioritizzare è quindi un 4768 con Pre-Authentication Type 0.

Pattern pratici di hunting

Parti da questi casi:

eventi 4768 ripetuti con Pre-Authentication Type = 0
burst di richieste dalla stessa origine contro più account
richieste verso account di servizio o admin che non dovrebbero autenticarsi in modo interattivo
picchi di 4768 Result Code 0x6, che possono indicare guessing dei nomi prima delle richieste valide
modifiche di account che attivano DONT_REQ_PREAUTH, soprattutto su identità di servizio o privilegiate

Esempio di query SIEM

event.code: "4768" AND
winlog.event_data.PreAuthType: "0" AND
winlog.event_data.Status: "0x0"

Se l'audit dei cambi di directory è attivo, conviene controllare anche le modifiche che impostano il bit userAccountControl interessato. Spesso è lì che si intercetta l'eccezione pericolosa prima dello sfruttamento.

Remediation

1. Rimuovere le eccezioni di pre-auth non giustificate

Set-ADAccountControl -Identity vulnerable_user -DoesNotRequirePreAuth $false

Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} | ForEach-Object {
    Set-ADAccountControl -Identity $_ -DoesNotRequirePreAuth $false
}

Questo è il fix principale. Se un account non ha una motivazione tecnica dimostrabile, l'eccezione non dovrebbe restare.

2. Ruotare le password dopo la correzione

Non basta riattivare la pre-autenticazione. Se l'account era roastable, bisogna assumere che il materiale possa essere già stato raccolto prima della correzione.

Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} |
    Set-ADUser -ChangePasswordAtLogon $true

Per gli account di servizio serve una vera rotazione del segreto, non soltanto il cambio del flag.

3. Riesaminare le dipendenze legacy

Se un team sostiene che l'account debba restare senza pre-auth, va imposta una review tecnica:

quale sistema dipende davvero da questa eccezione
se il sistema può essere modernizzato o isolato
se l'account può essere ridotto al minimo privilegio
se logon interattivo, delega o appartenenze ampie a gruppi possono essere rimossi

Un'eccezione di pre-auth su un account privilegiato o molto riutilizzato non è un piccolo compromesso di compatibilità. È esposizione offline della password.

4. Irrigidire gli account che temporaneamente devono restare in eccezione

Se un'eccezione deve sopravvivere per un periodo:

imporre una password lunga e casuale
rimuovere gruppi privilegiati dove possibile
limitare i diritti di logon
monitorare in modo mirato il 4768 di quell'account
assegnare owner e data di review

5. Non contare sull'oscurità dei nomi utente

Anche con LDAP anonimo disabilitato, bisogna assumere che gli attaccanti possano comunque ricostruire liste di utenti. Il controllo durevole è eliminare gli account roastable e ridurre il valore delle eccezioni che devono restare.

Validazione dopo il fix

Una chiusura professionale di AS-REP Roasting si basa su quattro verifiche semplici:

Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} restituisce solo eccezioni documentate.
Le password degli account precedentemente esposti sono state ruotate.
I 4768 con Pre-Authentication Type = 0 sono scomparsi per utenti e account di servizio ordinari.
Ogni eccezione residua ha owner, giustificazione di business, controlli compensativi e data di review.

Se questi quattro punti non possono essere dimostrati, il problema non è davvero chiuso.

Controllo aggiuntivo che vale la pena mantenere

Per ogni eccezione residua conviene rivedere anche l'inventario dei servizi associati: SPN presenti, età della password, gruppi a cui il conto appartiene e applicazione che continua a dipendere dall'eccezione. Questo controllo evita che un vecchio service account resti roastable solo perché nessuno ha deciso se la dipendenza legacy esiste ancora davvero.

Un'ultima prova utile dopo la chiusura

Vale la pena confermare anche da dove l'account potrebbe ancora essere raggiunto: reti client, jump host, segmenti server o punti di accesso remoti che hanno visibilità sui domain controller. Questa informazione aiuta a distinguere un'eccezione tecnicamente documentata da un'esposizione ancora facilmente sfruttabile in caso di foothold iniziale.

Errori frequenti dal lato difensivo

Gli errori ricorrenti sono quasi sempre gli stessi:

assumere che LDAP anonimo sia un requisito dell'attacco
riattivare la pre-autenticazione ma non ruotare la password
lasciare l'eccezione su vecchi account di servizio con privilegi ampi
trattare l'impostazione come innocua perché l'account “non è interattivo”
correggere l'account visibile senza correggere il processo di provisioning che ha creato l'eccezione

Per un lettore tecnico, il punto centrale non è la complessità dell'exploit. È la quantità di privilegio che l'account esposto ha accumulato nel tempo.

Fonti primarie

Come EtcSec rileva il problema

EtcSec segnala gli account con pre-autenticazione Kerberos disabilitata in ogni audit AD.

Il finding principale è ASREP_ROASTING_RISK: qualsiasi account con DONT_REQ_PREAUTH attivo è un candidato all'esposizione della password.

Finding correlati che cambiano la gravità reale:

PASSWORD_NEVER_EXPIRES
PASSWORD_POLICY_WEAK
WEAK_KERBEROS_POLICY

La combinazione conta più del flag da solo. Un account roastable con password debole, vecchia o che non scade mai è molto più pericoloso di un'eccezione temporanea strettamente controllata.

AS-REP Roasting: Raccogliere Hash Senza Credenziali