free exercise · worked answer · real lab output
Alert triage exercise: five real Wazuh alerts, which are an attack and which are noise?
Five alerts from our own cloud lab: one typo, one new account and one attack that got in. Decide each, then see the worked answer.
The scenario
You are the tier 1 analyst on shift for a small company. Its one Linux server, linux-server-01, sends its logs to Wazuh. The administrator works from a machine called admin-pc at 10.20.1.50 and logs in with the account student. Nobody else is supposed to log in over SSH. At 02:12 UTC you open the queue and these five alerts are among the newest:
| Time | Level | Rule | From | User | What the rule says | |
|---|---|---|---|---|---|---|
| A | 02:09:39 | 5 | 5760 | 10.20.1.50 | student | sshd: authentication failed. |
| B | 02:09:51 | 8 | 5902 | none | backup-svc | New user added to the system. |
| C | 02:11:03 | 8 | 5758 | 10.20.2.66 | student | Maximum authentication attempts exceeded. |
| D | 02:11:09 | 10 | 5763 | 10.20.2.66 | student | sshd: brute force trying to get access to the system. Authentication failed. |
| E | 02:11:23 | 12 | 40112 | 10.20.2.66 | student | Multiple authentication failures followed by a success. |
The log line behind each alert:
A Nov 13 02:09:38 linux-server-01 sshd[6163]: Failed password for student from 10.20.1.50 port 46210 ssh2 B Nov 13 02:09:50 linux-server-01 useradd[6249]: new user: name=backup-svc, UID=1002, GID=1002, home=/home/backup-svc, shell=/usr/sbin/nologin, from=none C Nov 13 02:11:03 linux-server-01 sshd[6274]: error: maximum authentication attempts exceeded for student from 10.20.2.66 port 33510 ssh2 [preauth] D Nov 13 02:11:08 linux-server-01 sshd[6276]: Failed password for student from 10.20.2.66 port 45722 ssh2 E Nov 13 02:11:22 linux-server-01 sshd[6278]: Accepted password for student from 10.20.2.66 port 48560 ssh2
Your task: for each alert, decide whether it is noise, an expected change to confirm, or part of a real attack. Say which one you escalate, and what you write in the ticket.
Words this exercise uses
- Wazuh
- A free, open source security tool that collects a server's logs and raises an alert when a line matches one of its rules.
- Level
- Every Wazuh rule has a level from 0 to 15. The higher the level, the more serious the alert.
- Tier 1 analyst
- The first person to look at new alerts, who decides which ones are harmless and which go to a more senior analyst.
- True positive
- An alert that really is an attack. A false positive looks like one but is not.
Show a hint
Never judge an alert alone. Group the alerts by the address they came from, then read what happened just before and just after each one. A failed password that is followed seconds later by a success from the same usual address tells a very different story from many failures that end in a success.
For the new account, ask two questions: who made it, and can it be used to log in? The shell= field answers the second.
Show the worked answer
Step 1. Open the highest level first, then group by address
Our lab's queue script sorts the whole shift, 41 alerts, by level and groups them by address. Two addresses appear: 10.20.1.50, the administrator's machine, with 5 alerts and nothing above level 5, and 10.20.2.66, a machine nobody mentioned, with 17 alerts up to level 12.
Step 2. Alert A: a typo
02:09:31 lvl 3 5715 10.20.1.50 student sshd: authentication success. 02:09:37 lvl 5 5503 10.20.1.50 student PAM: User login failed. 02:09:39 lvl 5 5760 10.20.1.50 student sshd: authentication failed. <- alert A 02:09:45 lvl 3 5715 10.20.1.50 student sshd: authentication success. 02:11:41 lvl 3 5715 10.20.1.50 student sshd: authentication success.
Every alert from 10.20.1.50 in the shift.
One failure, from the administrator's own machine, followed 6 seconds later by a successful login from the same address. That is a person mistyping a password once. Verdict: noise, close it with one line in the ticket saying why. Notice also that Wazuh did not raise rule 40112 here, even though a failure was followed by a success. Step 4 explains why.
Step 3. Alert B: an expected change, to confirm
Creating an account is something attackers do to keep their access: MITRE ATT&CK calls it T1136, Create Account, and Wazuh tags rule 5902 with it. But administrators create accounts every day. Three facts in the log line help. The account is named like a service account, backup-svc. Its shell is /usr/sbin/nologin, so nobody can log in to it interactively. And from=none means useradd was not typed in an interactive terminal (that would read from=/dev/pts/ and a number), so it was probably a script or a remote command. It also happened before any activity from 10.20.2.66.
Verdict: an expected change, but confirm it with the administrator or the change ticket before closing. In our lab we know the answer, because the administrator's script ran useradd -m -s /usr/sbin/nologin backup-svc as root through AWS Systems Manager. In a real shift you find out by asking. If nobody planned it, it becomes an incident.
Step 4. Alerts C, D and E: one attack, and it worked
02:10:47 lvl 5 5503 PAM: User login failed. 02:10:49 lvl 5 5760 sshd: authentication failed. 02:10:51 lvl 5 5760 sshd: authentication failed. 02:10:55 lvl 5 5760 sshd: authentication failed. 02:10:57 lvl 5 5760 sshd: authentication failed. 02:11:01 lvl 5 5760 sshd: authentication failed. 02:11:03 lvl 5 5760 sshd: authentication failed. 02:11:03 lvl 8 5758 Maximum authentication attempts exceeded. <- alert C 02:11:03 lvl 10 2502 syslog: User missed the password more than one time 02:11:03 lvl 5 5503 PAM: User login failed. 02:11:05 lvl 5 5760 sshd: authentication failed. 02:11:09 lvl 10 5763 sshd: brute force trying to get access to the system <- alert D 02:11:13 lvl 5 5760 sshd: authentication failed. 02:11:15 lvl 5 5760 sshd: authentication failed. 02:11:19 lvl 5 5760 sshd: authentication failed. 02:11:19 lvl 10 2502 syslog: User missed the password more than one time 02:11:23 lvl 12 40112 Multiple authentication failures followed by a success <- alert E 02:11:23 lvl 3 5501 PAM: Login session opened. (no address; user student, twice)
All 17 alerts from 10.20.2.66, in order, plus the sessions that opened at 02:11:23. Wazuh raises one alert per log line.
In 36 seconds, one address that nobody expected failed the password for student again and again, hit the server's limit on attempts (alert C), reconnected, was flagged by the brute-force pattern rule (alert D), and then logged in (alert E). In the same second two login sessions opened for student. Alerts C and D on their own say someone is guessing; alert E says the guess worked.
Why did the administrator's typo not raise rule 40112 too? Here is the rule as Wazuh 4.14.10 ships it:
<rule id="40112" level="12" timeframe="240">
<if_group>authentication_success</if_group>
<if_matched_group>authentication_failures</if_matched_group>
<same_source_ip />
<description>Multiple authentication failures followed </description>
<description>by a success.</description>
<mitre>
<id>T1078</id>
<id>T1110</id>
</mitre>
...
</rule>Rule 40112 from 0280-attack_rules.xml in the wazuh/wazuh-manager:4.14.10 image.
It fires on a successful login only if, within 240 seconds before it, the same address raised an alert in the group authentication_failures. Plain failed logins such as 5760 are in the group authentication_failed, singular. Only the pattern rules, such as 5763 (repeated SSH failures from one address), are in authentication_failures. One typo never makes a pattern, so it never triggers 40112.
Verdict: a true positive. Escalate alert E now, with C and D attached as one incident.
Step 5. Write the ticket
Incident: SSH password guessed on linux-server-01 for the user student
When: 2026-11-13 02:10:47 to 02:11:23 UTC
Source: 10.20.2.66, not a known admin machine
Evidence: repeated failed passwords (5760, 5503), max attempts (5758),
brute-force pattern (5763, 2502), then success (40112) and 2 sessions opened (5501)
Verdict: true positive, the attacker is likely logged in as student
Asked: tier 2 to review the sessions after 02:11:23, reset the student password,
block 10.20.2.66, and check whether student can use sudo
Also: alert A closed as a typo by the admin from 10.20.1.50 (success 6 s later);
alert B (backup-svc, nologin shell) sent to the admin to confirm it was plannedThe answer. A is noise, a single typo. B is an expected change that you confirm before closing. C, D and E are one real attack: password guessing from 10.20.2.66 that ended in a successful login, so you escalate E with C and D attached. The most frequent alert, 5760, was not the important one; the single level 12 alert was.
The course's free lesson What a security operations centre does all day walks through a shift like this one on the course lab, step by step, with the scripts that pulled these alerts. To turn alert B into a rule that only fires for accounts that can log in, try the Wazuh custom rule exercise.
Questions people ask
What is alert triage in a SOC?
Alert triage is deciding, for each alert, whether it is harmless, needs a closer look, or must be escalated now. A tier 1 analyst reads the alert, finds the related alerts and facts, decides, and writes down what was seen and why.
How do I tell a real attack from noise in Wazuh?
Look at what happened around the alert, not only at the alert. One failed password followed seconds later by a success from the usual address is a typo. Many failures from one address followed by a success is a guessed password. Group the alerts by source address and time first.
Which Wazuh alert should I open first?
Start with the highest level. In our lab that was rule 40112 at level 12, multiple authentication failures followed by a success, because it means someone probably got in.
Why did one wrong password not trigger rule 40112?
Rule 40112 needs an earlier alert in the group authentication_failures from the same address within 240 seconds. Single failed logins are in the group authentication_failed. Only the pattern rules, such as 5763 for repeated SSH failures, are in authentication_failures.
Is a new user account always an attack?
No. Creating an account is the technique T1136, which attackers use to keep access, but administrators create accounts every day. Check who created it, whether a change was planned, and whether the account can log in.
Where every number comes from
- Our AI SOC Analyst cloud lab on AWS, 13 Nov 2026: Wazuh 4.14.10, linux-server-01, admin-pc at 10.20.1.50, the attacker at 10.20.2.66; 41 alerts pulled with pull_alerts.py
- Wazuh 4.14.10 bundled ruleset: rule 5902 in 0020-syslog_rules.xml, rule 40112 in 0280-attack_rules.xml, read from the wazuh/wazuh-manager:4.14.10 image on 13 Nov 2026
- MITRE ATT&CK T1110 Brute Force (version 2.8) and T1110.001 Password Guessing (version 1.7), both modified 3 Nov 2026
- MITRE ATT&CK T1078 Valid Accounts and T1078.003 Local Accounts
- MITRE ATT&CK T1136.001 Create Account: Local Account (modified 4 Nov 2026)
This exercise comes from the course AI SOC Analyst, where each step is done on a real Wazuh lab and explained line by line. More exercises like it: Writing a Wazuh custom rule; Mapping log lines to MITRE ATT&CK. Or see every free exercise.