Overview
For this post we are going to be focusing on three EventIDs that pertain to the Windows Registry. These sysmon events occur when a registry key is created, updated, deleted, or renamed. The Registry is the central configuration system in the Windows world and a great place to monitor when looking for software activity, whether it be for configuration changes or malware looking to maintain persistence on a system.
It is important to note that the sysmon configuration that you choose will greatly affect the types of registry events that sysmon will emit. We will assume that you are using the great sysmon config provided by olafhartong (https://github.com/olafhartong/sysmon-modular) which targets some critical registry components for exclusive inclusion. This means that we will get events related to autorun, shell, some core windows components, and many login events. It will not log every time some random application creates or deletes a key in its own registry location. The config also attempts to call out some especially busy events that don't really need to be monitored. So let's dig in.
Event ID 12 - Create and Delete.
Event ID 12 represents a registry object creation or deletion, this means creating a key or deleting a key. These events typically happen when applications are starting up or during installation. Event ID 12 typically represents a minority of registry events, however you will notice misbehaving applications that like to mindlessly create and delete registry keys **COUGH** OneDrive.exe **COUGH**.
The registry create/deletion event contains six data items of note and one redundant UTC timestamp. They are:
- RuleName
- EventType
- ProcessGuid
- ProcessId
- Image
- TargetObject
The EventType data item tells us if this is a create (CreateKey) or delete (DeleteKey) event. The Process, Image, ProcessId, ProcessGuid, and Target data items tell us which process created (or deleted) the key and the path to the key. Let's look at an example creation event in Data Explorer to see some structure:
This event tells us that scvhost.exe created a key in the services registry path, the RuleName tells us why this particular event was logged. In this case it matches the rule that is fired when a service is created or modified. We can do a quick query to look at the distribution of CreateKey vs DeleteKey vs DeleteValue, and even graph it.
tag=$SYSMON winlog ProviderName=="Microsoft-Windows-Sysmon" EventID==12 EventType
| stats count by EventType
| chart count by EventType
There are a few critical registry locations that are worth monitoring and even setting up alerts, they are mostly around startup and shutdown (persistence) and shenanigans around lookup paths and automated actions. Windows, in all its wisdom decided to provide for approximately elevendy billion™ methods to run items at startup and/or shutdown so actually monitoring them all is kind of a pain, but here is an example query that looks for key creation or deletion with Winlogon in the registry key path:
tag=$SYSMON winlog ProviderName == "Microsoft-Windows-Sysmon" EventID == 12 EventType Target~Winlogon
The Windows registry has become somewhat of a configuration dumping ground with legacy keys going all the way back to Windows NT. Effectively choosing what matters can be tough.
Event ID 13 - Registry Value Set
Event ID 13 is fired every time a registry value is set, it does not occur when the registry key is initially created, only when something is written to the existing key. This registry event represents the overwhelming majority of registry events due. It should still be monitored as there are several critical registry keys that can profoundly alter the behavior of a Windows system. Malware will often update system critical keys to do all sorts of malicious things. Normal software also likes to hammer this event, which is why most good sysmon configs have large exclusion and inclusion blocks to try and narrow down on security relevant events.
The value set event has the same set of data items with one additional Details item. The Details item usually contains the value set to the key or "(Empty)" when a registry key is cleared.
Here is the event that Sysmon triggers when the GravwellEvents service is installed, you can see it setting the Start value to a DWORD value of 2, meaning that the service will start automatically at boot.
From a security context its worth looking at writes to registry keys based on the ruleset rather than trying to track every single registry key of value. You can get a quick breakdown of registry activity by rule using this query:
tag=$SYSMON winlog ProviderName == "Microsoft-Windows-Sysmon" EventID == 13 RuleName
| stats count by RuleName
| table RuleName count
If you are using the modular sysmon configuration provided by olafhartong you will get a really nice breakdown by technique_id and technique_name, if you are using any of the other configs that are not as well maintained you will get a rule breakdown that is pretty haphazard. Notice that the RuleName breakdown here is all over the board, this aggregation came from the SwiftOnSecurity config that is popular. We HIGHLY recommend starting from the modular sysmon config, the rules are well documented and well referenced.
There are a few that are worth calling out and as far as we can tell security significant items typically have a technique_id and technique_name. Here is a query that will drill into registry events that trigger the rule about running applications at startup:
tag=$SYSMON words Registry Run
| winlog ProviderName == "Microsoft-Windows-Sysmon" EventID == 13 RuleName~Run TargetObject Image Details
| kv -e RuleName -sep "=" -d "," technique_id technique_name
| table technique_id technique_name TargetObject Details Image TIMESTAMP
Notice that we are using the kv module to break apart the rule structure.
There are also some fun stupid human tricks using the Sysmon and the registry, here is a fun query that monitors audio capture by programs, tallies up how often applications are capturing audio:
tag=$SYSMON winlog Provider=="Microsoft-Windows-Sysmon" EventID==13 TargetObject RuleName~"Audio Capture" Computer TimeCreated Details
|sort by time asc
|regex -e Details "\((?P<qword>.+)\)" qword != "0x00000000-0x00000000"
|regex -e TargetObject "#(?P<appname>[^#]+)\\LastUsedTime(?P<mic_action>\S+)"
|diff TIMESTAMP by Computer appname
|eval mic_action=="Stop"
|stats count as Count sum(diff) as TotalTime by Computer appname
|table Computer appname TotalTime Count
Deciding which events matter for the registry can be tough, if you are not using a well maintained configuration with clearly defined RuleName members it can be extremely difficult to determine what matters. Using good configs makes it easy to quickly reference to the MITRE ATTACK framework technique IDs and key off of them for alerts and queries. For example we can get a rapid breakdown of all scheduled task events by keying on the technique_id T1053 rather than trying to manually track all the methods used to schedule a task in the registry. Basically let the config and rule organizations do this work for you. HOWEVER when your config rules miss (and they can) having the raw underlying data lets you still hunt with Gravwell.
Event ID 14 - Registry Key and Value Rename
The Sysmon EventID 14 data occurs whenever a monitored registry item is renamed. In practice this event is exceedingly rare. Under normal circumstances programs create registry values with a specific name in mind, this event only fires if an existing registry key or value is renamed. On the surface you might think this is a boring event that can be ignored entirely, but you would be wrong.
Let's start by looking at the data items in this event. It contains the same subset of items in EventID 12, with the additional NewName data item. The NewName data item represents the new name given to the TargetObject data item. So if we rename the Registry Key HKLM\SOFTWARE\testing\foobar to barbaz we will see the following event data:
This event is important because if we only monitored critical keys during creation or update an attacker could create a benign key and then rename it to a critical key. You would see the creation event of a benign key like foobar, but miss the rename to Run. Tracking key renames can be useful and even fun. For instance, let's use the Gravwell taint module with an FDG renderer to watch the life cycle of a key rename:
tag=$SYSMON winlog EventID == 14 ProviderName == "Microsoft-Windows-Sysmon" TargetObject NewName Computer
| join -s : Computer TargetObject as src
| join -s : Computer NewName as dst
| fdg src dst
This query makes use of the join module to create a src/dst pair out of the registry key path and the computer, this way we could track specific key renaming on multiple machines. For this example the crafty attacker attempted to shake us off his trail by renaming the key several times and then doubling back. The FDG saw it though:
The target registry values to monitor for Event14 are pretty much identical to those in Event 12 and 13 except that you should monitor the NewName data item rather than the TargetObject. Event 14 is rare enough that we only really saw it when users were manually fiddling with the registry via regedit.exe. In that case you see it when users create new keys, because regedit first creates the key using a generic New Key #1 value then renames it to the value they set.
Additional Notes
Sysmon can be a very powerful and free endpoint monitoring tool, however the ruleset you load it with ultimately controls how useful the tool will be. The Windows registry is a busy and complicated configuration system in Windows, as such the most popular configurations like those from SwiftOnSecurity and olafhartong have extensive rule sets to try and remove some of the noise. While this helps reduce the load and potential false positives, it also means that you will not have a complete view into all registry events.
Building out meaningful detections can be exceedingly difficult as well, as there are 10s if not hundreds of methods to provide persistence, process injection, and just straight up starting of processes. The good rule sets like the sysmon-module set does a good job of covering them and ensuring that they get logged, however you are ultimately at the mercy of the config and if its RuleName naming consistency is haphazard or the exclusion/inclusion filters miss something important sysmon will not emit events. This means that when a key gets updated, it can be difficult to trigger an alert without relying on RuleName consistency. This means that you will probably want to audit your config and make sure that it has consistent and usable naming consistency.
Example Gravwell Queries
List Registry Run Key Updates
tag=$SYSMON winlog Provider=="Microsoft-Windows-Sysmon" EventID == 13 Image Computer RuleName ~ "Registry Run Keys" Details TargetObject
| words Registry Run Keys
| table Computer Image Details TargetObject TIMESTAMP
List Environment Variable Changes
tag=$SYSMON winlog Provider=="Microsoft-Windows-Sysmon" Computer=="user-PC" EventID==13 TargetObject~Environment EventType==SetValue Image Details
| table Computer Image TargetObject Details
NOTE - This query only catches environment variable modification via the registry API. Modifying the environment variables using Windows Environment tools won't show up (even though the changes are reflected in the registry).
Conclusion
Data is better together, especially when we can tell the source of the data. You can use Gravwell’s automation system to automatically monitor registry activity and even pivot against many threat lists (both free and paid). The registry is dangerous, don't go it alone, take Gravwell.
Sysmon is excellent for bringing all of that telemetry to you, while Gravwell is fantastic for making it human-readable. Having the processes available to you in one centralized location makes threat hunting, blocklisting, and security analysis easier.
Are you interested in adding Gravwell+Sysmon data to your Operations and Security arsenal? Get in touch with us for a free trial and demo to geek out with us on how to improve your organization’s EDR.
