Port Forwarding with Windows
ssh.exe
The OpenSSH client has be bundled by default with windows since 2018 and has been available as a Feature-on-Demand since Windows 10. On Windows versions with SSH installed, we will find scp.exe, sftp.exe, ssh.exe along with other ssh-* utilities in %systemdrive%\Windows\System32\OpenSSH location by default.
The fact that the SSH client is compiled for Windows doesn't mean that we can only connect to Windows-compiled SSH servers. We can connect to any SSH server we want - as long as we have the credentials.
ssh.exe dynamic port forwarding scenario
Using the same scenario from the Port Forwarding on Linux and SSH Tunneling examples, we will set up dynamic port forwarding with ssh.exe on a Windows machine.
On MULTISERVER03, check for ssh installation:
Next check the version of SSH
The OpenSSH version bundled with windows needs to be higher than 7.6 for dynamic port forwarding
Plink
If OpenSSH is not available on a client, even on a more recent version of Windows, frequently found alternative tools were PuTTY and its command-line-only counterpart, Plink.
One of the benefits of using tools that are popular with network administrators is that they are rarely flagged by traditional antivirus software. From an attacker perspective this is a relatively covert compared to other tools.
Plink Scenario
Transfer the Plink binary to the Windows machine. We can use Plink to set up a remote port forward so we can access the MULTISERVER03 RDP port from our attackbox. The syntax to set up a remote port forward with Plink is very similar to the OpenSSH client remote port forward command. After the -R option, we'll pass the socket we want to open on the Kali SSH server, and the RDP server port on the loopback interface of MULTISERVER03 that we want to forwawrd packets to.
much the same way that it's not possible to accept the SSH client key cache prompt from a non-TTY shell on Linux, with some very limited shells with Plink on Windows, we also won't be able to respond to this prompt. An easy solution in that case would be to automate the confirmation with cmd.exe /c echo y, piped into the plink.exe command. This will emulate the confirmation that we usually type when prompted. The entire command would be: cmd.exe /c echo y | .\plink.exe -ssh -l kali -pw <YOUR PASSWORD HERE> -R 127.0.0.1:9833:127.0.0.1:3389 192.168.41.7.
Netsh
There is a native way to create a port forward on Windows we should explore: the built in firewall configuration tool Netsh (also known as Network Shell). Using Netsh we can set up a port forward with the portproxy subcontext within the interface context. While Netsh requires administrative privileges to create a port forward on Windows, it can be very useful in some restrictive situations.
Let's consider a slight modification of the previous scenario. MULTISERVER03 is serving its web application on TCP port 80 on the perimeter. CONFLUENCE01 is no longer accessible on the WAN interface. For simplicity, the firewall on MULTISERVER03 also allows inbound TCP port 3389, meaning we are able to log in over RDP directly.
We want to SSH into PGDATABASE01 directly from our attackbox. To do this we need to create a port forward on MULTISERVER03 that will listen on the WAN interface and forward packets to the SSH port on PGDATABASE01
The portproxy subcontext interface command requires administrative privileges to make any changes. This mean that in most cases we will need to take UAC into account. For this example, we're running it in a shell over RDP using an account with administrator privileges, so UAC is not a concern. However, we should bear in mind that UAC may be a stumbling block in order setups.
We'll instruct netsh interface to add a portproxy rule from an IPv4 listener that is forwarded to an IPv4 port (v4tov4). This will listen on port 2222 on the external-facing interface (listenport=2222 listenaddress=192.168.50.64) and forward packets to port 22 on PGDATABASE01 (connectport=22 connectaddress=10.4.50.215).
Although we don't receive any output from the command, we can confirm that port 2222 is listening using netstat.
We can also confirm that the port forward is stored by issuing the show all command in the netsh interface portproxy subcontext.
Here is how the port proxy is set up now
However, we still cannot connect to port 2222 on MULTISERVER03 from our attackbox due to the firewall. We will need to poke a hole in the firewall on MULTISERVER03 but using netsh advfirewall firewall. We will use the add rule command and name the rule "port_forward_ssh_2222". We need to use a memorable or descriptive name, because we'll use this name to delete the rule once we are done using it.
The command completes successfully with an "Ok." response. We can check how the port appears from our attackbox now using nmap
To delete the firewall rule:
To remove our port forwarding interface:
Last updated