Digging Into Sysinternals: PsExec

Inspiration

The inspiration for this, and a few subsequent posts, comes out of recently receiving Mark Russinovich’s new Sysinternals book, “Troubleshooting with the Windows Sysinternals Tools (2nd Edition)”. I got a copy of this book last week and I have not been able to put it down. While this is subject to my interpretation, the amount of Windows DFIR knowledge in Mark’s book is rarely contained in a single source. If you’re interested, I’d recommend picking up a copy of the book here on Amazon.

You can download a copy of the free Sysinternals suite here.

If you are newer to DFIR, or looking to freshen up your skills, I would recommend making this book part of your library ASAP. Over the past years, I have worked many investigations where attackers have utilized Sysinternals tools to complete their missions. I have also seen these tools in almost every step of the attacker lifecycle. These tools are so popular that Mark even comments on how he has received “angry emails from Windows users berating me for writing viruses and infecting their systems.” Talk about a tough crowd!

DFIR practitioners: I’d recommend understanding the Sysinternals suite as it gives you the opportunity to learn about your attackers’ tools without needing to reverse engineer malware. Knowing that attackers utilize these tools allows you to emulate their activities, understand their operations, and gain insight about the ease with which an attacker may or may not have moved throughout your environment.

Threat Hunters: Sysinternals artifacts may present anomalies that can be tracked down in your environment fairly quickly. With a bit of baselining, you may potentially discover a few systems of interest for follow-up. The next few blog posts are going to cover how to search for some of these artifacts.

PsExec

The first tool I’m going to cover with a DFIR lens is PsExec. I won’t spend time reciting the full description from the book, however in short, PsExec is a tool that allows for remote process execution. System administrators often use this tool for remote script execution, such as a setup script or data collection. It’s free and it works, saving the hassle of trying to bug your boss for more money for ${new_and_shiny_tool} that may not deliver on either of those qualities. It’s also been used for software deployment, although there are significantly better tools available for this. However, in a pinch, PsExec can help solve the problem.

Attackers utilize PsExec for the same reasons. This is often done for many, if not all of the above reasons, as well as:

• As these tools may be used legitimately, A/V or endpoint detection may ignore or only alert on these tools (will depend on your settings)
• They can be downloaded directly from Microsoft
• If they are used legitimately, they may already be placed on systems that the attackers have compromised.

One financially motivated group I have had extensive experience with (see my Grrcon ’16 talk on them here) utilizes a modified version of PsExec as their primary malware deployment tool. They use it so reliably that with a single IOC an analyst can confidentially determine that group’s presence.

For these and reasons I did not mention, I’ll stress again the importance for our DFIR analysts to understand these tools and their presence within your environment. Here’s a few approaches to examining PsExec activity:

PsExec Execution and Service Installation

Some of the most notable artifacts from PsExec usage are actually created on the remote system. Here is what you can expect to see:

• The service PSEXESVC will be installed on the remote system, which will give you a 4697 and/or 7045 event log entry. Note, the 4697 event, if available, may also contain account information.
• You may also have 4624 and/or 4625 Windows Event log entries, capturing the logon events of the tool usage.
• The executable PSEXESVC.EXE will be extracted to the Windows directory, and subsequently executed (to perform the remote operations).
• The requested activity should have been performed (we’ll ignore the artifacts for this, for the time being, as it could be anything).

There are a few additional artifacts that are generated from the extraction and execution of the PSEXESVC.EXE executable:

• If enabled, you may have a (Pre|Super)Fetch file for PSEXESVC.EXE.
• There should also be evidence of program execution in the Application Compatibility Cache (“AppCompat”) and/or Amcache, which replaces the RecentFileCache.bcf in newer Windows operating systems.

There is an important distinction about evidence of execution with regards to PSEXESVC.EXE; a new executable is written to the system each time a PsExec command is run on the target system. PsExec does not extract PSEXESVC.EXE once, rather it is a single instance each time. As a result of this behavior, each extraction creates new metadata, and thus new timestamps.

Both of our execution artifacts rely on these timestamps. First, you will receive an AppCompat entry for each time PsExec is used to connect to a system. Take a look at this output, generated from one of our SANS FOR508 images:

ShimCacheParser.py output, filtered for PSEXESVC

Note that the path remains the same, but we get a new ‘Modified Date’ (remember, AppCompat records the Modification timestamp) per instance of PSEXESVC. There are only a handful of executables where this timestamp can be trusted in this manner.

I can further correlate this by looking for my related 7045 Event Log Entries:

Parsed System Event Log Entries

Notice the timestamp correlation between Event Logs and AppCompat entries. Do we have any discrepancies?

Now, continuing with the FOR508 example, let’s look at the first part of our parsed Prefetch output:

Output for the parsed file PSEXESVC.EXE-51BA46F2.pf

Where we had multiple entries for AppCompat, we will have a single entry for PSEXESVC. Remember, this artifact is based on a hash/location — two values that do not change if the parameters for PsExec remote execution are not changed. It is important to note, however, the differences and similarities between the two. Our earliest timestamp in Prefetch, “accessed” in this case, corresponds to our first AppCompat time as well. On the other side, the final Prefetch “modification” time does not line up with our final AppCompat entry, but does line up with our most recent Event Log entry. We may want to do some more digging into our artifacts.

Notable Switches

If you happen to come across suspicious PsExec activity, there are a few distinct switches that may help indicate what activity has taken place. In no specific order, a handful of interest:

• -r allows for customization of the remote service. I have seen attackers utilize this switch before, and it makes it slightly tougher to identify PsExec service (but then again, a 7045 event log entry during a timeframe of attacker activity is an easier giveaway). I have also seen legitimate activity utilize the -r switch to help discern who was doing what. This stresses the importance of knowing whether this activity is expected in your environment or not. Stacking can also help find legit vs potentially-suspicious service names.

The financially-motivated threat group I discussed above renames the file dropped on the remote system to FRAMEPKG.EXE, instead of PSEXESVC.EXE. They have also been spotted changing the name of the service installed to something different. Take a look at the screenshot below for an example:

Attacker PsExec events with renamed services and executables

• -u and -p provide, as I’m sure you’ve guessed, a username and password for remote login, respectively. PsExec will first try to execute under the user issuing the command, and then try these credentials. If a -p is not provided, then the user is prompted for one. Note to sysadmins: Please do not hard-code these switches into your scripts; your leaving PsExec-capable credentials out in the open, even if they are encrypted in transmission :)
• -c allows for the copying of a specific program to the remote system for execution. I’ve seen this used for both legitimate and malware mass-deployments, and is very effective with the right credentials.
• -h will, on Vista+, run the process with the account’s elevated token, if available.
• -s will run the remote command in the System account.

Local Artifacts

We’ve spent some time discussing the artifacts on a remote system as well as switches of interest. Turning the lens onto our local system, other artifacts of PsExec activity on the may include:

• Sysinternals EULA acceptance registry key. I’m going to cover this in the next blog post, however Sysinternals tools will leave a registry key artifact that documents the user’s “acceptance” of the EULA. This key is written the first time the tool is executed. This can be found at HKCU\SOFTWARE\Sysinternals\<tool_name>\EulaAccepted — but more on this later.
• File system artifacts. We’ve talked about a few different artifacts thus far, but usage of PsExec on a local system will require a file to do so. In the next post, I’ll explore where this file may come from, but let’s assume a simple example that finds the file on disk. The location of this file may offer additional clues about whether it is legitimate or not. In many cases, sysadmins will download the entire Sysinternals suite and extract it, and then use the tools they need (this is not all sysadmins). Attackers may only copy over the tools they need to save on footprints.
• File execution artifacts. Similar to execution artifacts on our remote system, we would expect to see the same on our local system as well. Look at AppCompat or *Fetch artifacts for evidence of Sysinternals execution.

Other Reads

I’d also recommend reading Mike Pilkington’s Protecting Privileged Domain Accounts: PsExec Deep-Dive, which offers additional insight as well as analysis of credentials passed via PsExec.

Conclusion

If you’ve found PsExec activity, make sure to check with your sysadmins (or client contacts) whether this activity is expected. This can quickly help you filter out false positives, which in a large environment, may reduce the number of events from thousands to dozens.

If you’re looking to utilize these artifacts to help paint your timelines or intrusion windows, make sure to note what the timestamps may mean and how they can help you.

In my next post, we’re going to examine the Sysinternals registry key as well as Sdelete activity, another tool utilized by attackers.

As always, happy forensicating!