Vista a 10.000 metri:
Molti di noi conoscono la varietà di strumenti, attacchi e avversari che si concentrano sulla violazione di Active Directory. Con il rilascio nel 2018 di DCShadow, un altro vettore altamente efficace si è aggiunto a questo elenco in continua crescita. A merito del team di ricerca, insieme all'exploit, è stato discusso come comprendere e potenzialmente mitigare l'attacco con un maggiore monitoraggio e gestione di Active Directory. Tuttavia, come per molti attacchi, non si tratta solo di capire COME si è stati colpiti... ma da dove. È qui che il team di ricerca di Semperis ha concentrato gli sforzi recenti. Ora siamo in grado di fornire un quadro molto più accurato del panorama aziendale e di identificare con chiarezza e precisione i computer lato client che hanno utilizzato o stanno utilizzando lo strumento di attacco contro l'Active Directory dell'organizzazione.
Contesto:
Mimikatz, lo strumento di sfruttamento delle credenziali, offre una funzione chiamata "DCShadow". Si può pensare che DCShadow faccia l'opposto del comando DCSync. Mentre DCSync può costringere Active Directory (AD) a sincronizzare gli account utente e i relativi hash delle password a un utente malintenzionato, DCShadow consente a un aggressore di iniettare modifiche in AD. Lo fa simulando il comportamento di un controller di dominio, che è essenzialmente un qualsiasi computer compromesso all'interno di un dominio Active Directory. Vale la pena notare che DCShadow è uno strumento di persistenza del dominio. Richiede che l'attaccante abbia già un accesso Domain Admin, o equivalente, su un dominio AD prima di poterlo utilizzare. Tuttavia, una volta ottenuto tale livello di accesso, si tratta di uno strumento potente e silenzioso per la creazione e l'aggiornamento di oggetti in AD allo scopo di creare backdoor, elevare l'accesso agli account regolari e stabilire in altro modo un punto d'appoggio ed eseguire il controllo all'interno dell'ambiente preso di mira.
Rilevabilità
La parte difficile di DCShadow è che, poiché aggira i normali meccanismi di verifica delle modifiche apportate all'AD (ad esempio, normalmente tramite il registro degli eventi di sicurezza di Windows sui controller di dominio), non è possibile rilevare facilmente quando viene utilizzato. Inoltre, se l'aggressore esegue modifiche furtive che non vengono cercate (ad esempio, iniettando il SID di Enterprise Admins nell'attributo sidHistory di un utente altrimenti non privilegiato), può essere molto difficile rilevare queste backdoor. È possibile vedere delle briciole di pane che possono indicare il suo utilizzo: ad esempio, quando DCShadow viene eseguito, un oggetto di classe server viene temporaneamente aggiunto al contesto di denominazione della configurazione in una determinata foresta, per far sì che gli altri controller di dominio pensino che il server falso sia un vero DC. Ma questo oggetto viene rapidamente rimosso quando DCShadow termina la sua esecuzione. Fortunatamente per il difensore, si scopre che DCShadow lascia alcune impronte digitali quando viene eseguito su un host.
Scoprire l'uso di DCShadow
Innanzitutto, un po' di background. Un controller di dominio "normale" registra una serie di Service Principal Name (SPN) Kerberos quando viene promosso a DC. Uno di questi è un SPN basato su GUID, come mostrato qui:
Questo SPN basato su GUID ha una caratteristica interessante. Se lo osserviamo da vicino, vediamo che in realtà ci sono due GUID nell'SPN. Il primo, cioè E3514235-4B06-11D1-AB
04-00C04FC2DCD2, è noto come Well-Known GUID (WKGUID) ed è registrato da ogni controller di dominio in ogni foresta AD allo stesso modo. Il secondo GUID, nel nostro esempio: 8b699bb0-d35e-4199-8dd4-6a296c5fc7db, è unico per un particolare DC.
[semperis-mid-scroll-cta]
In che modo questo ci aiuta nel rilevamento di DCShadow? È emerso che quando DCShadow viene eseguito su un determinato host, aggiunge un paio di SPN al computer per far credere agli altri DC che si tratti di un DC. Uno di questi è l'SPN basato su WKGUID. Sfortunatamente, ciò che non fa è ripulire se stesso al termine dell'esecuzione (per fortuna, un DCShadow disordinato). Il risultato è che ogni host che ha eseguito DCShadow continua a memorizzare l'SPN WKGUID nell'attributo servicePrincipalName del suo account macchina.
Un esempio di ciò si può vedere nella seconda schermata qui sotto. In questo esempio, abbiamo eseguito DCShadow ripetutamente da questo host; notate quanti SPN WKGUID compaiono nell'elenco:
La buona notizia è che possiamo usare queste informazioni per distinguere gli host in AD che hanno eseguito DCShadow. Innanzitutto, sappiamo che solo i DC *legittimi* dovrebbero avere questo SPN WKGUID sul loro account macchina. Questo è abbastanza facile da cercare, ma possiamo restringere ulteriormente la ricerca cercando anche un altro SPN che sappiamo NON DEVE essere presente su nessun computer che non sia un DC legittimo. Il risultato ottenuto è la seguente query LDAP:
"(&(objectClass=computer)(servicePrincipalName=E3514235-4B06-11D1-AB04-00C04FC2DCD2*)(!(servicePrincipalName=ldap*)))"
Questa query cerca tutti gli oggetti computer il cui attributo SPN contiene l'SPN WKGUID (qui si usa un carattere jolly per escludere la parte GUID univoca di tale SPN) e non include l'SPN LDAP, che ogni DC legittimo contiene.
In linea con la natura furtiva di DCShadow, l'aggiunta di questo SPN WKGUID all'account macchina del falso DC non viene registrata nel registro degli eventi di sicurezza del DC reale che riceve la richiesta di replica dal falso DC.
Sintesi
Supponendo che DCShadow non si "ripulisca" in tempi brevi, questo rilevamento ci consente di raggiungere rapidamente i computer utilizzati per ospitare le iniezioni di DCShadow, di metterli in quarantena in modo appropriato e di eseguire processi forensi e IR completi PRIMA che possano causare ulteriori danni.
Dimostrazione dell'attacco DCShadow
DCShadow sfrutta un interruttore nell'utilità Mimikatz che consente agli utenti privilegiati di iniettare modifiche dannose in Active Directory senza essere rilevati. Guardate questo video di presentazione per scoprire come individuare i controller di dominio non autorizzati, annullare rapidamente le modifiche indesiderate e ripristinare la visibilità del SIEM. Per qualsiasi domanda, non esitate a contattare i tecnici di Semperis.
