• Guide, Sicurezza, Sistemi Operativi
• 8 Maggio 2024

Disclaimer: Gli strumenti e le tecniche descritte in questo articolo sono destinati esclusivamente a scopi educativi e di ricerca nel campo della sicurezza informatica. L’uso di tali strumenti e tecniche contro sistemi informatici senza il consenso esplicito del proprietario è illegale e può comportare gravi conseguenze legali. L’autore e gli editori declinano qualsiasi responsabilità per l’abuso o l’uso improprio di queste informazioni da parte degli utenti. Si consiglia vivamente di ottenere il consenso scritto prima di condurre qualsiasi tipo di test o di valutazione della sicurezza su sistemi informatici.

Questo articolo è parte della serie AD-ventures: La battaglia per la sicurezza di Active Directory – ICT Power

Il 2023 è terminato da pochi mesi. Il passaggio del testimone al novello 2024 è avvenuto come da previsioni: continuando la partita in corso. I vari gruppi criminali continuano le loro attività e sempre più vittime nel mondo continuano a subire problematiche serie, spesso con conseguenze devastanti. Gli attacchi che si concludono con data exfiltration, ransomware, rivendita di dati/utenze continuano a farla da padrone. Nella maggioranza dei casi, il problema resta sempre lo stesso: scarsa consapevolezza, disattenzione.

Mi capita sempre più spesso ricevere domande sul funzionamento di determinati attacchi, su come sia possibile per qualcuno riuscire a penetrare tutta una serie di sistemi di sicurezza ed essere così efficace nell’acquisire informazioni riservate. Nonostante la tecnologia a disposizione alcuni temi vengono ancora raccontati a mo’ di film. Spiegare tutto ciò che viene immaginato, considerato, studiato durante un attacco non è affatto semplice e, spesso, le competenze necessarie sono talmente vaste da rendere il compito piuttosto arduo.

Per questo motivo iniziamo un percorso, una strada fatta di vari passi con l’obbiettivo di definire un attacco da portare a termine, qualcosa di concreto, un viaggio che inizia con la compromissione di un oggetto e termina con il massimo danno possibile. Sarà costituito da nove passi dove approfondiremo sia il punto di vista dell’attaccante che quello del difensore, arrivando alla fine con un po’ di consapevolezza in più.

Ogni giorno, miliardi di utenti si affidano ad Active Directory per svolgere le proprie attività quotidiane. Il principale compito di un Domain Controller consiste nel validare un utente: quando si vuole accedere ad un dispositivo o oggetto in AD vengono fornite delle credenziali. Queste, se presenti/corrette, vengono validate concedendo l’autorizzazione richiesta e permettendo, quindi, l’accesso alla risorsa desiderata. Tenendo a mente questo concetto e che i servizi Active Directory sono i più utilizzati a livello globale è facile capire perché per un attaccante sono quelli che fanno più gola nel caso in cui l’obbiettivo sia una compromissione, l’accesso a reti e dati, per la compromissione di utenze e tanto altro.

Un attacco strutturato è suddiviso in varie fasi. Queste sono definite in un modello denominato Kill Chain. A seconda dell’interlocutore o della tipologia di attacco alcune di queste possono variare: nello standard sono sette; per il MITRE sono quattordici, e così via.

Semplificando, ne possiamo definire cinque:

Reconnaissance – Queste attività consistono nell’identificare correttamente il bersaglio raccogliendo informazioni su di esso. Queste attività possono essere di due tipologie: passive utilizzando fonti pubbliche, social media, ecc… oppure attive effettuando attività di network e port scanning, firewall detection, analizzando i sistemi e le applicazioni disponibili.

Planning – In questa fase si determina il vettore d’attacco, ovvero le modalità più remunerative per riuscire ad eseguire un primo accesso. Ad esempio: sfruttare una vulnerabilità, utilizzare tecniche di phishing e/o altro.

Intrusion – A questo punto viene eseguito il vero e proprio accesso con il metodo identificato.

Lateral movement and privilege escalation – Una volta all’interno le azioni che vengono eseguite sono relative alla ricerca di ulteriori metodi per aumentare i propri privilegi, compromettere altri sistemi raggiungibili e ottenere una persistenza all’interno del sistema vittima al fine di mantenere un accesso valido.

Exfiltration and cleanup – Questa parte rappresenta la fine dell’attacco. A seconda degli obbiettivi prefissati vengono eseguite azioni come l’esfiltrazione di dati sensibili o la crittografia dei dati per bloccare il normale funzionamento dei sistemi e, eventualmente, dei tentativi di pulizia di quanto fatto in modo da rendere estremamente più complesso determinare quanto accaduto o, ancora, tentare dei futuri accessi.

Figura 1 – Kill Chain

Questo è solo un esempio di come un attacco può essere costruito. Proviamo ad approfondire il più possibile iniziando la definizione del nostro attacco, pianificando il raggiungimento di un obbiettivo, una strategia da applicare e la scelta delle tecniche necessarie per arrivare a meta.

Un classico obbiettivo è riuscire a violare un’utenza (almeno una) con privilegi di Domain Admin in modo da avere la possibilità di gestire completamente il dominio della nostra vittima.

Posto questo primo assunto, la strategia e le tecniche da utilizzare non possono essere sempre definite a priori. Per poter procedere correttamente è necessario ottenere il maggior numero di informazioni possibili, in modo da essere pronti. Le tecniche che affronteremo nel nostro viaggio sono le seguenti:

• Domain Enumeration
• LLMNR/NBT-NS Poisoning Attack
• Unquoted Service Path
• Kerberoasting
• Uncostrained Delegation
• Pass the Hash
• Golden Ticket / Diamond Ticket
• DCSYNC
• Certificate Theft

Oggi parleremo del primo passo del nostro viaggio, il punto di partenza per determinare la nostra strategia e capire come proseguire al fine di ottenere i massimi privilegi sul Domain Controller della nostra vittima.

Immaginiamo di aver ottenuto già un primo accesso, ad esempio, a seguito di una campagna di phishing. Ci troviamo, quindi, all’interno di una VM joinata ad un dominio.

Domain Enumeration

La fase di enumerazione è fondamentale per definire una corretta strategia: più informazioni si riescono ad ottenere, maggiori sono le probabilità di riuscire a costruire diversi percorsi d’attacco. In molti casi, le infrastrutture Active Directory sono complesse sia in termini di configurazione sia in termini di gestione della moltitudine di servizi e dispositivi connessi. L’immagine seguente presenta una visione semplicistica di quanto solitamente è presente in questo tipo di infrastrutture e che, dal punto di vista di un Blue Team, deve essere monitorato in quanto potenziale “paziente zero”, quindi un possibile punto di ingresso sfruttato da un attaccante.

Figura 2 – Esempio logico dominio Active Directory

A seguito di un accesso, la prima cosa che un attaccante tenta di fare è l’enumerazione del dominio raccogliendo informazioni su gruppi, utenti, configurazioni, policy e tanto altro relative ad Active Directory (AD).

Ci sono numerosissimi tool online che forniscono un grande aiuto in questa fase, quello che utilizzeremo in questo caso è PowerView.

Disponibile su Github e parte del progetto PowerSploit, è un tool PowerShell che, una volta importato, mette a disposizione una lunga serie di funzioni pronte per analizzare le varie configurazioni di un dominio AD.

Dopo aver effettuato il download, è necessario modificare l’execution policy di PowerShell per permettere il caricamento delle funzioni all’interno dello script PowerView.ps1.

Per vedere l’elenco delle nuove funzioni importate possiamo eseguire i seguenti comandi:

Figura 3 – Elenco funzioni PowerView.ps1

A questo punto possiamo iniziare con le attività di ricerca informazioni. Ad esempio, utilizziamo Get-Domain per le informazioni sul dominio.

Figura 4 – Cmdlet Get-Domain

Informazioni che possono essere approfondite con Get-NetDomainController

Figura 5 – Cmdlet Get-NetDomainController

Oppure possiamo cercare informazioni sulle policy

Figura 6 – Cmdlet Get-DomainPolicy

Qui, ad esempio, si evince come è configurata la password policy. Possiamo eventualmente visualizzare il singolo dettaglio con la sintassi (Get-DomainPolicy).systemaccess

Figura 7 – Cmdlet Get-DomainPolicy

Relativamente agli utenti possiamo utilizzare Get-NetUser

Figura 8 – Cmdlet Get-NetUser

Oppure possiamo verificare le relative proprietà di ogni utente

Con il comando Get-NetGroupMember è possibile verificare i membri di specifici gruppi, i cui nomi vanno passati come parametro

Figura 9 – Cmdlet Get-NetGroupMember

O, ancora, è possibile enumerare le GPO presenti nel dominio

Figura 10 – Cmdlet Get-DomainGPO

Possiamo anche eseguire delle ricerche, ad esempio possiamo eseguire il comando Invoke-ShareFinder per farci restituire la lista delle cartelle condivise

Figura 11 – Cmdlet Invoke-ShareFinder

Insomma, sono davvero tante le funzioni disponibili, dobbiamo solo armarci di calma e pazienza al fine di collezionare il maggior numero possibile di informazioni.

Domain Enumeration Detection

Il monitoraggio è cruciale per individuare attività sospette. Bisogna essere consapevoli di come gli utenti possono abusare di PowerShell. Una buona pratica è quella di identificare coloro che eseguono frequentemente script e comandi per capire se le attività che svolgono sono legittime o sospette. Un censimento degli utenti e dei loro privilegi può essere un buon punto di partenza.

Oltre all’utilizzo del registro eventi, come vedremo più avanti, è saggio affidarsi anche ad altre tecnologie per la raccolta e la correlazione di log.

Ad esempio, un SIEM (Security Information and Event Management) dovrebbe essere configurato per monitorare eventi ed allarmare nel caso si rilevino anomalie.

In termini di configurazioni lato Windows, le difese che possiamo ergere sono due:

• PowerShell Script Block Logging
• PowerShell Module Logging

PowerShell Script Block Logging

La prima configurazione è quella che ci permette di registrare ciò che viene eseguito con PowerShell e, per farlo, possiamo utilizzare una GPO:

Computer Configuration > Administrative Templates > Windows Components > Windows PowerShell > Turn on PowerShell Script Block Logging.

Figura 12 – GPO Turn on PowerShell Script Block Logging

Questa configurazione abilita il logging di qualsiasi input script PowerShell nell’event log Microsoft-Windows-PowerShell/Operational con EventID 4104.

Incrementando il livello di logging, però, potrebbe accadere che dati sensibili possano essere trascritti nei log: immaginiamo uno script che contiene informazioni per il logon su una macchina o una password in chiaro. Per evitare questo tipo di situazione è possibile abilitare il Protected Event Logging, introdotto da Windows 10, che consente di effettuare questa operazione con l’aiuto della crittografia.

La GPO è presente nell’albero Administrative Templates > Windows Components > Event Logging > Enable Protected Event Logging

Figura 13 – GPO Enable Protected Event Logging

Questa configurazione richiede un certificato che può essere fornito in vari modi:

• Un certificato X.509 codificato in base64 (nella console di gestione certificati la funzione di export si comporta proprio in questo modo);
• Il Thumbprint di un certificato disponibile nell’archivio locale dei certificati computer (e può essere distribuito dall’infrastruttura PKI);
• Il path di una directory contenente un certificato;
• Il path assoluto di un certificato;
• Il subject name di un certificato presente nel Local Machine Certificate store.

Infine, il certificato deve avere la proprietà Document Encryption e la Data Encipherment o Key Encipherment abilitate.

Nei computer che registrano gli eventi evitiamo di distribuire anche la chiave privata. Quest’ultima sarebbe opportuno custodirla in una posizione sicura per poi decifrare i messaggi.

PowerShell Module Logging

La registrazione dei moduli è un’impostazione analoga che consente di loggare gli eventi di esecuzione della pipeline per i membri dei moduli specificati. Ad esempio, specificando il modulo NetTCPIP è possibile loggare tutti gli eventi PowerShell che lo utilizzano. Per farlo possiamo utilizzare la seguente GPO:

Computer Configuration > Administrative Templates > Windows Components > Windows PowerShell > Turn on Module Logging

Figura 14 – GPO Turn on Module Logging

Dopo aver abilitato il criterio, è necessario specificare un modulo. Ad esempio NetTCPIP.

Figura 15 – GPO Module Names

Dopo aver applicato la GPO è possibile effettuare un rapido test eseguendo un comando PowerShell contenuto nel modulo in questione.

Ad esempio: Get-NetIPAddress

Il risultato sarà un evento con ID 800 come il seguente:

Figura 16 – Event Viewer

Per monitorare tutti i comandi PowerShell, invece, è sufficiente inserire un “*” al posto del nome del modulo.

Figura 17 – Module Names

Dopo aver effettuato queste configurazioni è necessario tenere a mente che la mole di log sarà grande per cui è interessante ed importante avere la possibilità di affinare quanto più possibile la ricerca di eventi di questo genere.

Conclusioni

Dopo aver completato la fase di enumerazione dobbiamo concentrarci sul raccogliere altre informazioni. Un approccio largamente utilizzato è quello di verificare la presenza di vulnerabilità causate da configurazioni abilitate di default e non controllate, magari concentrandoci sulle utenze. Parleremo di questo tema nel prossimo articolo.

Un attaccante ha molte strade perseguibili per ottenere informazioni utili ai suoi scopi. Spesso, come in questo caso, una leggerezza può essere sufficiente a permettere un problema molto più grande. Come sempre abbiamo a disposizione tanti strumenti per migliorare le nostre infrastrutture e prendercene cura. La consapevolezza deve essere il mantra del 2024, in modo da concentrare l’attenzione dove realmente è necessario.

Stay tuned!