Manipulating IBM QRadar Windows Default Properties

Introduction

This post was created in order to highlight and remind that the effectiveness of a detection strategy in a SIEM does not only lie just in the creation of detection rules but in multiple other variables, including effective log parsing. For this reason — and with IBM QRadar as an example — , in this post we will demonstrate how a simple folder creation could potentially render almost every detection rule utilizing Windows event ID 4688 useless.

What is Parsing

Most SIEM come with built-in parsers to help parse incoming logs for well-known data sources. In the context of a SIEM, parsing is the process of analyzing and interpreting incoming log data to extract meaningful information. During parsing, relevant log fields like IP addresses, user IDs, timestamps, and event types are extracted and organized for better categorization and correlation. The result is the translation of logs into key-value pairs that can be later used in the creation of detection rules, hunting queries etc.

Windows Event ID 4688 Default QRadar Properties

IBM QRadar has an out-of-the-box parser for Windows event logs. This means that with a fresh installation of QRadar you already have most of the information you will need parsed. Each parsed piece of information in QRadar is named Property. Most properties created by the default parser of QRadar is done by using regular expressions.

As already stated, in this post we will focus on Windows event ID 4688: Success Audit: A new process has been created. More specifically, we will focus on the following 3 default properties that come with a fresh install of QRadar, along with their respective regular expressions:

· Command:

Process Command Line:\s?(.*?)\s+?Token\sElevation\sType

· Process Path:

New Process Name[:\s\\=]*(.*?)\s+(?:Token Elevation Type:|&&)

· Process Name:

New Process Name[:\s\\=]+.*?\\([^\\]*?)\s+(?:Token Elevation Type:|&&)

Example

To showcase how the above works in QRadar, we will test it by executing mimikatz with the following command in cmd:

"C:\Users\Doomdesire\Desktop\Tools\mimikatz_trunk\x64\mimikatz.exe"

This will generate the following log:

<13>Sep 14 13:04:16 DESKTOP-QTU1G8J AgentDevice=WindowsLog AgentLogFile=Security PluginVersion=WC.MSEVEN6.10.1.11.19 Source=Microsoft-Windows-Security-Auditing Computer=WKSTN-1.vscorp.local OriginatingComputer=WKSTN-1.vscorp.local User= Domain= EventID=4688 EventIDCode=4688 EventType=8 EventCategory=13312 RecordNumber=469215 TimeGenerated=1726308213 TimeWritten=1726308213 Level=Log Always Keywords=Audit Success Task=SE_ADT_DETAILEDTRACKING_PROCESSCREATION Opcode=Info Message=A new process has been created. Creator Subject: Security ID: WKSTN-1\Doomdesire Account Name: Doomdesire Account Domain: WKSTN-1 Logon ID: 0x16A922 Target Subject: Security ID: \NULL SID Account Name: - Account Domain: - Logon ID: 0x0 Process Information: New Process ID: 0x1d14 New Process Name: C:\Users\Doomdesire\Desktop\Tools\mimikatz_trunk\x64\mimikatz.exe Token Elevation Type: %%1938 Mandatory Label: Mandatory Label\Medium Mandatory Level Creator Process ID: 0x1870 Creator Process Name: C:\Windows\System32\cmd.exe Process Command Line: "C:\Users\Doomdesire\Desktop\Tools\mimikatz_trunk\x64\mimikatz.exe" Token Elevation Type indicates the type of token that was assigned to the new process in accordance with User Account Control policy. Type 1 is a full token with no privileges removed or groups disabled. A full token is only used if User Account Control is disabled or if the user is the built-in Administrator account or a service account. Type 2 is an elevated token with no privileges removed or groups disabled. An elevated token is used when User Account Control is enabled and the user chooses to start the program using Run as administrator. An elevated token is also used when an application is configured to always require administrative privilege or to always require maximum privilege, and the user is a member of the Administrators group. Type 3 is a limited token with administrative privileges removed and administrative groups disabled. The limited token is used when User Account Control is enabled, the application does not require administrative privilege, and the user does not choose to start the program using Run as administrator.

Which in turn is going to look like the following, when parsed by QRadar:

Manipulating the Regular Expressions

If we observe the way the 3 default properties were created, it seems that the regular expression is looking to match specific patterns between the fields Process Command Line and the Token Elevation Type phrase for the property Command and the fields New Process Name and Token Elevation Type for the properties Process Path and Process Name.

While it may seem obvious, regular expressions can be quite tricky to successfully utilize, in a way that every scenario is covered. To showcase this, we will create a folder in our Windows machine, named The Token Elevation Type Test &&. What this is going to accomplish is create the break point that the properties regular expressions are looking for, before it reaches the actual log field. In theory, if this succeeds, anything placed after this folder will be ignored and will not be visible when parsed in QRadar.

After creating the new folder and placing the mimikatz folder inside, we try executing it again with the following command:

"C:\Users\Doomdesire\Desktop\Tools\The Token Elevation Type Test &&\mimikatz_trunk\x64\mimikatz.exe"

As expected, while this command generates the expected log:

<13>Sep 14 12:52:15 DESKTOP-QTU1G8J AgentDevice=WindowsLog AgentLogFile=Security PluginVersion=WC.MSEVEN6.10.1.11.19 Source=Microsoft-Windows-Security-Auditing Computer=WKSTN-1.vscorp.local OriginatingComputer=WKSTN-1.vscorp.local User= Domain= EventID=4688 EventIDCode=4688 EventType=8 EventCategory=13312 RecordNumber=469111 TimeGenerated=1726307531 TimeWritten=1726307531 Level=Log Always Keywords=Audit Success Task=SE_ADT_DETAILEDTRACKING_PROCESSCREATION Opcode=Info Message=A new process has been created. Creator Subject: Security ID: WKSTN-1\Doomdesire Account Name: Doomdesire Account Domain: WKSTN-1 Logon ID: 0x16A922 Target Subject: Security ID: \NULL SID Account Name: - Account Domain: - Logon ID: 0x0 Process Information: New Process ID: 0x6d4 New Process Name: C:\Users\Doomdesire\Desktop\Tools\The Token Elevation Type Test &&\mimikatz_trunk\x64\mimikatz.exe Token Elevation Type: %%1938 Mandatory Label: Mandatory Label\Medium Mandatory Level Creator Process ID: 0x1fbc Creator Process Name: C:\Windows\System32\cmd.exe Process Command Line: "C:\Users\Doomdesire\Desktop\Tools\The Token Elevation Type Test &&\mimikatz_trunk\x64\mimikatz.exe" Token Elevation Type indicates the type of token that was assigned to the new process in accordance with User Account Control policy. Type 1 is a full token with no privileges removed or groups disabled. A full token is only used if User Account Control is disabled or if the user is the built-in Administrator account or a service account. Type 2 is an elevated token with no privileges removed or groups disabled. An elevated token is used when User Account Control is enabled and the user chooses to start the program using Run as administrator. An elevated token is also used when an application is configured to always require administrative privilege or to always require maximum privilege, and the user is a member of the Administrators group. Type 3 is a limited token with administrative privileges removed and administrative groups disabled. The limited token is used when User Account Control is enabled, the application does not require administrative privilege, and the user does not choose to start the program using Run as administrator.

The parsed information is now messed up:

Why it is important

In an example scenario where we had implemented a simple detection rule that was just searching for the word “mimikatz” in these 3 properties, it would have failed to detect it, even though it was part of the process path, name and command line.

This Windows parser is something that everyone is using when utilizing IBM QRadar, with a very low chance of having modified the default properties that come with it. Unless also using Sysmon, Windows event ID 4688 is probably going to correspond to a huge percentage of an organization’s ruleset. In the case of an adversary wanting to bypass these detections, a simple folder creation appears to be enough to mess with the detection rules. Another thing to consider is that an adversary can actually see and test these properties beforehand, since QRadar also comes as a free version that anyone can install.

Conclusion

In this post, it was demonstrated that while someone can bypass SIEM rules by messing with the rule logic, you can also bypass rules even when doing exactly what they are supposed to detect. While this demonstration only included IBM QRadar, it is possible that the theory behind it may be applicable to other SIEM too. If you are using Windows default properties in IBM QRadar, are these blind spots taken into consideration in your detection strategy?