Attacco ad Active Directory: cos’è, come funziona, come mitigare il Kerberoasting

Uno degli attacchi più diffusi alle reti informatiche strutturate basate su domini Active Directory è il Kerberoasting. E il perché è presto detto.

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.

Questa guida è la prima di una serie il cui obiettivo è informare le organizzazioni sulle 17 tecniche di hacking utilizzate abitualmente da chi si occupa di penetration testing infrastrutturale (cyber gang comprese) in ambito Microsoft per compromettere un tipico dominio Active Directory: attraverso questa serie di articoli cercherò di fornire una panoramica di ciascuna tecnica, come venga sfruttata da utenti malintenzionati o attacker.

Infine, per ciascuna tecnica indicherò delle strategie di difesa utili per mitigare o impedire a monte la minaccia attraverso l’hardening stesso di Active Directory.

Implementando i principi contenuti nei presenti articoli, le organizzazioni potranno migliorare significativamente la sicurezza informatica di Active Directory e, di conseguenza, la Cyber Security Posture di una rete Microsoft.

Perché i domini Active Directory sono bersagli preziosi

Un dominio Active Directory è suscettibile di compromissione 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 vulnerabilità è la complessità e l’opacità delle relazioni che esistono all’interno di Active Directory tra 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.

Un accesso privilegiato a tutti i sistemi

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.

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.

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 cyber security strategica, e quindi per strutturare in maniera sistematica un ecosistema Active Directory da rendere resiliente agli attacchi.

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 scalare 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.

L’attacco Kerberoasting: cos’è e come funziona

Iniziamo conuna premessa: la tecnica di attacco Kerberoasting mira a compromettere Kerberos, il protocollo (nonché servizio) di autenticazione distribuita in rete usato da Active Directory.

Kerberoasting imita le normali funzionalità del servizio Kerberos ed è sfruttabile in qualunque ambiente Active Directory che si avvalga di oggetti utente configurati con un SPN (un nome univoco assegnato a un servizio in Active Directory che permette ai client di identificare e autenticare quel determinato servizio).

Se un oggetto utente è configurato con un SPN, qualsiasi altro oggetto utente – inclusi gli utenti senza privilegi – può richiedere il suo ticket TGS (Ticket Granting Service, che si occupa di fare da “ponte crittografico” e rilascia messaggi corredati di timestamp chiamati TGT, ossia ticket-granting ticket) ad un Domain Controller (questa funzionalità è progettata per consentire agli oggetti utente di interagire con i servizi).

Il ticket TGS è cifrato con l’hash della password dell’oggetto utente, che in base all’algoritmo utilizzato può essere violato per recuperare la password in chiaro: se l’attacker riesce a violare il ticket TGS e ad ottenere la password in chiaro facendo reversing (reversing di un hash? Sì e non è fantascienza, ma crittoanalisi), potrà autenticarsi come oggetto utente (vedi Figura 1).

La tecnica Kerberoasting può essere eseguita dall’attacker subito dopo aver ottenuto un accesso iniziale (in che modo? Ad esempio, sfruttando exploit RCE, oppure del phishing o sfruttando gli altri vettori di attacco elencati nella matrice MITRE ATT&CK) a un dominio Active Directory per tentare di aumentare i propri privilegi e spostarsi lateralmente.

I tipi di oggetti utente configurati con SPN sono comunemente denominati account di servizio: si tratta di “oggetti utente” che eseguono servizi su “oggetti computer” e possono avere privilegi amministrativi. Se uno di questi account di servizio venisse compromesso tramite Kerberoasting, potrebbe fornire privilegi e accessi aggiuntivi di cui l’attacker potrà beneficiare per compromettere in profondità Active Directory.

In alcuni casi, gli account di servizio possono far parte di gruppi AD di sicurezza altamente privilegiati, come il gruppo di sicurezza Domain Admins, che fornisce accessi amministrativi a tutti gli oggetti utente e computer, nonché ad altri oggetti in Active Directory.

La compromissione di un account di servizio nel gruppo di sicurezza Domain Admins o in un altro gruppo di sicurezza altamente privilegiato, spesso consente la compromissione completa del dominio attaccato.

Figura 1: workflow ad alto livello della tecnica di hacking denominata Kerberoasting.

Per sfruttare Kerberoasting un attacker o un penetration tester può avvalersi di svariati software gratuiti (come Mimikatz, Rubeus e Impacket ad esempio), ma potrebbe anche sfruttare nativamente dei comandi PowerShell con appositi script (vedi PowerView e Invoke-Kerberoast, ad esempio).

Figura 2: Rubeus in azione da una postazione Windows nel laboratorio con i miei studenti.

Tecniche di mitigazione della minaccia

Ecco, quindi, le attività di mitigazione della tecnica di attacco Kerberoasting.

1. Ridurre la superficie di attacco minimizzando il numero di oggetti utente configurati con gli SPN.
2. Creare oggetti utente con SPN come gruppo di account di servizio gestiti (gMSA). I gMSA hanno di default la rotazione automatica delle password, una password lunga 120 caratteri e gestione semplificata degli SPN: queste funzionalità di sicurezza informatica aumentano il layer di protezione delle password, riducendo la probabilità che Kerberoasting abbia successo. Tuttavia, se la creazione di oggetti utente con SPN come gMSA non è fattibile nell’organizzazione presa in esame, ad esempio, se trattasi di un sistema che non è basato su Windows ad ospitare il servizio oppure, se trattasi di un’applicazione che non supporti completamente i gMSA (come, ad esempio, System Center Configuration Manager di Microsoft) è opportuno impostare una password di almeno 30 caratteri che sia univoca, complessa e gestita in maniera accurata.
3. Assegnare agli oggetti utente dotati di SPN solo e soltanto i privilegi minimi che risultano necessari per poter svolgere le loro attività, assicurandosi che non siano membri di gruppi di sicurezza con privilegi elevati, come il gruppo Domain Admins. Se gli attacker dovessero riuscire ad attuare Kerberoasting violando il ticket TGS (ottenendo quindi la password in chiaro), riducendo preventivamente i privilegi assegnati agli oggetti utente si circoscrive l’impatto limitandone appunto l’accesso fraudolento.

Tecniche di rilevamento di un attacco Kerberoasting

Diversamente da quanto raccontano molti (troppi superficiali) analisti InfoSec, accorgersi di un attacco Kerberoasting in corso può essere complicato, poiché questa tecnica si confonde con le attività legittime di Active Directory: gli oggetti utente richiedono un ticket TGS quando accedono ai servizi nel dominio, e gli eventi generati da questa attività legittima sono analoghi agli eventi generati da Kerberoasting.

Questo scenario rende possibile che i sintomi di un attacco Kerberoasting si confondano tra i numerosi altri eventi Active Directory legittimi tracciati da un SIEM.

Un metodo per rilevare Kerberoasting è analizzare gli eventi di richieste TGS (Event ID 4769 nell’Event Viewer di Windows) identificando le istanze in cui vengono effettuate (in un lasso di tempo breve) richieste TGS per più oggetti utente configurati con SPN.

Kerberoasting, in genere, si avvale del recupero contemporaneo di ticket TGS per tutti gli oggetti utente con SPN: la presenza di eventi di richiesta ticket TGS (Event ID 4769) per numerosi oggetti utente con SPN in un lasso di tempo molto contenuto può appunto costituire il segnale che qualcuno stia sfruttando attivamente questa tecnica.

Un’altra spia rivelatrice di Kerberoasting è possibile notarla dall’analisi delle richieste TGS insolite per i servizi: si potrebbero scoprire richieste TGS per servizi a cui in genere non accedono né l’utente né la postazione richiedente, come un server di backup a cui solitamente accedono solo altri server.

Infine, un’altra tecnica utile per rilevare Kerberoasting consiste nell’avvalersi di Active Directory canary, che tratterò prossimamente poiché fondamentale come controffensiva anche per altri attacchi.

Event ID coinvolti

Gli eventi elencati nella seguente tabella dovrebbero essere tracciati centralmente (attraverso un sistema di Log Management e/o uno o più SIEM) nonché analizzati tempestivamente dagli analisti.