ShadowMove: Lateral Movement by Duplicating Existing Sockets
Last updated
Last updated
ShadowMove (original paper by researchers Amirreza Niakanlahiji, Jinpeng Wei, Md Rabbi Alam, Qingyang Wang and Bei-Tseng Chu, go check it for full details) is a lateral movement technique that works by stealing (duplicating) an existing socket connected to a remote host, from a running process on a system an adversary has compromised.
This is a quick lab to familiarize with the technique, while using the PoC by Juan Manuel Fernández which he provided in his post.
The below is a simplified diagram showing how the technique works and how I tested it in my lab:
Let's see what we have in the above diagram:
On the left, we have a compromised host (for example, we landed on this host by means of a successful phish) 192.168.1.117 - this is the source host from which we want to move laterally to the target host 192.168.56.102.
On the right, we have the target host 192.168.56.102, which has a listening socket on TCP port 80, by means of running nc -lvp 80
Source host 192.168.1.117 has an established connection to the target host 192.168.56.102:80 via nc.exe.
On the source host, there's ShadowMove.exe process running - this is the process that executes the ShadowMove lateral movement technique. Note that it does not establish any connections to remote hosts at any point in time during its lifetime - this is the beauty of the technique.
On the source host, ShadowMove.exe enumerates all handles nc.exe has opened and looks for handles to \Device\Afd, which are used for network socket communications. Once found, the handle is used to create a duplicate socket with WSADuplicateSocketW and WSASocket API calls. Once the shared socket is created, getpeername is used to check if the destination address of the socket is that of target host's IP address, which in our case is 192.168.56.102.
Once the shared socket is created based on the \Device\Afd handle pointing to the target host, as found in step 5, ShadowMove.exe can now write to that socket with send and read from it with recv API calls.
It's important to stress once more, the ShadowMove.exe does not create any TCP connections to the target host. Instead, it reuses the existing connected socket to 192.168.56.102:80 between the source and target host, that was established by the nc.exe process on the source system - and this is the key point of this lateral movement technique.
Below is the code written by Juan Manuel Fernández which I modified slightly, so that it would compile without errors in my development environment with Visual Studio 2019:
Once we have compiled the above code, we can test the technique as it was described earlier in our diagram. Below highlighted are key aspects of the demo:
In the top right corner, there's a target system 192.168.56.102 with nc listening on port 80.
In the top left corner, there's a compromised (source) system and nc.exe establishing a connection to target host 192.168.56.102:80.
In the bottom left corner, there's ShadowMove.exe running on the source system, which enumerates handles of the nc.exe running on the source system, finds a socket that is connected to 192.168.56.102:80 (target system), duplicates it and writes hello from shadowmove and reused socket! to it, which is then received on the target system (top right).
Target system (top right) writes back to the same socket hello from target to shadowmove, which is received by shadowmove.exe on the source system (bottom left).
In the bottom right, we see a ProcessHacker that shows that at no point in time shadowmove.exe establishes no TCP connections.
https://www.usenix.org/system/files/sec20summer_niakanlahiji_prepub.pdf
