Malware Persistence
Malware persistence is the ability of a malware infection to maintain its presence on a system even after it has been removed or detected by security software. Persistent malware is able to survive system reboots and other attempts to remove it, allowing it to continue its harmful activities.
There are several ways in which malware can establish persistence on a system. These include:
- Modifying the operating system’s startup process to automatically run the malware when the system boots up
- Placing the malware in a location that is executed automatically by the operating system or a commonly used application
- Hiding the malware in a location that is not easily accessible or detectable by security software
- Disabling or altering security software to prevent it from detecting or removing the malware
Malware persistence is a serious concern for cybersecurity, as it allows the malware to continue to cause harm and potentially spread to other systems. It is important for individuals and organizations to implement effective security measures to detect and remove persistent malware.
In this article we will cover WMI Event Consumers and discuss what they are and how we can detect and remediate.
WMI Event Consumers
WMI (Windows Management Instrumentation) event consumers can be used to monitor and respond to changes in the state of managed objects. For example, a WMI event consumer might be used to monitor a computer’s CPU usage and send an alert if it exceeds a certain threshold.
WMI event consumers can be written in a variety of programming languages, such as Visual Basic, JScript or PowerShell. They can also be integrated with other applications and systems, such as database management systems or network monitoring tools.
Overall, WMI event consumers are an important part of the WMI framework, providing a way for applications and systems to monitor and respond to changes in the state of managed objects on a computer.
Malicious Event Consumers
Because WMI event consumers have the ability to monitor and respond to changes in the state of managed objects on a computer, they could potentially be used by malware to monitor and execute malicious actions.
For example, a WMI event consumer could be used by malware to monitor the creation of new files on a computer and automatically execute any files that match certain criteria (such as a specific file name or extension). This could allow the malware to spread itself to other files or computers on the network.
However, it should be noted that WMI event consumers are not inherently malicious and can be used for legitimate purposes as well. It is up to the person or organization who creates the consumer to determine how it will be used.
Threat actors need to do three things for this persistence mechanism, create a filter, add a consumer and create a binding to tie the two together.
Event Filter
An event filter is a set of criteria that is used to determine which events a WMI event consumer should receive and process. WMI event consumers can be registered to receive events that are generated by a WMI provider. An event filter specifies which events the consumer should receive based on certain characteristics of the event, such as its type, source, or time of occurrence.
For example, an event filter might specify that a WMI event consumer should only receive events of the “Error” type that are generated by a particular provider. This would allow the consumer to focus on a specific subset of events and ignore the rest.
Event Consumer
These were discussed above, but a simple way of thinking about them is they are the script or executable set to run.
Binding
The binding is the part that links the filter and the consumer together, it is loaded into the WMI repository and is ready to run when the conditions are met.
How To Discover Malicious Event Consumers
Luckily it is quite easy to use Powershell to call and review these three objects for review. The hard part is getting to know how to identify a malicious one. There is the “SCM Event Log Filter” setup on Windows by default that you can review using these commands to learn what the components look like. To check the components use the following commands:
Get-WmiObject -Namespace root\Subscription -Class __EventFilter
Get-WmiObject -Namespace root\Subscription -Class __EventConsumer
Get-WmiObject -Namespace root\Subscription -Class __FilterToConsumerBindingBear in mind the root\Default namespace should also be checked. A good starting point is to review the __EventConsumer for what class it is, pay particular attention if it is CommandLineEventConsumer or ActiveScriptEventConsumer. Once you notice a malicious one, you can move to the filter and see what the trigger event will be.
Another thing to look out for is threat actors will try to hide their malicious event consumers. For instance if you see “SCM Event Logs Filter” and the class is set to “CommandLineEventConsumer”, this is likely a malicious event consumer, and the threat actor has used a similarly name in an attempt to hide it.
Summing Things Up
While malicious WMI Event Consumers are not one of the most popular persistence mechanisms, they are important to know about as their rarity often sees them over looked. One of the most famous uses for this persistence mechanism was STUXNET. In the coming weeks we will go onto some of the other persistence mechanisms and what to look out for, but in the meantime go check out some of our other cyber articles.
