Chain the Sigma Rules: Brute Force That Worked

bastion01 is the only SSH entry point into the network, and the SOC wants one alert for the moment a brute force actually works. One day of its sshd authentication events is in /var/log/bastion/sshd_auth.jsonl, one JSON object per line, with timestamp, action (failed_password, invalid_user, accepted_password, accepted_publickey), user and src_ip.

A single Sigma rule looks at one event at a time, so it cannot express "many of these, then one of those". Sigma v2 correlation rules can. They are meta-rules that count or sequence the matches of other rules, grouped by a field and inside a time window, and a correlation can build on another correlation.

The alert policy is a burst of at least 10 failed logins from one source within 5 minutes, followed by a successful login from that same source within 10 minutes. Only the success after the burst counts, not a success before it.

1. Hunt. Find the source that matches the policy, and the sources that only look like it: typos, an office NAT failing all day, a brute force that never got in, a monitoring host, a slow guesser, a near-miss.

2. Write the chain in one file, /home/student/rules/ssh-bruteforce-success.yml, with rules separated by ---. Base rules carry a name so correlations can refer to them. Exactly one rule may raise alerts, and it must be a correlation (Sigma only alerts on the rules nothing else references). example-sudo-failures.yml in the same folder shows the correlation syntax for a different detection.

3. Make it hold. Grading runs the chain over this log and over an unseen day from another bastion. Every attacker must alert and no decoy may.

4. Map it. Tag the alerting rule with the MITRE ATT&CK brute-force technique.

sigma-hunt --check FILE validates the file and shows which rule alerts. sigma-hunt FILE LOG prints the alerts.