Corporate Security

Threat Hunting: How to Detect PsExec

This post is the first in a threat hunting series profiling detection points for common cyber threat actor attack techniques. The series is geared toward network defenders wanting to understand, identify, and protect against these attacks. Each post will briefly describe a technique, when and how it might be used, potential indicators generated, and ways to detect or hunt for those indicators. Praetorian’s goal is for this series to serve as a handy reference for defenders looking to answer the question: How do I detect ___?

A note on tools: There are many options when it comes to network defense tooling. Some defenders might have access to full packet captures and robust endpoint telemetry, others might collect only a subset of events from a few sources. In order to present these techniques using a standard nomenclature and accessible toolset, Praetorian will present examples using DetectionLab¹. While the DetectionLab environment might not generate the exact same events as, for example, popular enterprise EDR products, it will produce the same kind of events. Crafty defenders can apply the detection logic presented in these posts to their tools in order to identify potentially malicious activity in different environments.

What is PsExec?

PsExec is a system administration utility that can execute programs on remote Windows hosts². The tool is a lightweight, standalone utility that can provide interactive access to the programs it runs remotely. Similar functionality is available using things like PowerShell Remoting in newer versions of Windows, however PsExec’s versatility and ease of use make it a favorite for attackers. Common exploit kits Cobalt Strike and Metasploit each provide PsExec-style capabilities. There are also a number of threat actors³ known to use either the official version of the tool, which is signed by Microsoft, or a custom variant.

Attackers often use Sysinternals PsExec to perform lateral movement. Assume an attacker has (1) a foothold in an environment and (2) compromised credentials with Local Administrator privileges on one host. The attacker can run PsExec on the compromised host and execute commands on another host.

The standard PsExec activity pattern is as follows:

(1) Authenticate to the target host over SMB using either the current logon session or supplied credentials.
(2) Copy the service executable file PSEXECSVC.EXE to the path <target_host>admin$system32.
(3) Connect to the service control manager on the target host to install and start PSEXESVC.
(4) Facilitate input/output via the named pipe .pipepsexesvc.
(5) (On completion) Uninstall the service and delete the service executable.

codeblock results — Example PsExec Usage

How do I Detect PsExec?

Most indicators of PSExec activity are available from host-based telemetry tools. In this case, event IDs will be taken from Sysmon and Windows System/Security logs, but there are analogues available in other popular monitoring solutions.

PsExec activity always involves remote service creation. The Windows Security EventCode for this activity is 7045 and the default name is PSEXESVC.

event code 7045 psexesvc — *The corresponding service creation event created by the example usage.*

In order to run PsExec, users must accept its EULA. This creates a registry change on the source host. (Many environments might not be logging all registry changes, but this can be a useful indicator during investigation.) The registry key is: HKEY_CURRENT_USERsoftwaresysinternalspsexeceulaaccepted.
The default PsExec named pipe used for communication is .pipepsexesvc. MENASEC Applied Security Research has also noted that uniquely-named pipes are created on the target host for each use. These pipes are named according to the format <psexecsvc_name>-<machine_name>-<5_random_digits>-<stdin|stdout|stderr>⁴. Windows Security event 5145 is logged when these pipes are accessed. (This insight can be particularly useful for identifying evasive PsExec usage, or the use of PsExec variants.)

win-event-log: security — *The stdin pipe created by example PSExec usage.*

Variants and Evasions

It is possible for attackers to modify several of the values associated with the indicators above. Defenders should be on the lookout for evasion indicators in line with the following:

Renaming the service: the default service name can be changed by supplying an argument to the command on the calling host. For example, instead of the command psexec.exe <target_host> cmd.exe, an attacker could execute psexec.exe -r spoolsrv <target_host> cmd.exe to evade simple detection. Modification of the service name generally corresponds to a similar modification to named pipes used by the tool.
Registry: The remote registry key change created when the EULA is accepted can be deleted by attackers in order to cover their tracks. Also note that this indicator is only generated by official distributions of PsExec – custom implementations will not change the registry key.
Clones: Several custom PsExec implementations exist. Some of these implementations are, like PsExec, signed and distributed by legitimate vendors. Others are components of offensive security toolkits such as Cobalt Strike, Metasploit, and Impacket. Most variants, however, follow the same activity pattern as the original PsExec tool, but use different or configurable service names and pipes. Such variants also follow a similar pattern of pushing a service executable or DLL to the target host, and executing it using the service control manager.
Accounts: PsExec can operate using the current logon session or supplied credentials. An authentication event on the target host will hold this information. An anomalous PsExec activity pattern involving several sets of credentials should be considered as a critical data point when scoping an intrusion.

Take note: both the service name and the named pipe created during PsExec activity are arbitrary; any variant of the PsExec program provides the ability to easily change these values on a per-execution basis. This potential variability can, however, lend itself to scoping intrusions. Once identified, “custom”-named services and pipes matching the PsExec activity pattern can provide a high-fidelity signature for scoping an intrusion.

Detection Logic

Basic detection of PsExec activity can be accomplished by monitoring for remote service creation using the well-known “PSEXESVC” name:

EventCode==7045 AND (“Service Name” CONTAINS “PSEXESVC”)

If telemetry is available, the optimal solution is to monitor for the uniquely-named pipes that are created as part of the process⁴:

EventCode==5145 AND (“Relative Target Name” CONTAINS (“*-stdin” OR “*-stdout” OR “*-stderr”))

Finally, changes to the EULA registry key could be a useful addition to any of the above:

EventCode==13 AND (“TargetObject” CONTAINS “*softwaresysinternalspsexeceulaaccepted”)

Proper whitelisting and baselining are critical to identifying anomalous and potentially malicious activity. Sysinternals PsExec is a legitimate systems administration utility, and may be used as such day-to-day in an environment. Some legitimate monitoring solutions, vulnerability scanners, or asset management systems might also exhibit this activity pattern. Knowing your allow lists and baseline profile can help differentiate between common benign activity and potentially malicious behavior.

Further Considerations

It is important to remember that PsExec will rarely be seen as an “opening move” in an attack. The tool requires credentials and network access to target hosts. Because of this, detection of potentially malicious PsExec activity is likely one piece of a larger attack chain. Thus, if detection occurs during threat hunting, it is important to outwardly scope potential compromise using the detection event as a starting point.

It is also important to remember that the best evidence of PsExec activity lives on affected hosts. In the event of an incident involving PsExec activity host security logs are crucial. If an organization does not collect security logs from hosts on a day-to-day basis, then preserving those security logs in the event of an incident should be a priority. If possible, extracting a memory image of a compromised device before remediation activity can also provide useful indicators for scoping.

The following questions may be helpful in guiding an investigation: