Command and Control with WebSockets WSC2
This all started with a conversation I was having with a few other BHIS testers. At the time, I was testing a web application that used WebSockets. The app was giving me headaches, and I was venting my frustration. Penetration testers, red teams, and baddies are always looking for new ways to sneak by defenses. So, it wasn’t surprising that the conversation shifted to discussing how these struggles could be used in an offensive capacity. Someone mentioned that it would be super cool to have a command and control (C2) channel that used WebSockets. Before we get into why that would be super cool, we should take a closer look at the WebSocket protocol.
WebSocket isn’t all that new. The protocol originally showed up in HTML5 in the mid to late 2000s. It gained traction with developers, started shipping with browsers, and the specification (RFC 6455) was finalized in 2011. The WebSocket protocol facilitates a full-duplex communication channel between the server and the client over TCP. This allows for true asynchronous communication between the client and the server. This is a big break from the request/response nature of the HTTP protocol. Before WebSocket, the most popular way to achieve “asynchronous” communication was to use AJAX. Except AJAX still depends on the client to poll the server, so it’s really just half-duplex. WebSockets allow the server to send messages to the client at will and vice versa.
Tracking the flow of asynchronous communication is a little harder than tracking the flow of traditional HTTP requests and responses. Also, the format of the data sent using WebSockets is almost completely specified by the application developer. As I found out, these factors can make testing applications that use WebSockets more challenging. This also means more work for defenders who need to inspect web traffic! So, the idea is that we can use WebSockets to establish a command and control channel that might not be given as much scrutiny.
Fortunately, @Arno0x0x is way ahead of us on this and wrote a tool called WSC2 which is available on GitHub at https://github.com/Arno0x/WSC2. There is also a great blog post introducing the tool: https://arno0x0x.wordpress.com/2017/11/10/using-websockets-and-ie-edge-for-c2-communications/.
So let’s take WSC2 for a spin! The tool comes almost ready to use as soon as you clone it to your attack server. Details like the IP address of the C2 server are managed in a configuration file called config.py. I did make a couple of modifications to this file like configuring the callback to point to my command and control server and setting a new password.
Once launched, I found the controller component of WSC2 to be intuitive and similar to other C2 applications I’ve used in the past. WSC2 comes with several stager payloads, but I decided to use the PowerShell one-line stager to launch an agent on my Windows 10 victim machine. Because the callback configuration had already been handled in a separate file, generating the payload was as quick as launching the WSC2 controller and typing “genStager psoneliner”. All that was left to do was run the PowerShell one-liner on my victim machine. I was immediately rewarded with an agent callback! The following screenshot shows the entire process form the controller point of view.
The WSC2 agent itself isn’t packed with a ton of features. It does let you upload and download files to/from the victim machine as well as drop into a shell and execute commands on the remote host.
One of the interesting things about the WSC2 agent is that it communicates with the C2 server through Internet Explorer/Edge using a COM object. @Arno0x0x threw that in for EDR evasion, and I thought it was cool. For demonstration purposes, I ran Process Monitor (part of Windows’ Sysinternals Suite) on my victim machine to watch processes that were participating in network communications while the agent was running. Sure enough, all of my agent traffic showed up as IEXPLORE.EXE.
I configured Internet Explorer to proxy traffic through Burp Suite on the victim side. This allowed me to see the connection upgrade from HTTP to WebSocket.
We can also use Burp Suite to view the WebSocket traffic generated when commands are issued to the agent.
Using WebSockets for command and control is something that should be considered by penetration testers, red teams, and defenders alike. WSC2 makes establishing a WebSocket command and control channel in your environment to test your monitoring and defense solutions quick and easy.
Ready to learn more?
Level up your skills with affordable classes from Antisyphon!
Available live/virtual and on-demand
