How to Detect and Prevent impacket’s Wmiexec

• Impacket, an open source collection of Python modules for manipulating network protocols, contains several tools for remote service execution, Windows credential dumping, packet sniffing and Kerberos manipulation.
• CrowdStrike Services has seen an increased use of Impacket’s wmiexec module, primarily by ransomware and eCrime groups.
• Wmiexec leaves behind valuable forensic artifacts that will help defenders detect its usage and identify evidence or indication of adversary activity.

Introduction

Impacket’s wmiexec.py (“wmiexec”) is a popular tool used by red teams and threat actors alike. The CrowdStrike Services team commonly sees threat actors leveraging wmiexec to move laterally and execute commands on remote systems as wmiexec leverages Windows native protocols to more easily blend in with benign activity. CrowdStrike has also identified threat actors packaging wmiexec using PyInstaller to run it as an executable on Windows systems, remotely executing data exfiltration tools such as Rclone, and Cobalt Strike beacons for lateral movement and command-and-control operations. 

Impacket’s suite of tools is extremely versatile and is low impact, making detection more difficult compared to other threat actor tool sets. This blog deep dives into wmiexec usage seen from multiple incident response investigations, and describes indicators to help defenders detect wmiexec. 

Wmiexec Overview

Wmiexec relies on the Windows native service known as Windows Management Instrumentation (WMI). Microsoft defines WMI as “the infrastructure for management data and operations on Windows-based operating systems.” While WMI has legitimate use-cases, threat actors commonly use WMI to move laterally. 

Wmiexec allows a threat actor to execute commands on a remote system and/or establish a semi-interactive shell on a remote host. The remote connection and command execution requires using a valid username and password or an NTLM hash. Usage of wmiexec does not require the remote service installation that similar lateral movement techniques require, such as smbexec.py by Impacket. 

Wmiexec uses Distributed Component Object Model (“DCOM”) to connect remotely to a system. DCOM allows COM objects to communicate over the network. The threat actor’s execution of wmiexec.py will establish their connection with DCOM/RPC on port 135, the response back to the threat actor system is sent via the Server Message Block (“SMB”) protocol.

Initial Indicators

When hunting for wmiexec, defenders should look for WMI usage. A defender’s first step should be to analyze the process relationship involving a parent process known as WMIPRVSE.EXE. Suspicious processes such as CMD.EXE or POWERSHELL.EXE running as a child process to WMIPRVSE.EXE are a red flag. Most commonly, and by default, wmiexec will use a child process of CMD.EXE. A common indicator of wmiexec is the command line switches of the CMD.EXE process, which is somewhat unique. An example of executing a tasklist using wmiexec would establish a process relationship similar to the image in Figure 1. Throughout this blog we will often refer to the publicly available source code on Impacket’s GitHub repository.

Understanding wmiexec Command Execution

As shown in Figure 2, on line 127 of the publicly available source code, execution of CMD.EXE will use the parameters of /Q /c. First the parameter, /Q, is set to turn off echo, ensuring the command is run silently. Secondly, the parameter /c is set to stop after the command specified by the string is carried out.

Identifying commands issued with the default cmd.exe /Q /c arguments are an indicator that wmiexec may be in use but note that these are parameters which can be used for legitimate purposes. To further validate the identification of wmiexec usage, another indicator is command redirection. During execution of wmiexec, the command is redirected to a file created on the remote host’s local ADMIN$ share by default. The ADMIN$ share aligns with the file path C:\Windows\.

As shown in Figure 3, on line 295 of the wmiexec code, the command variable has a few variables that are appended with additional data, concatenating the /Q /c switches with the command being run and the redirection. While this full command line is a great indicator of wmiexec usage, the variable __output (shown in Figure 3 as self.__output) is the name of the temporary file written to disk and creates additional forensic artifacts on disk. When the tool concatenates the command parameters together, an example final resulting command is shown in Figure 4 where the threat actor is attempting to execute hostname.

The output variable containing the name of the file that is to be written to disk is declared in two places, shown in Figure 5 of the wmiexec code. First on line 46, the output of the command is given a filename of two underscores, __, followed by the current time in EPOCH. This is important for two reasons: the presence of this file indicates execution of (or attempted execution of) wmiexec and also it will give us a time of execution. As previously mentioned, this file will reside in C:\Windows\, which is remotely accessible using the ADMIN$ share. An example of the file written to disk is shown in Figure 6. The output file stores the results of the command executed to be sent back to the threat actor, which can also be useful to defenders (more on this later).

Cleanup Operations

The output file is not always present on disk because wmiexec, upon successful and complete execution, will clean up after itself. Most commonly this file is left behind for one of two reasons: a threat actor prematurely canceled a command before it has completed (i.e., CTRL+C), or wmiexec failed or was prevented from executing. In either scenario, if the wmiexec script is unable to complete execution it will not reach line 285, shown in Figure 7, to clean up the file on disk. Also of note, incomplete execution of wmiexec does not necessarily mean the threat actor was unable to successfully execute their command.

An example of a failed cleanup operation is if an interrupt command such as CTRL+C was issued while wmiexec is running, which would leave behind a file on disk. In Figure 8, execution of wmiexec is performed using the NTLM hash of a user winadmin to the host INFOSEC-PC1 in a test environment. Executing wmiexec without a command will establish a semi-interactive shell — from an threat actor perspective, this means a shell is established that appears interactive, but each command executed will be sent through the wmiexec channel and include the standard process execution cmd.exe /Q /C <command> 1> \\\\127.0.0.1\ADMIN$\__<EPOCHTIME> 2>&1 command format. In Figure 8, after running nslookup an abort command is issued (CTRL+C) and the nslookup process is interrupted. The result is a file on disk containing the output of the command executed, shown in Figure 9. Note: In Figure 9, an abort command needed to be issued since nothing was supplied to nslookup, and although this was done in a test environment, CrowdStrike Services has seen this exact occurrence happen during real incident response engagements.

Another example of failure to clean up and artifacts left on disk is shown in Figures 10 and 11. In Figure 10, wmiexec is executed similarly as before, but this time powershell.exe is executed. Since running the command powershell.exe would open a new PowerShell prompt, issuing another abort command (CTRL+C) will result in the output file not being cleaned up. Figure 11 shows the header of a new PowerShell window in the contents of the output file, __1645636397.851114.

The temporary files discussed here can be a valuable indicator of wmiexec execution even when they are successfully cleaned up. Windows Prefetch files are used by the Microsoft Windows operating system to improve application start-up performance. Prefetch is a common forensic artifact located in C:\Windows\Prefetch that can be used to identify process execution along with contextual information related to the file that was executed. 

As shown in Figure 12, contextual information can be parsed from Prefetch using a tool such as PECmd. This contextual information includes Dynamic Link Libraries (DLLs) and other files used by the process that was executed. In this example, a variety of DLLs are referenced in the Prefetch file for whoami.exe as well as the temporary files associated with wmiexec. The temporary files previously discussed cannot be extracted from the Prefetch file — but, this example does show that Prefetch data contains evidence that whoami.exe was executed with wmiexec.

Key visibility into potential wmiexec execution comes from command-line process execution. Process execution will give a defender more definitive evidence and visibility into the exact commands being executed regardless of actions taken by the threat actor. Relying primarily on local logging, the Windows Security Event Log can provide granular data on the command line execution with the right settings enabled. Unfortunately, Security Event ID 4688 is not enabled by default. After enabling Event ID 4688, defenders must also configure it for full command line auditing, which is described below.

Note: When introducing any recommendations for security or visibility enhancements to your environment, proper testing should be conducted to ensure it will not affect business operations negatively.

To enable Event ID 4688, open the Local Group Policy Editor and do the following (shown in Figure 13):

Local Group Policy Editor > Open Computer Configuration > Open Windows Settings > Security Settings > Advanced Audit Policy Configuration > System Audit Policies > Detailed Tracking > Enabled Audit Process Creation

In addition, the box for configuring both success and failure events should be checked, and then click apply, as shown in Figure 14.

Finally, check to make sure auditing is enabled, as shown in Figure 15.

After enabling Event ID 4688, the Windows Security Event Log will log created and new process names, giving a defender granular insight into the commands issued on a particular system. As previously mentioned, WMIPRVSE.exe with a child process of CMD.exe is a great indicator of potential wmiexec usage, as shown in Figure 16.

Although visibility into parent/child processes on a system helps defenders, the full process command line in Figure 16 is blank because it must be enabled separately. In order to enable the full process command line, open Local Group Policy Editor and navigate to the following location (as shown in Figures 17 and 18):

Local Group Policy Editor > Computer Configuration > Administrative Templates > System > Audit Process Configuration > Include command line in process creation events > Enable

With process command line auditing enabled for Event ID 4688, more granular detail on the exact commands executed is recorded, rather than just parent/child process execution. Forwarding this data to a centralized security information and event management (SIEM) tool can allow defenders to set up alerts and dashboards to track process executions. As shown in Figure 19, Event ID 4688 is now logging the entire command line, giving a defender the ability to see wmiexec was used to remotely execute the command hostname.

Other resources such as antivirus detection logs and the Microsoft Protection Log (“MPLog”) are also good resources for gaining command line visibility into wmiexec usage. This CrowdStrike blog discusses how to leverage MPLog in greater detail. 

Prevention and Mitigation

Enabling process command lines and Event ID 4688 is great for visibility and can assist defenders in identifying a threat actor within your environment, although it does not aid much in prevention. As shown in Figure 20, running Impacket to establish a semi-interactive shell will give the threat actor the ability to run commands and while visibility into these attacks is critical, mitigating them is the ultimate goal.

CrowdStrike Falcon Insight™ endpoint detection and response will collect granular data on process execution in real time, going into more detail than the standard process creation logging available in Windows. Indicators of attack (IOAs) are a method used to create detections and preventions for wmiexec. Commonly on CrowdStrike Services Red Team/Blue Team assessments, CrowdStrike experts will assist internal teams to configure an IOA that will allow detection and prevention of wmiexec. In Figure 21, having a proper IOA and then attempting to execute tasklist again shows not only the ability to see the full process parent relationships but also how to prevent it.

Each of the processes that spawned the suspected malicious process can be examined to identify a gold mine of information, including the host where the request originated and full command line parameters, as shown in Figure 22.

The prevention will restrict the threat actor’s ability to issue remote commands to systems that have an active CrowdStrike Falcon endpoint protection agent. As shown in Figure 23, the threat actor will receive a response of “SMB SessionError.” The failure to execute wmiexec is true for the semi-interactive shell (Figure 23), as well as running single commands (Figure 24).

Falcon Insight provides detection data for events with the appropriate prevention and IOAs enabled, but telemetry by default will also be useful to identify threat actor activity. Figure 25 shows an example output of an event search in the CrowdStrike Falcon^® console to identify all commands issued. By looking at this list, defenders can see the process, cmd.exe; the remote host that executed the command, 192.168.1.211 (threat actor Testing System); and the full process command line. This is all captured in real time and enables defenders to investigate and respond quickly. The process command line should look familiar and shows execution of a handful of commands (cd, whoami and tasklist).

Falcon Forensics

When looking historically at the artifacts discussed in this blog, Falcon Forensics can be a great asset to a defender’s investigation. Falcon Forensics is a run-once script that is easily deployed through RTR or other deployment tools that will capture a variety of forensic artifacts used for forensic triage of a system. The most beneficial advantage to using Falcon Forensics is the variety of sourcetypes and triage data matched with the ability to perform investigations at scale across an entire environment. Considering the artifacts discussed in this blog, there are specific examples that can be used to find evidence of wmiexec execution at scale, and historically. 

Three source types to scratch the surface and highlight when hunting for wmiexec are prefetch, pslist and dirlist. The standard Falcon Forensics executable will not only capture the presence of Prefetch artifacts but also parse the artifact to identify related modules used by the process, similar to parsing Prefetch discussed previously. In Figure 26 below, the whoami.exe Prefetch file contains a module name of the temporary wmiexec artifacts. Using Falcon Forensics across your environment can look for these artifacts at scale.

In addition to the Prefetch sourcetype, pslist can be used to identify the previously discussed command line artifacts associated with wmiexec that may be still running at the time of Falcon Forensics deployment. Shown in Figure 27, since PowerShell and nslookup will both hang on execution, the processes were still running, which allowed for visibility into the process execution.

Lastly, files written to disk are a strong indicator of threat actor activity. In Figure 27 an example of wmiexec execution that failed to clean up is easily identifiable using Falcon Forensics to search for the recognizable common file name format, __<EPOCHTIME>, in C:\Windows.

Conclusion

Impacket, and specifically wmiexec, is a tool increasingly leveraged by threat actors. While defenders should remain vigilant on the usage of Impacket, the strategies discussed in this blog can also be used to dissect and understand other threat actor tool sets to identify avenues for detection and prevention.

Additional Resources