{ "id": "832def30-4b4a-433d-84b7-cd57434949f4", "created_at": "2026-04-06T00:21:32.784382Z", "updated_at": "2026-04-10T03:24:29.917596Z", "deleted_at": null, "sha1_hash": "c94c6113ccc7099296b6f4cbe1a68e8c4407e8b8", "title": "Protecting Privileged Domain Accounts: PsExec Deep-Dive", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 531344, "plain_text": "Protecting Privileged Domain Accounts: PsExec Deep-Dive\r\nBy Mike Pilkington\r\nPublished: 2012-12-17 ยท Archived: 2026-04-05 17:58:10 UTC\r\nMy primary goal is to help incident responders protect their privileged accounts when interacting with comprised\r\nhosts, though I also believe this information will be useful to anyone administering and defending a Windows\r\nenvironment.]\r\nPsExec is an extremely powerful tool and is used commonly in enterprise networks, for both good and evil.\r\nSystems administrators and incident responders use it for its flexibility in interacting with remote machines,\r\nincluding a telnet-like ability to run command-line tools on remote machines and receive the output on their local\r\nconsole. Attackers utilize it for the same reasons, providing a convenient way to move laterally and interact with\r\nremote machines using compromised credentials.\r\nGiven its power, you might wonder what the ramifications are of using this tool on a compromised machine. In\r\nother words, could it lead to your credentials being compromised? In this article, I'll discuss the two \"native\"\r\nmethods of logging onto a remote machine with PsExec and why you should always avoid one of the two. I'll also\r\ndiscuss possible workarounds to the second, more dangerous logon. Finally, since attackers have been known to\r\nuse this tool for lateral movement, I'll follow up the logon discussion with a brief forensic analysis of the artifacts\r\nyou will typically find from PsExec usage.\r\n2 Types of Logons with PsExec\r\nIt's easy to overlook that fact that there are two distinct ways to logon to a remote host with PsExec. The first\r\nmethod is to run PsExec under the context of the currently logged-on user. This requires no special switches or\r\nspecification of an account. It simply uses the logged-on account to authenticate to the remote machine. As we'll\r\nsee in a moment, this results in a network logon to the remote machine.\r\nThe second method is to specify an alternate account using the \"-u\" switch and optionally the \"-p\" switch (if you\r\ndon't supply \"-p\", it behaves the same but will prompt you for the password). This allows you to authenticate to\r\nthe remote machine as a different user. This would commonly be a user with higher privileges than your currently\r\nlogged-on account. While this is often convenient, it provides more than just convenience?it also provides a full\r\ninteractive logon, which loads all the user's credentials on the remote host. This has the benefit of allowing a user\r\nto authenticate to another system from the remote host, but it also carries the significant drawback of exposing NT\r\n\u0026 LM hashes, Kerberos Ticket Granting Ticket (TGT), and clear-text passwords to malware on the remote host.\r\nWe clearly don't want to do this on an untrusted host!\r\nAn important side note here is to be aware that both logon methods for PsExec have the potential of creating the\r\ndelegate-level access token, if the remote system is trusted for delegation. This is also a significant risk, though\r\nnot as commonly exploited. As discussed in my article on access tokens, we fortunately have a simple fix\r\nhttps://www.sans.org/blog/protecting-privileged-domain-accounts-psexec-deep-dive/\r\nPage 1 of 16\n\navailable by enabling the setting \"Account is sensitive and cannot be delegated\", which is recommended by\r\nMicrosoft for sensitive accounts.\r\nOk, so let's have a look at these two logon methods in action.\r\nTesting: PsExec with logged-on user account\r\nIn the following screenshot, I'm logged onto machine IR-XP-PC as MSAD2-RESPONDER1. I've initiated a\r\nPsExec logon from the local host to the remote host named USER-XP-PC. Since I did not specify \"-u\", the\r\ncurrently logged-on user will use standard Kerberos or NTLM integrated authentication to connect to the remote\r\nhost. Once connected, I ran a couple of commands to show that I am still MSAD2-RESPONDER1 and am now\r\nexecuting commands on USER-XP-PC.\r\nThe following screenshot shows the relevant Event Log from the PsExec logon. This connection created only a\r\nType 3 network logon, which is the safe way to connect to a remote host.\r\nhttps://www.sans.org/blog/protecting-privileged-domain-accounts-psexec-deep-dive/\r\nPage 2 of 16\n\nTo confirm the logon type and the fact that password hashes are not revealed, here's the relevant output from\r\nSysinternals' logonsessions tool, again showing a network logon for MSAD2-RESPONDER1. The screenshot\r\nalso shows the output of Windows Credentials Editor (WCE), which verifies the hash is not in memory for the\r\nMSAD2-RESPONDER1 account.\r\nhttps://www.sans.org/blog/protecting-privileged-domain-accounts-psexec-deep-dive/\r\nPage 3 of 16\n\nSo the good news is that we've seen that a standard connection with PsExec, using the currently logged-on user's\r\ncredentials, results in only a network logon. This is the safe way to execute PsExec remotely.\r\nNow let's look at the other authentication method with PsExec.\r\nTesting: PsExec with Alternate Credentials \"-u\" option\r\nThis time I'm logged on locally with a non-privileged account and will then log on remotely using a privileged\r\naccount, MSAD2-RESPONDER1.\r\nhttps://www.sans.org/blog/protecting-privileged-domain-accounts-psexec-deep-dive/\r\nPage 4 of 16\n\nExamining the logs on the remote machine, we initially see a network logon (Type 3), but then 1 second later we\r\nsee an interactive logon (Type 2) for our alternate credentials user, MSAD2-RESPONDER1.\r\nhttps://www.sans.org/blog/protecting-privileged-domain-accounts-psexec-deep-dive/\r\nPage 5 of 16\n\nhttps://www.sans.org/blog/protecting-privileged-domain-accounts-psexec-deep-dive/\r\nPage 6 of 16\n\nThis interactive logon causes the credentials of the responder account to be loaded and available for an attacker to\r\nsteal. The following screenshot shows the currently logged on sessions for MSAD2-RESPONDER1 (two of\r\nthem), and as expected, WCE shows us the password hashes for MSAD2-RESPONDER1.\r\nTo make matters worse, an additional concern with the \"-u\" option is that it sends the password in clear-text in\r\norder to generate the interactive logon. Microsoft Sysinternals warns us of this issue on their PsExec download\r\npage . Here is a screenshot of Wireshark showing the password being sent over the network in the clear\r\n(password = responder1-pw1):\r\nhttps://www.sans.org/blog/protecting-privileged-domain-accounts-psexec-deep-dive/\r\nPage 7 of 16\n\nConclusions on PsExec Logon Methods, with Workarounds\r\nIt is clearly not safe to use PsExec's \"-u\" option on an untrusted remote host. On the other hand, using PsExec\r\nwithout \"-u\" and therefore authenticating as the currently logged-on user is much safer and does not expose the\r\naccount to theft of password hashes, the Kerberos TGT, or the plain-text password itself. As mentioned earlier,\r\nthere is still the possibility of the account's delegation token being stolen. The simple fix for this risk is to enable\r\nthe setting \"Account is sensitive and cannot be delegated\", as discussed in the article.\r\nThe ability to specify alternate credentials is a useful one, and fortunately, there are a couple of ways we can still\r\nmake this work without divulging credentials on the remote host.\r\nOne possibility is the use of RunAs. For example, I logon to my machine as a standard user, but will often need to\r\nconnect to a remote machine with a privileged account. For me, the easiest way to do this, while still being safe\r\nassuming my local machine is not compromised, is to spawn a new CMD command shell as the privileged\r\naccount, using the command \"RunAs.exe /user:domain\\user cmd.exe\". As I discussed in my article on hashes,\r\nusing RunAs will still result in an interactive logon, but at least I'm doing it on my trusted workstation rather than\r\nthe untrusted remote host.\r\nRunAs is a good option in many cases, but there are situations where using RunAs is not feasible. For example, if\r\nthe machine you are using is not a part of the privileged account's domain. It turns out there is another workaround\r\nthat can allow you to specify alternate credentials but not create an interactive logon. The suggested workaround is\r\nhttps://www.sans.org/blog/protecting-privileged-domain-accounts-psexec-deep-dive/\r\nPage 8 of 16\n\nto first connect to the IPC$ share of the remote host using the alternate account, and then use PsExec without \"-u\".\r\nThe process looks like this for my current test setup:\r\nWhen performed this way, my tests show that only a network logon is created (no interactive logon) and also the\r\npassword is not sent in clear-text (presumably since there is no interactive logon). I'd recommend you confirm this\r\nin your own environment before using it in production. The main thing to check for is that there is no Type 2\r\ninteractive logon in the logs of the remote host.\r\nA Forensic Overview of PsExec\r\nSince we sometimes see attackers use PsExec for lateral movement, let's take the discussion a step further and\r\nlook at some artifacts that could reside from PsExec usage. The artifacts presented here are the direct result of\r\nusing PsExec in my tests above. Of course there are other ways of utilizing PsExec, so the resulting artifacts may\r\nvary.\r\nWhen PsExec executes on a remote machine, the local machine sends a service executable named\r\nPSEXESVC.EXE to the remote machine and that executable is installed as a service. Here's a look at that service\r\nrunning on the remote host. Notice the service executable resides in C:\\WINDOWS.\r\nhttps://www.sans.org/blog/protecting-privileged-domain-accounts-psexec-deep-dive/\r\nPage 9 of 16\n\nOnce the user has cleanly logged off (exited) PsExec, the service is removed and PSEXESVC.EXE is deleted.\r\nAlthough PsExec is deleted (as indicated by the red X icon), the screenshot below shows the file and its metadata.\r\nNotice the UTC creation and modification times correspond to the second logon time in my tests above (12/15/12\r\n9:43:20 PM Central time).\r\nhttps://www.sans.org/blog/protecting-privileged-domain-accounts-psexec-deep-dive/\r\nPage 10 of 16\n\nAlso notice that the owner of this file is the user who connected remotely to run PsExec.\r\nhttps://www.sans.org/blog/protecting-privileged-domain-accounts-psexec-deep-dive/\r\nPage 11 of 16\n\nA profile is created for this user at the time of first login, if it didn't already exist. This is regardless of whether an\r\ninteractive logon occurred or not. Here are the timestamps for the MSAD2-RESPONDER1 account's profile\r\nfolder. Notice the UTC creation timestamp is the same time of the first logon in the tests above (12/12/12 9:52:27\r\nPM Central time).\r\nhttps://www.sans.org/blog/protecting-privileged-domain-accounts-psexec-deep-dive/\r\nPage 12 of 16\n\nPrefetch shows both the first time the service executable was run (Prefetch file creation time minus 10 seconds)\r\nand last time run (Prefetch file modification time minus 10 seconds).\r\nhttps://www.sans.org/blog/protecting-privileged-domain-accounts-psexec-deep-dive/\r\nPage 13 of 16\n\nThe Application Compatibility Cache shows this as well, with an entry for both times run.\r\nhttps://www.sans.org/blog/protecting-privileged-domain-accounts-psexec-deep-dive/\r\nPage 14 of 16\n\nSince PsExec is typically run remotely, these run times can be used to examine the Event Logs and look for\r\nnetwork logons at the same time. The corresponding Event Logs for these PsExec executions are shown in the\r\nscreenshots at the beginning of this article.\r\nWhen PsExec is exited, the PsExec service is removed, but you may find the deleted service key still in the\r\nRegistry. Here is the deleted key shown by YARU . Note that the last write time of the key corresponds to the\r\ntime the responder account logged out and exited PsExec the second time (12/15/12 9:49:13 PM Central time)\r\nhttps://www.sans.org/blog/protecting-privileged-domain-accounts-psexec-deep-dive/\r\nPage 15 of 16\n\nFinal Thoughts\r\nI've found that there are safe ways to use PsExec, but unfortunately it is not obvious how to do so. Hopefully this\r\ndiscussion has provided a deeper understanding of the tool and how you can use it safely, as well as analyze the\r\nforensic artifacts it can leave behind.\r\nSource: https://www.sans.org/blog/protecting-privileged-domain-accounts-psexec-deep-dive/\r\nhttps://www.sans.org/blog/protecting-privileged-domain-accounts-psexec-deep-dive/\r\nPage 16 of 16", "extraction_quality": 1, "language": "EN", "sources": [ "MITRE" ], "references": [ "https://www.sans.org/blog/protecting-privileged-domain-accounts-psexec-deep-dive/" ], "report_names": [ "protecting-privileged-domain-accounts-psexec-deep-dive" ], "threat_actors": [ { "id": "d90307b6-14a9-4d0b-9156-89e453d6eb13", "created_at": "2022-10-25T16:07:23.773944Z", "updated_at": "2026-04-10T02:00:04.746188Z", "deleted_at": null, "main_name": "Lead", "aliases": [ "Casper", "TG-3279" ], "source_name": "ETDA:Lead", "tools": [ "Agentemis", "BleDoor", "Cobalt Strike", "CobaltStrike", "RbDoor", "RibDoor", "Winnti", "cobeacon" ], "source_id": "ETDA", "reports": null }, { "id": "aa73cd6a-868c-4ae4-a5b2-7cb2c5ad1e9d", "created_at": "2022-10-25T16:07:24.139848Z", "updated_at": "2026-04-10T02:00:04.878798Z", "deleted_at": null, "main_name": "Safe", "aliases": [], "source_name": "ETDA:Safe", "tools": [ "DebugView", "LZ77", "OpenDoc", "SafeDisk", "TypeConfig", "UPXShell", "UsbDoc", "UsbExe" ], "source_id": "ETDA", "reports": null } ], "ts_created_at": 1775434892, "ts_updated_at": 1775791469, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/c94c6113ccc7099296b6f4cbe1a68e8c4407e8b8.pdf", "text": "https://archive.orkl.eu/c94c6113ccc7099296b6f4cbe1a68e8c4407e8b8.txt", "img": "https://archive.orkl.eu/c94c6113ccc7099296b6f4cbe1a68e8c4407e8b8.jpg" } }