<lport> - local port to listen on <lhost> - local address to bind to <rport> - remote port <rhost> - remote host
This would bind locally to 0.0.0.0 (all network interfaces) on 1194/tcp and route incoming connections to remote host 10.10.10.20:8080. This particular example might be used to reach a web application that’s sitting behind a restrictive firewall.
Why this technique?
This pivoting technique is an example of living off the land to expand access with the added benefit of stealth. It comes in handy when options are limited or when there’s a genuine concern of being noticed by AV or HIPS sitting on the endpoint. Using netsh to temporarily modify firewall tables is much less likely to be flagged by one of these products than a malicious or unknown executable, and it requires no uploading of software to the target host.
From a detection standpoint, this technique demonstrates the need for baselining. Comparing network traffic and system behavior against a solid baseline in order to detect anomalous behavior should be part of any proper defense-in-depth strategy. Unfortunately, this is a concept foreign to many security teams. A colleague of mine and I are currently researching and developing a simple tool to help organizations capture these kind of baselines - more info to come as we develop.
To give this technique a bit more context, here’s how I utilized this feature during a recent engagement:
I had obtained admin creds and had access to a Domain Controller via SMB. An Nmap scan showed that the network firewall allowed me to also get to 88/tcp, 389/tcp, and some of the high-range TCP ports (49152, 49153, etc.) on the DC as well. However, the network firewall didn’t allow me to reach back to my attack host, so reverse connections were out of the question. I couldn’t reach RDP, and all quick attempts to get a Meterpreter session going failed. I tried altering the local firewall, but it got me nowhere due to the restrictive network firewall rules. I really wanted to use this DC as a pivot point to get to some juicy targets that I suspected had RDP exposed.
Within my winexe session, I ran netstat on the DC (10.10.10.10) to figure out which high-range TCP port would be available for me to bind to:
I decided to bind to 0.0.0.0:49162, seeing as it was unused and I could most likely reach it through the network firewall. I used the netsh interface portproxy command to forward my traffic to a database server located at 10.10.10.20:3389:
The pivot point was set on the DC. I could now connect xfreerdp to my newly-created listener and have my traffic forwarded to the secondary host:
Woo, thanks netsh!
This is an example of using netsh interface portproxy to establish pivoting routes over IPv4, but it’s also possible over IPv6, and even IPv4-to-IPv6 (and vice versa). Check out the documentation from Microsoft here.
This should work out of the box on Windows 2008 and later. It should also work on Windows 2003, but it may error out if IPv6 isn’t supported on the host. More info here.