Summary:
In one way or another, PsExec – a wildly popular remote administration tool in the Microsoft SysInternals Suite – peeks its head in the wild. Threat actors tend to leverage PsExec for various reasons, such as executing commands or programs on a remote host in a victim’s environment, or for more nefarious reasons, such as deploying ransomware. The focus of this blog is to bring attention to a relatively new method of identifying the source host from which PsExec was executed from. Huge shoutout to Joe Ziemba for bringing this to my attention on a ransomware case we worked on together!
Target Host Example:
There are a few ways to identify PsExec was executed on a target system, but I will focus on the ever-so-fruitful System 7045 (Service Install) event. Any time PsExec is executed on a target host, a forensic analyst will stumble on a System 7045 event for PSEXESVC at this location: %SystemRoot%\PSEXESVC.exe. PSEXESVC is the service that gets installed on the destination host which was on the receiving end of a PsExec command. Keep in mind, PSEXESVC will be the default service name on a target system any time PsExec is executed but can be changed using the -r option which is used to specify the name of the remote service to create or interact with.
Source Host Example:
One method to identify the source system from which a PsExec command was remotely executed from is the Security 4624 event that everyone is so fond of – specifically Type 3 Network Logons. Anytime PsExec is executed on a target system, a 4624 Type 3 Logon will be generated on the target. An analyst can get lucky and cross-correlate the Type 3 Logon time with a service install for PSEXESVC which should be off by a few milliseconds.
PsExec Key File (New Identification Method – USN Journal):
Starting with PsExec v2.30 (which was released in early 2021), anytime a PsExec command is executed, a .key file gets written to the file system and will be recorded in the USN Journal on the target system. It will follow this naming convention: PSEXEC-[Source Hostname]-[8 Unique Characters].key and will be located at the C:\Windows directory. Keep in mind, if PsExec is run on a system against itself, the .key filename will include the same source hostname as the system in which PsExec was run on (i.e. Running PsExec from host Win10VM against itself will generate a .key file in the USN Journal on Win10VM with the following naming convention: PSEXEC-Win10VM-[8 unique characters].key).
See the below screenshot of the PSEXEC .key file being recorded in the USN Journal as a FileCreate event using output that was generated by Eric Zimmerman’s MFTECmd.exe and loaded into Timeline Explorer (Note – Client data was redacted for confidentiality):
Now when you stack the USN Journal FileCreate event for the PSEXEC .key file with a System 7045 event, you can see the timestamps are off by a few milliseconds. See the below screenshot of the System 7045 event using output that was generated by Eric Zimmerman’s EvtxECmd.exe and loaded into Timeline Explorer (Note – Client data was redacted for confidentiality):
This was found on a recent ransomware engagement I worked on which allowed my team and I to track most of the PsExec activity the threat actors performed in this environment. This can prove highly beneficial to properly understand what systems were compromised by the threat actors, especially during a ransomware incident in which threat actors tend to leverage PsExec to deploy ransomware across a victim’s environment.
UPDATE – PsExec Key File (New Identification Method – Prefetch):
Huge thanks to Richard Davis for discovering another way to identify the PSEXEC .key files using Prefetch. He demonstrates this in his 13Cubed video “Detecting PsExec Usage” which will be linked below in the article.
Prefetch, which is an evidence of execution artifact in Windows, can also be leveraged to identify PSEXEC .key files similarly to the USN Journal. When PsExec is executed, a PSEXESVC.exe Prefetch file will be created on the target system by default (or whatever service name was supplied in the PsExec command that was executed from the source system with the -r option I mentioned earlier). This Prefetch file can then be parsed in order to find all of the files that were referenced by it’s execution. In the screenshot below, I parsed a PSEXESVC.exe Prefetch file that was generated on the target system after PsExec was executed from the source system using Eric Zimmerman’s PECmd.exe and loaded into Timeline Explorer (Note – Client data was redacted for confidentiality):
As you can see, after parsing the PSEXESVC.exe Prefetch file from the target system, we were able to identify six PSEXEC .key files which show us the source hostnames in which PsExec was executed from – similarly to how the USN Journal does!
Conclusion:
More research will need to be conducted on why at times when a System 7045 event exists for PSEXESVC.exe on a target system, there isn’t a correlating FileCreate event being recorded in the USN Journal for the PSEXEC .key file. Still, I found these PSEXEC .key files to be very beneficial and adds another quick way for forensic analysts to identify PsExec in the wild when threat actors inevitably leverage it.
Resources:
For reference on the various ways to identify a source system that executed PsExec, check out the widely known SANS FOR508 Hunt Evil Poster.
Check out this community post by Microsoft that initially mentioned this feature change with PsExec v2.30: https://techcommunity.microsoft.com/t5/sysinternals-blog/sysmon-v13-01-and-psexec-v2-30/ba-p/2054904.
Check out Richard Davis’ 13Cubed video on Detecting PsExec Usage.
