riccardoancarani/liquidsnakeHerramienta de movimiento lateral sin archivos que utiliza suscripciones a eventos de WMI para ejecutar ensamblados .NET en memoria, con inyección de shellcode a través de tuberías con nombre para comprometer Windows de forma remota.
Liquid Snake es un programa diseñado para realizar movimiento lateral contra sistemas Windows sin tocar el disco. La herramienta se basa en la Suscripción a Eventos WMI para ejecutar un ensamblado .NET en memoria; el ensamblado .NET escuchará un shellcode en una tubería con nombre y luego lo ejecutará usando una variación de la inyección de shellcode mediante secuestro de hilo.
El diagrama a continuación (con suerte) aclara el flujo de datos:
El proyecto está compuesto por dos soluciones separadas:
CSharpNamedPipeLoader - el componente que se transformará en VBS mediante GadgetToJScript.LiquidSnake - el componente responsable de crear la Suscripción a Eventos WMI en el sistema remoto.Simplemente abra ambas soluciones en Visual Studio y constrúyalas. Asegúrese de apuntar a la arquitectura x64 para CSharpNamedPipeLoader. Si todo sale bien, debería tener dos EXEs separados: CSharpNamedPipeLoader.exe y LiquidSnake.exe.
Usando GadgetToJScript, convierta CSharpNamedPipeLoader.exe a VBS con el siguiente comando:
GadgetToJScript.exe -a CSharpNamedPipeLoader.exe -b -w vbs
Pruebe la deserialización .NET usando cscript.exe y asegúrese de que todo funciona como se espera:
cscript.exe test.vbs
Luego, codifique en base64 el archivo vbs e insértelo en la variable vbscript64 del archivo Program.cs de LiquidSnake en la línea 29.
Ya lo hice por usted, así que solo puede compilar la solución LiquidSnake y usarla tal cual.
El uso de este proyecto es sencillo; use LiquidSnake.exe contra un host sobre el cual tenga acceso administrativo de la siguiente manera:
LiquidSnake.exe <host> [<username> <password> <domain>]
LiquidSnake.exe dc01.isengard.local
LiquidSnake.exe dc01.isengard.local saruman DeathToFrodo123 isengard.local
NOTA: Actualmente hay un error cuando se establecen explícitamente credenciales de usuario; la herramienta no funcionará en ese caso. Se recomienda usar make_token o cualquier otro mecanismo de suplantación en su lugar.
Si todo sale bien, debería obtener una salida similar a la siguiente:
[*] Event filter created.
[*] Event consumer created.
[*] Subscription created, now sleeping
[*] Sending some DCOM love..
[*] Sleeping again... long day
El ejemplo anterior usa execute-assembly de CobaltStrike para lanzar LiquidSnake:
Mientras tanto, en el host remoto se creará una nueva tubería con nombre con el siguiente nombre:
\\.\pipe\6e7645c4-32c5-4fe3-aabf-e94c2f4370e7
Luego, usando mi proyecto send_shellcode_via_pipe de mis BOFs puede enviar un shellcode arbitrario a la tubería remota que será cargado y ejecutado:
send_shellcode_via_pipe \\dc01\pipe\6e7645c4-32c5-4fe3-aabf-e94c2f4370e7 beacon.bin
Si todo funcionó como se esperaba, debería obtener un beacon como SYSTEM:
NOTA: La versión actual de LiquidSnake contiene un artefacto generado por GadgetToJScript que apunta a la versión 4.x de .NET. Si su host objetivo tiene solo la versión 3.5 instalada, esto fallará. Simplemente repita el mismo proceso pero usando la versión adecuada de .NET al construir GadgetToJScript.
Hay muchas oportunidades de detección para identificar el abuso de esta herramienta y, en general, el uso de esta técnica:
clr.dll relacionados con el proceso scrcons.exe.scrcons.exe.Adicionalmente, el mayor inconveniente de esta implementación específica es que el shellcode se envía en texto claro a través de SMB. Esto significa que si una solución de monitoreo de red puede inspeccionar ese tráfico, es probable que lo detecte. No he hecho muchas pruebas contra el conjunto de reglas de zeek/bro, pero estoy bastante seguro de que sería detectado de inmediato.
En la carpeta detection-artefacts dejé el archivo PCAP de una captura de Wireshark y los eventos de Sysmon generados durante el ataque (usando la configuración predeterminada de Swift On Security).