Why you should be using reverse SOCKS

What and Why⌗

SOCKS is a protocol that allows us to send arbitrary TCP and UDP packet via a middle-man to a device. The benefit over other types of proxies (HTTP for example) is that it can target almost any protocol.

In normal use, a SOCKS proxy is deployed like so:

• SOCKS server creates an open port (usually 1080).
• Client configures tools to use SOCKS proxy (i.e. via ProxyChains or $PROXY)
• Client’s packets get sent to server, server sends packets to end device

This can be visualised like so:

Basically a normal setup… but there are a few problems if we want to deploy this setup while performing a penetration test:

• Binding a service to a port (such as 1080) usually requires administrative permissions
• The server with port 1080 open won’t be available from the internet

If we want to utilise SOCKS to target an internal network, then we need to go about this in a different way.

Introducing… Reverse Socks⌗

Okay so our SOCKS proxy always needs two components:

• A server listening to incoming SOCKS traffic on port 1080
• A server that can forward packets through to remote hosts

But, what if instead of running both of these components on a single host, we split them up?

Doing it this way solves both of our issues:

• Server binding to port 1080 is a controlled device of ours
• The server forwarding packets is connecting back to our server binding port 1080

This introduces some new requirements, but these can be more easily overcome:

• The server binding to port 1080 must be exposed to the internet
• There needs to be some protocol for transferring packets from server 1 to server 2 and back

Implementing these two things is a weekend project for an experienced programmer, but there are also tools we can leverage that already have this stuff built in.

(The benefit of DIY is that it won’t be fingerprinted as malware by any AV)

Let’s reverse those socks⌗

There are a few tools that can help us do this:

• https://github.com/Acebond/ReverseSocks5 (I am biased since this is maintained by a friend of mine)
• https://github.com/RedTeamPentesting/resocks
• https://github.com/kost/revsocks
• https://github.com/jpillora/chisel
• https://github.com/nccgroup/SocksOverRDP (This one is a useful, special case)

ReverseSocks5 / resocks / revsocks⌗

ReverseSocks5, resocks and revsocks all operate in functionally the same way. So take your pick ;).

In my case, I’ve had success with ReverseSocks5 so I’ll be demoing that.

We can compile the project using go on a linux installation:

git clone https://github.com/Acebond/ReverseSocks5 && git clone ReverseSocks5
go build

We can also cross-compile for windows:

GOOS=windows GOARCH=amd64 go build

This will produce the following files:

├── ReverseSocks5
└── ReverseSocks5.exe

In this case the victim host is inside a windows network, so I’ll be using the ReverseSocks5.exe as the client, and ReverseSocks5 as the server.

First, we set-up a listener:

Now we come to an important consideration, how do we make our service accessible to the internet?

There are a couple of ways:

• Use a tunnelling service like ngrok, localtunnel, cloudflare tunnel etc. (more can be found here)
• Run ReverseSocks5 on a host in a cloud provider that can then expose port 10443 to the IP of the target network, and 1080 to your local network
• Open a port on our router that redirects traffic to our host machine

There are some issues with ingress services, for example I find that ngrok tends to mangle non-http connections which breaks ReverseSocks5, but will work with something like chisel. In this case, I chose to go with opening a port on my router, which isn’t inherently unsafe but you should double-check what holes you are opening up on your network.

To open the port, I configure a NAT rule on my router to expose the service to the internet:

Finally, I can connect to the host and run ReverseSocks5.exe to expose its network:

Now we can configure proxychains to use our server:

Finally, we can talk to those internal services:

Chisel⌗

Chisel is an incredibly powerful tool that does a tad more then reverse socks, if you want to learn more here are some great articles:

• Reverse SOCKS Proxy Using Chisel — The Easy Way
• Tunneling with Chisel and SSF
• Using Windows web server as SOCKS proxy with proxychains, chisel and ngrok

The biggest down-side of Chisel, especially on real-world engagements, is that real threat actors have used it and so Windows considers it Malware:

• Defender entry for Chisel
• Ransomware groups that used Chisel

Socks Over RDP⌗

Thanks to https://twitter.com/xoreipeip over at NCC Group we have this lovely little tool that can help us setup a reverse SOCKS proxy via RDP. This is super useful as RDP is a fairly ubiquitous remote desktop solution, and the most common corporate alternative Citrix Workspace (at least, from what I’ve seen), uses RDP.

The big gain is that rather then sending the traffic between the SOCKS bind server and the SOCKS forwarding server over the internet, we can do it via an RDP virtual channel:

Virtual channels can be disabled for normal RDP, the instructions for Citrix are actually ineffective.

Additionally, most people won’t want to disable virtual channels since doing so will stop Copy & Paste from working.

Normal RDP⌗

For normal RDP, we need to obtain the architecture-relevant copy of SocksOverRDP and load up an elevated instance of powershell.

Once that’s downloaded, we need to register the plugin on our host:

regsvr32.exe SocksOverRDP-Plugin.dll

Then we need to modify the following registry to set-up our SOCKS bind server:

Computer\HKEY_CURRENT_USER\SOFTWARE\Microsoft\Terminal Server Client\Default\AddIns\SocksOverRDP-Plugin

Alternatively, if you always have the same setup, you can use the following as a .reg file:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Terminal Server Client\Default\AddIns\SocksOverRDP-Plugin]
"Name"="{61715a27-63a8-4dc1-9857-83eb00fb60a3}"
"enabled"=dword:00000001
"ip"="0.0.0.0"
"port"="1080"

The main change here is switching the bind host from 127.0.0.1 to 0.0.0.0, that is from listening for connections only from your computer, to listening for connections from any computer in your local network. This is usually necessary for me since the host used to run RDP is a windows machine, and my tools are located on an adjacent linux machine.

Once this is done, open up Remote Desktop Connection and type in the relevant hostname etc.

Upon clicking connect, you should see this little pop-up:

Then, once you’re on the machine, copy over SocksOverRDP-Server.exe and run it (you should not need elevated permissions for this):

Citrix Workspace⌗

Citrix is much of the same steps, but it’s important to note that the Citrix Workspace application uses 32-Bit RDP.

Additionally, you might be scoped to a single application inside Citrix, and so running SocksOverRDP-Server.exe is difficult. Don’t worry though, because it is very possible to breakout of Citrix applications, just look at:

• Breaking out of citrix and other restricted desktop environments (and yes this article is old, but it’s all still relevant)
• Breaking Out! of Applications Deployed via Terminal Services, Citrix, and Kiosks

Basically, it’s very similar to a kiosk breakout, so any tutorial for that is also relevant:

• Kiosk BREAKOUT - Web Browser to Command Prompt (Easy Mode) - John Hammond
• Kiosk BREAKOUT - Web Browser to Command Prompt (Hard Mode) - John Hammond

I might make a future blog post showing off what this looks like in current windows, but making a Citrix Gateway lab environment has its own challenges.

Wrap-Up⌗

In conclusion, Reverse SOCKS is a highly effective technique that allows penetration testers to overcome deployment challenges and efficiently target internal networks. By splitting up the proxy components across two machines the levels of access required on the victim host are greatly reduced, while still allowing for full access to an internal network.