Running Sigma rules over EVTX with Chainsaw and Hayabusa

Hand-querying with PowerShell is right for a question you can phrase. But "tell me everything suspicious in these 200 .evtx files" needs detection rules applied at scale. That is what Sigma plus a fast scanner gives you. This post is the practical map of that workflow.

What Sigma is

Sigma is a generic, vendor-neutral detection-rule format written in YAML — "the regex of SIEM rules." A rule describes a detection (which log source, which fields, which values) once, and tooling converts it to whatever backend you run. A minimal rule looks like:

title: Suspicious Scheduled Task Creation
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4698
    TaskContent|contains:
      - 'powershell -enc'
      - 'mshta'
  condition: selection
level: high

The public SigmaHQ repository ships thousands of community rules covering the event IDs across this blog — logon, scheduled tasks, RDP, WMI, and more.

Two tools that run Sigma directly on EVTX

You don't need a SIEM. Two fast, free Rust tools read .evtx files and apply Sigma locally:

Chainsaw (WithSecure)

Built for fast triage of EVTX (and other Windows artifacts). It ships detection/hunting mappings and runs Sigma rules against logs, with output to table/CSV/JSON.

# Hunt with Sigma rules + Chainsaw's mappings over a folder of logs
chainsaw hunt ./logs/ -s ./sigma/ --mapping ./mappings/sigma-event-logs-all.yml -o results.csv

# Quick keyword/EventID search
chainsaw search -t 'Event.System.EventID: =4624' ./logs/

Chainsaw is excellent when you want a fast first pass that highlights the records worth reading.

Hayabusa (Yamato Security)

A timeline-oriented scanner: it applies its own curated Sigma-based ruleset (plus upstream Sigma) and produces a single, ranked CSV timeline across many logs — purpose-built for "give me the story."

# Produce a ranked detection timeline from a logs directory
hayabusa csv-timeline -d ./logs/ -o timeline.csv

Hayabusa leans toward a prioritised, analyst-readable timeline; Chainsaw leans toward flexible hunting and search. Many teams run both.

When to use which

You want…	Reach for
A fast "what's suspicious here" first pass	Hayabusa csv-timeline
Flexible hunting with your own/SigmaHQ rules	Chainsaw hunt
One specific question, one box	PowerShell Get-WinEvent
Eyeball a single file, no install	browser parser

These aren't exclusive — a common flow is Hayabusa/Chainsaw to surface hits, then open the specific .evtx to read the surrounding records in context.

Fitting it into an investigation

Rule-based scanning is a lead generator, not a verdict:

Collect the logs (from a live host or an image).
Scan with Hayabusa and/or Chainsaw to get ranked detections.
Triage the hits — read each flagged record and its neighbours, not just the rule title.
Pivot on the real ones: take the account/IP/time from a hit and pull the full logon or RDP timeline around it.
Build the timeline (next post) from the confirmed events.

Caveats

Rules ≠ truth. Sigma rules have false positives (and false negatives). A hit means "look here," not "this is malicious." Always read the underlying event.
Logging coverage decides everything. A rule for 4698 finds nothing if Object Access auditing was off; a Sysmon rule needs Sysmon installed. Know what was being logged before trusting an empty result. See Sysmon configuration.
Field mapping matters. Chainsaw uses a mapping file to connect Sigma's field names to EVTX fields; a wrong/old mapping silently misses detections. Keep tools and mappings current.
Time zones. Normalise everything to UTC (the native EVTX timestamp) before merging tool output with other evidence.

Rule scanning tells you where to look across a big pile of logs; the PowerShell guide tells you how to interrogate a specific file; and the timeline guide tells you how to assemble the confirmed pieces into a narrative.