Tattiche di Phishing XLL
Con il recente annuncio di Microsoft riguardo al blocco delle macro nei documenti provenienti da internet (email e download web), gli aggressori hanno iniziato ad esplorare aggressivamente altre opzioni per ottenere accesso guidato dall'utente (UDA). Ci sono diverse considerazioni da valutare e bilanciare quando si cerca un metodo di phishing valido per l'accesso:
Queste sono le domande principali, ma ce ne sono sicuramente altre. Le cose si complicano quando ci si rende conto che questi fattori si combinano tra loro; ad esempio, se un cliente ha un proxy web che vieta il download di eseguibili o DLL, potresti dover inserire il tuo payload all'interno di un contenitore (ZIP, ISO, ecc.). Fare ciò può presentare ulteriori problemi in seguito per quanto riguarda il rilevamento. Difese più robuste richiedono combinazioni più complesse di tecniche per essere superate.
Questo articolo sarà scritto pensando a un'organizzazione target fittizia; questa organizzazione ha adottato diverse misure difensive, tra cui regole di filtraggio delle email, blacklist di determinati tipi di file scaricabili, whitelist delle applicazioni sugli endpoint e Microsoft Defender for Endpoint come soluzione EDR.
Le organizzazioni reali potrebbero non adottare nessuna di queste, alcune o anche più difese, che possono semplificare o complicare le tecniche delineate in questa ricerca. Come sempre, conosci il tuo target.
Gli XLL sono DLL, specificamente create per Microsoft Excel. A un occhio inesperto sembrano molto simili ai normali documenti Excel.
Gli XLL offrono un'opzione molto interessante per l'UDA poiché vengono eseguiti da Microsoft Excel, un software molto comune nelle reti dei clienti; come vantaggio aggiuntivo, poiché sono eseguiti da Excel, il nostro payload bypasserà quasi certamente le regole di whitelist delle applicazioni perché un'applicazione attendibile (Excel) lo esegue. Gli XLL possono essere scritti in C, C++ o C#, il che offre molta più flessibilità e potenza (e sanità mentale) rispetto alle macro VBA, rendendoli una scelta desiderabile.
Lo svantaggio, ovviamente, è che ci sono pochissimi usi legittimi per gli XLL, quindi DOVREBBE essere una casella molto facile da spuntare per le organizzazioni per bloccare il download di quell'estensione di file sia via email che tramite download web. Purtroppo molte organizzazioni sono anni indietro e quindi gli XLL rappresentano un metodo di phishing valido per un po' di tempo.
Esistono una serie di eventi diversi che possono essere utilizzati per eseguire codice all'interno di un XLL, il più notevole dei quali è xlAutoOpen. L'elenco completo può essere visto qui:
Facendo doppio clic su un XLL, l'utente viene accolto da questa schermata:
Questa singola finestra di dialogo è tutto ciò che separa l'utente dall'esecuzione del codice; con un social engineering abbastanza sottile, l'esecuzione del codice è quasi certa.
Una cosa da tenere a mente è che gli XLL, essendo eseguibili, sono specifici per architettura. Ciò significa che devi conoscere il tuo target; la versione di Microsoft Office/Excel utilizzata dall'organizzazione target di solito determina per quale architettura devi costruire il tuo payload.
C'è una suddivisione abbastanza netta nelle versioni di Office che può essere usata come regola pratica:
Office 2016 o precedente: x86
Office 2019 o successivo: x64
Va notato che è possibile installare l'altra architettura per ciascun prodotto, tuttavia queste sono le architetture predefinite installate e nella maggior parte dei casi questo dovrebbe essere un modo affidabile per decidere per quale architettura realizzare il tuo XLL. Ovviamente, a seconda del metodo di consegna e del pretesto utilizzato nella campagna di phishing, è possibile fornire entrambe le versioni e fare affidamento sulla vittima per selezionare la versione appropriata per il proprio sistema.
Il payload XLL costruito durante questa ricerca si basa su questo progetto di edparcell. Il suo repository ha buone istruzioni per iniziare con gli XLL in Visual Studio, e ho usato il suo codice come punto di partenza per sviluppare un file XLL dannoso.
Una deviazione notevole dal suo repository è che se desideri creare il tuo progetto XLL, dovrai scaricare l'ultimo Excel SDK e poi seguire le istruzioni nel repository precedentemente collegato usando questa versione invece della versione 2010 dell'SDK menzionata nel README.
La consegna del payload è una considerazione importante nel contesto dell'UDA. Ci sono due metodi principali su cui ci concentreremo:
Sia allegando un file che includendo un link a un sito web da cui scaricare un file, l'email è una parte critica del processo UDA. Nel corso degli anni molte organizzazioni (e provider di posta elettronica) sono maturate e hanno imposto regole per proteggere utenti e organizzazioni da allegati dannosi. L'efficacia varia, ma le organizzazioni ora hanno la capacità di:
Testare le regole email di un'organizzazione può essere una parte importante di un engagement, ma bisogna sempre prestare attenzione per non rivelare che è in corso un'operazione Red Team e che si stanno raccogliendo attivamente informazioni.
Ai fini di questo articolo, si assumerà che l'organizzazione target abbia regole robuste per gli allegati email che impediscono la consegna di un payload XLL. Ci sposteremo e guarderemo alla consegna via web.
L'email sarà ancora utilizzata in questo vettore d'attacco, tuttavia invece di inviare un allegato verrà utilizzata per inviare un link a un sito web. Le regole del proxy web e le mitigazioni di rete che controllano i tipi di file scaricabili possono differire da quelle applicate per gli allegati email. Ai fini di questo articolo, si assume che l'organizzazione impedisca il download di file eseguibili (intestazioni MZ) dal web. In questo caso, vale la pena esplorare i packer/contenitori.
Il presupposto è che potremmo essere in grado di nascondere il nostro eseguibile all'interno di un altro tipo di file e farlo passare oltre le policy dell'organizzazione. Una considerazione importante qui è il supporto nativo per il tipo di file; i file 7Z, ad esempio, non possono essere aperti da Windows senza installare software di terze parti, quindi non sono una buona scelta. Formati come ZIP, ISO e IMG sono scelte interessanti perché sono supportati nativamente da Windows e, come ulteriore vantaggio, aggiungono pochissimi passaggi extra per la vittima.
L'organizzazione sfortunatamente blocca il download di ISO e IMG dal web; inoltre, poiché impiega la prevenzione della perdita di dati (DLP), gli utenti non possono montare dispositivi di archiviazione esterni, e ISO e IMG sono considerati tali.
Fortunatamente per noi, anche se l'organizzazione impedisce il download di file con intestazione MZ, permette il download di file zip contenenti eseguibili. Questi file zip vengono attivamente scansionati per malware, incluso chiedere all'utente la password per i file zip protetti da password; tuttavia, poiché l'eseguibile è zippato, non viene bloccato dal divieto generale per i file MZ.
I file Zip sono stati scelti come contenitore per il nostro payload XLL perché:
Comodamente, facendo doppio clic su un file ZIP su Windows si apre quel file zip in Esplora File:
Meno comodamente, facendo doppio clic sul file XLL dalla posizione zippata si attiva Windows Defender; anche usando il progetto base di edparcell che non contiene alcun tipo di codice malevolo.
Guardando l'avviso di Windows Defender vediamo che è solo un avviso generico "Wacatac":
Tuttavia c'è qualcosa di strano; il file identificato come malevolo era in c:\users\user\Appdata\Local\Temp\Temp1_ZippedXLL.zip, non in C:\users\user\Downloads\ZippedXLL\ dove abbiamo fatto doppio clic. Guardando l'istanza di Excel in ProcessExplorer si vede che Excel sta effettivamente eseguendo l'XLL da appdata\local\temp, non dal file ZIP da cui proviene:
Sembra essere un problema associato ai file ZIP, non agli XLL. Aprire un file TXT da uno zip usando il Blocco note comporta anche la copia del file TXT in appdata\local\temp e l'apertura da lì. Mentre aprire un file di testo da questa posizione è ok, Defender sembra identificare qualsiasi tipo di esecuzione di codice in questa posizione come malevola.
Se un utente estraesse l'XLL dal file ZIP e poi lo eseguisse, funzionerebbe senza problemi; tuttavia non c'è modo di garantire che un utente lo faccia, e non possiamo davvero rischiare di far scattare AV/EDR se non lo estraggono. Inoltre, fare doppio clic sullo ZIP e poi doppio clic sull'XLL è molto più semplice e una vittima è molto più propensa a completare queste semplici azioni piuttosto che prendersi la briga di estrarre lo ZIP.
Questo problema mi ha portato a considerare un diverso tipo di payload rispetto all'XLL; ho iniziato a esplorare i VSTO, che sono modelli di Visual Studio per Office. Ti incoraggio vivamente a dare un'occhiata a quell'articolo.
I VSTO alla fine chiamano una DLL che può essere posizionata localmente con il file .XLSX che avvia tutto, oppure ospitata in remoto e scaricata dal file .XLSX tramite http/https. L'opzione locale non offre vantaggi reali (e anzi diversi svantaggi in quanto ci sono molti più file associati a un attacco VSTO), e l'opzione remota sfortunatamente richiede un certificato di firma del codice o che la posizione remota sia una rete attendibile. Non avendo un certificato di firma del codice valido, i VSTO non mitigano nessuno dei problemi in questo scenario che il nostro payload XLL sta incontrando.
Sembra davvero che siamo messi con le spalle al muro. Eseguire l'XLL in sé è ok, ma l'XLL non può essere consegnato da solo alla vittima né tramite allegato email né download web a causa delle policy dell'organizzazione. L'XLL deve essere impacchettato all'interno di un contenitore, ma a causa del DLP formati come ISO, IMG e VHD non sono praticabili. La vittima deve essere in grado di aprire il contenitore nativamente senza software di terze parti, il che lascia lo ZIP come opzione; ma come discusso, eseguire l'XLL da una cartella zippata comporta la sua copia ed esecuzione da appdata\local\temp, il che fa scattare l'AV.
Ho passato molte ore a fare brainstorming e testare cose, addentrandomi nella tana del coniglio dei VSTO, esplorando tutte le opzioni concepibili finché ho finalmente deciso di provare qualcosa di così stupido che potrebbe funzionare.
Questa volta ho creato una cartella, inserito l'XLL al suo interno, e poi zippato la cartella:
Entrando nella cartella si vede il file XLL:
Facendo doppio clic sull'XLL viene visualizzata la richiesta del componente aggiuntivo da Excel. Nota che l'XLL viene ancora copiato in appdata\local\temp, tuttavia c'è un livello aggiuntivo a causa della cartella extra che abbiamo creato:
Cliccando su Abilita si esegue il nostro codice senza attivare Defender:
Ottimo! Esecuzione del codice. E ora?
Il pretesto per indurre una vittima a scaricare ed eseguire l'XLL varierà notevolmente in base all'organizzazione e al metodo di consegna; i temi potrebbero includere dati salariali dei dipendenti, calcolatori per la compensazione in base alle competenze, informazioni su un progetto, un elenco di partecipanti a un evento, ecc. Qualunque sia il richiamo, il nostro attacco sarà molto più efficace se forniamo effettivamente alla vittima ciò che è stato promesso. Senza un seguito, le vittime potrebbero insospettirsi e segnalare il documento ai loro team di sicurezza, il che può rapidamente smascherare l'attaccante e limitare l'accesso al sistema target.
L'XLL da solo lascerà solo una finestra di Excel vuota dopo che il nostro codice ha terminato l'esecuzione; sarebbe molto meglio per noi fornire il foglio di calcolo Excel che la vittima sta cercando.
Possiamo incorporare il nostro XLSX come array di byte all'interno dell'XLL; quando l'XLL viene eseguito, scriverà l'XLSX sul disco accanto all'XLL, dopodiché verrà aperto. Assegneremo all'XLSX lo stesso nome dell'XLL, con l'unica differenza dell'estensione.
Dato che il nostro XLL è scritto in C, possiamo introdurre alcune delle capacità da un precedente writeup che ho fatto su Payload Capabilities in C, in particolare l'auto-cancellazione. Combinando queste due tecniche si ottiene che l'XLL viene cancellato dal disco e l'XLSX con lo stesso nome viene scritto al suo posto. Per un occhio poco attento, sembrerà che l'XLSX sia sempre stato lì.
Sfortunatamente la posizione in cui l'XLL viene cancellato e l'XLSX viene scritto è la cartella appdata\temp\local, non lo ZIP originale; per affrontare questo possiamo creare un secondo ZIP contenente solo l'XLSX e leggerlo anche come array di byte all'interno dell'XLL. Durante l'esecuzione, oltre alle azioni menzionate, l'XLL potrebbe provare a localizzare il file ZIP originale in c:\users\victim\Downloads\ e cancellarlo prima di scrivere il secondo ZIP contenente solo l'XLSX al suo posto. Questo potrebbe ovviamente fallire se l'utente ha salvato lo ZIP originale in una posizione diversa o con un nome diverso, ma in molti casi dovrebbe finire automaticamente nella cartella dei download dell'utente.
Questo screenshot mostra nel riquadro inferiore la cartella temp creata in appdata\local\temp contenente l'XLL e l'XLSX scritto, mentre il riquadro superiore mostra la finestra originale di Esplora File da cui è stato aperto l'XLL. Nota nel riquadro inferiore che l'XLL ha dimensione 0. Questo perché si è cancellato durante l'esecuzione, ma finché il riquadro superiore non viene chiuso, il file XLL non scompare completamente dalla posizione appdata\local\temp. Anche se la vittima facesse nuovamente clic sull'XLL, ora è inerte e non esiste realmente.
Allo stesso modo, non appena la vittima esce dallo ZIP aperto in Esplora File (chiudendolo o navigando in una cartella diversa), se fa nuovamente clic su spreadsheet.zip ora troverà che la cartella test contiene importantdoc.xlsx; quindi l'XLL è stato rimosso e sostituito dall'XLSX innocuo in entrambe le posizioni in cui esisteva sul disco.
Questa GIF mostra il download e l'esecuzione dell'XLL su una VM di prova MDE. Nota che per qualche motivo Excel apre due istanze qui; sul mio computer di casa ne ha aperta solo una, quindi non sono sicuro del perché differisca.
Come sempre, ci chiederemo "Cosa vede MDE?"
Un rapido dump di screenshot per dimostrare che ho effettivamente eseguito questo su target e ricevuto un beacon su TestMachine11:
Prima di tutto, zero avvisi:
Cosa cattura la timeline/log degli eventi?
Accidenti. A dire il vero non ho idea da dove provengano gli avvisi di keylogging, crittografia e decrittografia delle credenziali, poiché il mio codice non fa nulla di tutto ciò. Le nostre azioni sembrano sicuramente sospette quando vengono elencate in questo modo, ma commenterò ancora una volta quanti dati vengono raccolti da MDE su un singolo endpoint, figuriamoci su centinaia, migliaia o centinaia di migliaia che un'organizzazione può avere collegati all'EDR. Finché non lanciamo avvisi reali, probabilmente siamo a posto.
Il momento che molti probabilmente stavano aspettando, fornisco un esempio di codice del mio XLL runner sviluppato, limitato solo alle parti discusse qui nella sezione Tradecraft. Spetterà al lettore effettivamente inserire il codice in un XLL e implementarlo insieme al resto del suo runner. Come sempre, non fare danni, avere il permesso di fare phishing a un'organizzazione, ecc.
Ho incluso il codice sorgente per un programma che legge un file e produce esadecimale da copiare negli array di byte definiti nello snippet. Usalo per l'XLSX che desideri presentare all'utente, così come per il file ZIP contenente la cartella che contiene lo stesso XLSX e memorizzali nei rispettivi array di byte. Compila questo codice usando:``` gcc -o ingestfile ingestfile.c
Ho avuto alcuni problemi a far compilare i miei XLL usando MingW su una macchina Kali, quindi ho pensato di pubblicare i comandi qui:
**x64**```
x86_64-w64-mingw32-gcc snippet.c 2013_Office_System_Developer_Resources/Excel2013XLLSDK/LIB/x64/XLCALL32.LIB -o importantdoc.xll -s -Os -DUNICODE -shared -I 2013_Office_System_Developer_Resources/Excel2013XLLSDK/INCLUDE/
x86``` i686-w64-mingw32-gcc snippet.c 2013_Office_System_Developer_Resources/Excel2013XLLSDK/LIB/XLCALL32.LIB -o HelloWorldXll.xll -s -DUNICODE -Os -shared -I 2013_Office_System_Developer_Resources/Excel2013XLLSDK/INCLUDE/
Dopo aver compilato, vorrai creare una nuova cartella e copiare il XLL in quella cartella. Poi comprimilo usando:```
zip -r <myzipname>.zip <foldername>/
Nota che affinché le tecniche descritte in questo post funzionino, dovrai abbinare alcune variabili nel frammento di codice al nome che dai al file XLL e al file zip.
Con il predominio delle macro di Office in declino, gli XLL rappresentano un'opzione interessante per le campagne di phishing. Con un po' di creatività, possono essere utilizzati insieme ad altre tecniche per bypassare molti livelli di difesa implementati da organizzazioni e team di sicurezza. Grazie per aver letto e spero che tu abbia imparato qualcosa di utile!