PSExec is a powerful utility offered by Microsoft’s Sysinternals. It lets you execute processes on other systems without having to install anything manually. The tool interactively installs itself on the remote target machine, so you can redirect the input and output of console applications. For example, you can run ipconfig on a remote host, redirecting the input back to your local host.
Figure 1. IPConfig on a Remote Host
This useful tool for Windows Administrators also serves as a convenient opportunity for attackers, and pen testers often use it as well.
It’s actually quite easy to detect when PSExec is used, because the tool installs itself as a service, creating a Windows Event (Event ID 7045 logged in the System Eventlog).
In Windows XP, Windows Server 2003 and earlier versions of Windows, all services ran in “Session 0” along with applications. This situation posed a security risk.
In Windows Vista, Windows Server 2008 and later versions of Windows, the operating system isolates Services in Session 0 and runs applications in other sessions, so Services are protected from attacks that originate in application code. In practice, this means that regular users should never start a process that runs in Session 0.
Because PSExec installs itself as a service, any process that you run using PSExec will run in Session 0. Either it will use the passed-through credentials of the user who launched PSExec or the username and password provided on the command line.
This being the case, you can detect not only PSExec, but also any process being run by PSExec or any other processes that are being run in Session 0—either through misconfiguration or malign intent.
The simplest way to detect PSExec itself is to monitor the SYSTEM Event Log for Event ID 7045 with the process name PSEXESVC:
Figure 2. System Event Log for Event ID 7045
Detecting what is being run by PSEXESVC and where requires a little more effort. To do this, let’s introduce another (LogRhythm supported) Log Source Type—Sysmon.
From the Sysinternals suite of tools, Sysmon is installed as a background service that logs security-relevant process and network activity to an Extended Windows Event Log. Amongst other things, it logs the Session ID that the process is running under. (It’s stored in the Group metadata field.)
Figure 3. Introducing Sysmon
Additionally, the Sysmon log contains the parent process ID and process name, so you can confirm that PSExec was what launched this process:
Figure 4. Confirming PSExec with Sysmon Log
You can now create an AI Engine rule based on this information:
Clarification: Start-up and Shutdown
Group: 0
User (Origin): Not in Service Account list
(The Service Account list should include any Domain Service accounts, plus the local SYSTEM and SERVICE accounts on the hosts).
This allows you to detect processes started in SESSION ID 0 by any account that is not a recognized service account:
Figure 5. Creating the AI Engine Rule
Visibility is key to defending the network. Because Session 0 has a clearly defined purpose in modern versions of Windows, which is intended to isolate Windows Services from User Applications, monitoring this behavior can give you an early warning to nefarious activity in the environment.
LogRhythm’s approach to log collection and parsing, combined with the ability of AI Engine to ask the data appropriate questions, gives you extra visibility you need to help keep your networks secure.
Stay up to date with the latest from the LogRhythm blog.
Businesses need to stay proactive to protect their infrastructure from emerging attack vectors. LogRhythm provides a cybersecurity…
The combined company will bring together two cybersecurity SIEM and UEBA innovation leaders with renowned…
Security teams face the challenge of staying ahead of new and advanced threats. By harnessing…