From Sysmon Analysis to Sigma & QRadar Detection Rules

Introduction

Detection engineering is about understanding suspicious behavior and converting that behavior into reusable detection logic.

In the CyberDefenders Sigma 101 lab, three EVTX files were analyzed. Each file contained a different malicious or suspicious technique:

➡️ Obfuscated PowerShell execution through wscript.exe

➡️ Process hollowing or process injection involving rundll32.exe

➡️ PowerShell security-control tampering through the Registry

This article explains the investigation process, the attacker’s actions, and the Sigma rules created during the lab. As an additional detection-engineering exercise, it also includes three example QRadar rules based on the same observed behaviors.

What Is Sigma?

Sigma is an open detection-rule format written in YAML. It allows analysts to describe suspicious log activity independently of a specific SIEM platform. A Sigma rule can later be converted for platforms such as QRadar, Splunk, Microsoft Sentinel, Elastic Security, and Google SecOps.

A basic Sigma rule looks like this:

title: Suspicious Activity
id: 00000000-0000-0000-0000-000000000000
status: experimental
description: Detects a specific suspicious behavior
logsource:
    category: process_creation
    product: windows
detection:
    selection:
        Image|endswith: '\example.exe'
        CommandLine|contains: 'suspicious-value'
    condition: selection

The logsource section defines the expected log type, while the detection section defines the matching conditions.

Investigation Overview

Together, these events demonstrate script execution, obfuscation, process injection, and defense evasion.

Level 1: Obfuscated PowerShell Through WScript

The first EVTX file contained three Sysmon process-creation events. The most suspicious event involved:

Image: "C:\Windows\System32\wscript.exe"

CommandLine: wscript.exe /E:vbs C:\Windows\Temp\icon.ico
"powershell -exec bypass -c ""IEX ([System.Text.Encoding]::ASCII.GetString([System.Convert]::FromBase64String('...')))"""

ParentImage: "C:\Windows\explorer.exe"

The attacker used wscript.exe to execute an .ico file as VBScript.

Get Enes Cayvarli’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

The following indicators made the event suspicious:

• icon.ico was executed as VBScript
• PowerShell was launched with -exec bypass
• The command contained Base64 decoding
• IEX was used to execute decoded content
• A second file named picture.jpg was read as encoded data

The simplified attack flow was:

icon.ico
   ↓
Executed as VBScript
   ↓
PowerShell with ExecutionPolicy Bypass
   ↓
Base64 decoding
   ↓
picture.jpg decoded
   ↓
Payload executed with IEX

Although the final payload was not available, the activity clearly represented a multi-stage PowerShell loader.

Level 1 Sigma Rule

title: Suspicious WScript ICO Execution
id: 4e29a677-6acb-4ae7-9fa5-bd102741a678
status: experimental
description: Detects Windows Script Host executing an ICO file as VBScript.
logsource:
    category: process_creation
    product: windows
detection:
    selection:
        Image|endswith: '\wscript.exe'
        CommandLine|contains|all:
            - '/E:vbs'
            - 'icon.ico'
    condition: selection

The contains|all modifier ensures that both /E:vbs and icon.ico are present in the command line.

Level 2: Process Hollowing Activity

The second EVTX file showed rundll32.exe loading a DLL from a temporary directory (C:\Temp\) and launching wermgr.exe.

Image: "C:\Windows\System32\wermgr.exe"

ParentImage: "C:\Windows\SysWOW64\rundll32.exe"

ParentCommandLine: "rundll32.exe C:\Temp\winfire.dll,DllRegisterServer"

A Sysmon Process Access event then showed:

SourceImage: "C:\Windows\SysWOW64\rundll32.exe"

TargetImage: "C:\Windows\System32\wermgr.exe"

GrantedAccess: 0x1fffff

This indicated that rundll32.exe obtained highly permissive access to wermgr.exe. The likely sequence was:

winfire.dll
   ↓
Loaded by rundll32.exe
   ↓
wermgr.exe created
   ↓
Extensive process access obtained
   ↓
Possible process injection or hollowing

The available logs strongly supported process injection and were consistent with process hollowing. However, the full memory-manipulation sequence was not visible in the EVTX data.

What Is Process Hollowing?

Process hollowing is a technique in which malicious code is executed inside a legitimate process.

The attacker typically creates a trusted process, replaces or modifies its memory, and then resumes it so that malicious code runs under a legitimate process name. In this case, the attacker likely attempted to hide malicious activity inside wermgr.exe.

Level 2 Sigma Rule

title: Rundll32 Full Access To Wermgr
id: e2a349e8-db52-47e7-9cc2-b176f25af297
status: experimental
description: Detects rundll32.exe obtaining extensive access to wermgr.exe, which may indicate process injection or process hollowing.
logsource:
    category: process_access
    product: windows
detection:
    selection:
        SourceImage|endswith: '\rundll32.exe'
        TargetImage|endswith: '\wermgr.exe'
        GrantedAccess: '0x1fffff'
    condition: selection

A separate process-creation rule could also detect wermgr.exe being launched by rundll32.exe after loading a DLL from a temporary directory.

Level 3: PowerShell CLM Tampering

The third EVTX file contained one Sysmon registry event:

EventType: DeleteValue

Image: "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe"

TargetObject: HKLM\System\CurrentControlSet\Control\Session Manager\Environment\__PSLockdownPolicy

PowerShell deleted the __PSLockdownPolicy registry value. This value is associated with PowerShell Constrained Language, which limits access to advanced PowerShell and .NET functionality. The likely activity was:

powershell.exe
   ↓
Deletes __PSLockdownPolicy
   ↓
Attempts to weaken PowerShell restrictions

This behavior was classified as a potential defense-evasion attempt.

Level 3 Sigma Rule

title: PowerShell CLM Policy Deleted
id: 671e9867-d0dc-4199-8814-8955762d70a9
status: experimental
description: Detects deletion of the PowerShell __PSLockdownPolicy registry value.
logsource:
    category: registry_event
    product: windows
detection:
    selection:
        EventType: 'DeleteValue'
        Image|endswith: '\powershell.exe'
        TargetObject|endswith: '\Environment\__PSLockdownPolicy'
    condition: selection

The correct Sigma log source is registry_event because the event represents a registry operation rather than process creation.

Combined Attack Scenario

When the three levels are evaluated together, the attack flow can be summarized as follows:

Disguised VBScript execution
        ↓
Obfuscated PowerShell loader
        ↓
Encoded payload execution
        ↓
Malicious DLL loaded through rundll32.exe
        ↓
Possible process hollowing inside wermgr.exe
        ↓
PowerShell security-control tampering

The attacker used trusted Windows binaries and disguised files to avoid detection. The main techniques included:

→ Script Masquerading
→ PowerShell Obfuscation
→ Living-off-the-Land Binary Abuse
→ Process Injection
→ Defense Evasion

MITRE ATT&CK Mapping

QRadar Detection Rules

The same behaviors can be adapted into QRadar correlation rules.

Rule 1: Obfuscated PowerShell Execution via WScript

when the event(s) were detected by one or more of Microsoft Sysmon
AND when Event ID is 1
AND when Image (custom) ends with "wscript.exe"
AND when CommandLine (custom) contains "/E:vbs"
AND when CommandLine (custom) contains "powershell"
AND when CommandLine (custom) contains one or more of:
    "IEX"
    "FromBase64String"
    "-exec bypass"
    "-ExecutionPolicy Bypass"

This rule detects WScript executing VBScript content that launches suspicious PowerShell commands.

Rule 2: Potential Process Hollowing via Rundll32

when the event(s) were detected by one or more of Microsoft Sysmon
AND when Event ID is 10
AND when SourceImage (custom) ends with "rundll32.exe"
AND when TargetImage (custom) ends with "wermgr.exe"
AND when GrantedAccess (custom) equals "0x1fffff"

This rule detects extensive process access from rundll32.exe to wermgr.exe.

Rule 3: PowerShell CLM Registry Tampering

when the event(s) were detected by one or more of Microsoft Sysmon
AND when Event ID is 12
AND when Image (custom) ends with "powershell.exe"
AND when EventType (custom) equals "DeleteValue"
AND when TargetObject (custom) contains "__PSLockdownPolicy"

This rule detects deletion of the registry value associated with PowerShell Constrained Language Mode.

Key Lessons From the Lab

The lab highlighted four important detection-engineering principles.

First, detections should focus on behavior rather than a single filename. A rule matching only icon.ico could miss the same technique when the attacker uses a different name.

Second, the correct log source matters. Process creation, process access, and registry events require different Sigma categories.

Third, one event may not be enough to confirm a technique. Process hollowing becomes more convincing when suspicious process creation and process access appear together.

Finally, encoded or obfuscated content still leaves detectable indicators such as IEX, FromBase64String, suspicious parent-child relationships, and unusual registry modifications.

Conclusion

The CyberDefenders Sigma 101 lab demonstrated how suspicious Sysmon events can be analyzed and translated into Sigma detection rules.

The first scenario involved a disguised VBScript launching an obfuscated PowerShell loader. The second scenario showed suspicious process activity consistent with process injection or process hollowing. The third scenario involved deletion of the __PSLockdownPolicy registry value, indicating possible PowerShell security-control tampering.

The Sigma rules presented in this article were created as part of the lab exercises. The QRadar rules were added separately to demonstrate how the same behaviors could be adapted into practical SIEM detection logic.

The main takeaway is that strong detections should focus on recurring attacker behavior rather than individual filenames, hashes, or process identifiers.