In my previous blog post I covered how Microsoft has enhanced WMI logging in the latest versions of their client and server operating systems. WMI Permanent event logging was also added in version 6.10 specific events for logging permanent event actions. The new events are:
- Event ID 19: WmiEvent (WmiEventFilter activity detected). When a WMI event filter is registered, which is a method used by malware to execute, this event logs the WMI namespace, filter name and filter expression.
- Event ID 20: WmiEvent (WmiEventConsumer activity detected). This event logs the registration of WMI consumers, recording the consumer name, log, and destination.
- Event ID 21: WmiEvent (WmiEventConsumerToFilter activity detected). When a consumer binds to a filter, this event logs the consumer name and filter path
In version 6.10 it tracks the creation and deletion of __EventFilter Class, Any Consumer Type Class and __FilterToConsumerBinding Class.
For looking at the events it captures lest create a sample configuration file that will log WMI Events. The configuration file is the following:
<Sysmon schemaversion="3.4"> <HashAlgorithms>SHA256</HashAlgorithms> <EventFiltering> <WmiEvent onmatch='exclude'> </WmiEvent> </EventFiltering> </Sysmon>
We can save this file as test.xml and apply it by running sysmon -c .\test.xml from a cmd or PowerShell console running as administrator. When we run sysmon -c to list the configuration we should see something like this:
System Monitor v6.10 - System activity monitor Copyright (C) 2014-2017 Mark Russinovich and Thomas Garnier Sysinternals - www.sysinternals.com Current configuration: - Service name: Sysmon - Driver name: SysmonDrv - HashingAlgorithms: SHA256 - Network connection: disabled - Image loading: disabled - CRL checking: disabled - Process Access: disabled Rule configuration (version 3.40): - WmiEvent onmatch: exclude - WmiEvent onmatch: exclude - WmiEvent onmatch: exclude
We will use Windows PowerShell to create a permanent event that will track service changes in state in to a text file.
We start by creating a __EventFilter that will check for a modification of the Win32_Service class every 5 seconds.
#Creating a new event filter $ServiceFilter = ([wmiclass]"\\.\root\subscription:__EventFilter").CreateInstance() # Set the properties of the instance $ServiceFilter.QueryLanguage = 'WQL' $ServiceFilter.Query = "select * from __instanceModificationEvent within 5 where targetInstance isa 'win32_Service'" $ServiceFilter.Name = "ServiceFilter" $ServiceFilter.EventNamespace = 'root\cimv2' # Sets the intance in the namespace $FilterResult = $ServiceFilter.Put() $ServiceFilterObj = $FilterResult.Path
Once the event is created we see that a Event 19 is create and under EventData we wee a Data element where the Operation attribute says Created.
Since I know that some APT groups associated to state actors are known not modify existing permanent events to blend in target environments I decided to test modifying the current filter Query to see if it logged the action with the following actions in the PowerShell window:
$ServiceFilter.Query = "select DisplayName from __instanceModificationEvent within 5 where targetInstance isa 'win32_Service'" $FilterResult = $ServiceFilter.Put()
The creation was logged under Event Id 19. We can see that under Operation it is blank now, this means there is no logic in 6.10 to track modification but it still logs an action we can filter and trigger on. I informed one of the developers at Microsoft about this and they will address this in the next release of Sysmon for all log types.
Lets create now a consumer that will create a log file on the C:\ drive with the following Windows PowerShell Code in the existing window where we created the filter.
#Creating a new event consumer $LogConsumer = ([wmiclass]"\\.\root\subscription:LogFileEventConsumer").CreateInstance() # Set properties of consumer $LogConsumer.Name = 'ServiceConsumer' $LogConsumer.Filename = "C:\Log.log" $LogConsumer.Text = 'A change has occurred on the service: %TargetInstance.DisplayName%' # Sets the intance in the namespace $LogResult = $LogConsumer.Put() $LogConsumerObj = $LogResult.Path
We can see the LogFileEventConsumer creation was logged with Event Id 20 and all properties of it where parsed under EventData Element of the log structure.
Lets create a __FilterToConsumerBinding class instance using the __EventFilter and the LogFileEventConsumer class instance we created earlier.
# Creating new binder $instanceBinding = ([wmiclass]"\\.\root\subscription:__FilterToConsumerBinding").CreateInstance() $instanceBinding.Filter = $ServiceFilterObj $instanceBinding.Consumer = $LogConsumerObj $result = $instanceBinding.Put() $newBinding = $result.Path
The action is logged with Event Id 21 and that the Filter and Consumer paths in the CIM Database are included under EventData.
In conclusion I can say that the logging in Sysmon expands on what we can already log in the newer versions of Windows and it provides better consistency and insight on Permanents type events and their components that the current Windows logging does not. It does not over temporary events, providers or query errors but it is a great start. I would recommend to simply enable logging of all events associated with WMI permanent events and to not filter in the configuration file since their creation is not common on aday to day operation and their modification is very rare so the simple presence of the events is enough to warrant a look in a production environment.