Individual alerts are useful. A chain of correlated alerts is where real threat detection happens. A brute force attack followed immediately by a successful login on the same account means the attack worked. The system should reflect that difference — not treat both events as separate medium-severity notes.
The goal
A rule that fires at critical severity when: brute force attack detected AND a successful login follows on the same account within 5 minutes. This is T1110.001 — Brute Force: Password Guessing confirmed successful.
The rule architecture
Rule 100002 fires (failed logon)
│
│ × 5 in 120 seconds, same username
▼
Rule 100003 fires — group: windows_brute_force
│
│ within 300 seconds
▼
Rule 100006 fires (interactive logon detected)
│
▼
Rule 100007 fires — level 13 critical
"Breach confirmed after brute force"The successful login rule
<rule id="100006" level="3">
<if_sid>60118</if_sid>
<field name="win.system.eventID">^4624$</field>
<field name="win.eventdata.logonType">^2$|^7$|^10$|^11$</field>
<description>Windows: Interactive user logon detected</description>
<group>windows_logon_success,</group>
</rule>LogonType values that indicate interactive access:
| Type | Meaning |
|---|---|
2 | Interactive — at the keyboard |
7 | Unlock |
10 | RemoteInteractive (RDP) |
11 | CachedInteractive |
The ^ and $ anchors ensure exact matches. Without them, 2 would also match 12, 21, 32.
The breach confirmation rule
<rule id="100007" level="13" timeframe="300">
<if_matched_group>windows_brute_force</if_matched_group>
<if_sid>100006</if_sid>
<same_field>win.eventdata.targetUserName</same_field>
<description>Windows: Successful login following brute force — possible breach</description>
<group>windows_breach_confirmed,attack_chain,</group>
<mitre><id>T1110.001</id></mitre>
</rule>Level 13 automatically sets mail: true in Wazuh — email notification fires on breach confirmation without any additional configuration.
Testing the full chain
A test account was created for successful login simulation. Multiple failed logins were run to trigger brute force detection, then the test account was authenticated successfully. The level 13 alert fired. The alert showed mail: true.
The first-match-wins problem
Two rules competing for the same parent event — the first rule in the file wins. Rule ordering matters in Wazuh. If a rule chain isn't firing as expected, check whether an earlier rule is consuming the triggering event before the intended rule can match it. The fix is restructuring the chain so rules feed into each other rather than compete.