Sigma Rules and Hayabusa Detection

Sigma Rules & Hayabusa Detection: A Comprehensive Guide for GIAC GCIH

Introduction

In modern cybersecurity operations, the ability to detect threats efficiently across diverse log sources is critical. Sigma Rules and Hayabusa are two interconnected tools that empower defenders to identify malicious activity within Windows Event Logs and other data sources. For the GIAC GCIH (GIAC Certified Incident Handler) certification, understanding these tools is essential, as they fall squarely within the Reconnaissance, Scanning, and Enumeration domain.

Why Are Sigma Rules and Hayabusa Detection Important?

Sigma Rules and Hayabusa are important for several key reasons:

1. Vendor-Agnostic Detection: Sigma rules provide a universal, open-source signature format for log events. Unlike SIEM-specific detection rules (e.g., Splunk SPL queries or Elastic KQL), Sigma rules can be converted to work across multiple platforms, making them highly portable and reusable.

2. Rapid Incident Response: Hayabusa enables fast triage of Windows Event Logs (EVTX files) without needing a full SIEM deployment. This is invaluable during incident response when time is critical.

3. Community-Driven Threat Intelligence: The Sigma rule repository is maintained by the security community, meaning new detection rules for emerging threats are constantly being added. This collective defense model accelerates threat detection across the industry.

4. Forensic Analysis: Both tools support offline analysis of log files collected from compromised systems, making them essential for post-incident forensic investigations.

5. Coverage of the Attack Lifecycle: Sigma rules exist for virtually every phase of the MITRE ATT&CK framework, from initial access and reconnaissance through lateral movement, persistence, and exfiltration.

What Are Sigma Rules?

Sigma is an open-source generic signature format for describing log events. Think of Sigma as the equivalent of YARA rules for logs or Snort rules for network traffic. Sigma rules are written in YAML format and describe conditions that, when matched against log data, indicate potentially malicious or suspicious activity.

Key Components of a Sigma Rule:

- title: A descriptive name for the rule
- id: A unique identifier (UUID) for the rule
- status: The maturity level (experimental, test, stable)
- description: A detailed explanation of what the rule detects
- author: The creator of the rule
- date: When the rule was created or modified
- references: Links to relevant threat intelligence or documentation
- logsource: Defines the type of log data the rule applies to (category, product, service)
- detection: The core logic containing search conditions and filters
- level: Severity level (informational, low, medium, high, critical)
- tags: MITRE ATT&CK mappings and other metadata
- falsepositives: Known conditions that may trigger false alerts

Example Sigma Rule Structure:

title: Suspicious PowerShell Download Cradle
id: 3b6ab547-8ec2-4991-b9d2-2b06702a48d7
status: stable
description: Detects suspicious PowerShell download commands commonly used by attackers
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    CommandLine|contains:
      - 'Invoke-WebRequest'
      - 'wget'
      - 'Net.WebClient'
  condition: selection
level: high
tags:
  - attack.execution
  - attack.t1059.001

The Detection Section Explained:

The detection section is the most critical part of a Sigma rule. It uses:
- Selection statements: Define what patterns to look for in the logs
- Filter statements: Exclude known benign activity to reduce false positives
- Condition: A Boolean expression combining selections and filters (e.g., selection and not filter)

Common modifiers in Sigma rules include:
- |contains: Substring match
- |startswith: Matches the beginning of a string
- |endswith: Matches the end of a string
- |re: Regular expression match
- |all: All values in a list must match

Sigma Rule Conversion:

Sigma rules can be converted to platform-specific queries using tools like:
- sigma-cli / pySigma: The official Sigma conversion tool
- Uncoder.IO: A web-based Sigma rule converter
- Backends exist for Splunk, Elastic, QRadar, Microsoft Sentinel, Crowdstrike, and many more

What Is Hayabusa?

Hayabusa (Japanese for "peregrine falcon") is a Windows Event Log fast forensics timeline generator and threat hunting tool created by the Yamato Security team. It is written in Rust for maximum performance and is designed to process large volumes of EVTX files rapidly.

Key Features of Hayabusa:

- Sigma-Based Detection: Hayabusa uses Sigma-compatible detection rules (plus its own built-in rules) to scan Windows Event Logs
- High Performance: Written in Rust, it can process gigabytes of EVTX files in minutes
- Offline Analysis: Can analyze exported EVTX files without needing access to the live system
- Timeline Generation: Creates chronological timelines of detected events for investigation
- Multiple Output Formats: Supports CSV, JSON, and other formats for integration with other tools
- Built-in Rule Set: Ships with thousands of Sigma rules plus Hayabusa-specific rules
- MITRE ATT&CK Mapping: Detected events are mapped to ATT&CK techniques

How Hayabusa Works:

1. Input: Hayabusa takes EVTX files as input — either from a live system or collected during forensic acquisition
2. Rule Loading: It loads Sigma-compatible rules and Hayabusa-specific detection rules
3. Parsing: EVTX files are parsed and each event record is evaluated against the loaded rules
4. Matching: When an event matches a rule's detection logic, an alert is generated with details including the rule name, severity, timestamp, and MITRE ATT&CK mapping
5. Output: Results are presented as a timeline, summary statistics, or detailed alert logs

Common Hayabusa Commands:

- hayabusa csv-timeline -d [evtx-directory] — Generate a CSV timeline from EVTX files
- hayabusa json-timeline -d [evtx-directory] — Generate a JSON timeline
- hayabusa logon-summary -d [evtx-directory] — Summarize logon events
- hayabusa search -d [evtx-directory] -k [keyword] — Search for specific keywords
- hayabusa update-rules — Update the detection rule set
- hayabusa csv-timeline -d [dir] -m [min-level] — Filter by minimum alert level (informational, low, medium, high, critical)

How Sigma Rules and Hayabusa Work Together:

The relationship between Sigma and Hayabusa is synergistic:

1. Sigma provides the detection logic in a standardized, portable YAML format
2. Hayabusa acts as the detection engine that applies Sigma rules against Windows Event Logs
3. Hayabusa extends Sigma with its own rule format that adds additional capabilities specific to Windows Event Log analysis
4. When new threats emerge, new Sigma rules can be added to Hayabusa's rule set immediately via the update-rules command

Detection Use Cases Relevant to GCIH:

- Reconnaissance: Detection of port scanning, service enumeration, and network discovery commands
- Brute Force Attacks: Multiple failed logon attempts (Event ID 4625) followed by a success (Event ID 4624)
- Lateral Movement: Detection of PsExec, WMI remote execution, or RDP connections from unusual sources
- Privilege Escalation: Detection of token manipulation, service creation for SYSTEM access, or exploitation of known vulnerabilities
- Persistence: New scheduled tasks, registry run key modifications, or new service installations
- Credential Dumping: Detection of LSASS access patterns, Mimikatz signatures, or SAM database access
- PowerShell Abuse: Encoded commands, download cradles, and execution policy bypasses
- Defense Evasion: Event log clearing, timestamp manipulation, and disabling of security tools

Important Windows Event IDs Commonly Referenced in Sigma Rules:

- 4624: Successful logon
- 4625: Failed logon
- 4648: Logon using explicit credentials
- 4672: Special privileges assigned to new logon
- 4688: New process creation (with command line logging enabled)
- 4697: Service installed on the system
- 4698: Scheduled task created
- 4720: User account created
- 4732: Member added to a local group
- 7045: New service installed (System log)
- 1 (Sysmon): Process creation
- 3 (Sysmon): Network connection
- 11 (Sysmon): File creation
- 1102: Audit log cleared

Sigma Rule Severity Levels:

- Informational: Baseline or normal activity worth logging
- Low: Slightly suspicious, may warrant investigation in context
- Medium: Moderately suspicious, should be reviewed
- High: Highly suspicious, likely malicious activity
- Critical: Almost certainly malicious, requires immediate response

Practical Workflow for Incident Handlers:

1. Collect: Gather EVTX files from the target system(s) using forensic tools
2. Update Rules: Run hayabusa update-rules to ensure you have the latest detection rules
3. Generate Timeline: Run Hayabusa against the collected logs to generate a detection timeline
4. Triage: Focus on high and critical alerts first, then work down through medium and low severity
5. Correlate: Cross-reference detected events with other evidence (network logs, file system artifacts, memory analysis)
6. Document: Record findings with timestamps, affected systems, and mapped ATT&CK techniques
7. Custom Rules: Write custom Sigma rules for organization-specific indicators of compromise (IOCs)

---

Exam Tips: Answering Questions on Sigma Rules and Hayabusa Detection

1. Know the Sigma Rule Structure: Be able to identify the key sections of a Sigma rule, especially logsource, detection, and condition. Exam questions may present a Sigma rule snippet and ask you to interpret what it detects.

2. Understand the Condition Logic: Pay careful attention to Boolean operators in the condition field. Know the difference between selection, selection and not filter, 1 of selection*, and all of selection*. Questions may test your understanding of how these conditions combine.

3. Remember Sigma Is Vendor-Agnostic: If a question asks about the primary advantage of Sigma over SIEM-specific detection rules, the answer is portability and vendor independence. Sigma rules can be converted to work with any supported SIEM platform.

4. Know Hayabusa's Primary Purpose: Hayabusa is a fast forensics timeline generator and threat hunting tool for Windows Event Logs. It is not a SIEM, not an EDR, and not a network monitoring tool. If asked what tool is used for rapid offline triage of EVTX files using Sigma rules, the answer is Hayabusa.

5. Memorize Key Windows Event IDs: Many Sigma rules reference specific Windows Event IDs. Know the most important ones (4624, 4625, 4688, 4698, 4720, 7045, 1102, and Sysmon Event IDs 1, 3, 11). Questions may describe a scenario and ask which Event ID or Sigma rule would detect it.

6. Understand MITRE ATT&CK Mapping: Sigma rules use ATT&CK tags (e.g., attack.t1059.001 for PowerShell execution). Be prepared to map a described attack technique to its ATT&CK ID or vice versa.

7. Distinguish Between Sigma Modifiers: Know the difference between |contains, |startswith, |endswith, |re, and |all. A question might show a detection block and ask which modifier would correctly match a given pattern.

8. Know the Severity Levels: Understand the five Sigma severity levels (informational, low, medium, high, critical) and be able to assess which level is appropriate for a given detection scenario.

9. Process of Elimination: When faced with scenario-based questions, eliminate answers that describe capabilities Sigma/Hayabusa do NOT have. For example, Sigma rules do not perform active blocking or prevention — they are for detection only.

10. Hayabusa Command-Line Familiarity: Know the basic Hayabusa commands and their purposes. Questions may describe a task (e.g., creating a timeline, searching for keywords, updating rules) and ask which command accomplishes it.

11. Focus on the Logsource Section: When interpreting Sigma rules, the logsource section tells you what type of log data the rule applies to. Common categories include process_creation, network_connection, file_event, and registry_event. Products include windows, linux, and azure. Services include security, sysmon, powershell, and system.

12. Understand False Positives: Sigma rules include a falsepositives field for a reason. In exam scenarios involving alert triage, remember that not every alert is a true positive. The ability to assess context and eliminate false positives is a key incident handler skill.

13. Practice Reading YAML: Since Sigma rules are written in YAML, be comfortable reading YAML syntax. Indentation matters in YAML, and misreading the structure can lead to incorrect interpretation of the rule logic.

14. Time Management: Questions on Sigma and Hayabusa tend to be straightforward if you know the fundamentals. Don't overthink them — identify the key concept being tested (rule structure, tool purpose, detection logic, or Event ID knowledge) and answer directly.

15. Index Your Materials: For the GCIH exam (which is open book), create an index entry for Sigma Rules, Hayabusa, key Event IDs, and MITRE ATT&CK technique IDs. Having quick access to a reference table of Event IDs mapped to attack techniques can save valuable time during the exam.