optiv/dentUn framework per creare bypass basati su COM sfruttando vulnerabilità nei sensori WDAPT di Microsoft.
Per visualizzare l'ultima versione di Dent o per inviare un problema, fare riferimento a https://github.com/Tylous/Dent.
Dent
Se vuoi saperne di più sulle tecniche utilizzate in questo framework, dai un'occhiata a questo articolo.
Questo framework genera codice per sfruttare le vulnerabilità nelle regole di Attack Surface Reduction (ASR) di Microsoft Defender Advanced Threat Protection per eseguire shellcode senza essere rilevati o bloccati. ASR è stato progettato per essere la prima linea di difesa, rilevando eventi basati su azioni che violano un insieme di regole. Queste regole si concentrano su indicatori comportamentali specifici sull'endpoint che sono spesso associati alle tattiche, tecniche o procedure (TTP) di un aggressore. Queste regole hanno un forte focus sulla suite Microsoft Office, poiché questo è un vettore di attacco comune per stabilire un punto d'appoggio remoto su un endpoint. Molti dei controlli basati su regole si concentrano su indicatori comportamentali di rete o di processo che si distinguono dalle normali operazioni aziendali. Queste regole si concentrano o sul compromesso iniziale di un sistema o su una tecnica che può avere un impatto grave su un'organizzazione (ad esempio, divulgazione di credenziali o ransomware). Coprono gran parte della superficie di attacco comune e si concentrano sull'ostacolare tecniche note utilizzate per compromettere risorse.
Dent sfrutta diverse vulnerabilità per bypassare questi controlli restrittivi ed eseguire payload su un endpoint senza essere bloccato o efficacemente rilevato dai sensori di Microsoft Defender Advanced Threat Protection. L'articolo sopra descrive queste vulnerabilità che sono ANCORA presenti in Microsoft Defender Advanced Threat Protection anche dopo la divulgazione.
Il primo passo, come sempre, è clonare il repository, poi compilarlo
go build Dent.go
./Dent -h
________ __
\______ \ ____ _____/ |_
| | \_/ __ \ / \ __\
| | \ ___/| | \ |
/_______ /\___ >___| /__|
\/ \/ \/
(@Tyl0us)
"Call someone a hero long enough, and they'll believe it. They'll become it.
They have no choice. Let them call you a monster, and you become a monster."
Usage of ./Dent:
-C string
Name of the COM object.
-N string
Name of the XLL playload when it's writen to disk.
-O string
Name of the output file. (default "output.txt")
-P string
Path of the DLL for your COM object. (Either use \\ or '' around the path)
-U string
URL where the base64 encoded XLL payload is hosted.
-show
Display the script in the terminal.
Questo framework è destinato a sfruttare vulnerabilità e carenze in Microsoft Defender Advanced Threat Protection, per questo motivo non genera effettivamente alcun payload/impianto. Per generarli, puoi utilizzare un gran numero di strumenti pubblicamente disponibili, tuttavia tutta la ricerca, lo sviluppo e i test sono stati condotti utilizzando ScareCrow. Microsoft Defender Advanced Threat Protection non si basa sull'hooking in spazio utente per la telemetria, ma piuttosto utilizza vari altri meccanismi come i callback del kernel. Dai test, questo framework funziona estremamente bene per bypassare Microsoft Defender Advanced Threat Protection ed eseguire shellcode.
Al momento del rilascio, ci sono attualmente due tecniche. Aggiungerò costantemente diverse varianti che sfruttano queste vulnerabilità in modi diversi periodicamente, quindi rimanete sintonizzati per ulteriori.
Gli oggetti COM vengono spesso creati quando un'applicazione viene installata su un sistema. Una volta creati, qualsiasi applicazione o script può chiamarli, tuttavia questo non è l'unico modo per crearli. Modificando/creando chiavi di registro nella sezione HKEY_CLASSES_ROOT del Registro di Windows, possiamo creare un oggetto COM che punta al nostro shellcode sul sistema. Ciò significa che qualsiasi applicazione o script in grado di utilizzare COM può chiamarlo, eseguendo lo shellcode.
Questo funziona grazie al funzionamento dell'API CoCreatInstance. CoCreateInstance viene utilizzata per creare e inizializzare oggetti COM basati sul CLSID (un identificatore univoco globale utilizzato per identificare una specifica classe di oggetti COM). Questa funzione recupera le informazioni per eseguire la chiamata utilizzando i valori memorizzati nelle chiavi di registro. Questi valori CLSID possono essere trovati nel percorso HKEY_CLASSES_ROOT\CLSID\ del registro. Tuttavia, prima che un processo possa chiamare il CLSID, deve conoscere il valore di quel CLSID. Questo viene fatto eseguendo prima una query di registro per cercare l'oggetto COM in HKEY_CLASSES_ROOT\<nome oggetto COM>, e se esiste, viene eseguita una seconda query di registro per ottenere il valore CLSID memorizzato nella sottocartella.
Un ulteriore esame delle sottocartelle del registro mostra che le autorizzazioni per i valori CLSID non sono coerenti. La grande maggioranza degli oggetti COM memorizzati qui consente solo l'autorizzazione “Controllo completo” a Trusted Installer. Trusted Installer è un account di servizio che possiede le risorse per proteggerle, anche dagli amministratori. Questo ha lo scopo di garantire che anche se un attaccante ottiene privilegi amministrativi, le risorse non possano essere manipolate malevolmente. Sfortunatamente, molti oggetti COM consentono a chiunque nei gruppi Administrators l'autorizzazione “Controllo completo”. Inoltre, la chiave radice CLSID consente al gruppo Administrators le autorizzazioni “Controllo completo” anziché NT AUTHORITY\System o Trusted Installer. Per questo motivo, in un contesto elevato possiamo creare, o persino modificare, valori specifici di oggetti COM.
Importante
La creazione di queste chiavi di registro funziona solo se si esegue in un contesto elevato. Fare doppio clic su questo tramite una GUI non eseguirà il file .VBS in un contesto elevato anche se si è amministratori. Si consiglia di eseguirlo da un prompt dei comandi o shell amministrativa. Tuttavia, una volta create le chiavi, qualsiasi applicazione può chiamare questo oggetto COM in qualsiasi contesto.
Per utilizzare un payload di ScareCrow con questo tipo di bypass puoi eseguire il seguente comando:
./ScareCrow -I <path to your raw stageless shellcode> -domain <domain name> -Loader dll
Una volta che hai il tuo payload, usa il flag -N per il nome del payload quando viene scritto su disco, il flag -C per il nome dell'oggetto COM, il flag -I per la posizione in cui scriverlo, e infine il flag -O per il file di output in cui memorizzare il contenuto.
Questa opzione genera un blocco di codice per bypassare diverse regole ASR per scaricare, scrivere su disco, caricare ed eseguire shellcode, aggirando i controlli preventivi di ASR. Questo viene fatto utilizzando l'oggetto COM Excel.Application che rappresenta l'intera applicazione Excel, ma in forma automatizzata, e consente l'interazione programmatica con essa. Poiché si tratta ancora di Excel, non attiva la regola ASR. Questo perché quando chiamiamo Excel.Application, possiamo vedere che viene generato sotto un processo Service Host (Svchost.exe) e non il processo WinWord.exe. Mentre Svchost.exe è un processo a livello di sistema utilizzato per ospitare più servizi Windows, il processo figlio creato (Excel.exe) non ha ottenuto privilegi a livello di sistema.
Poiché abbiamo creato un oggetto COM che era un'intera applicazione, il processo di Excel è stato creato sotto Svchost.exe in modo che potesse essere gestito correttamente per prevenire instabilità al processo WinWord.exe. Sebbene questo processo sia sotto Svchost.exe, c'è un'altra sfida da affrontare: l'esecuzione di shellcode. L'esecuzione binaria o l'uso di WinAPI all'interno di una macro attiverà altre regole ASR, limitando ciò che possiamo fare senza attivare una regola ASR o essere scoperti dal componente EDR di WDAPT. È qui che le DLL brillano. Se un payload basato su DLL viene compilato con le giuste funzioni di esportazione, può essere utilizzato come plugin di Office che, una volta caricato, eseguirà automaticamente lo shellcode. Per fare ciò, possiamo utilizzare la funzione RegisterXLL di Excel. La funzione RegisterXLL carica un plugin XLL in memoria, registrandolo automaticamente ed eseguendolo. I file XLL sono essenzialmente DLL basate su Excel.
Per ottenere il contenuto sul sistema, possiamo utilizzare un altro oggetto COM (Microsoft.XMLHTTP), ottenendo la capacità di eseguire una richiesta HTTP, in questo caso una richiesta HTTP GET verso un URL. Il secondo oggetto COM (ADODB.stream) fornisce la capacità di leggere/scrivere byte di un flusso di dati. Combinando i due oggetti COM, un attaccante può richiedere una risorsa remota tramite una richiesta HTTP GET e scrivere la risposta (in questo caso, il file stesso) su disco. Questo viene fatto utilizzando di nuovo l'oggetto COM (ADODB.stream) per gestire la lettura/scrittura di byte del flusso di dati. Il secondo oggetto COM (Microsoft.XMLDOM) consente la lettura dei dati memorizzati in un file. L'oggetto XMLDCOM permette di impostare il tipo di dato (in questo caso, base64) e una volta aperto e memorizzato in una stringa con il tipo di dato appropriato, l'oggetto ADODB.stream può scrivere la stringa di codice su disco utilizzando un tipo di dato diverso (in questo caso, BinaryStreamType), riconvertendo la stringa base64 in forma binaria.
Per utilizzare un payload di ScareCrow con questo tipo di bypass puoi eseguire il seguente comando:
./ScareCrow -I <path to your raw stageless shellcode> -domain <domain name> -Loader excel -O <Output filename>
Una volta generato, copia le righe 13 e 14 dal file prodotto e uniscile insieme, assicurandoti di rimuovere:
var <nome variabile>; alla fine di ogni riga
Una volta che hai il tuo payload codificato, usa il flag -N per il nome del payload quando viene scritto su disco, il flag -U per l'URL su cui il payload codificato sarà ospitato (ad esempio https:///), e il flag -F per il nome del file ospitato dal sito. Il codice prodotto è progettato per funzionare in un documento macro .
Attraverso ulteriori indagini, è stato osservato non come una lacuna nei sensori di WDATP, ma piuttosto che WDATP ha visibilità su questa attività, ma viene ignorata. Attraverso la cronologia degli eventi dell'endpoint di WDATP cercando qualsiasi riferimento a Appwiz.xll, abbiamo osservato che WDAPT ha registrato un evento “file creato” quando Word ha creato il file AppWiz.xll. È importante notare che i file .XLL sono eseguibili.
20/11/2020 - Sviluppo della ricerca e articolo scritto.
14/03/2021 - Fornito a Microsoft un documento di divulgazione preliminare che delineava i problemi identificati.
31/03/2021 - Microsoft ha riconosciuto e ammesso che le vulnerabilità relative alla creazione di un processo figlio di Office e alla scrittura di file su disco erano vulnerabilità reali e ha iniziato a lavorare alla correzione. Tuttavia, le incongruenze delle autorizzazioni nel registro non sono state considerate una vulnerabilità a causa del requisito di privilegi elevati.
21/04/2021 - Microsoft ha informato l'autore che la build della signature 1.333.1055.0 rilasciata il 22/03/2021 e la 1.335.1321.0 rilasciata il 21/04/2021 contenevano il rilevamento per le vulnerabilità basate sull'applicazione Office e ha chiuso il caso.
22/04/2021 - L'autore ha ritestato le stesse tecniche identificando che le vulnerabilità erano ancora presenti.