gmh5225/cs-dropspawn_bof# BOF per CobaltStrike per generare Beacon tramite DLL Application Directory Hijacking
DropSpawn è un BOF per CobaltStrike utilizzato per generare Beacon aggiuntivi tramite un metodo relativamente sconosciuto di DLL hijacking. Funziona x86-x86, x64-x64 e x86-x64/viceversa. Da usare come alternativa all'iniezione di processi.
Gli eseguibili Windows seguono l'ordine di ricerca delle DLL quando tentano di caricare DLL il cui percorso assoluto non è stato specificato:
Il DLL hijacking richiede tipicamente che:
A. Un utente abbia permessi di scrittura in una cartella con precedenza nell'ordine di ricerca superiore rispetto a quella in cui risiede la DLL reale
oppure
B. Che la DLL in questione non esista da nessuna parte sul sistema, nel qual caso può essere collocata in una cartella scrivibile dall'utente nella variabile %PATH% dell'utente (come %USERPROFILE%\appdata\local\microsoft\windowsapps).
Questi requisiti escludono il DLL hijacking per gli eseguibili che risiedono in C:\Windows\System32 perché quasi tutte le DLL che questi eseguibili caricano risiedono anch'esse in System32. Copiare un eseguibile di System32 in una posizione scrivibile dall'utente ed eseguirlo lì è un'opzione, ma non è molto sicura dal punto di vista OPSEC perché i binari di System32 eseguiti da posizioni alternative sono facili da identificare.
DropSpawn abilita il DLL hijacking utilizzando eseguibili di System32 (e altri presenti in cartelle aggiuntive non scrivibili dall'utente) falsificando "La directory da cui viene caricata l'applicazione" con una arbitraria specificata dall'utente.
La versione pubblica di DropSpawn differisce leggermente da quella non pubblica. La versione non pubblica sfrutta un generatore di payload proprietario, rendendo l'esperienza molto più fluida per l'operatore. La versione pubblica è stata leggermente modificata per tenere conto del fatto che gli utenti avranno i propri metodi per generare payload compatibili con il DLL hijacking. Uno script Python3 e il codice sorgente per una DLL dimostrativa sono stati inclusi per assistere gli utenti nell'integrazione e nell'armamento di DropSpawn.
Identifica alcuni eseguibili target che tentano di caricare DLL senza specificarne i percorsi assoluti. Puoi farlo copiando l'exe in una directory scrivibile dall'utente ed eseguendolo mentre lo monitori con Procmon. In questo esempio useremo WerFault.exe che normalmente risiede in C:\Windows\System32\WerFault.exe
Nell'esempio sopra, cryptsp.dll, wer.dll, dbghelp.dll e bcrypt.dll sono tutti candidati validi perché i loro percorsi assoluti non sono stati specificati all'interno di WerFault; di conseguenza, WerFault tenterà di caricarli dalla propria directory dell'applicazione prima di ricorrere al resto dell'ordine di ricerca delle DLL. Nota che questo tipicamente non è un problema perché la directory dell'applicazione di WerFault È System32.
Scarica una delle DLL hijackable dal sistema target.
Questo è necessario per poter estrarre le sue esportazioni e includerle nella nostra DLL payload. È importante prelevare la DLL hijackable dalla stessa macchina su cui desideri usare DropSpawn, poiché le DLL cambiano tra le versioni di Windows. Inoltre, se stai eseguendo un beacon x86 e vuoi generare un beacon x64 usando DropSpawn, assicurati di scaricare la versione x64 della DLL reale specificando 'C:\windows\sysnative...' invece di 'C:\windows\system32...'.
Esegui generate_dll.py, passando la DLL scaricata e l'architettura del payload desiderata. Generate_dll.py è una versione modificata di questo script. Analizzerà la DLL fornita, creerà un file .def contenente le esportazioni della DLL e chiamerà MingW per compilare la nostra DLL payload dimostrativa. Quando il processo generato tenta di chiamare una funzione reale all'interno della DLL falsificata, la nostra DLL payload inoltrerà la chiamata alla DLL reale situata in System32 così che il processo host non vada in crash.
Chiama dropspawn usando la DLL payload generata.
dropspawn <payload DLL> <x86|x64> <programma da generare> [cartella target scrivibile] [parent]
payload DLL - il percorso completo della DLL payload generata.
architettura - l'architettura del processo che desideri generare
programma da generare - il nome/percorso del processo che desideri generare. Se questo processo risiede in System32 (o syswow64), puoi semplicemente specificare il nome. Altrimenti, specifica il percorso completo. Puoi anche fornire argomenti da riga di comando al processo. Se ci sono spazi nel percorso/se usi argomenti, racchiudi il tutto tra virgolette.
cartella target scrivibile - Opzionale. Se lasciato vuoto, dropspawn tenterà di usare la directory corrente del Beacon. Usa le virgolette se ci sono spazi nel percorso.
parent - Opzionale. Il nome del processo da usare per lo spoofing del PPID con il processo appena generato. Se viene specificato un processo che ha più istanze in esecuzione con diversi livelli di privilegio (es. svchost.exe), dropspawn tenterà di identificarne una che possa essere usata per lo spoofing del PPID.
Esempio: dropspawn /root/dbgcore.dll x64 "WerFault.exe -u -p 4352 -s 160" C:\users\user\appdata\local\temp explorer.exe
Questo rilascerà la DLL payload 'dbgcore.dll' su disco in 'c:\users\user\appdata\local\temp\dbgcore.dll' e genererà un processo WerFault.exe x64 con gli argomenti da riga di comando '-u -p 4352 -s 160' e explorer.exe come processo padre.
La pulizia è semplice. Includendo la funzione di Auto-Cancellazione nella DLL payload rilasciata su disco, questa verrà eliminata non appena il nostro nuovo processo viene generato e la carica. Questo è un punto di svolta, poiché tipicamente la DLL rimarrebbe bloccata su disco finché il nostro processo che l'ha caricata continua a essere in esecuzione. Se la tecnica di Auto-Cancellazione fallisce per qualche motivo (o il processo non riesce a essere generato), DropSpawn tenterà di eliminare la DLL payload dal disco e informerà l'utente del risultato dell'operazione in entrambi i casi.
L'iniezione di processi segue tipicamente la catena apri processo remoto -> alloca memoria remota -> scrivi memoria remota -> esegui memoria remota, con l'opzione di generare un nuovo processo all'inizio invece di usarne uno esistente. DropSpawn crea solo un nuovo processo; il processo appena generato è responsabile di allocare, scrivere ed eseguire lo shellcode, quindi possiamo evitare molti degli IOC tipicamente associati all'iniezione di processi remoti.
Questa tecnica è ovviamente alla mercé di quanto siano buone le tue DLL payload. Ma possiamo dare un'occhiata a ciò che Windows vede (questa sezione successiva usa la versione privata di DropSpawn e la generazione di Beacon).
Per quanto riguarda il Visualizzatore eventi, tutto sembra normale:
In MDE c'è molto poco da vedere.
Esecuzione di dropspawn:
Log MDE:
Con spoofing del PPID:
Senza spoofing del PPID:
In entrambi i casi vediamo il nostro processo beacon originale (anche lui un werfault) rilasciare dbgcore.dll su disco, creare un nuovo processo WerFault.exe, il processo appena generato caricare dbgcore.dll e poi rinominarla (eliminandola). Fondamentalmente non c'è alcun controllo aggiuntivo su dbgcore.dll che spesso accompagna i DLL hijack perché non la stiamo scrivendo in nessuna posizione spesso oggetto di hijack, e WerFault.exe (o qualunque processo tu scelga di usare) non è realmente associato ai DLL hijack nello stesso modo in cui lo sono cose come WmiPrvSE.exe.
È interessante notare che è quasi più visibile fare questo con lo spoofing del PPID che senza. Questo può variare a seconda del prodotto di sicurezza comunque.
Come menzionato, è essenziale che gli utenti scarichino le DLL reali dalla macchina target su cui intendono usare DropSpawn. Usare la versione sbagliata di una DLL può causare il crash del processo generato se tenta di chiamare una funzione che non esiste.
DropSpawn può essere usato con eseguibili al di fuori di System32; sii comunque avvisato che possono sorgere problemi se il processo tenta di caricare DLL aggiuntive dalla vera directory dell'applicazione del processo. Poiché abbiamo falsificato la directory dell'applicazione altrove, se la vera directory dell'applicazione non è anche raggiungibile tramite l'ordine di ricerca delle DLL altrimenti, il processo andrà in crash/non riuscirà ad avviarsi perché non può individuare DLL essenziali. Testa sempre i potenziali hijack su macchine di sviluppo prima di usarli in produzione!
Questa ricerca è nata mentre esploravo come i processi assemblano il loro ordine finale di ricerca delle DLL (poiché deve essere determinato in fase di esecuzione a causa di eseguibili che risiedono in directory diverse, della directory corrente che fa parte del percorso di ricerca, ecc.). La mia ricerca mi ha portato a questo post del forum, che è servito come origine delle due API critiche non documentate che sono centrali per questa tecnica.
Sono già stati linkati prima, ma questo post sull'evitare il loader lock, questo script per generare un file .def per il proxying delle DLL e questa ricerca sull'abilitazione dell'auto-cancellazione degli eseguibili in esecuzione sono essenziali per produrre DLL payload efficaci e armate adatte a DropSpawn.
Quando ho pubblicato per la prima volta questa tecnica su Twitter, molti altri si sono uniti alla conversazione e hanno prodotto POC. SecurityAndStuff ha prodotto questo, mentre Snovvcrash ha il suo qui
