AS-REP Roasting: Kerberos Pre-Authentication Abuse (T1558.004)

L'attività inizia con l'enumerazione degli account che hanno pre-autenticazione disabilitata. Con credenziali di dominio valide, anche di basso privilegio, si interroga LDAP filtrando gli oggetti user con l'attributo userAccountControl contenente il flag 0x400000 (DONT_REQ_PREAUTH).

Da PowerShell con il modulo Active Directory:

Get-ADUser -Filter 'useraccountcontrol -band 4194304' -Properties useraccountcontrol

In alternativa, con PowerView (open source, parte di PowerSploit) si usa Get-DomainUser -PreauthNotRequired. Da Linux, ldapsearch (open source) permette la stessa query con filtro (&(objectClass=user)(userAccountControl:1.2.840.113556.1.4.803:=4194304)).

La fase successiva è la raccolta degli hash AS-REP. Lo strumento di riferimento è Rubeus (S1071, open source), eseguito da un contesto autenticato:

Rubeus.exe asreproast /format:hashcat /outfile:hashes.txt

Rubeus enumera automaticamente gli account vulnerabili e richiede i TGT, restituendo hash pronti per il cracking. Da Linux, impacket-GetNPUsers (open source, parte di Impacket) è l'equivalente:

impacket-GetNPUsers dominio.local/ -usersfile users.txt -format hashcat -outputfile hashes.txt

Quando non si dispone di credenziali, si può fornire una lista di username presunti e testarli uno per uno: il DC risponderà con AS-REP solo per gli account vulnerabili, senza autenticazione richiesta. Questa modalità genera più rumore ma non richiede un account valido.

Il cracking offline avviene con Hashcat (open source) usando la modalità 18200 per AS-REP RC4:

hashcat -m 18200 hashes.txt wordlist.txt -r rules/best64.rule

In alternativa John the Ripper (open source) con il formato krb5asrep. Un hash RC4 con password debole (dizionario o lunghezza inferiore a 10 caratteri) cade tipicamente in minuti su GPU consumer.

In un engagement red team, dopo aver ottenuto le credenziali in chiaro, si valuta l'appartenenza dell'account a gruppi privilegiati con BloodHound (open source), mappando percorsi verso Domain Admins. Account di servizio con pre-auth disabilitata sono spesso membri di gruppi applicativi con permessi eccessivi, o hanno SPN registrati che aprono a Kerberoasting successivo.

In laboratorio, la simulazione richiede un DC Windows Server con almeno un utente configurato con Do not require Kerberos preauthentication attivo dalle proprietà dell'account in ADUC. Si consiglia di documentare timing, encryption type osservato e volume di query LDAP per validare le regole di detection SOC.

La detection si basa principalmente sui log di sicurezza del Domain Controller, dove l'evento chiave è EventCode 4768 (A Kerberos authentication ticket TGT was requested). Il campo discriminante è Pre-Authentication Type: il valore 0 indica che il TGT è stato rilasciato senza pre-autenticazione, condizione anomala che merita indagine immediata.

Un secondo indicatore forte è Ticket Encryption Type pari a 0x17 (RC4-HMAC). In ambienti moderni con AES abilitato, l'uso di RC4 su richieste TGT è raro e spesso segnala tool offensivi come Rubeus o Impacket che preferiscono RC4 per il cracking più rapido. La query SIEM combinata cerca eventi 4768 con PreAuthType=0 AND TicketEncryptionType=0x17.

L'enumerazione LDAP preliminare produce query verso il DC con filtri specifici sul flag userAccountControl contenente 4194304. Se si dispone di logging LDAP dettagliato (EventCode 1644 con Field Engineering abilitato o audit tramite Directory Services), i pattern di filtro (userAccountControl:1.2.840.113556.1.4.803:=4194304) sono altamente sospetti quando provengono da workstation non amministrative.

Le regole di correlazione dovrebbero includere:

• Baseline degli account legittimamente configurati senza pre-auth (spesso account applicativi legacy noti). Deviazioni indicano enumerazione avversaria.
• Soglia di richieste AS-REQ/AS-REP per singolo account entro finestre brevi (es. più di 5 in 60 secondi).
• Correlazione tra 4768 anomali e successivi EventCode 4769 (service ticket request) dallo stesso principal, che indica progressione post-cracking.
• Alert su modifiche all'attributo userAccountControl di utenti (EventCode 4738) che introducono il flag DONT_REQ_PREAUTH — spesso segnale di persistenza avversaria.

Sul piano preventivo, D3FEND suggerisce di rafforzare la configurazione autenticativa: audit periodico degli account con pre-auth disabilitata tramite script PowerShell schedulati, e restrizione dell'uso di RC4 tramite Group Policy (Network security: Configure encryption types allowed for Kerberos) forzando AES128/AES256.

I falsi positivi principali derivano da account di servizio legacy legittimi, scanner di vulnerabilità (Tenable, Rapid7) che testano proattivamente questa condizione, e strumenti di audit interni. Una whitelist degli host autorizzati a eseguire enumerazione LDAP massiva (server di gestione IAM, scanner PAM) riduce il rumore. Il monitoraggio dei source IP delle AS-REQ senza pre-auth aiuta a distinguere tool avversari da configurazioni legittime: le prime provengono da workstation utente, le seconde da server applicativi noti.

L'analisi forense di un incidente AS-REP Roasting parte dai Domain Controller coinvolti, dove il Security.evtx contiene la traccia primaria. Gli eventi 4768 con PreAuthType=0 costituiscono la prova diretta dell'emissione di TGT senza pre-autenticazione. Ogni evento include Account Name, Client Address (l'IP del richiedente), Ticket Encryption Type e Service Name. La correlazione temporale di più eventi 4768 anomali dallo stesso Client Address verso account diversi ricostruisce la sessione di roasting.

La timeline si arricchisce con gli eventi 4769 successivi, che indicano l'uso dei ticket ottenuti dopo il cracking, e con 4624 (logon success) da parte degli account compromessi, spesso da host anomali. L'intervallo tra il 4768 iniziale e il primo 4624 con quelle credenziali dà una stima del tempo di cracking, utile per valutare la robustezza delle password compromesse.

Sull'host origine dell'attacco, se sotto controllo, si cercano artefatti di Rubeus o Impacket. Con Sysmon configurato (EventCode 1 per process creation), i comandi Rubeus lasciano tracce nella command line, spesso offuscate ma con pattern riconoscibili (asreproast, /format:hashcat). File di output degli hash (spesso hashes.txt, asrep.txt) possono residuare in %TEMP% o nelle directory profilo. Il Prefetch (*C:\Windows\Prefetch*) conserva evidenze di esecuzione anche dopo la rimozione del binario.

Per Impacket da Linux, i log di bash_history dell'attaccante (se accessibili) e i log auth.log o syslog documentano l'esecuzione. Il traffico di rete catturato o ricostruito da NetFlow verso la porta 88/TCP del DC in volumi anomali è un altro indicatore. Se disponibile PCAP, i pacchetti AS-REQ senza campo PA-ENC-TIMESTAMP sono la firma sul filo.

Sul DC, il NTDS.dit e i log Directory Service documentano eventuali modifiche al flag DONT_REQ_PREAUTH, utili a stabilire se l'attaccante ha creato o modificato account per abilitare persistenza tramite questa tecnica. L'evento 4738 (user account changed) mostra le modifiche a userAccountControl.

Gli artefatti secondari includono voci nel Registry relative a moduli PowerShell caricati (HKCU\Software\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txt), che spesso conservano le query Get-ADUser usate per l'enumerazione. Su sistemi con PowerShell ScriptBlock Logging attivo (EventCode 4104), lo script completo è ricostruibile.

La fase di scoping determina l'ambito: ogni account con pre-auth disabilitata al momento dell'incidente deve essere considerato potenzialmente compromesso, con password resettate e sessioni terminate. L'analisi delle proprietà lastLogon e pwdLastSet aiuta a prioritizzare la remediation.

I dati MITRE ATT&CK non associano T1558.004 a gruppi APT specifici documentati nel framework al momento della raccolta. Questa assenza formale non riflette la rarità della tecnica, ma piuttosto la difficoltà di attribuzione: AS-REP Roasting è un'operazione silenziosa, condotta con tool ampiamente disponibili, che raramente lascia firme distintive di uno specifico attore.

Lo strumento di riferimento censito è Rubeus (S1071), tool .NET open source sviluppato originariamente come porting di funzionalità del framework Kekeo. Rubeus è oggi parte dell'arsenale standard di penetration tester e red team, ma è stato osservato anche in operazioni malevole reali per la sua efficacia nel gestire l'intero ciclo Kerberos (asreproast, kerberoast, s4u, ptt). La sua adozione trasversale — da operatori ransomware ad attori state-sponsored — rende difficile l'attribuzione basata sul solo tooling.

Il pattern operativo tipico che emerge nell'ecosistema threat intelligence mostra AS-REP Roasting come attività post-compromise early-stage: l'attaccante ottiene un initial foothold (phishing, exploit web, credenziali VPN comprate su broker) e usa la tecnica come primo movimento verso l'escalation, prima ancora di distribuire beacon C2 o eseguire ricognizione avanzata. Il vantaggio è che opera in un contesto autenticato legittimo, con minima probabilità di detection in ambienti privi di regole specifiche sul PreAuthType.

La tecnica è particolarmente attraente per operatori ransomware che puntano a cifratura rapida del dominio: una password service crackata offline permette lateral movement senza generare i pattern rumorosi di credential dumping (LSASS access, DCSync) che i moderni EDR intercettano. Gruppi ransomware come quelli dietro affiliate program noti hanno integrato workflow di AS-REP Roasting nei loro playbook, spesso in combinazione con Kerberoasting nella stessa sessione.

Sul piano geografico e settoriale, gli ambienti più esposti sono quelli con Active Directory legacy e presenza significativa di account applicativi storici: finanza tradizionale, manifatturiero, pubblica amministrazione e sanità. La presenza di applicazioni degli anni 2000 che richiedevano configurazioni Kerberos permissive per interoperabilità è una causa strutturale della persistenza di account vulnerabili.

Il trend osservabile è duplice. Da un lato Microsoft ha progressivamente reso più difficile mantenere RC4 come encryption type predefinito, spingendo verso AES; dall'altro la migrazione a Azure AD / Entra ID non elimina il rischio dove sopravvivono deployment ibridi con AD on-premise. Le organizzazioni che stanno modernizzando l'identity stack ma mantengono forest legacy per compatibilità restano il target privilegiato. La detection della tecnica è ancora sottodimensionata in molti SOC, dove le regole standard sui log 4768 non discriminano il campo PreAuthType.

MITRE ATT&CK T1558.004 (AS-REP Roasting), tattica TA0006. Software S1071 (Rubeus). Mitigazioni M1027 (Password Policies), M1041 (Encrypt Sensitive Information), M1047 (Audit). Detection DET0113 con analytic AN0316 (Windows Security e Sysmon). Framework MITRE D3FEND per mapping difensivo. Sono state utilizzate conoscenze professionali di cybersecurity per dettagli operativi su tool open source (Rubeus, Impacket, Hashcat, John the Ripper, PowerView, BloodHound, ldapsearch) e sintassi comandi Windows/Linux.