Windows Detection Engineering Lab

I built this browser-based lab to practice how a detection engineer moves from Windows event logs to a documented finding. It runs six rules, maps the results to MITRE ATT&CK, and exports a report with the supporting evidence.

Open live lab Back to portfolio

Detection rules: 6 documented rules
Validation tests: 5 safe scenarios
Event boundary: 1,000 validated records
ATT&CK coverage: 6 techniques

My role

Detection engineering, TypeScript rule engine, interface design, event validation, testing

Technology

Next.jsTypeScriptSysmonWindows Event LogsSigma conceptsMITRE ATT&CKCytoscape.js

The challenge

A real problem with practical constraints.

I wanted this project to show more than a list of alerts. A reviewer should be able to see which event fields matched, test the rule again, follow the related activity, and understand what I would investigate next. I also needed to make the limits of a public lab clear.

The response

A working system, not a slide deck.

I created a typed event model and six rules covering encoded PowerShell, Office child processes, scheduled tasks, repeated failed logons, unusual DNS queries, and local administrator changes. Each finding links back to its source events and includes ATT&CK context, evidence, investigation steps, a relationship graph, and a downloadable report.

System design

How information moves through the project.

Event input

Use the included fictional records or import a local JSON file after validation.

Rule engine

Single-event conditions and time-based thresholds check normalized Windows logs.

Investigation

Each finding connects its evidence, ATT&CK mapping, event timeline, and related activity.

Testing

Five harmless test cases check the expected result for all six rules.

Engineering decisions

Choices that shaped the result.

These are the tradeoffs I would discuss in a technical interview.

Keep the rule logic readable

I used direct TypeScript conditions and thresholds so another person can follow each rule. Every finding lists the matching rule, source events, severity, ATT&CK technique, and investigation steps.

Keep imported events in the browser

JSON files are limited to 1 MB and 1,000 records, checked against the event schema, and processed locally. The import does not send the event data to a server.

Test the rules without running commands

The test buttons add harmless event records and compare the results with the expected rules. This makes the tests repeatable without running PowerShell, changing accounts, or creating scheduled tasks.

Security by design

The default dataset uses fictional hosts, users, IP addresses, domains, and command lines that I created for this lab.
Imported JSON is schema-checked, limited to 1 MB and 1,000 records, and analyzed in the browser.
The lab does not run attack simulations or present itself as production security monitoring.

Outcome

A reviewer can change the active rules, run the built-in tests, import events, inspect a finding, and export a report.
The relationship graph changes with the finding and shows only the accounts, processes, hosts, network activity, and resources tied to its evidence.
Automated tests confirm that all six rules match their intended cases and that the clean baseline produces no findings.

Lessons learned

What I would carry into the next build.

LESSON 01

A rule is easier to evaluate when its evidence, threshold, and expected test result appear together.

LESSON 02

Event data has to be normalized before correlation rules can produce consistent results.

LESSON 03

A public lab should prove the logic without pretending to reproduce a full enterprise environment.

Scope note

All included events are fictional. This is a learning project, not an endpoint agent, production SIEM, incident-response service, or replacement for an authorized enterprise assessment. The test controls add sample records and never execute operating-system commands.