Splunking with Sysmon Part 3: Detecting PsExec in your Environment
PsExec is another powerful tool created by Windows Sysinternal. It was created to allow Administrators to remotely connect to and manage Windows systems. Because of the power of PsExec, many different malware actors have used it in various forms of malware as well as a part of pass-the-hash attacks. PsExec has been used in Mitre ATT&CK techniques T1569.002 (System Services: Service Execution), T1021.002 (Remote Services: SMB/Windows Admin Shares), and T1570 (Lateral Tool Transfer).
PsExec allows members of a computer’s Local Administrator group to connect to and have an interactive command line interface with remote computers. It is a major vector of lateral movement in an environment, and because of that, is a very important tool to be able to detect. In this blog I will go through the basics of how PsExec works, the three current primary ways it is used, and how to detect its usage with Sysmon.
PsExec
PsExec is a rather simple tool, but one that has a lot of power. The tool copies a service executable to the hidden Admin$ share, and then uses the Windows Service Control Manager API to start the service. The service uses named pipes, which connect back to the psexec tool. The tool can be run on the local machine or remote machines, and it can allow a user to act as the NT Authority\System account.
The log examples shown below are with the default Modular Sysmon configuration file, and I tested the detections by using the various methods of PsExec to run the command “cmd /c time /T”. Each example will have screenshots of the usage of the tool and select fields from the logs generated by Sysmon.
Sysinternals PsExec
Sysinternal’s PsExec starts by setting registries on the remote machine to run %SystemRoot%\PSEXESVC.exe when the service PSEXESVC starts. It writes the file to disk and starts the process in a new thread. PSEXESVC then creates a new process to run the commands it was sent from PsExec, cleaning up after itself by closing all the processes and deleting the registry key it created once finished.
The logs start with a created file (Event Code 11), which is then set to run with a service via registry entries (Event Code 13) and called. The service creates a pipe (Event Code 17) that psexec connects to (Event Code 18), which runs the command (Event Code 1) that is sent over psexec. Because a lot of the activity happens at the same time, some logs get mixed up in order, but knowing how it actually runs can help decipher the logs.
Impacket PsExec.py
As you can see from the Process Monitor output, Impacket’s Psexec.py runs basically the same as Sysinternals, except that it uses a random file name and a random service name to execute. It still sets the service registry entries first, runs the necessary processes, and cleans itself up after execution.
The logs are similar to the first run of PsExec, except that it misses all of the pipe events. That is because the configuration file limits Pipe events to a specific segment of pipes so as to not cause too much noise. So what we see with Impacket is: a file creation (Event Code 11), service creation via registry (Event Code 13), and the command being run (Event Code 1).
Metasploit PsExec Module 489
Metasploit’s PsExec Module runs very differently than the other two. It starts by still creating the initial service via registries, but instead of uploading a file for the service to run, it sets a cmd.exe command that opens PowerShell to create the connection. The service starts the cmd.exe command, which opens a PowerShell process that then opens another PowerShell process. It cleans up and closes the service and cmd process before the second PowerShell process starts. The second PowerShell process is what runs the commands sent by PsExec.
The PowerShell processes also create a lot of Registry Keys for System Certificates. In the Process Monitor output, I filtered out over 480 RegCreateKey events.
The initial logs are much higher than the other two versions. They start with the service creation Registry events (Event Code 13), but then it has a Process Creation event for cmd and PowerShell (Event Code 1). You can see the Root Certificate events generated as well.
Detection
The detection I developed looks at the one commonality between the three techniques, the service creation, and registry edits. In the first two examples, you can see a file is created, which is then set as the path for the service in the registry, and in the last example, the PowerShell commands are run. The detection looks for recently created files that match the “Details” field of that ImagePath or PowerShell in the ImagePath.
In order for my detection to work, your configuration needs to include the following rules in your configuration file. Both rules are included by default in the SwiftonSecurity and Modular Sysmon configurations. Also, you will need the TA-Microsoft-Sysmon app installed for extractions.
To follow up if the detection alerts, the best place to start would be the Process Creation events (Event Code 1) that are created by the service and then following the tree that is created from them. As it is sometimes hard to follow them easily, the easiest place to start for me was looking into the Process Creation events that were created by the LogonId of the initial event. That will limit the events to only events created by that logon session and should be a good starting place. This detection and all future detections will be available on my GitHub.
Conclusion
PsExec is a very powerful and important tool to monitor in your network. The opportunities it presents malicious actors make it a tool that is vital to monitor for vulnerabilities. The detection above works consistently in my testing, and it does not generate False Positives (FP)–but it should be tested in your environment if you choose to deploy it. If the configurations are not the same, it may not generate the logs properly, and if you have users that regularly use PsExec, it may need to be altered to ensure that those can be suppressed or tuned out.
The post Splunking with Sysmon Part 3: Detecting PsExec in your Environment appeared first on Hurricane Labs.
*** This is a Security Bloggers Network syndicated blog from Hurricane Labs authored by Dusty Miller. Read the original post at: https://hurricanelabs.com/splunk-tutorials/splunking-with-sysmon-part-3-detecting-psexec-in-your-environment/?utm_source=rss&utm_medium=rss&utm_campaign=splunking-with-sysmon-part-3-detecting-psexec-in-your-environment
