SANS Digital Forensics and Incident Response Blog

Protecting Privileged Domain Accounts: PsExec Deep-Dive

[Author's Note: This is the 6th in a multi-part series on the topic of "Protecting Privileged Domain Accounts". My primary goal is to help incident responders protect their privileged accounts when interacting with comprised hosts, though I also believe this information will be useful to anyone administering and defending a Windows environment.]

PsExec is an extremely powerful tool and is used commonly in enterprise networks, for both good and evil. Systems administrators and incident responders use it for its flexibility in interacting with remote machines, including a telnet-like ability to run command-line tools on remote machines and receive the output on their local console. Attackers utilize it for the same reasons, providing a convenient way to move laterally and interact with remote machines using compromised credentials.

Given its power, you might wonder what the ramifications are of using this tool on a compromised machine. In other words, could it lead to your credentials being compromised? In this article, I'll discuss the two "native" methods of logging onto a remote machine with PsExec and why you should always avoid one of the two. I'll also discuss possible workarounds to the second, more dangerous logon. Finally, since attackers have been known to use this tool for lateral movement, I'll follow up the logon discussion with a brief forensic analysis of the artifacts you will typically find from PsExec usage.

2 Types of Logons with PsExec

It's easy to overlook that fact that there are two distinct ways to logon to a remote host with PsExec. The first method is to run PsExec under the context of the currently logged-on user. This requires no special switches or specification of an account. It simply uses the logged-on account to authenticate to the remote machine. As we'll see in a moment, this results in a network logon to the remote machine.

The second method is to specify an alternate account using the "-u" switch and optionally the "-p" switch (if you don't supply "-p", it behaves the same but will prompt you for the password). This allows you to authenticate to the remote machine as a different user. This would commonly be a user with higher privileges than your currently logged-on account. While this is often convenient, it provides more than just convenience?it also provides a full interactive logon, which loads all the user's credentials on the remote host. This has the benefit of allowing a user to authenticate to another system from the remote host, but it also carries the significant drawback of exposing NT & LM hashes, Kerberos Ticket Granting Ticket (TGT), and clear-text passwords to malware on the remote host. We clearly don't want to do this on an untrusted host!

An important side note here is to be aware that both logon methods for PsExec have the potential of creating the delegate-level access token, if the remote system is trusted for delegation. This is also a significant risk, though not as commonly exploited. As discussed in my article on access tokens, we fortunately have a simple fix available by enabling the setting "Account is sensitive and cannot be delegated", which is recommended by Microsoft for sensitive accounts. Please refer to the access token article for complete details.

Ok, so let's have a look at these two logon methods in action.

Testing: PsExec with logged-on user account

In the following screenshot, I'm logged onto machine IR-XP-PC as MSAD2-RESPONDER1. I've initiated a PsExec logon from the local host to the remote host named USER-XP-PC. Since I did not specify "-u", the currently logged-on user will use standard Kerberos or NTLM integrated authentication to connect to the remote host. Once connected, I ran a couple of commands to show that I am still MSAD2-RESPONDER1 and am now executing commands on USER-XP-PC.

The following screenshot shows the relevant Event Log from the PsExec logon. This connection created only a Type 3 network logon, which is the safe way to connect to a remote host, as discussed in my previous article on password hashes.

To confirm the logon type and the fact that password hashes are not revealed, here's the relevant output from Sysinternals' logonsessions tool?again showing a network logon for MSAD2-RESPONDER1. The screenshot also shows the output of Windows Credentials Editor (WCE), which verifies the hash is not in memory for the MSAD2-RESPONDER1 account.


So the good news is that we've seen that a standard connection with PsExec, using the currently logged-on user's credentials, results in only a network logon. This is the safe way to execute PsExec remotely.

Now let's look at the other authentication method with PsExec.

Testing: PsExec with Alternate Credentials "-u" option

This time I'm logged on locally with a non-privileged account and will then log on remotely using a privileged account, MSAD2-RESPONDER1.

Examining the logs on the remote machine, we initially see a network logon (Type 3), but then 1 second later we see an interactive logon (Type 2) for our alternate credentials user, MSAD2-RESPONDER1.

This interactive logon causes the credentials of the responder account to be loaded and available for an attacker to steal. The following screenshot shows the currently logged on sessions for MSAD2-RESPONDER1 (two of them), and as expected, WCE shows us the password hashes for MSAD2-RESPONDER1.

To make matters worse, an additional concern with the "-u" option is that it sends the password in clear-text in order to generate the interactive logon. Microsoft Sysinternals warns us of this issue on their PsExec download page. Here is a screenshot of Wireshark showing the password being sent over the network in the clear (password = responder1-pw1):


Conclusions on PsExec Logon Methods, with Workarounds

It is clearly not safe to use PsExec's "-u" option on an untrusted remote host. On the other hand, using PsExec without "-u" and therefore authenticating as the currently logged-on user is much safer and does not expose the account to theft of password hashes, the Kerberos TGT, or the plain-text password itself. As mentioned earlier, there is still the possibility of the account's delegation token being stolen, as discussed in my article on access tokens. The simple fix for this risk is to enable the setting "Account is sensitive and cannot be delegated", as discussed in the article.

The ability to specify alternate credentials is a useful one, and fortunately, there are a couple of ways we can still make this work without divulging credentials on the remote host.

One possibility is the use of RunAs. For example, I logon to my machine as a standard user, but will often need to connect to a remote machine with a privileged account. For me, the easiest way to do this, while still being safe assuming my local machine is not compromised, is to spawn a new CMD command shell as the privileged account, using the command "RunAs.exe /user:domain\user cmd.exe". As I discussed in my article on hashes, using RunAs will still result in an interactive logon, but at least I'm doing it on my trusted workstation rather than the untrusted remote host.

RunAs is a good option in many cases, but there are situations where using RunAs is not feasible. For example, if the machine you are using is not a part of the privileged account's domain. It turns out there is another workaround that can allow you to specify alternate credentials but not create an interactive logon. The workaround is described in another PsExec article I wrote a couple of years ago. The suggested workaround is to first connect to the IPC$ share of the remote host using the alternate account, and then use PsExec without "-u". The process looks like this for my current test setup:

When performed this way, my tests show that only a network logon is created (no interactive logon) and also the password is not sent in clear-text (presumably since there is no interactive logon). I'd recommend you confirm this in your own environment before using it in production. The main thing to check for is that there is no Type 2 interactive logon in the logs of the remote host.


A Forensic Overview of PsExec

Since we sometimes see attackers use PsExec for lateral movement, let's take the discussion a step further and look at some artifacts that could reside from PsExec usage. The artifacts presented here are the direct result of using PsExec in my tests above. Of course there are other ways of utilizing PsExec, so the resulting artifacts may vary.

When PsExec executes on a remote machine, the local machine sends a service executable named PSEXESVC.EXE to the remote machine and that executable is installed as a service. Here's a look at that service running on the remote host. Notice the service executable resides in C:\WINDOWS.

Once the user has cleanly logged off (exited) PsExec, the service is removed and PSEXESVC.EXE is deleted. Although PsExec is deleted (as indicated by the red X icon), the screenshot below shows the file and its metadata. Notice the UTC creation and modification times correspond to the second logon time in my tests above (12/15/12 9:43:20 PM Central time).

Also notice that the owner of this file is the user who connected remotely to run PsExec.


A profile is created for this user at the time of first login, if it didn't already exist. This is regardless of whether an interactive logon occurred or not. Here are the timestamps for the MSAD2-RESPONDER1 account's profile folder. Notice the UTC creation timestamp is the same time of the first logon in the tests above (12/12/12 9:52:27 PM Central time).

Prefetch shows both the first time the service executable was run (Prefetch file creation time minus 10 seconds) and last time run (Prefetch file modification time minus 10 seconds).

The Application Compatibility Cache shows this as well, with an entry for both times run.


Since PsExec is typically run remotely, these run times can be used to examine the Event Logs and look for network logons at the same time. The corresponding Event Logs for these PsExec executions are shown in the screenshots at the beginning of this article.

When PsExec is exited, the PsExec service is removed, but you may find the deleted service key still in the Registry. Here is the deleted key shown by YARU. Note that the last write time of the key corresponds to the time the responder account logged out and exited PsExec the second time (12/15/12 9:49:13 PM Central time)


Final Thoughts

I've found that there are safe ways to use PsExec, but unfortunately it is not obvious how to do so. Hopefully this discussion has provided a deeper understanding of the tool and how you can use it safely, as well as analyze the forensic artifacts it can leave behind.


Mike Pilkington is a Sr. Information Security Analyst and Incident Responder for a Fortune 500 company in Houston, TX, as well as a SANS Mentor and Community Instructor. Mike will be teaching FOR408: Computer Forensic Investigations - Windows In-Depth in Phoenix, AZ, Jan 14-19, 2013 and FOR508: Advanced Computer Forensic Analysis and Incident Response in Houston, TX Feb 5 - Apr 9, 2013.


Posted December 19, 2012 at 3:49 PM | Permalink | Reply

Tom Yarrish

Have you done any testing if you execute PSEXEC with the -e (don't load the user's profile) or -s (run as System account) options? Just curious how the forensic artifacts change.

Posted December 21, 2012 at 9:41 PM | Permalink | Reply

Mike Pilkington

Hi Tom,
As you know, with PSEXEC -s, it will launch the remote process (cmd.exe in my case) under the SYSTEM account. This works fine when logging on with PSEXEC without specifying alternate credentials (which we determined is safe, other than the access token issue I mentioned). However, when you need to log on with alternate credentials using -u, and you also specify -s, PSEXEC fails. Here's an example:

C:\\>psexec \\\\user-xp-pc -s -u msad2\\msad2-responder1 cmd.exe
PsExec v1.98 - Execute processes remotely
Copyright (C) 2001-2010 Mark Russinovich
Sysinternals -
Couldn't access user-xp-pc:
Access is denied.

When I examined the Event Logs on the remote host, it showed the logon attempts originating from my standard user account, MSAD2-USER1. Since this was not the privileged account and therefore did not have rights to start PSEXEC on the remote machine, access is denied. So unfortunately, we can't use -s as a workaround for connecting with alternate credentials.
Regarding the -e option, it works exactly the same as without -e except the profile is not created (as expected). Here's what it looks like in from my testing:

C:\\>psexec \\\\user-xp-pc -e -u msad2\\msad2-responder1 cmd.exe
PsExec v1.98 - Execute processes remotely
Copyright (C) 2001-2010 Mark Russinovich
Sysinternals -
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.
C:\\WINDOWS\\system32>hostname & whoami

The Event Logs on the remote host show that there were still 2 logons, a network Type 3 followed by an interactive Type 2, both by the privileged account MSAD2-RESPONDER1. Since an interactive logon was generated, it will still expose hashes, Kerberos TGT, and the password of the privileged account.
From the forensics point of view, it does not create the user profile under "Documents and Settings" or "Users", so yes that would result in fewer artifacts on the remote host.
Hope that helps!
Thanks, Mike

Posted December 20, 2012 at 5:19 PM | Permalink | Reply


Mike, thanks for all of this research into safe ways to log into remote machines and the artifacts the different methods leave behind. One quick question, though. Your screen shots show the service as being named "PSEXESVC.exe" but the blog text says "PSEXECSVC.exe." Which is right?

Posted December 21, 2012 at 9:51 PM | Permalink | Reply

Mike Pilkington

Hi Jon,
Glad to hear you've found the information helpful, and that you're reading with such a keen eye! I didn't notice the typos, but you are correct, the actual name is PSEXESVC.EXE''no "C". I just updated the article. Thanks!

Posted April 16, 2013 at 9:30 PM | Permalink | Reply

Nate Schoolfield

Heya Mike, I love your series, even if it does make me nervous about our current practices.
Anyway, I thought I'd pass along a tidbit that I haven't seen referenced, and that's a way to replace non-interactive mode PSEXEC with WMIC to achieve an encrypted session (unless I'm wrong!).
Here's the command:
wmic /node:$target /authlevel:Pktprivacy process call create "net user administrator $newpassword"

Posted April 19, 2013 at 2:23 AM | Permalink | Reply

Mike Pilkington

Hi Nate,
Thanks for compliment and for the tip! I hadn't noticed Pktprivacy. Looks like a nice feature. It also looks to be the default authlevel, which is nice:
Thanks again!

Posted April 17, 2013 at 2:53 PM | Permalink | Reply


Hi Mike,
In Workarounds part you say,
"using RunAs will still result in an interactive logon, but at least I'm doing it on my trusted workstation rather than the untrusted remote host."
Are not you running all the commands in this article on your trusted workstation?
Are not your hashes going to untrusted machine with runAs?
are your hashes will stored on your trusted workstation or where?
How a workaroud is that I coudln't get it.

Posted April 19, 2013 at 2:05 AM | Permalink | Reply

Mike Pilkington

Hi Emre,
Let me try to answer each of your questions''
Are not you running all the commands in this article on your trusted workstation?
''">Yes, I'm running them on my trusted machine. However, if I run ''psexec -u' from my trusted machine, it sends the password to the remote untrusted machine and performs an interactive logon. We need to avoid this. So one workaround was to use RunAs to lunch a new command shell as my privileged account on my trusted machine and then logon using psexec without ''-u'. This avoids sending the password and creating the interactive logon on the remote untrusted host.
Are not your hashes going to untrusted machine with runAs?
''">Not in the scenario I just described, because I would be authenticating with a network logon.
are your hashes will stored on your trusted workstation or where?
''">Yes, the hashes of my privileged account will be stored on my local trusted workstation once I use RunAs to start a command shell as that user.
How a workaroud is that I coudln't get it.
''">If you're asking why it is a workaround, it's a workaround in the sense that I can connect to a remote machine using a privileged account without having to use the ''-u' option. Instead it uses the credentials of the currently logged on privileged user within the RunAs session.

Posted April 19, 2013 at 2:01 PM | Permalink | Reply


If you make a network logon (where you just described I could not find it, sorry, I also checked your hashes article with ctrl f) before interactive logon (runAs makes here), why you cannot use psexec without -u.
Note that, your articles are perfect, I want to clear only one line in tons of line (6 article). Again thanks much. After clearing it, you can delete these comments.

Posted April 24, 2013 at 9:38 PM | Permalink | Reply

Mike Pilkington

Emre, I'm sorry but I may not understand your question. In any case, if you make a network logon first to the remote IPC$ share, as I suggested above and in the article, then yes, you can connect without "-u" and psexec will not create an interactive logon. Regarding network logons, I discussed those in the hashes article ( They are "Type 3" logons in the Windows Event Logs.
I hope that helped.
Thanks, Mike

Posted October 22, 2013 at 12:03 PM | Permalink | Reply


Can you tell me if it is possible to run remotly application using psexec as a user right now login ? but no as admin account which I use to remote credential login (switch -u and -p)? My goal is to stop one process and I don't have problem with it, but I also need to start this process and it is tricky, because it is exe file and it has to be started as a user who password I don't have. Maybe there is another way?

Posted September 5, 2014 at 6:27 AM | Permalink | Reply


I am using psexec.exe to run remote commands of a host which is on another domain. If i use hostname, i am unable to run the commands, and if i use ip address of the host then i am able to run the commands. To resolve the ip address using hostname, i added the host information in the hosts file as well. But still unable to run the remote commands using hostname. Could you please suggest me how can i solve this problem.

Posted October 30, 2014 at 1:32 PM | Permalink | Reply


Hi, nowadays communication between client and server is encrypted from version 2.1. Here is quote from changelog:
"PSExec v2.1: This update to PsExec, a command-line utility that enables you to execute programs on remote systems without preinstalling an agent, encrypts all communication between local and remote systems, including the transmission of command information such as the user name and password under which the remote program executes."
I've tried to catch password via Wireshark but it's encrypted so sending plaintext passwords are gone.