Microsoft Active Directory è uno dei sistemi di autenticazione e autorizzazione più usati nelle reti IT aziendali e, per questo, esposto a tutta una serie di cyber attacchi, tra cui quello conosciuto come Authentication Server Response Roasting.
In questo articolo, come fatto per la tecnica di attacco Kerberoasting, forniremo una panoramica di come l’Authentication Server Response Roasting può essere sfruttata da utenti malintenzionati o attacker, indicando le contromisure utili per mitigare o impedire a monte la minaccia attraverso l’hardening e il monitoraggio stesso di Active Directory.
In letteratura sono censite svariate tecniche utilizzabili per compromettere AD DS, AD CS e AD FS, ma ciò che le accomuna, è che gli attacker prendono di mira questi servizi per aumentare i loro privilegi ed effettuare movimenti laterali attraverso le postazioni e i sistemi aziendali.
Questa guida affronta le tecniche più comuni sfruttate per compromettere AD DS, AD CS e AD FS, fornendo una panoramicadi ciascuna tecnica e soprattutto come mitigarla: ho organizzato le sequenze di compromissione come in genere vengono eseguite in un penetration testing su Active Directory, iniziando da quelle utilizzate per aumentare abusivamente i propri privilegi, a quelle per spostarsi lateralmente, concludendo infine con le tecniche di compromissione volte a stabilire la persistenza.
Implementando tali principi, i sistemisti e gli analisti InfoSec in forza alle organizzazioni potranno migliorare significativamente la sicurezza informatica di Active Directory e, di conseguenza, la Cyber Security Posture dell’intera rete.
Indice degli argomenti
L’importanza strategica di Active Directory
Ricordiamo che Microsoft Active Directory è uno dei sistemi di autenticazione e autorizzazione più utilizzati nelle reti IT (Information Technology) aziendali a livello globale: fornisce molteplici servizi, tra cui Active Directory Domain Services (AD DS), Active Directory Federation Services (AD FS) e Active Directory Certificate Services (AD CS).
Questi servizi offrono molteplici opzioni di autenticazione, tra cui gli accessi attraverso servizi on-premise, gli accessi a sistemi in cloud, nonché l’accesso tramite smart card.
Il ruolo fondamentale di Active Directory nell’autenticazione e nel processo di autorizzazione lo rendono un bersaglio prezioso agli occhi degli attacker: viene infatti regolarmente preso di mira negli attacchi alle reti informatiche strutturate.
Un dominio Active Directory è passibile di compromissioni a causa delle sue impostazioni predefinite (decisamente permissive), delle sue relazioni complesse e delle autorizzazioni, a causa del supporto predefinito a protocolli legacy, e dulcis in fundo, a causa della carenza di strumenti di diagnostica dei problemi di sicurezza informatica dell’infrastruttura AD nel suo complesso: questi problemi noti vengono comunemente sfruttati dagli attacker per compromettere le funzionalità di Active Directory.
In particolare, la predisposizione di Active Directory alla compromissione in parte è dovuta al fatto che ogni utente nel dominio o nella foresta dispone di autorizzazioni sufficienti per consentirgli sia di identificare che di sfruttare le vulnerabilità a livello di protocollo, di configurazioni e di algoritmi in uso.
Queste autorizzazioni di default rendono la superficie di attacco di Active Directory eccezionalmente ampia e difficile da difendere. Un altro fattore che contribuisce alla sua estrema vulnerabilità è la complessità e l’opacità delle relazioni che esistono all’interno di Active Directory tra i diversi utenti e sistemi.
Sono spesso queste relazioni nascoste – che spesse volte vengono trascurate dai sysadmin delle organizzazioni – che gli attacker sfruttano (a volte anche in modi banali) per ottenere il controllo completo sulla rete IT aziendale.
Le criticità di un attacco ad Active Directory
Espugnare Active Directory fornisce agli attacker un accesso privilegiato a tutti i sistemi e gli utenti gestiti attraverso il dominio LDAP. Sfruttando questo accesso privilegiato, gli attacker possono aggirare altri controlli e accedere ai sistemi, inclusi i mailserver, i file e le applicazioni aziendali critiche a loro discrezione.
Questo accesso privilegiato spesso viene esteso a sistemi e servizi basati su cloud tramite la funzionalità di Identità e Accesso basata su cloud computing di Microsoft, ovvero Entra ID (una funzionalità a pagamento): questo consente agli utenti di accedere ai sistemi e ai servizi basati su cloud, tuttavia, può anche essere sfruttato dagli attacker per mantenere ed espandere i loro accessi abusivi.
Vantaggi criminali di ottenere il controllo di Active Directory
Ottenere il controllo di Active Directory può consentire agli attacker motivati di ottenere l’accesso di cui hanno necessità per raggiungere i propri obiettivi malevoli nella rete interna della vittima.
Active Directory può essere quindi utilizzato in modo improprio dagli attacker per stabilire la persistenza nelle organizzazioni colpite. Alcune tecniche di persistenza permettono agli attacker di accedere alle organizzazioni da remoto, persino aggirando i controlli di autenticazione a più fattori (MFA).
Molte di queste tecniche di persistenza sono altresì resistenti alle attività di Incident Response (d’ora in avanti IR negli articoli, riferendomi alle fasi di risposta agli incidenti di sicurezza informatica) volte a individuare e bloccare gli attacker.
Inoltre, se i principi elencati e discussi in questa guida non vengono messi in atto, c’è il rischio che gli attacker più abili tecnicamente possano persistere per mesi o addirittura anni all’interno della stessa infrastruttura Active Directory senza essere scoperti.
Le criticità nel rispondere a un attacco ad Active Directory
L’individuazione e la conseguente bonifica degli attacker più insidiosi può richiedere un’azione drastica, che va dal ripristino delle password di tutti gli utenti alla ricostruzione dell’albero stesso di Active Directory.
Rispondere tecnicamente, ripristinare i dati compromessi e ripartire da attività dannose che hanno coinvolto la compromissione di Active Directory è dispendioso sia in termini di tempo che di denaro.
Pertanto, le organizzazioni sono invitate a implementare le esortazioni contenute in questa guida – dedicata decisamente più ai sysadmin sul campo – per investire in termini di cybersecurity strategica, e quindi per strutturare in maniera sistematica un ecosistema Active Directory da rendere resiliente agli attacchi.
Cos’è l’Authentication Server Response Roasting
L’Authentication Server Response Roasting è una delle 17 tecniche di hacking abitualmente adottate da chi si occupa di penetration testing infrastrutturale (cyber gang comprese) al fine di compromettere un tipico dominio Active Directory.
AS-REP Roasting sfrutta gli oggetti utente di Active Directory che sono stati configurati per non richiedere la pre-autenticazione Kerberos.
Similmente alla tecnica Kerberoasting, qualsiasi oggetto utente nel dominio, inclusi gli oggetti utente senza privilegi, può inviare una richiesta di autenticazione al server (AS-REQ) per recuperare il ticket AS-REP per qualsiasi altro oggetto utente configurato per non richiedere la pre-autenticazione Kerberos.
Il ticket AS-REP è crittografato con l’hash della password dell’oggetto utente, che può essere violato per rivelare la password in chiaro. Se l’attacker dovesse riuscire a violare il ticket AS-REP ottenendo la password in chiaro, potrà autenticarsi come oggetto utente.
L’attacco Authentication Server Response Roasting può essere eseguito da attori malintenzionati subito dopo aver ottenuto l’accesso iniziale a un dominio Active Directory al fine di aumentare i propri privilegi e muoversi lateralmente nel sistema.
Tecniche di mitigazione della minaccia
Un attacker ha meno opportunità di eseguire l’Authentication Server Response Roasting rispetto a Kerberoasting, poiché in AD DS per impostazione predefinita gli oggetti utente sono configurati per richiedere la pre-autenticazione Kerberos, e un attacco AS-REP Roasting è fattibile solo se gli oggetti utente sono stati configurati per non richiederla.
Il protocollo di autenticazione Kerberos è il principale protocollo di autenticazione utilizzato da Active Directory: la configurazione per non richiedere la pre-autenticazione Kerberos esiste solo per supportare sistemi che non supportano Kerberos, che sono in genere considerati IT legacy e meno diffusi.
Se, tuttavia, nella tua organizzazione hai applicazioni o sistemi che utilizzano una versione Kerberos inferiore alla versione 5, è possibile configurare oggetti utente per non richiedere la pre-autenticazione Kerberos, preparando l’ambiente ad essere vulnerabile ad Authentication Server Response Roasting.
Per scongiurare un attacco AS-REP Roasting è opportuno assicurarsi che gli oggetti utente richiedano la pre-autenticazione Kerberos.
Authentication Server Response Roasting viene mitigato se tutti gli oggetti utente richiedono pre-autenticazione Kerberos, tuttavia, se gli oggetti utente devono essere configurati per bypassare la pre-autenticazione Kerberos, allora a questi oggetti utente dovrebbe essere concesso il set minimo di privilegi richiesti per svolgere le loro funzioni, e non dovrebbero essere membri di gruppi di sicurezza altamente privilegiati, come gli amministratori di dominio.
Inoltre, impostare una password minima di 30 caratteri per gli account di servizio o una password minima di 15 caratteri per i normali utenti assicurandosi che la password sia univoca e complessa.
Authentication Server Response Roasting: event ID coinvolti
Se le applicazioni o i sistemi operativi nel tuo datacenter utilizzano una versione di Kerberos precedente alla versione 5, AS-REP Roasting si confonderà con le attività legittime di Active Directory, inclusa l’attivazione degli stessi eventi, e sarà difficile da rilevare.
Authentication Server Response Roasting in genere comporta il recupero simultaneo dei ticket TGT per tutti gli utenti configurati per bypassare la pre-autenticazione Kerberos.
Pertanto, un metodo per rilevare AS-REP Roasting (simile a un metodo per rilevare Kerberoasting) è analizzare gli eventi di richiesta TGT (ID evento 4768) e identificare le istanze in cui le richieste di ticket TGT vengono effettuate per più oggetti utente con la pre-autenticazione Kerberos disabilitata entro un breve lasso di tempo.
Gli eventi elencati nella seguente tabella dovrebbero essere tracciati centralmente attraverso un sistema di Log Management e correlati da uno o più SIEM,nonché analizzati tempestivamente dagli analisti InfoSec.
| Event ID | Sorgente | Descrizione |
| 4625 | Domain Controller | Questo evento viene generato quando un account non riesce ad accedere. AS-REP Roasting può essere eseguito prima dell’autenticazione, il che significa che gli attacker devono solo essere connessi al dominio senza aver bisogno di un oggetto utente valido. Il ticket AS-REP viene comunque recuperato, ma verrà generato l’evento 4625 poiché non sono state fornite credenziali valide al momento della richiesta del ticket. Se AS-REP Roasting viene eseguito nel contesto di un oggetto utente valido, il ticket AS-REP viene recuperato, vengono fornite credenziali valide e l’evento 4625 non viene generato. L’evento 4625 può essere correlato all’evento 4768 per confermare se AS-REP Roasting è stato eseguito nel contesto di un oggetto utente di dominio valido. |
| 4738, 5136 | Domain Controller | Questi eventi vengono tracciati quando un account utente viene modificato. Gli attacker possono modificare gli oggetti utente e configurarli in modo che non richiedano la pre-autenticazione Kerberos come tecnica per recuperare il loro ticket AS-REP. Una volta recuperato il ticket di servizio del ticket AS-REP, l’oggetto utente viene modificato di nuovo per richiedere la pre-autenticazione Kerberos. Se questi eventi vengono generati a causa di modifiche alla pre-autenticazione Kerberos, potrebbe indicare che si è verificato un Roasting AS-REP. |
| 4768 | Domain Controller | Questo evento viene generato quando viene richiesto un TGT. Gli attacker che eseguono AS-REP Roasting attivano questo evento poiché il messaggio AS-REP restituito da un Domain Controller contiene un TGT. Se questo evento viene attivato più volte in un breve lasso di tempo, potrebbe indicare che si è verificato un AS-REP Roasting. Gli attacker in genere cercano di recuperare i ticket TGT cifrati con RC4 (Rivest Cipher 4) poiché tali ticket sono più facili da decifrare. Se viene richiesto un TGT con crittografia RC4, il tipo di crittografia del ticket conterrà il valore “0x17” per l’evento 4769. Poiché questo tipo di crittografia è utilizzato meno frequentemente, dovrebbero esserci meno istanze dell’evento 4769, rendendo più facile identificare un potenziale AS-REP Roasting. |
Infine, un’altra tecnica utile per rilevare tempestivamente questo attacco consiste nell’avvalersi di Active Directory canary, che tratterò prossimamente poiché fondamentale come controffensiva anche per altri attacchi.
