riccardoancarani/liquidsnakeStrumento di movimento laterale senza file che utilizza le sottoscrizioni di eventi WMI per eseguire assembly .NET in memoria, con iniezione di shellcode tramite named pipe per il compromesso remoto di Windows.
Liquid Snake è un programma progettato per eseguire movimenti laterali contro sistemi Windows senza toccare il disco. Lo strumento si basa sulla sottoscrizione di eventi WMI per eseguire un assembly .NET in memoria; l'assembly .NET ascolterà uno shellcode su una named pipe e poi lo eseguirà utilizzando una variante dell'iniezione di shellcode tramite thread hijacking.
Il diagramma seguente (si spera) chiarisce il flusso dei dati:
Il progetto è composto da due soluzioni separate:
CSharpNamedPipeLoader - il componente che verrà trasformato in VBS tramite GadgetToJScriptLiquidSnake - il componente responsabile della creazione della sottoscrizione di eventi WMI sul sistema remotoBasta aprire entrambe le soluzioni in Visual Studio e compilarle. Assicurati di puntare all'architettura x64 per CSharpNamedPipeLoader. Se tutto è andato bene, dovresti ottenere due EXE separati: CSharpNamedPipeLoader.exe e LiquidSnake.exe
Usando GadgetToJscript, converti CSharpNamedPipeLoader.exe in VBS con il seguente comando:
GadgetToJScript.exe -a CSharpNamedPipeLoader.exe -b -w vbs
Testa la deserializzazione .NET usando cscript.exe e assicurati che tutto funzioni come previsto:
cscript.exe test.vbs
Poi, codifica in base64 il file vbs e inseriscilo nella variabile vbscript64 del Program.cs di LiquidSnake alla riga 29.
L'ho già fatto io per te, quindi puoi semplicemente compilare la soluzione LiquidSnake e usarla così com'è.
L'uso di questo progetto è semplice, usa LiquidSnake.exe contro un host su cui hai accesso amministrativo come segue:
LiquidSnake.exe <host> [<username> <password> <dominio>]
LiquidSnake.exe dc01.isengard.local
LiquidSnake.exe dc01.isengard.local saruman DeathToFrodo123 isengard.local
NOTA: Attualmente c'è un bug quando si impostano esplicitamente le credenziali dell'utente; in quel caso lo strumento non funzionerà. Si consiglia invece di usare make_token o qualsiasi altro meccanismo di impersonificazione.
Se tutto è andato bene, dovresti ottenere un output simile al seguente:
[*] Filtro evento creato.
[*] Consumer evento creato.
[*] Sottoscrizione creata, ora in pausa
[*] Invio di un po' di amore DCOM..
[*] Di nuovo in pausa... lunga giornata
L'esempio sopra utilizza execute-assembly di CobaltStrike per lanciare LiquidSnake:
Nel frattempo, sull'host remoto verrà creata una nuova named pipe con il seguente nome:
\\.\pipe\6e7645c4-32c5-4fe3-aabf-e94c2f4370e7
Quindi, usando il mio progetto send_shellcode_via_pipe dai miei BOF puoi inviare uno shellcode arbitrario sulla pipe remota che verrà caricato ed eseguito:
send_shellcode_via_pipe \\dc01\pipe\6e7645c4-32c5-4fe3-aabf-e94c2f4370e7 beacon.bin
Se tutto ha funzionato come previsto, dovresti ottenere un beacon SYSTEM:
NOTA: La versione attuale di LiquidSnake contiene un artefatto generato da GadgetToJScript che punta a .NET versione 4.x. Se l'host di destinazione ha solo la 3.5 installata, fallirà. Basta ripetere lo stesso processo ma usando la versione .NET appropriata durante la build di GadgetToJScript.
Ci sono molte opportunità di rilevamento per identificare l'abuso di questo strumento e in generale l'uso di questa tecnica:
clr.dll relativi al processo scrcons.exescrcons.exeInoltre, il più grande svantaggio dell'implementazione specifica è che lo shellcode viene inviato in chiaro su SMB. Ciò significa che se una soluzione di monitoraggio di rete è in grado di ispezionare quel traffico, molto probabilmente risalterà. Non ho fatto molti test con il set di regole zeek/bro, ma sono abbastanza sicuro che verrà rilevato immediatamente.
Nella cartella detection-artefacts ho lasciato il file PCAP di una cattura Wireshark e gli eventi Sysmon generati durante l'attacco (utilizzando la configurazione predefinita di Swift On Security).