Multi-Host and OS Pivoting Using Secure Socket Funneling

During some recent self-study, I encountered a scenario where I wanted to use WinRM on a machine and couldn't from Kali due to the limitations of Powershell Core. The target machine was also two pivots deep, so I needed a way to move through those networks to connect to WinRM.

My VPN was running on Kali, and while I could disconnect it and switch to a Windows machine, I still wanted tools on Kali to be available.

Secure Socket Funneling (SSF) to the rescue.

But first, an example of what the environment looks like.

Network Layout

This a sample of what the network looks like. Hopefully it's not too difficult to follow.

  • Windows Machine
    • VM Network 192.168.11.3
  • Kali Machine
    • VM Network 192.168.11.4
    • VPN Network 10.0.1.14
  • Target Environment Host A - Linux
    • External IP 10.0.0.100
    • Internal IP 172.16.1.100
  • Target Environment Host B - Windows - this machine is running OpenSSH.
    • Internal IP 172.16.1.5
  • Target Host C
    • Internal IP 172.16.2.20
  • Kali can connect to Host A only.
  • Host A can connect Host B only.
  • Host A is firewalled and can't listen on on any extra ports on 10.0.0.100

Setting up the SSF Daemons

SSF binaries: https://securesocketfunneling.github.io/ssf/#download

Host B

We need to get SSF onto the machine, so grab the Windows binaries from the SSF website. We can these over using SCP.

To do this, we need to jump via Host A. Assuming we have some way of unzipping on the Windows machine, perform the following:

scp -J root@10.0.0.100 ./ssf-windows.zip user@172.16.1.5:

If we don't have an easy way to unzip the file, you can recursively the directory over using the following:

scp -r -J root@10.0.0.100 ./ssf-windows/extracted/ user@172.16.1.5:

If the host weren't running OpenSSH, you would need to use another method such as WinRM using this same process.

Once complete, we can now ssh in and set up the daemon by doing the following:

ssh -J root@10.0.0.100 user@172.16.1.5

Then followed by kicking off the ssfd daemon to listen on port 63000:

Expand-Archive ssf-windows.zip
cd .\extracted
.\ssfd -p 63000

Host A

For Host A, grab the Linux binaries and them over. This process is the same as Host B but without the jump host '-J' option.

In this scenario, due to the firewall, we only listen on localhost.

scp ./ssf-windows.zip root@10.0.0.100
ssh root@10.0.0.100
./ssfd -p 63000 -l 127.0.0.1

Kali Machine

Since we need to get the traffic through to Host A, we'll use ssh local port forwarding to get around the firewall issue.

The below command sets up ssh to listen on 1111 and forward it to 63000 on Host A:

ssh -L 1111:127.0.0.1:63000 root@10.0.0.100

Now we set up ssfd on our Kali host. Unzip SSF on Kali and from within the extracted folder run:

./ssfd -p 63000

If you have an SSH server running on your Kali host, you could use SSH forwarding from Windows, but I think that's a bit messier.

Windows Machine

SSF supports routing via several intermediate hosts. To do this, we configure the below JSON config file:

{
  "ssf": {
    "circuit": [
      {"host": "192.168.11.4", "port":"63000"},
      {"host": "127.0.0.1", "port":"1111"}
    ]

    }
  }
}

This config does the following

  1. Connects to Kali
  2. Connect to Host A via localhost on Kali (the SSH local port forward)

Info on configuring the relay hosts can be found at https://securesocketfunneling.github.io/ssf/#how-to-use-relay-servers

Host B is the last hop, so we don't need it in the config. To connect, we run the following:

.\ssf.exe -c config.json -D 9000 -p 63000 172.16.1.5

We now have dynamic port forwarding on the Windows machine listening on port 9000, which is essentially a socks proxy. Dynamic port forwarding isn't necessarily what we want as we need WinRM. With SSF, you can perform both TCP and UDP forwarding.

We can set up SSF to forward to the WinRM HTTP port on 5985:

.\ssf.exe -c .\c.json -L 6666:172.16.2.5:5985 172.16.1.20 -p 63000

And now we can finally connect to WinRM:

$s = New-PSSession -Port 6666 -ComputerName 127.0.0.1 -Credential 'username'
Enter-PSSession $s

Local UDP/TCP Forwarding Example and Notes

I don't think it's evident in the SSF docs, but you can perform multiple forwards much like SSH, and you can forward both UDP and TCP for the same port.

Here's an example of forwarding some Domain Controller ports to a Windows host on Kali a lot of the UDP ports aren't requried but I assembled this with regex and it was easier.

./ssf  -L 445:172.16.2.5:445 -U 445:172.16.2.5:445 -L 636:172.16.2.5:636 -U 636:172.16.2.5:636 -L 389:172.16.2.5:389 -U 389:172.16.2.5:389 -L 464:172.16.2.5:464 -U 464:172.16.2.5:464 -L 139:172.16.2.5:139 -U 139:172.16.2.5:139 -L 135:172.16.2.5:135 -U 135:172.16.2.5:135 -L 593:172.16.2.5:593 -U 593:172.16.2.5:593 -L 3268:172.16.2.5:3268 -U 3268:172.16.2.5:3268 -L 3269:172.16.2.5:3269 -U 3269:172.16.2.5:3269 -L 88:172.16.2.5:88 -U 88:172.16.2.5:88 -L 137:172.16.2.5:137 -U 138:172.16.2.5:138  -p 63000 172.16.1.20

With the above, you could run enum4linux or crackmapexec against 127.0.0.1. Note that you may need to also provide a DC IP for some commands that talk to Kerberos. Check your command's options and if this is required, set it to 127.0.0.1 in addition.

And that's it.

The SSF docs are available at https://securesocketfunneling.github.io/ssf/#home

Depending on the environment, a lot of this can be achieved using SSH forwarding.

Previous
Previous

OPNSense UPnP

Next
Next

Extracting Public IPs from an Azure Tenant