CrackMapExec (CME) is a popular post-exploitation framework and penetration testing tool, and it’s frequently used in the field. Although CME is versatile and modular, it has become a target for threat actors exploiting its features for malicious purposes. For that reason, it’s important for blue teams to keep up with updates of such frameworks. With the introduction of new modules and capabilities, defenders should make sure they have detections and hunting strategies in place.

In this blog, we’ll dive deep into these new additions to understand what they do, how they can be used, and, most importantly, how you can detect and hunt for these activities on your network.

Keeping Up with Updates

Staying up-to-date with the latest red-team tools and techniques in our field is crucial. For blue teamers, this means keeping an eye on what the red teamers are up to. How can you defend against tactics you’re not even aware of?

Following good red teamers on social media isn’t just for admiration of their skill set — it’s a critical component of a proactive defence strategy. These professionals often post about their latest discoveries, new features in their tools, and methods they find particularly effective. And guess what? Threat actors are reading those same updates and thinking about how they can use those tactics against you.

Below is the tweet by @mpgn_x64, creator of CrackMapExec, announcing key features of this latest update.

In this article, I will mainly focus on the below updates:

• New Protocol Implementation: WMI (CME #81)
• New Module: WCC (not sure what it stands for, but from context, I am guessing Windows Configuration Checks) (CME #56)
• New Module: pi (process injection method) (CME #61)
• Extracting credentials in IIS Application Pool configuration files using appcmd.exe (CME #L46)

For me, this is the biggest update of this CME update, and thus, I’ll be covering this section in more detail. WMI module is now able to use DCE/RPC over TCP/IP. This means that it can now utilize remote procedure calls (RPC). The main advantage of this update is that it doesn’t need to use the SMB protocol. Previously, the SMB protocol was required to receive responses from the target machine. Now, the WMI module can execute and receive commands through WMI access only. Let’s have a look at what this would look like and how we can detect/hunt for this activity.

Network Traffic
As explained above, this implementation uses WMI exclusively. This is useful to the red team as many networks have started blocking access to port 445 (SMB), and security products are closely monitoring this port. Here is a connection example:

First, the attacker’s host initiates a DCE/RPC bind operation to IOXIDResolver, signifying that it wants to interact with that specific DCOM object. IOXIDResolver is an interface within this system that plays a role in resolving Object Exporter IDs to Object Exporters. In simple words, it maps the identifier to a network address so the client knows where to send the RPCs (Remote Procedure Calls). For more information, see the Python implementation of this here: IOXIDResolver.py.

We then see the attacker’s host sends authentication information for the user “administrator” after a challenge request for NTLM authentication. No SMB connection is required whatsoever, and the network footprint is significantly smaller.

Host-Based Events & Artifacts
I will only cover the updates for this implementation and not existing information. There are plenty of good articles on how to detect existing execution, which is based on the Impacket framework. I will have those listed on the references at the end of this post.

After the attacker uses the WMI method to launch a command on the remote host, there are several new processes that take place. It mainly uses WMI events to execute the attacker’s command. To understand this execution flow, I will also briefly explain how WMI event subscriptions work. You can easily get lost in the world of WMI. To keep things short and relevant, we should only focus on the three specific WMI objects and how they fit in the context of this new execution flow:

1. Event Filter: An Event Filter defines the criteria for events that you are interested in. It specifies what type of events to monitor, such as the creation of a new process. Event Filters are essentially WQL queries that tell WMI what to look out for. The query that CME is using on the registered Event Filter is:

   select * from __TimerEvent where TimerID=\"windows-object-13177001-3989-4aac-91b8-6eef858249d7\"

   —

   select *: This means "select all properties." In the context of WMI, this would mean gathering all the available data fields related to a particular instance of the __TimerEvent class.
   — from __TimerEvent: This specifies that the query should look within the __TimerEvent WMI class. The __TimerEvent class is a type of system class used in WMI for timing-related events.
   — where TimerID = "windows-object-<UUID>": This is a filter that narrows down the query only to return instances where the TimerID property matches the given GUID.

2. Event Consumer: An Event Consumer is the action that gets executed when a specified event occurs. For example, if your Event Filter is set to monitor the creation of new files in a directory, the corresponding Event Consumer could be configured to log this activity or send an alert. Event Consumers define what to do when the events caught by the Event Filters occur.

   This WMI-updated module uses the ActiveScriptEventConsumer to execute scripts. These scripts can be found under wmiexec_event_vbscripts of the CME project, and they contain instructions for executing the desired attacker’s command on the remote host. CME is populating the VBS script on the fly and registers it as the Event Consumer. Once the Event Filter is triggered, the VBScript will check to see if the command is written in Base64 encoded format under C:\Windows\Temp , which will execute once the Event Filter is triggered. If it has, it will execute the Base64 command from the txt output. If it hasn’t, It will create a Scheduled Task with the descriptionUpdate , and the Author set to Microsoft .

   For more details on the VBScript functionality, you can check the source code here: Exec_Command_WithOutput.vbs.

3. FilterToConsumerBinding: This WMI object serves as the glue between Event Filters and Event Consumers. It maps a specific Event Filter to a specific Event Consumer, thereby establishing a relationship between what events to monitor and what actions to take when those events occur. This binding ensures that the right actions are triggered by the appropriate events.

Using Sysmon event logs, we can observe the following Event IDs generated on the target host:
— 19(WmiEventFilter)
— 20(WmiEventConsumer)
— 21(WmiEventConsumerToFilter)

To provide some context to the above screenshot:

• Event Filter Name = windows-object-13177001-3989-4aac-91b8-6eef858249d7

• Event Consumer Script = The script under the Destination field with the name being the same as the Event Filter.

• FilterToCosumer Binding

Now that we understand how the new WMI module works let's explore ways to detect its activities.

↪ Interrogate
To begin with, you need to make sure that you have visibility over WMI event subscription telemetry. As we saw earlier, Sysmon can generate those events if you configure its config accordingly. On the other hand, EDR vendors can be a hit or miss. If you are unsure whether your EDR vendor is providing this telemetry, you can refer to the EDR Telemetry project to learn more about the telemetry they offer.

↪ Investigate
To check for unusual WMI activity, first, look for suspicious commands or scripts in event consumers. EventConsumers are by far the most interesting objects to focus on as they contain potentially malicious code. Continue with finding the linked event filter through FilterToConsumerBinding. Examine the filter’s triggers and watch for any actions by scrcons.exe in the process tree.

The scrcons.exe executable is responsible for running WMI scripts that are set up to execute in response to events detected by WMI Event Filters. When a WMI Event Filter detects an event that matches its criteria, scrcons.exe is invoked to execute the script specified in the corresponding Event Consumer.

↪ Detect/Hunt
Looking at the newly added code, the InstanceID will serve as the WMI Event Filter Name.

Detection: We can use the below regex pattern to search or detect event filters that contain the default name:

^windows-object-[0-9a-fA-F]{8}\b-[0-9a-fA-F]{4}\b-[0-9a-fA-F]{4}\b-[0-9a-fA-F]{4}\b-[0-9a-fA-F]{12}$

Be mindful that these names are only the defaults and can be changed with ease by non-script kiddie threat actors.

The new WCC module queries important Registry Keys that collect information about the target host. Some of the collected information includes:

- Last successful update
- LAPS
- Administrator’s name
- UAC configuration
- Hash storage format
- Always install elevated
- IPv6 preference
- Spooler service
- Wigest authentication
- WSUS configuration
- LSA cache
- AppLocker
- RDP expiration time
- CredentialGuard
- LAPSma
- Administrator’s name
- PPL
- Powershell v2 availability
- UAC configuration
- NTLMv1
- Hash storage format
- Always install elevated
- IPv6 preference
- NBTNS
- Spooler service
- mDNS
- Wigest authentication
- SMB signing
- WSUS configuration
- LDAP signing
- LSA cache
- AppLocker
- SMB encryption
- RDP expiration time
- CredentialGuard
- PPL
- Powershell v2 availability
- NTLMv1
- NBTNS
- mDNS
- RDP authentication
- BitLocker configuration
- SMB signing
- Guest account disabled
- LDAP signing
- SMB encryption
- Automatic session lock
- Powershell Execution Policy
- RDP authentication
- BitLocker configuration
- Guest account disabled
- Automatic session lock
- Powershell Execution Policy

For the full list of Registry Keys, you can check out the newly added code here. This module is using the hBaseRegOpenKey function from the rrp.py script in the Impacket project. The rrp.py script is responsible for implementing functionalities related to the Remote Registry Protocol (RRP).

The rrp.py file includes definitions for operations like OpenLocalMachine, OpenRemoteMachine, QueryValue, SetValue, etc., which interact with the registry on a remote machine.

↪ Investigate
Do you have visibility over querying against registry keys? This is not an easy metric to collect. There are numerous applications and OS operations that are querying the registry every second. This is what makes this new CME feature stealthy, collecting valuable information without the risk of detection.

↪Verify
Having said that, the WCC module checks various configuration items on Windows machines, such as LSA cache, hash storage format, etc. You can proactively check and make sure your Windows hosts are configured correctly. There are various ways to safely perform these checks. You can also wear your purple hat and utilize CME on a limited number of Windows hosts. However, it’s advisable to follow safer methods unless you have a lab setup that replicates your production environment.

The new Pi module is used to run commands by process injection method for logged-in user(s). It is an import of the RunCommandViaProcessInjection GitHub project, and thus, it relies on a portable executable to complete the actions. More on that in the detection/hunt section below. This application allows the attacker to take control of a specific process and execute a command. One of the prerequisites is that the attacker needs to know thePID of the target process.

↪ Detect/Hunt
The new Pi module uploads an executable from this project to the target host. The PE file can be found on this VirusTotal link. The executable is written under C:\Windows\Temp a directory with the name pe.exe. The new pi.py module contains the hardcoded PE file in Base64 encoded format.

A very easy win could be to detect the default binary with SHA256 hash: 173de723e89647bc2b884ed7770fc259dcf9de641c7d3df99693811503d9cd8e

A more reliable method would be to detect the process injection using Sysmon event logs or an EDR that can provide you with the relevant telemetry. For Sysmon, that would be:

• Event ID 1: Process Create
  The ParentCommandLine is in accordance with the default smbexec.py execution. Please refer to the links on the references for more information on the execution flow as well as related detections.

• Event ID 10: Process Accessed

• Event ID 8: CreateRemoteThread detected

CrackMapExec has a new feature that looks for the dNSHostName attribute using an LDAP search filter. It is using Impacket’s ldapasn1.py script to accomplish the LDAP search.

↪ Interogate
You can use the "Microsoft-Windows-LDAP-Client" event logs for visibility over LDAP queries from the target host. Be aware that this event log is not Enabled by default.

↪ Detect/Hunt
You can then monitor or hunt for search filters like (&(objectCategory=computer)(primaryGroupId=516)). More information can be found in this fantastic article by @blacklanternllc and Adeem Mawani.

Lastly, this is also a feature that I believe will be abused quite a lot. The author is using PowerShell to execute appcmd.exe. The appcmd.exe tool is a command-line utility that comes with Microsoft's Internet Information Services (IIS) web server and can be used to configure and manage IIS settings.

This method is looking for credentials under applicationHost.config configuration file. The credentials should be encrypted; however, using appcmd.exe with administrator rights, one can list the application pools using appcmd.exe list apppools command and take it a step further by adding /text: to list all or a specific segment of the config.

Below, you can see the code implemented by this new feature:

According to Microsoft:

AppCmd is an IIS admin tool that requires admin privilege to run. Therefore, showing the password doesn’t break the security boundary.

↪ Detect/Hunt
I created a sigma rule for this activity based on process creation logs. I made the rule a little more generic to hopefully catch other execution patterns. Feel free to use https://sigconverter.io/ to translate this rule to the SIEM or EDR of your choice!

Keeping up-to-date with changes in popular penetration testing frameworks like CrackMapExec is essential for staying one step ahead of the majority of threat actors. As this framework evolves, the detection and hunting strategies also need to be updated. With proper visibility and proactive monitoring, you can spot these techniques early and take appropriate action. This post describes my process of researching and creating hunting and detection opportunities using open-source sources. I hope you found it useful. For any questions, feel free to reach out to me on Twitter (@Kostastsale) or anywhere else you find me, and I’ll be happy to chat.

I’d like to thank all the talented red teamers who have contributed to this project. Projects like this demonstrate what is possible in terms of attack avenues and enable us to explore similar methods that are likely used by threat actors. Thanks to everyone who contributed to the articles referenced below; they are invaluable sources of information that helped me better understand the concepts mentioned in this blog post.

References