Beginner·250 points·5 solves

Wazuh Alert Triage

You learn to triage a real SOC queue by subtraction: use a tuning baseline to dismiss agreed noise, but verify the conditions of each exemption rather than matching on source alone, and rank findings by impact instead of by alert level.

The vulnerability

The evidence lives in /var/log/soc. alerts.json is the Wazuh feed in JSON Lines - 1,193 alerts from one 24-hour window across four agents, with real rule IDs, levels, MITRE blocks and group strings taken from the v4.12.0 ruleset. tuning-baseline.md is what the team has already agreed is expected noise and, more importantly, the exact conditions each of its five entries depends on. wazuh-alert-reference.md explains how to read an alert: what each level means, how composite (frequency) rules fire and what their firing does not prove, and why data.srcuser and data.dstuser are not interchangeable. asset-inventory.csv lists the agents, their address ranges, the service accounts and what each account is meant to be used for. Two ideas carry the lab. The first is that a tuning exemption is conditional: every entry names a source, a behaviour and a set of conditions - a host, a window, a schedule - and it holds only while all of them still match. Dismissing an alert because the source is a familiar one is the commonest and most expensive triage error, and an attacker who works out which sources a SOC exempts will operate from one of them. The second is that level is volume, not priority: level 10 in Wazuh means a repetition threshold was crossed and says nothing about whether anything worked, while the quiet level-3 records are where success is written. There are 97 successful authentications in this file, and a queue sorted by level shows you none of them.

Your tasks

Profile the queue

Aggregate alerts.json by rule id, level and description before reading any single alert - it is JSON Lines, so one jq pass piped through sort | uniq -c gives you the shape in seconds. A handful of rule IDs account for the large majority of the 1,193 events. Take each of those rules to tuning-baseline.md and decide, entry by entry, whether it is genuinely covered. Volume on its own is not evidence that something is noise, and not every high-volume rule here has a baseline entry.

Work the loud end against the baseline

List everything at level 10 and above: eleven alerts, from four distinct source addresses. For each one, find the baseline entry that would explain it, then read that entry properly - the source it names, the behaviour it describes, the host it limits itself to and the window it states. Record what you dismiss and on what grounds. Matching on the source address alone is exactly the error the baseline document warns about at the bottom of itself.

Find the exemption that stopped holding

Read all five baseline entries and note for each what its exemption is actually conditional on — some are bounded by a time window, others by a named path, rule set or approved change. More than one carries a time condition, so the window alone will not single out an entry; the one you want is the entry that ties a scheduled window to a specific authenticating source. Then filter every alert carrying that entry's source address, sort by timestamp, and compare each one against the hours the entry actually allows. Note the first alert that falls outside them, to the second, and how much of that source's activity sits outside the window rather than inside it.

Rank what is left by impact

More than one source should now be unaccounted for: one that appears nowhere in the baseline, and one the baseline names but whose stated conditions did not hold. Do not rank them by level. For each, filter the level-3 successful-authentication rule - the one wazuh-alert-reference.md uses in its example queries - on that source's address, and see which of them, if either, ended up with a session. On a success the account name sits in data.dstuser, not data.srcuser; filter the wrong key and the login is invisible.

Reconstruct the sequence and map it

Take the out-of-window alerts in time order and watch the failure rule id change shortly before the success. Identify failures by rule.id and not by rule.description - the reference warns that two different rules carry the identical description string - and work out what that change says about what the attacker had learnt between the two batches. Then read rule.mitre on the successful-authentication alert: it carries two technique IDs and two technique names, and you should be able to say which ID belongs to which name.

Answer the questions

Start the lab, investigate the evidence in the terminal, and answer the questions here.

Hints

Loading…

Official write-up

Loading…

Frequently Asked Questions

What is Wazuh used for?

Wazuh is an open-source security platform that collects logs from agents, runs detection rules and raises alerts. Teams use it as a SIEM and XDR for monitoring endpoints, file integrity and compliance.

How do you triage a large Wazuh alert queue?

Group alerts by rule, agent and source, discard documented noise, then look for anything that deviates from its known baseline. Prioritise by asset value and rule severity, and escalate changes in behaviour first.

Can I practise Wazuh triage for free?

Yes. This Codelivly lab is free and beginner-friendly. You work through a realistic Monday-morning alert queue in the browser, with no Wazuh server to install.

NEW350+ rooms now have a live terminal, so you can learn by typing the commands, right in your browser.Learn in a live terminal. 350+ rooms.Try a labCodelivly is 100% free, no paywall. If it helped you, chip in to keep it running.100% free. Help keep it so.Support us