SEC504 - Hacker Tools, Techniques, and Incident Handling
Windows Event Log Threat Hunting with Hayabusa and Sigma
Solo, Lab
Focus: Threat Hunting
Level: SEC504
Date: Jun 2026
Artifacts: Sanitized Hayabusa CSV timeline and Timeline Explorer views from the SEC504 lab against a compromised Windows 10 EVTX set
TL;DR
- •Hayabusa applied 4,151 Sigma + Hayabusa rules to 361 EVTX files, reducing 4,419 events to 33 unique detections
- •All 3 high-severity alerts were log-clearing events, a direct anti-forensics indicator
- •Timeline Explorer grouping reconstructed the sequence: six log-clears, then logoff, then Event Log Service stopped
Skills demonstrated
Note: Course-provided PCAPs and lab instructions are not shared. Only my own captures and sanitized notes are published.
Why this matters
An analyst cannot read 4,419 raw events, but they can act on 33 detections and read 3 high alerts. Hayabusa applies the open Sigma rule set to Windows logs to do that reduction, and the grouping step in Timeline Explorer is what turns the output into an incident narrative. The high alerts here were all log clearing, which is the tell that an attacker tried to erase their tracks, and finding it fast is the difference between catching the intrusion and cleaning it up later.
Context
This lab runs Hayabusa, a Sigma-based EVTX detection engine, over a compromised Windows 10 event log set (361 files, 35.5 MB) and triages the results in Timeline Explorer. The point is data reduction: turning thousands of raw events into a ranked list of detections, then grouping to find the handful of high-severity alerts that describe the actual attack.
Tools used
Steps taken
1Choose the detection subcommand
hayabusa.exe with no arguments lists the subcommands: csv-timeline and json-timeline for full detection output, plus logon-summary, eid-metrics, and search for quick pivots. csv-timeline is the one that produces a Timeline Explorer-ready file.
$ .\hayabusa.execsv-timelinefull detection timelinelogon-summary/eid-metricsquick stats2Run the full detection timeline
Ran csv-timeline over the EVTX directory. The scan wizard offered rule set 5 (all event and alert rules, 4,417) and prompted for deprecated, unsupported, noisy, and sysmon rules. Including sysmon rules (3,685) added meaningful coverage. Total input: 361 EVTX files, 35.5 MB.
$ .\hayabusa.exe csv-timeline --directory C:\Tools\win10evtx\ -o win10-threatdetect.csv --no-color--directoryEVTX folder-ooutput CSV--no-colorclean output for redirection3Read the scan summary and data reduction
After channel filtering, 16 logs matched and 2,031 rules ran (167 Hayabusa + 3,984 Sigma = 4,151 total). Of 4,419 events, 2,983 produced hits, a 32.5% reduction. The value of a detection engine is exactly this: it tells you which fraction of events are worth an analyst's attention.
$ # scan summary section of the run4,151 rules over 16 logs; 4,419 events -> 2,983 with hits4Triage by severity
The results summary broke 2,989 total detections into 33 unique: 0 critical, 3 high (2 unique), 66 medium, 1,573 low, 1,347 informational. Three high alerts is a list an analyst can actually read, which is the entire goal of running the engine first.
$ # results summary section0 critical / 3 high / 66 medium / 1,573 low / 1,347 info5Read the top alerts and spot the anti-forensics
The top high alerts were all log-clearing: Important Log File Cleared (x2) and Log Cleared (x1). Top medium included Potentially Malicious PowerShell (57) and password guessing/spray. Log clearing at the top of the high list is the signal that someone tried to erase evidence.
$ # top alerts by severityHigh = log clearing; medium = malicious PowerShell + password attacks6Group in Timeline Explorer and rebuild the sequence
Loaded the CSV into Timeline Explorer and dragged the Level and Rule Title headers to group. This collapsed 2,989 rows into a readable tree and exposed the anti-forensics window: six consecutive Log Cleared events at 10:18:28-29, then Logoff / RDS Session Logoff at 10:19:06, then Event Log Service Stopped at 10:19:08. The cell viewer showed the full EID 4104 ScriptBlock text for the PowerShell hits.
$ # Timeline Explorer: drag Level, then Rule Title, to the group barGrouping turns a flat CSV into an incident timelineKey findings
Outcome / Lessons learned
Reduced 4,419 raw Windows events to 33 unique detections and 3 high-severity alerts, all of which were log-clearing. Grouping in Timeline Explorer reconstructed a clear anti-forensics sequence (mass log clear, then logoff, then Event Log Service stopped), giving an incident narrative from what started as an unreadable pile of EVTX files.
Forward EVTX to a SIEM and run Sigma rules continuously rather than after the fact, alerting immediately on 1102 (Security log cleared) and 104 (log cleared) since those were the high-fidelity indicators here. Enable PowerShell script-block logging (4104) fleet-wide so the malicious-PowerShell detections have full command text. Baseline normal logon and account-management volume so the low/informational tier (explicit logons, group changes) can be diffed rather than read.
Security controls relevant
- Centralized log forwarding to a SIEM (logs off the host beat log clearing)
- Alerting on log-clear events (Security 1102, System 104)
- PowerShell script-block logging (EID 4104)
- Sigma rule coverage and tuning
- Baselining of logon and account-management event volume
What I took away from this
The number that matters is 4,419 down to 33. No analyst triages four thousand events, but everyone can read thirty-three detections and act on three high alerts. That reduction is the entire argument for running a Sigma engine over raw logs before a human looks at them, and it is why detection-as-code beats manual log review at any real scale.
Log clearing being the top high-severity finding is the tell. An attacker who clears logs is telling you two things: they had the privilege to do it, and they expected someone to look. The defensive countermove is to get logs off the host in real time, because once they are in a SIEM, clearing the local copy destroys nothing and the clear event itself becomes one of your highest-fidelity alerts.