by Bhabesh Raj Rai, Associate Security Analytics Engineer
Hunting for PsExec artifacts in your enterprise
PsExec is a free, lightweight tool that can execute remote systems processes and supports full interactivity for console applications. PsExec is a valuable tool in a system admin’s arsenal. Admins can use the tool to launch interactive command-prompts on remote systems without the hassle of manually installing client software.
System administrators commonly use PsExec to download or upload a file over network shares or execute commands, scripts or binaries on remote systems. However, what makes PsExec useful for system admins also makes it attractive for threat actors. Don’t forget – attackers can hide their actions as legitimate system admin activity in your environment.
So far, numerous threat actors have used PsExec, including APT1, menuPass, Turla and Wizard Spider. FIN5, a financially motivated threat group, uses a custom version of PsExec. Also, ransomware operators like Ryuk and Maze heavily use PsExec for lateral movement.
PsExec’s execution generates many events which various sensors can pick up if configured correctly. The most notable generated events are new service creation, authentication to the target endpoint over SMB, and creating and connecting named pipes. Also, intrustion detection systems (IDS) and intrustion prevention systems (IPS), like Snort and Suricata, can readily detect PsExec activity in the network.
We’ll focus on hunting PsExec activity in LogPoint and detecting successful exploitation of a newly discovered local privilege escalation (LPE) vulnerability.
Hunting PsExec in LogPoint with Sysmon
In LogPoint, you can view a PsExec search template for an overview of all related activity.
While running PsExec (or any Sysinternals tool) for the first time, it creates a new registry key on the source host that documents the user’s acceptance of the EULA. Detecting this registry change is trivial via Sysmon’s Registry event logs.
norm_id=WindowsSysmon event_id=13 target_object="*\EulaAccepted"
| norm on target_object Sysinternals\
| chart count() by host, image, tool, target_object
However, the registry change only occurs for official PsExec versions released by Microsoft, and custom versions will avoid changing the registry key.
By default, PsExec creates a new service, named PSEXESVC, on the remote system that can be detected via Windows new service creation logs, Event ID 7045 and 4697. The difference being the latter provides the account information.
norm_id=WinServer event_id=4697 service=PSEXESVC
| chart count() by host, user, service, file
The service name can be changed from the command line and the event alone cannot fully detect all the PsExec executions.
PsExec will drop the PSEXESVC.exe binary, which can be changed, in the SYSTEMROOT directory of a remote system that will be later executed by the newly created service. Sysmon’s file creation event logs can be used to look for binary droppings in the SYSTEMROOT directory.
norm_id=WindowsSysmon event_id=11 path="C:\Windows" file="*.exe"
| chart count() by host, file, path
Every remote command executed via PsExec will be spawned by the PSEXESVC.exe process that can be picked up by the Windows native process creation events (Event ID 4688).
norm_id=WinServer event_id=4688 parent_process="*\PSEXESVC.exe"
| chart count() by host, parent_process, "process", command
One of the most valuable detection capabilities offered by Sysmon is the pipe creation (Event ID 17) and connections (Event ID 18) events.
norm_id=WindowsSysmon event_id IN [17, 18]| chart count() by host, message, pipe order by count() desc
PsExec requires many pipes for its operation like \psexesvc, though the name of a pipe can be changed. The pipes of interest are of format —<stdin|stdout|stderr>. Detection of a pipe creation or connection adhering to the format is an indicator of the PsExec’s activity at the endpoint.
norm_id=WindowsSysmon event_id IN [17, 18] pipe IN ["*-stdin", "*-stderr", "*-stdout"]| chart count() by host, message, pipe order by count() desc
We can create a widget that shows the top source hosts responsible for the PsExec executions.
norm_id=WindowsSysmon event_id IN [17, 18] pipe IN ["*-stdin", "*-stderr", "*-stdout"]| norm on pipe--<:word>-<:'stdin|stdout|stderr'>
| chart count() by source_host order by count() desc
Hunting PsExec in LogPoint without Sysmon
Windows’s file share auditing logs detect PsExec if Sysmon is not deployed in the environment. Only the basic file share auditing is insufficient, so users must enable “Detailed File Share” auditing.
The basic file share auditing (Event ID 5140) consists of a username, source IP and share name information.
norm_id=WinServer event_id=5140
| chart count() by host, user, source_address, share_name
The main detection capability lies in zooming the relative target field with the same format as the pipe name recorded in Sysmon Pipe creation and connection events.
norm_id=WinServer event_id=5145 share_name=IPC$ relative_target IN ["*-stdin", "*-stderr", "*-stdout"]| norm on relative_target -<source_host:word>-<:word>-<:'stdin|stdout|stderr'>| chart count() by host, user, source_address, source_host
However, for detecting Impacket’s version of PsExec, the above query needs to be slightly modified because the relative_target field of Impacket’s PsExec uses a different format– RemCom_(stdin|stdout|stderr)t*. Also, notice how in Impacket’s PsExec there is a loss of source host information.
norm_id=WinServer event_id=5145 share_name=IPC$ relative_target IN ["RemCom_stdint*", "RemCom_stderrt*", "RemCom_stdoutt*"]| chart count() by host, user, source_address
If you have an IDS or IPS, you can look for a signature match to detect PsExec’s network activity.
IDS and IPS detection
We need to look for an IDS or IPS signature match that covers PsExec’s network activity.
(norm_id=Snort OR norm_id=SuricataIDS) message IN ["Remote Service Control Manager Access*", "PsExec service created*",
"SMB2 NT Create AndX Request For an Executable File*", "Executable File Transfer*"]
Detection of local privilege escalation exploitation via PsExec
On December 9, David Wells, a researcher at Tenable Security, discovered a LPE vulnerability in PsExec that allows a non-admin process to escalate to SYSTEM. The vulnerability was fixed in the latest released PsExec version 2.3.
Detecting successful exploitation of the vulnerability is simple by hunting for a child process creation of PSEXESVC.exe with the SYSTEM’s integrity level.
norm_id=WindowsSysmon event_id=1 integrity_level=SYSTEM parent_image="C:\Windows\PSEXESVC.exe"
You can use the following query to detect when the dropped binary is renamed by using the command line switch:
norm_id=WindowsSysmon event_id=1 integrity_level=SYSTEM parent_image="C:\Windows\*.exe" -parent_image="C:\Windows\System32\*.exe"
| chart count() by user, image, parent_image
Detection of PsExec by Defender’s ASR rules
Defender’s Attack Surface Reduction (ASR) rules are one of the main features of Defender Exploit Guard. It aims to disrupt specific behavior types used by malware to infect devices like malicious macros and suspicious scripts. Defender has an ASR rule named block process creations originating from PSExec and WMI commands. If this rule is activated, then Defender blocks PsExec executions and an event (Event ID 1121) is generated with the rule’s GUID.
norm_id=WinServer event_id=1121 id="D1E49AAC-8F56-4280-B9BA-993A6D77406C" -process_name IN ["*\wmic.exe", "*\wmiprvse.exe"]| chart count() by host, file, path, process_name
Activating Defender’s ASR rule blocks PsExec executions and generates a corresponding event.
Use multiple detection methods for full coverage
In conclusion, defenders have various opportunities to detect PsExec. However, advanced threat actors tweak the command line parameters to avoid naive detections by referring to a service or binary name. We recommend that you have multiple detection possibilities to gain full coverage.
In the current threat landscape, ransomware activity is rampant. Detecting PsExec activity can prevent eventual Ryuk, Maze or other ransomware deployments in an organization. We recommend system administrators to switch to PowerShell Remoting instead of PsExec for administration tasks and treat all the PsExec activity in the environment as malicious.
