Final-Year Project · 2025–2026 · SOC detection + red team

The Silent Operator

End-to-end SOC lab — Wazuh SIEM, Kali Linux, Windows 10, virtualised hosts — ingesting Sysmon and system logs from multiple endpoints into centralised dashboards. Controlled red-team attacks are executed against it, mapped to MITRE ATT&CK, then hunted from the defender side to find out what the stack missed.

Wazuh
Sysmon
MITRE ATT&CK
Kali
Windows 10
Virtualised lab

objective

Find out whether a detection stack I built myself would actually catch a red-team run — and record honestly where it did not.

environment

Wazuh SIEM
Sysmon
Kali Linux
Windows 10
Virtualised lab
MITRE ATT&CK

approach

01Built the lab end to end: Wazuh manager, agents on every endpoint, Sysmon and system logs forwarded into centralised dashboards.
02Executed controlled red-team attacks against the lab hosts, one technique at a time.
03Mapped each technique to its MITRE ATT&CK ID before running it, so the expected telemetry was written down in advance.
04Hunted from the defender side: log correlation, custom alert rules, triage, threat hunting.

outcome

›Techniques that fired an alert were recorded with the rule that caught them.
›Techniques that produced nothing were recorded as gaps, then closed with new rules and re-run.

how it works

detection pipeline — what a single event passes through

the loop — simulate, observe, assess, close

detection logic

Brute force on Windows logon, then contain· xmlvalidated in lab · 2026-09-05

<group name="authentication_failures,windows,">
  <!-- 60122 is Wazuh's built-in Windows logon-failure rule. A burst of
       them from one source inside sixty seconds escalates to a brute-force
       alert at level 12 — the version captured firing in the lab. -->
  <rule id="100211" level="12" frequency="5" timeframe="60">
    <if_matched_sid>60122</if_matched_sid>
    <same_source_ip />
    <description>Brute-force attack detected - multiple Windows logon failures</description>
    <mitre><id>T1110</id></mitre>
  </rule>
</group>

Level 12 and the 60122 base rule are read directly off the capture. The frequency and timeframe come from the lab notes and cannot be confirmed — a dashboard shows what fired, not the rule that fired it, and the lab has been decommissioned; treat those two numbers as a starting point to tune. A three-stage chain (100210 into 100211 into 100212, the last one catching a success straight after the burst) was designed and never validated: neither 100210 nor 100212 appears anywhere in the capture, and it reuses 100211 for a different rule. The repository README carries it, labelled. Captured firing on 5 Sep 2026 (see the artifact above): four level-5 60122 logon failures on WIN-SERVER-2022, then rule 100211 at level 12. The same capture also shows isolated 60122 events at 21:34 and 21:31 that raised nothing — a correlation rule is only worth having if it stays quiet on the noise, and that is the half usually left out of a screenshot. Tune the frequency before trusting it — five in sixty seconds is what the deployed rule uses, not a measurement. False positives: service accounts with stale cached credentials and password managers retrying after a change.

The same detection as a Sigma rule· yamlvalidated in lab · 2026-09-05

title: Windows brute force followed by success
id: 0f1b2c3d-4e5f-6071-8293-a4b5c6d7e8f9
status: experimental
description: Repeated 4625 failures from one source, then a 4624 success
logsource:
  product: windows
  service: security
detection:
  failures:
    EventID: 4625
  success:
    EventID: 4624
  timeframe: 2m
  condition: failures | count() by IpAddress > 5 and success
falsepositives:
  - Service accounts with stale cached credentials
  - Password managers retrying after a change
level: high
tags:
  - attack.credential_access
  - attack.t1110

Sigma keeps the logic portable: the same reasoning moves to Splunk or Elastic without being rewritten.

artifacts

Wazuh Threat Hunting, a fifteen-minute window on 5 Sep 2026. Four level-5 logon failures (rule 60122) land on WIN-SERVER-2022 between 21:38:55 and 21:39:04, and rule 100211 then fires at level 12 at 21:39:08 — "Brute-force attack detected - multiple Windows logon failures". Isolated failures earlier in the same window, at 21:34:21 and 21:31:39, raise no correlation alert, which is the threshold doing its job rather than the rule matching anything that looks like a failure.

Wazuh Threat Hunting — the lab manager (sahil) with a WIN-SERVER-2022 agent enrolled, events flowing, a custom level-15 rule firing on the Windows host, alerts mapped to MITRE Valid Accounts and Command & Scripting. Captured 5 Sep 2026.

highlights

$Simulated attacks mapped technique-by-technique to ATT&CK
$Detected via log correlation, custom alert rules, triage and threat hunting
$Exposed detection gaps, then closed them with new rules

scope

Every technique referenced here was executed inside authorised environments — my own virtualised lab hosts, DVWA, and systems I was engaged to assess. Attack simulation is always paired with the detection or hardening that answers it: that pairing is the whole point of the work, not a disclaimer on it.

write-up →ask me about this