Protecting Admin Passwords During Remote Response and Forensics

PsExec

[Update: I've posted a new "Deep Dive" article on PsExec. I recommend taking a look at this article for even more details on PsExec, including how to use it safely and the forensic artifacts it leaves behind.]

PsExec has been a great tool for remotely executing processes on a Windows machine. It has been around for years and is one of many useful tools from Mark Russinovich (formerly of SysInternals, now with Microsoft). As described on PsExec's webpage, "PsExec is a light-weight telnet-replacement that lets you execute processes on other systems, complete with full interactivity for console applications, without having to manually install client software."

That said, there is a significant drawback to PsExec's default behavior, as described in the last sentence of the description on PsExec's webpage: "Note that the password is transmitted in clear text to the remote system."

This is something that needs to be seriously considered and accounted for when using PsExec. Corporate incident responders typically have domain administrator rights for response purposes. The idea of passing your domain administrator password in the clear is frightening and should be avoided. Luckily, we have options.

First, there is an easy workaround you can employ with PsExec to avoid sending your password in clear text. The trick is to first mount the IPC$ share of the remote computer and then use PsExec. Jean-Baptiste Marchand has written an excellent article about this technique, as well as several other remote administration tips.

Let me show the difference between the default behavior and the IPC$ technique.

TEST 1:

First I'll show the result of using PsExec as-is, without password protection.

I used the following command to connect to the suspect PC at 192.168.253.130, mount the trusted CD-ROM being shared on 192.168.253.128, and spawn a command shell from the mounted CD:

C:\>psexec.exe -u testxp\testadmin -p testpassword \192.168.253.130 cmd "/C net use x: \192.168.253.128\cdrom & x:\ir\xp\cmd.exe"

Now I'll show the workaround technique which does not send the password in the clear. Note that I first reverted to snapshot on the test VM in order to remove any chance of cached credentials. Also, I started the Wireshark capture before mapping the IPC$ share.

First I mapped the IPC$ share with my "testadmin" account and password of "testpassword":

C:\>net use \192.168.253.130\IPC$ /u:testxp\testadmin *

Type the password for 

 \192.168.253.130\IPC$: testpassword

The command completed successfully.

Then I ran the same PsExec command as above, except I omitted the username and password:

C:\>psexec.exe \192.168.253.130 cmd "/C net use x: \192.168.253.128\cdrom & x:\ir\xp\cmd.exe"

So the IPC$ workaround is very handy because there are times when it is nice to use PsExec, such as when you need interactive access to the suspect PC via a command shell, as shown above. However, in just about all other cases, I've begun using WMIC in place of PsExec. I'll have more on that in a follow up post later this week.

Mike Pilkington, GCFA, EnCE, is a Sr. Security Analyst and Lead Incident Responder for a global Fortune 500 company in Houston, TX, as well as a SANS Mentor. Visit http://www.securityscaper.com for more on Mike's activities and SANS Mentor schedule.