Active Directory AS-REP Roasting Account di Servizio Privilegiati: Gli Account Che la Pre-Auth Doveva Proteggere

Active Directory AS-REP roasting di account di servizio privilegiati è il caso a maggior rischio trattato in questo articolo: account Kerberos con la pre-autenticazione disabilitata che si trovano anche in un gruppo privilegiato o operano come account di servizio, non un utente standard qualsiasi.

Active Directory AS-REP Roasting Account di Servizio Privilegiati

Il catalogo EtcSec traccia separatamente il caso degli account privilegiati come ADMIN_ASREP_ROASTABLE (Critico), perché un account già presente in Domain Admins, Enterprise Admins o in un altro gruppo Tier 0 con questo flag impostato trasforma l'AS-REP roasting in una corsa di cracking offline diretta verso il DA, non in una catena di lateral movement a più fasi. Per la versione generale di questo attacco applicabile a qualsiasi account, vedi AS-REP Roasting: raccogliere hash senza credenziali — questo articolo ha un ambito più ristretto, focalizzato sul cluster di account privilegiati e di servizio che quell'articolo non copre.

Il flag sottostante è DONT_REQ_PREAUTH (0x400000 / decimale 4194304) nell'attributo userAccountControl (Microsoft Learn: UserAccountControl property flags). Quando è impostato, qualsiasi client può richiedere una risposta Kerberos Authentication Server (AS-REP) per quell'account, e la risposta torna con una parte cifrata usando una chiave derivata dalla password dell'account — senza che il client debba mai dimostrare di conoscere quella password. MITRE ATT&CK T1558.004 classifica questo come «Steal or Forge Kerberos Tickets: AS-REP Roasting».

La maggior parte degli articoli generici tratta questo come una misura di igiene uguale per tutti gli account utente. Questa impostazione non coglie perché due cluster specifici contano di più:

• Account privilegiati senza pre-autenticazione (ADMIN_ASREP_ROASTABLE, Critico) — appartenenza a un gruppo Tier 0 combinata con un hash roastable.
• Account di servizio con il cluster di misconfigurazioni adiacenti — nessuna pre-autenticazione (SERVICE_ACCOUNT_NO_PREAUTH), accesso interattivo consentito (SERVICE_ACCOUNT_INTERACTIVE), e una password che non ruota da oltre un anno (SERVICE_ACCOUNT_OLD_PASSWORD). Ciascuno da solo è di severità Alta; insieme significano che l'hash è facile da ottenere e, una volta craccato, resta valido a lungo su un account che può anche essere sfruttato per accesso interattivo.

Perché il flag finisce impostato su account reali

DONT_REQ_PREAUTH viene raramente impostato per malizia — di solito è un residuo di una specifica esigenza di compatibilità mai ripulita. Le cause documentate includono le migrazioni SIDHistory tra domini, in cui alcune soluzioni di terze parti per VPN o federazione non riescono a completare la pre-autenticazione Kerberos per le identità migrate a meno che il flag non venga temporaneamente disabilitato durante il passaggio (Quest support KB 4313059), e la compatibilità con applicazioni o appliance legacy, in cui una libreria client Kerberos più vecchia non riesce proprio a gestire la pre-autenticazione (Tenable: How to Stop the Kerberos Pre-Authentication Attack; JumpCloud: What Is Kerberos Pre-Authentication?). La migrazione o l'appliance legacy vengono dismesse; il flag resta impostato sull'account a tempo indeterminato perché nessuno lo riverifica più.

Come funziona

La pre-autenticazione Kerberos esiste proprio per bloccare questa classe di attacco: il client deve cifrare un timestamp con una chiave derivata dalla propria password e inviarlo nell'AS-REQ prima che il KDC emetta qualsiasi cosa. Senza questo requisito, la sequenza si riduce a quattro passaggi: l'attaccante invia un AS-REQ per il nome utente target senza password e senza autenticazione preventiva al dominio, purché l'account sia enumerabile (LDAP, RPC, o un elenco di nomi utente trapelato); il KDC risponde immediatamente con un AS-REP perché la pre-autenticazione non è richiesta; parte di quell'AS-REP è cifrata con una chiave derivata dalla password dell'account; e l'attaccante cracca quella parte offline, senza alcun logging lato dominio dei tentativi di password falliti, poiché ogni tentativo avviene sull'hardware dell'attaccante, non contro il DC.

La velocità di cracking dipende dal tipo di cifratura Kerberos negoziato. Se l'account consente ancora RC4 (etype 23), l'attaccante richiede RC4, e la modalità hashcat 18200 ($krb5asrep$23$...) lo cracca ordini di grandezza più velocemente di quanto farebbe una risposta AES-256 (etype 18). Vale la pena chiudere anche il fallback RC4 — vedi Kerberos RC4 Fallback in Active Directory per il relativo percorso di rilevamento e rimozione.

La catena d'attacco

L'AS-REP roasting raramente resta isolato in una compromissione reale. Un walkthrough pubblicato del lab ShadowGate di Hack Smarter Labs — «ShadowGate Active Directory Lab Walkthrough» di incoggeek — descrive una catena che inizia con l'enumerazione SMB anonima, passa all'AS-REP roasting come primo passo autenticato, e poi si sposta verso l'abuso di ACL mappato con BloodHound (un permesso GenericWrite sfruttato tramite Shadow Credentials) e attacchi di enrollment AD CS (ESC8, tramite autenticazione forzata da PetitPotam verso l'endpoint web di enrollment della CA) fino a un certificato di controller di dominio. L'AS-REP roasting è ciò che trasforma un punto d'appoggio completamente non autenticato nel primo segreto craccabile di quella catena — la stessa ragione per cui Active Directory Attack Paths to Domain Admin tratta un passaggio iniziale di roasting Kerberos come un arco cardine, e esattamente perché un riscontro ADMIN_ASREP_ROASTABLE su un account Tier 0 viene classificato come Critico anziché come igiene di routine.

Passaggio 1 — Enumerare e richiedere

# Impacket -- enumera ogni account in usersfile.txt con la pre-auth disabilitata
# ed estrae hash AS-REP craccabili senza alcuna credenziale di dominio valida
impacket-GetNPUsers CORP.LOCAL/ -no-pass -usersfile usersfile.txt -format hashcat -outputfile asrep_hashes.txt

Passaggio 2 — Craccare offline

# Craccare offline gli hash $krb5asrep$23$... ottenuti (modalità 18200 = Kerberos 5, AS-REP, etype 23)
hashcat -m 18200 asrep_hashes.txt rockyou.txt

Rilevamento

Il segnale più affidabile è l'Event ID 4768 di Windows Security (richiesta di ticket di autenticazione Kerberos) con Pre-Authentication Type 0, che si verifica legittimamente solo quando l'account target ha la pre-auth disabilitata (MITRE ATT&CK Detection Strategy DET0113; HackTheBox: AS-REP roasting detection). Abbinalo al tipo di cifratura negoziato: 0x17 (RC4) insieme a Pre-Auth Type 0 è l'indicatore combinato più forte, poiché un attaccante effettua deliberatamente il downgrade a RC4 per velocizzare il cracking offline. Per la baseline più ampia di audit policy ed Event ID su cui si basa questo rilevamento, vedi Active Directory Monitoring: Security Event IDs That Matter.

Due query PowerShell coprono direttamente i rilevatori di questo cluster:

# Account privilegiati con pre-auth disabilitata (candidati ADMIN_ASREP_ROASTABLE)
Get-ADUser -Filter {(userAccountControl -band 4194304) -and (adminCount -eq 1)} `
    -Properties userAccountControl, adminCount, ServicePrincipalName, MemberOf |
    Select-Object Name, DistinguishedName, ServicePrincipalName

# Account di servizio (con SPN) con pre-auth disabilitata, più l'anzianità della password
Get-ADUser -Filter {(userAccountControl -band 4194304) -and (ServicePrincipalName -like '*')} `
    -Properties ServicePrincipalName, PasswordLastSet, LastLogonDate |
    Select-Object Name, ServicePrincipalName, PasswordLastSet,
        @{N='PasswordAgeDays';E={(New-TimeSpan -Start $_.PasswordLastSet -End (Get-Date)).Days}}

SERVICE_ACCOUNT_INTERACTIVE non è un flag di userAccountControl — è un riscontro comportamentale. Confermalo correlando lo sAMAccountName dell'account di servizio con eventi 4624 con Logon Type 2 (Interactive) o 10 (RemoteInteractive/RDP). Un vero account di servizio dovrebbe mostrare solo Logon Type 3 (Network) o 5 (Service).

Remediation

Per gli account privilegiati

Rimuovi il flag: deseleziona «Non richiedere la preautenticazione Kerberos» nella scheda Account dell'account, oppure esegui Set-ADAccountControl -Identity <account> -DoesNotRequirePreAuth $false. Rilancia la query di rilevamento sopra e conferma che restituisca zero righe. Se l'account è stato contrassegnato a causa di una precedente migrazione SIDHistory o di un passaggio di federazione, conferma che quella migrazione sia completamente terminata — pulizia SIDHistory inclusa — prima di riattivare la pre-auth, così da non interrompere una dipendenza ancora attiva.

Per gli account di servizio

1. Migra gli account di servizio roastable a gMSA. I Group Managed Service Account ruotano automaticamente una password di 120 caratteri e, per progettazione, non possono essere usati per il logon interattivo, chiudendo SERVICE_ACCOUNT_OLD_PASSWORD e SERVICE_ACCOUNT_INTERACTIVE nella stessa mossa. Vedi gMSA Password Exposure in Active Directory per le avvertenze su chi può ancora leggere la password di un gMSA una volta distribuito.
2. Limita esplicitamente il logon interattivo. Dove un account non può ancora passare a gMSA, applica «Nega accesso locale» e «Nega accesso tramite i Servizi Desktop remoto» tramite una GPO limitata all'OU dell'account di servizio, e limita «Accedi come servizio» solo agli host che ne hanno realmente bisogno.
3. Ruota la password e imponi Kerberos AES. Imposta subito una password forte e univoca, e metti l'account sotto una password policy o una Fine-Grained Password Policy che imponga davvero la rotazione invece di lasciarla statica per un anno o più. Separatamente, imponi AES invece di RC4 tramite «Sicurezza di rete: configura i tipi di crittografia consentiti per Kerberos» — questo non risolve l'assenza del requisito di pre-auth, ma alza il costo di cracking di ogni ticket che l'account negozia legittimamente.
4. Non affidarti a Protected Users come soluzione. Il gruppo di sicurezza Protected Users è il controllo giusto per gli account privilegiati umani, ma Microsoft sconsiglia esplicitamente di aggiungervi account di servizio o computer: l'appartenenza blocca la cache delle credenziali, quindi un account di servizio che non riesce a raggiungere un DC anche solo brevemente fallirà completamente. L'appartenenza inoltre non rimuove il flag DONT_REQ_PREAUTH — un account di servizio lasciato nel gruppo con quel flag ancora impostato resta esattamente roastable come prima. Vedi Active Directory Privileged Accounts: Protected Users, Delegation, and Service Account Gaps per capire dove questo gruppo si applica e dove no.

Come EtcSec rileva tutto questo

L'audit Active Directory di EtcSec verifica direttamente questo cluster: ADMIN_ASREP_ROASTABLE contrassegna i membri di gruppi privilegiati con la pre-autenticazione Kerberos disabilitata, SERVICE_ACCOUNT_NO_PREAUTH copre lo stesso flag su qualsiasi account di servizio dotato di SPN, SERVICE_ACCOUNT_INTERACTIVE contrassegna gli account di servizio osservati o configurati per il logon interattivo, e SERVICE_ACCOUNT_OLD_PASSWORD contrassegna gli account di servizio la cui password non ha ruotato secondo policy. Nessuno di questi richiede una simulazione di attacco live — sono controlli di attributi LDAP e di comportamento di logon eseguiti a ogni passata di audit.