CyberBlue Academy — Blue Team & SOC Training

What You'll Learn

Write a complete Sigma rule from scratch for three common attack techniques: brute force, suspicious process creation, and service installation
Apply the detection lifecycle to each rule: define hypothesis, research the log source, write the detection logic, and plan for false positives
Use named selections and filters to create precise detection logic that minimizes noise
Choose appropriate logsource categories, severity levels, and ATT&CK technique tags for each rule
Test detection logic by reasoning about which log events will and will not match
Connect each rule to the corresponding lab exercise in Lab 8.2 and Lab 8.3

From Theory to Practice

You know the Sigma rule structure. You know the detection lifecycle. Now it is time to write real detections. In this lesson, you will build three Sigma rules from scratch, each targeting a different ATT&CK technique. For every rule, you will follow the same process:

Hypothesis — What technique are we detecting, and why does it matter?
Research — What log source captures this activity? What fields are available?
Write — Build the detection logic with selections, filters, and conditions
Validate — Reason through true positives, false positives, and edge cases

By the end, you will have three complete rules ready for conversion and deployment.

Rule 1: Brute Force Detection

Hypothesis

Attackers frequently attempt to compromise accounts by trying many passwords against a single username or many usernames with common passwords. This generates a burst of authentication failures in a short window. MITRE ATT&CK classifies this as T1110 — Brute Force.

Research

Question	Answer
What log source?	Windows Security Event Log — Event ID 4625 (failed logon)
Sigma logsource?	`product: windows`, `service: security`
Key fields?	`EventID`, `TargetUserName`, `IpAddress`, `LogonType`
What does the attack look like?	Multiple Event ID 4625 entries from the same source IP within minutes
What is legitimate?	Occasional mistyped passwords, service account lockouts, password rotation

The Rule

title: Brute Force — Multiple Failed Logons
id: a1b2c3d4-1111-2222-3333-444455556666
status: test
description: |
    Detects 5 or more failed logon attempts from a single source
    within a short time window, indicating a possible brute force attack.
references:
    - https://attack.mitre.org/techniques/T1110/
author: CyberBlue Academy
date: 2026/02/23
logsource:
    product: windows
    service: security
detection:
    selection:
        EventID: 4625
    filter_system:
        TargetUserName|endswith: '$'
    condition: selection and not filter_system
    # Note: Aggregation (count >= 5 per source IP in 5 minutes)
    # is handled at the SIEM level after conversion
fields:
    - TargetUserName
    - IpAddress
    - LogonType
    - WorkstationName
falsepositives:
    - Service accounts with expired credentials
    - Users forgetting passwords after a long absence
    - Password rotation scripts during deployment windows
level: medium
tags:
    - attack.credential_access
    - attack.t1110

Analysis

Element	Design Decision
selection	Matches all Event ID 4625 (failed logon) events
filter_system	Excludes machine accounts (usernames ending with `$`) — these are computer-to-computer authentication failures, not human brute force
condition	`selection and not filter_system` — the classic pattern
level: medium	A single failed logon is informational. The aggregation (5+ in 5 minutes) makes this medium. Without aggregation at the SIEM level, this fires on every single failure
falsepositives	Documents three known FP scenarios that analysts should check before escalating

⚠

Sigma's aggregation limitation. Sigma supports a count condition (e.g., condition: selection | count(IpAddress) > 5), but not all SIEM backends support this syntax. In practice, you write the base detection in Sigma and configure the threshold/grouping in your SIEM after conversion. In Lab 8.2, you will deploy this rule to Wazuh and configure the threshold in the OpenSearch alert settings.

Rule 2: Suspicious Process Creation

Hypothesis

Attackers regularly use cmd.exe, powershell.exe, or wscript.exe — but what matters is how they are launched. A PowerShell process spawned by Microsoft Word is almost certainly malicious (macro execution). A cmd.exe spawned by a service with unusual arguments warrants investigation. ATT&CK classifies this under T1059 — Command and Scripting Interpreter.

Research

Question	Answer
What log source?	Process creation events — Sysmon Event ID 1 or Windows Security Event ID 4688
Sigma logsource?	`category: process_creation`, `product: windows`
Key fields?	`Image`, `CommandLine`, `ParentImage`, `User`
What does the attack look like?	A suspicious parent process (Word, Excel, Outlook) spawning a command interpreter
What is legitimate?	IT automation scripts, developer tools, legitimate software installers

The Rule

title: Suspicious Process Spawned by Office Application
id: b2c3d4e5-2222-3333-4444-555566667777
status: test
description: |
    Detects command interpreters (cmd.exe, powershell.exe, wscript.exe,
    cscript.exe, mshta.exe) spawned by Microsoft Office applications,
    which commonly indicates macro-based malware execution.
references:
    - https://attack.mitre.org/techniques/T1059/
    - https://attack.mitre.org/techniques/T1204/002/
author: CyberBlue Academy
date: 2026/02/23
logsource:
    category: process_creation
    product: windows
detection:
    selection_parent:
        ParentImage|endswith:
            - '\\winword.exe'
            - '\\excel.exe'
            - '\\powerpnt.exe'
            - '\\outlook.exe'
            - '\\msaccess.exe'
    selection_child:
        Image|endswith:
            - '\\cmd.exe'
            - '\\powershell.exe'
            - '\\pwsh.exe'
            - '\\wscript.exe'
            - '\\cscript.exe'
            - '\\mshta.exe'
    condition: selection_parent and selection_child
fields:
    - Image
    - CommandLine
    - ParentImage
    - ParentCommandLine
    - User
    - Computer
falsepositives:
    - Legitimate Office add-ins that invoke command-line tools
    - Office macros used for approved business automation
level: high
tags:
    - attack.execution
    - attack.t1059
    - attack.t1204.002

Analysis

Sigma rule design pattern — using parent-child process relationships for detection

Element	Design Decision
Two named selections	`selection_parent` matches Office processes, `selection_child` matches interpreters. Both must be true (AND logic).
Multiple values	Each selection lists multiple executables. Within a single field, multiple values use OR logic — the rule fires if the parent is ANY Office app AND the child is ANY interpreter.
level: high	Office spawning a command interpreter is almost always malicious. Few legitimate scenarios exist.
Two ATT&CK techniques	T1059 (Command and Scripting Interpreter) for the child process, T1204.002 (User Execution: Malicious File) for the Office macro trigger.
No filter	False positives are rare enough that filtering is not needed. If a specific add-in causes noise, add a filter in the tuning phase.

💡

Parent-child process analysis is one of the most powerful detection techniques. Many attacks depend on specific process chains: outlook.exe → powershell.exe (phishing), explorer.exe → cmd.exe → whoami (manual reconnaissance), services.exe → cmd.exe (service exploitation). Each chain tells a story. Learning to detect these chains in Sigma translates directly to Wazuh and Velociraptor rules.

Rule 3: Suspicious Service Installation

Hypothesis

Attackers install malicious services for persistence. A new service running from a temporary directory, a user profile, or a non-standard path is suspicious. Windows logs service installations in the System event log. ATT&CK classifies this as T1543.003 — Create or Modify System Process: Windows Service.

Research

Question	Answer
What log source?	Windows System Event Log — Event ID 7045 (new service installed)
Sigma logsource?	`product: windows`, `service: system`
Key fields?	`EventID`, `ServiceName`, `ImagePath`, `ServiceType`, `StartType`
What does the attack look like?	Service installed with an `ImagePath` pointing to temp directories, user profiles, or containing suspicious commands
What is legitimate?	Software installations, Windows updates, driver installations

The Rule

title: Service Installed from Suspicious Path
id: c3d4e5f6-3333-4444-5555-666677778888
status: test
description: |
    Detects installation of a Windows service where the image path
    points to a user profile, temp directory, or public folder —
    common indicators of malicious persistence.
references:
    - https://attack.mitre.org/techniques/T1543/003/
author: CyberBlue Academy
date: 2026/02/23
logsource:
    product: windows
    service: system
detection:
    selection:
        EventID: 7045
    selection_path:
        ImagePath|contains:
            - '\\Users\\'
            - '\\Temp\\'
            - '\\tmp\\'
            - '\\AppData\\'
            - '\\ProgramData\\'
            - '\\Public\\'
            - 'cmd.exe /c'
            - 'powershell'
    condition: selection and selection_path
fields:
    - ServiceName
    - ImagePath
    - ServiceType
    - StartType
    - AccountName
falsepositives:
    - Legitimate software installed to user directories
    - Development tools using temp directories
    - Some enterprise agents (monitoring, backup) installed per-user
level: high
tags:
    - attack.persistence
    - attack.t1543.003

Analysis

Element	Design Decision
Two selections combined with AND	Event ID 7045 AND path contains suspicious indicators
Path indicators	Covers common attacker staging locations: user profiles, temp directories, and inline commands
level: high	Services running from user directories are abnormal. Legitimate software typically installs to `Program Files` or `Windows\System32`
falsepositives	Documents the most common legitimate scenarios — dev tools and per-user agents

Putting It All Together — The Rule Development Checklist

Before submitting any Sigma rule for deployment, verify it against this checklist:

Check	Question
Metadata complete?	Title descriptive? UUID generated? Status set? Author and date filled?
Logsource correct?	Category matches the log type? Product set? Service specified if needed?
Detection logic sound?	Selection matches the attack? Filter excludes known-good? Condition correct?
Level appropriate?	Reflects true risk, not worst-case fear?
Tags mapped?	ATT&CK tactic and technique IDs included?
Fields useful?	Output fields help analysts triage without opening raw logs?
False positives documented?	Known FP scenarios listed?
Edge cases considered?	Variations in paths, usernames, and process names tested?

The Sigma rule development checklist — verifying metadata, logic, and quality before deployment

Key Takeaways

Every Sigma rule starts with a hypothesis — know what technique you are detecting and why before writing any YAML
Research the log source first: if the required fields are not available, no detection logic will work
The selection and not filter pattern handles most detection scenarios, with named selections for complex logic
Parent-child process relationships are among the most powerful detection patterns for endpoint-based attacks
Event IDs anchor log-based detections: 4625 (failed logon), 4688/Sysmon 1 (process creation), 7045 (service install)
Level should reflect real risk in context: a single failed login is informational, but 5+ in 5 minutes is medium, and an Office app spawning PowerShell is high
Always document false positives — this helps analysts triage faster and builds trust in your rules

What's Next

You have three complete Sigma rules covering credential access, execution, and persistence. In Lesson 8.4, you will learn how to convert these rules from Sigma's universal YAML format into Wazuh/OpenSearch queries using sigma convert, and deploy them to a live SIEM. Lab 8.3 takes the PowerShell detection rule, converts it, deploys it to Wazuh, triggers a test alert, and confirms the detection fires.

Knowledge Check: Writing Your First Detection

10 questions · 70% to pass

When writing a brute force detection rule, which Windows Event ID captures failed logon attempts?

In the brute force rule, why does the filter exclude usernames ending with '$'?

The suspicious process rule detects Office applications spawning command interpreters. Which two ATT&CK techniques does this map to?

In Lab 8.2, you write a brute force Sigma rule from scratch. What is the correct logsource for Windows authentication events?

Why is the Office-to-interpreter rule set to level: high instead of medium?

In the service installation rule, which Windows Event ID indicates that a new service was installed?

In Lab 8.3, you will convert a PowerShell detection rule and deploy it to Wazuh. What makes the parent-child process pattern a powerful detection technique?

When a Sigma selection lists multiple values for a single field (e.g., multiple Image|endswith values), what logic is applied?

The service installation rule flags ImagePath values containing '\\Users\\' or '\\Temp\\'. Why are these paths suspicious for a Windows service?

Before deploying a new Sigma rule, the rule development checklist requires verifying several elements. Which of the following is NOT on the checklist?

0/10 answered

Sigma Rule StructurePrevious Sigma → Wazuh/OpenSearchNext