Using winrelay or fpipe for port redirection via a Windows host

When attacking networks in a pentest, it is sometimes useful to be able to redirect tcp or udp traffic, via an intermediary system.

This may be to obfuscate the source of the attack, or perhaps because the victim host (ip address and port combination) is not directly accessable for the attacking machine.

This is commonly used in pivoting, i.e. to attack an initial host, and then use that compromised system to attack other systems on the network, which were not initially accessable.

Here we look at two Windows commandline tools which can be used for port redirection; winrelay and fpipe, and test them.

These techniques should only be used on your own test systems, or where you have express permittion to do penetration testing.

winrelay from ntsecurity.nu

This tool can be downloaded here and there are various options:

Let's look at an example:
The command below would be run on the intermediary system. The victim system in this case is 192.168.10.132 on port 80. 

C:\>winrelay.exe -lip 0.0.0.0 -lp 81 -dip 192.168.10.132 -dp 80 -proto tcp

WinRelay 2.0 - (c) 2002-2003, Arne Vidstrom (arne.vidstrom@ntsecurity.nu)
             - http://ntsecurity.nu/toolbox/winrelay/

This can be tested easily by using netcat and typing a simple HTTP GET request from the attacking system. For example

nc -nvv 192.168.11.96 81
(UNKNOWN) [192.168.11.96] 81 (?) open
HEAD / HTTP/1.0

HTTP/1.1 200 OK
Date: Mon, 22 Nov 2010 13:05:55 GMT
Server: Apache/2.2.9 (Ubuntu) PHP/5.2.6-bt0 with Suhosin-Patch
Last-Modified: Mon, 22 Nov 2010 09:01:37 GMT
ETag: "259f4a-9-495a080ea7e40"
Accept-Ranges: bytes
Content-Length: 9
Vary: Accept-Encoding
Connection: close
Content-Type: text/html
 
sent 17, rcvd 306

So that worked fine, but winrelay doesn't log any connections to the screen, so not much to see on the intermediary system.

In my testing I also tried using wfuzz to try to brute force some common webserver file locations on my victim system using the relay. It worked well and here is the output:

Fpipe.exe from foundstone

This tool can be downloaded here and, again there are various options, so we will do a similar test to that above:

C:\Documents and Settings\Administrator\Desktop>fpipe -l 82 -c 512 -r 80 192.168.10.132
FPipe v2.1 - TCP/UDP port redirector.
Copyright 2000 (c) by Foundstone, Inc.
http://www.foundstone.com

Pipe connected:
   In:   192.168.10.132:41609 --> 192.168.11.96:82
  Out:    192.168.11.96:4075  --> 192.168.10.132:80
Pipe connected:
   In:   192.168.10.132:41629 --> 192.168.11.96:82
  Out:    192.168.11.96:4076  --> 192.168.10.132:80

As you can see, Fpipe logs connections to the screen, so more to see, and the HTTP GET request test from the attacking system (below) works as expected.

nc -nvv 192.168.11.96 81
(UNKNOWN) [192.168.11.96] 81 (?) open
HEAD / HTTP/1.0
HTTP/1.1 200 OK
Date: Mon, 22 Nov 2010 13:14:03 GMT
Server: Apache/2.2.9 (Ubuntu) PHP/5.2.6-bt0 with Suhosin-Patch
Last-Modified: Mon, 22 Nov 2010 09:01:37 GMT
ETag: "259f4a-9-495a080ea7e40"
Accept-Ranges: bytes
Content-Length: 9
Vary: Accept-Encoding
Connection: close
Content-Type: text/html

 sent 17, rcvd 306



However, I found difficulty in getting the web brute force attack to work using fpipe. I will have to have a look with wireshark when I have more time to see what was going wrong...