SANS Digital Forensics and Incident Response Blog

SANS Digital Forensics and Incident Response Blog

Protecting Admin Passwords During Remote Response and Forensics


[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.


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, mount the trusted CD-ROM being shared on, and spawn a command shell from the mounted CD:

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

The following screenshot shows the resulting packet capture in Wireshark. I located the clear text password using Wireshark's "Edit -> Find Packet" feature, searching for the string "testpassword":

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 \\IPC$ /u:testxp\testadmin *

Type the password for \\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 \ cmd "/C net use x: \\cdrom & x:\ir\xp\cmd.exe"

The following screenshot shows the resulting packet capture in Wireshark.

I was unable to locate the password using Wireshark's "Edit -> Find Packet" feature, searching for the string "testpassword":

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 for more on Mike's activities and SANS Mentor schedule.


Posted June 2, 2010 at 2:56 AM | Permalink | Reply

Cory Altheide

This protects the passphrase from unlikely threat of being sniffed across the network but does nothing to prevent incredibly likely threat of the domain administrator's hash from being captured _on the remote compromised system being investigated_ and used via pass-the-hash.

Posted June 3, 2010 at 2:36 PM | Permalink | Reply

Mike Erman

In the scenario where the incident responder has domain admin rights, then you can go directly to running psexec without the username and password options. Psexec defaults to using the tokens of the user initiating it and does not send the password with the session.

Posted June 4, 2010 at 1:59 PM | Permalink | Reply

Dave Hull

Cory you raise a great point and I'm sure you've thought about alternative solutions. Are there any safe methods for connecting to that compromised host via the network?

Posted June 7, 2010 at 5:34 PM | Permalink | Reply


Cory, thanks for your comment. You bring up an excellent point and one I should have mentioned in the blog. However, after some extensive testing this weekend, I don't believe this is an issue with PsExec (used in the way I described). I tested with fgdump, pwdump3, Cain, and Metasploit. I'll post a new blog in the next week or two showing my test process and results. Please let me know if there are other tools I should include in my tests. Thanks! -Mike

Posted October 23, 2010 at 4:00 PM | Permalink | Reply

bharath vn

I'm seeing the same problem. I can get around it by using the -d argument, but that means I don't get back the return code from the process I started remotely.
It gives the workaround, but not ideal.

Posted October 25, 2010 at 3:18 PM | Permalink | Reply


Hi bharath vn. I'm not sure what problem you are running into. Can you give more details? Is the PSEXEC command failing to give you a shell or connect to the network share? You'll want to make sure that share is open to "Everyone" but with read-only permissions. Typically the share will simply be a set of trusted binaries and tools, so the fact that it's open read-only to Everyone should not be an issue.

Posted August 13, 2012 at 11:03 AM | Permalink | Reply


So now you're sending away net use's password in clear text, what's the difference?

Posted August 14, 2012 at 3:46 AM | Permalink | Reply

Mike Pilkington

The password is not sent in clear-text with NET USE. The NET command uses native Kerberos or NTLM/LM challenge response.

Posted December 14, 2012 at 9:33 PM | Permalink | Reply


Mike ''" Great stuff !! This actually works ! Thanks a ton.

Posted February 2, 2013 at 2:59 PM | Permalink | Reply

Saiful Bahri bin Sulaimi

Hello, I tested this workaround but I still couldn't use psexec and access a network path from the remote computer. Can anyone confirm this ?