Hands-on detection engineering built on a home SOC lab: Wazuh 4.14.5 (manager, Ubuntu) + Windows 11 endpoint running Sysmon (SwiftOnSecurity config).
I am a Mathematics and Computer Science student preparing for a career in blue team security and detection engineering. This repository showcases not only the detection rules I develop, but also the investigation, troubleshooting, and decision-making process behind them. Each rule went through failed attempts before reaching a working state, and those failures are documented here because they are where the actual engineering happened.
Each detection follows the same five-step loop:
behavior → data source → rule → testing (positive + negative + regression) → lessons learned
The loop is deliberate. Most of the work is not in the rule syntax — it is in choosing the right telemetry and proving the rule stays silent when it should.
| # | Detection | Tactic | Technique | Data Source | Status |
|---|---|---|---|---|---|
| 001 | Account Discovery via net.exe | Discovery | T1087 | Sysmon EID 1 | ✅ Tested |
| 002 | User Identity Discovery via whoami | Discovery | T1033 | Sysmon EID 1 | ✅ Tested |
| 003 | User Identity Discovery via Environment Variable | Discovery | T1033 | PowerShell EID 4104 | ✅ Tested |
Detection 003 is an evasion of 002: the same intent, a different technical footprint, and — critically — a different data source. That pair is the clearest illustration of what this repo is about.
Custom rules use a consistent severity scale rather than a per-rule judgement call:
| Level | Tactic class | Rationale |
|---|---|---|
| 10 | Discovery | Warrants analyst attention; common in both legitimate administration and post-exploitation reconnaissance |
| 12 | Persistence, Execution | Rarer in normal operation; a successful match implies attacker intent more strongly |
Levels are revised as coverage grows; the table is the current policy, not a final one.
- SIEM: Wazuh 4.14.5 all-in-one (Ubuntu VM, VMware)
- Endpoint: Windows 11 VM, Sysmon with SwiftOnSecurity configuration, Wazuh agent
- Telemetry in use:
- Sysmon Event ID 1 — process creation
- PowerShell Script Block Logging, Event ID 4104 —
Microsoft-Windows-PowerShell/Operational
- Rules: custom rules live in
local_rules.xml(rule IDs from 100101) - Validation: every rule is exercised with positive, negative, and regression tests before it is marked as tested
Configuration steps required to reproduce this lab — enabling Script Block
Logging on Windows 11 Home without gpedit.msc, adding the PowerShell channel
to ossec.conf, and enabling logall_json to inspect archives — are
documented in lab-setup/.
- 004 — Registry Run Key persistence (T1547.001), introducing Sysmon Event ID 13 (RegistryEvent, value set)
- False positive tuning — measuring the noise a Run key detection produces in practice and tuning it against real baseline data
- Dashboard evidence — Wazuh dashboard screenshots added to each Testing section
- Additional telemetry — Sysmon Event ID 11 (file create) and Event ID 12 (registry object create/delete)
- Cloud detection — moving beyond the Windows endpoint to cloud audit logs
Each detection is chosen to force engagement with something new: a data source, a Wazuh component, or a tactic class. The goal is detection engineering as a transferable discipline — Wazuh is the current vehicle, not the subject.