Looking for COM Hijacking with Splunk and Sysmon

I will admit there wasn't much I could do to make this a prettier title. Today's content might be niche; it has involved me using Splunk (which I am still relatively new to) and is actually a 'transposition' of a query I've done fairly quickly within KQL.

First and foremost, this post assumes you have:

• A Splunk instance
• Sysmon ingestion to Splunk

A massive thanks to Hurricane Labs who has written a fantastic guide on how to get Sysmon logs into Splunk: https://hurricanelabs.com/splunk-tutorials/splunking-with-sysmon-series-part-1-the-setup/.

COM (Component Object Model) Hijacking

COM Hijacking falls under Privilege Escalation and Persistence in Mitre ATT&CK, implying security controls up until these stages have failed. It involves the adversary manipulating the registry keys associated with Component Object Model (COM) identifiers. An attacker can edit a legitimate COM entry key and edit them to redirect calls of that COM to a malicious binary. By targeting frequently used COM's, it can be used for persistence without relying on more obvious techniques like scheduled tasks.

When a COM object is created, Windows will first look for the CLSID under "HKEY_CURRENT_USER\Software\Classes” before falling back to “HKEY_LOCAL_MACHINE\Software\Classes”. This means COM hijacks can occur at the user level, causing differing behaviours between them, thus making it harder for heuristic detection capabilities.

I won't profess to be an expect in this area, so I strongly recommend reading up on Attack IQ's article on how COM objects are used.

Some test criteria

We need to start by generating some logs to review them in Splunk. We'll make some assumptions based on the position of COM Hijacking in the Mitre ATT&CK framework: an adversary already has system access and is intending to remain under the radar. The adversary is likely to resort to pragmatic access to the registry using built-in tools; like using 'reg.exe'.

For the purpose of this post, the following command will be used for testing criteria:

  reg add "HKEY_CURRENT_USER\Software\Classes\SampleKey1" /v Empty /t REG_SZ /d "calc.exe"        

This makes a new 'SampleKey1' under "HKEY_CURRENT_USER\Software\Classes\" with the string value 'calc.exe'.

Developing the Splunk query

After running our testing command, let's start by filtering all logs submitted by Sysmon:

source=xmlwineventlog:Microsoft-Windows-Sysmon/Operational        

Running 'wide' searches like this gives and indication of field names that can be filtered on. For instance:

• EventCode: 1 - Process Creation in Sysmon
• OriginalFileName: Look for reg.exe from the PE header, so even if reg.exe gets renamed to something else the detection still works
• CommandLine: Contains the registry hive that we're looking for modifications against

This results in:

source=xmlwineventlog:Microsoft-Windows-Sysmon/Operational EventCode=1 OriginalFileName=reg.exe CommandLine=*HKEY_CURRENT_USER\\Software\\Classes*         

Working with the data

The query matches with the test command, but we can still extract 'calc.exe' from 'CommandLine' allowing for further refinement.

For those familiar with my posts, you'll know I'm a fan of Regular Expressions.

Regular Expressions can be done by invoking 'rex' in the Splunk query. The Regular Expression we're using today looks for spaces and backslashes to determine each argument and results in each one being captured in its own group.

A new concept to me is that Splunk requires a field name within the Regular Expression (denoted by '?<Name>') so this gets added after we're happy the core expressions matches what's needed. A great SPL (Splunk Search Processing Language) cheat sheet can be found here.

The additions to the Splunk query for extracting arguments from the 'CommandLine' field:

| rex field=cmdline max_match=0 "(?<CmdLineArgument>[^\" \t\n]+|\"[^\"]*\")"        

Great! We can now see the list of argument matches in the new field name specified:

Evaluating each argument

The argument list can be expanded into individual rows with 'mvexpand', allowing us to evaluate each individual item in the list. Imagine my happiness when I found out that SPL has this capability!

To evaluate any arguments ending with .exe (such as 'calc.exe') this can be done with two additions to our query:

| mvexpand CmdLineArgument | where CmdLineArgument like "%.exe"        

Depending on your risk appetite, you can also opt to look for other file extensions (like .dll, or .ps1) that could also indicate some nefarious presence.

Conclusion

Putting the query together results in a unique field that shows 'calc.exe' being entered into the registry:

This allows for expansion of the query in the future, like comparing frequency analysis of how many times this has been observed (stay tuned for a follow up post). The query itself is quite niche and should be added to an existing repertoire of detections that target tactics techniques and procedures from prior ATT&CK stages.

Prevention is better than detection, so it would be recommended to use the rule in conjunction with other security policies, such as enforcing the 'Prevent access to registry editing tools' via Group Policy. Note this only prevents built in tools and doesn't prevent 3rd party tools manipulating 'NTUSER.DAT', where user-based registry keys are kept.

Full Query

source=xmlwineventlog:Microsoft-Windows-Sysmon/Operational EventCode=1 OriginalFileName=reg.exe CommandLine=*HKEY_CURRENT_USER\\Software\\Classes* | rex field=cmdline max_match=0 "(?<CmdLineArgument>[^\" \t\n]+|\"[^\"]*\")" | mvexpand CmdLineArgument | where CmdLineArgument like "%.exe"