What You'll Learn
- Log into the Wazuh Dashboard and navigate its core interface panels
- Understand alert severity levels and what each level means for triage priority
- Trace three real alerts from the dashboard back to their source through the full data pipeline
- Map the complete alert data flow: agent → manager → indexer → dashboard → analyst → action
- Complete an Alert Trace Worksheet documenting your findings
Lab Overview
| Detail | Value |
|---|---|
| Lab Profile | lab-wazuh |
| Containers | Wazuh Manager, Wazuh Indexer, Wazuh Dashboard, Wazuh Agent |
| Estimated Time | 45–60 minutes |
| Difficulty | Beginner |
| Browser Access | Web UI — opens directly in your browser |
| Pre-Loaded Data | 50 sample alerts from Windows, Linux, and network sources |
| Deliverable | 3 completed Alert Trace Worksheets |
Your First Shift. This is your first hands-on exercise as a SOC analyst. You're going to do exactly what a junior analyst does on day one: open the SIEM, look at alerts, and start asking "what happened here?" The goal isn't to master Wazuh — it's to get comfortable reading alerts and tracing them back to their source.
Part 1: Log into the Wazuh Dashboard
When you click Start Lab, a cloud environment with Wazuh will spin up in about 30 seconds. You'll receive a direct link to the Wazuh Dashboard — click it to open it in your browser.
Step 1: Access the Dashboard
Click the lab link to open the Wazuh Dashboard in your browser.
Credentials:
- Username:
admin - Password:
SecretPassword
What Is Wazuh? Wazuh is an open-source SIEM (Security Information and Event Management) platform. It's the tool SOC analysts spend most of their time in — it collects logs from every system in the network, applies detection rules, and generates the alerts you'll investigate. Think of it as the central nervous system of the SOC.
Step 2: Orient Yourself
Once logged in, take 2 minutes to scan the interface. Don't click anything yet — just read.
| Panel | Location | What It Shows |
|---|---|---|
| Top Navigation | Top bar | Modules, Management, Agents, Dev Tools |
| Security Events | Main area | Total events, alerts by severity, recent activity |
| Agent Status | Agents tab | Endpoints reporting to this Wazuh instance |
| Alerts Summary | Center widgets | Counts by severity: Critical, High, Medium, Low |
Resist the Urge to Click Everything. New analysts often dive into random menus and get lost. Instead, follow this lab step by step. You'll explore every panel in Module 2 — right now, we're focused on one skill: reading and tracing alerts.
Part 2: Understand Alert Severity
Before tracing specific alerts, you need to understand the severity system. Wazuh assigns every alert a severity level that determines how urgently it needs attention.
Step 3: Review the Severity Scale
Navigate to Modules → Security Events (or click "Security Events" on the main dashboard). You'll see a list of alerts. Each has a severity level:
| Level | Color | Meaning | Example |
|---|---|---|---|
| Critical (15) | Red | Active attack or compromise — drop everything | Rootkit detected, ransomware encryption |
| High (12-14) | Orange | Likely malicious — investigate immediately | Brute force success, privilege escalation |
| Medium (7-11) | Yellow | Suspicious — could be malicious or benign, needs context | Failed logins, new service installed |
| Low (1-6) | Blue/Gray | Informational — normal activity, logged for reference | Successful login, agent heartbeat |
Step 4: Examine One Alert from Each Level
Click into the alert list and find one alert from each severity level (Critical/High, Medium, Low). For each, read the full alert details and note:
- The rule name (what triggered the alert)
- The severity level (the number)
- The timestamp (when it happened)
This gives you a feel for the range of events a SOC sees — from routine noise to genuine threats.
Pre-Loaded Data: Your lab comes with 50 sample alerts that simulate a realistic SOC shift. These include failed login attempts, new services being installed, file integrity changes, and suspicious process executions. This is what a junior analyst's first hour looks like.
Part 3: Trace the Alert Data Flow
This is the core exercise. You're going to pick three specific alerts and trace each one backward through the pipeline to understand exactly how data flows from an endpoint to the screen in front of you.
The Six-Stage Pipeline
Every alert you see traveled through this exact path:
| Stage | Component | What Happens |
|---|---|---|
| 1 | Endpoint Agent | A Wazuh agent on a server/workstation collects local logs (Windows Events, syslog, file changes) |
| 2 | Wazuh Manager | The agent sends events to the Manager, which applies 4,000+ detection rules |
| 3 | Wazuh Indexer | Alerts and raw events are stored in the Indexer (OpenSearch) for fast searching |
| 4 | Wazuh Dashboard | The Dashboard queries the Indexer and shows you the alerts in the panels you're looking at |
| 5 | SOC Analyst | You review the alert, investigate context, and make a triage decision |
| 6 | Response Action | Close as false positive, escalate to case management, enrich with threat intel, or automate |
Understanding this pipeline is fundamental. When you look at an alert and ask "where did this come from?" — you're mentally walking backward through stages 4 → 3 → 2 → 1.
Step 5: Trace Alert #1 — A Failed Login
Find an alert related to failed authentication. Look for rule names containing "authentication failure," "failed logon," or Windows Event ID 4625.
Click the alert to expand its full details. Now answer these questions — write them down in your Alert Trace Worksheet:
| # | Question | Your Answer |
|---|---|---|
| 1 | Which agent sent this event? | Check the agent.name or agent.id field |
| 2 | What log source generated it? | Windows Security Event Log? Linux auth.log? |
| 3 | What rule detected it? | Note the rule ID and rule description |
| 4 | When did it happen? | Exact timestamp |
| 5 | What was the raw log entry? | Expand to see the original log |
| 6 | What stage of the pipeline created the alert? | Which stage applied the detection rule? |
Think Like an Analyst. A failed login isn't just a number — it's someone (or something) trying to access a system and getting rejected. Who tried? From where? How many times? At what time? These questions separate a good analyst from someone who just clicks "dismiss."
Step 6: Trace Alert #2 — A New Service Installed
Find an alert related to a new service or process being installed. Look for rule names mentioning "new service," "service installed," or Windows Event ID 7045.
Complete the same worksheet. Add two extra questions:
| # | Question | Your Answer |
|---|---|---|
| 1–6 | (same as above) | |
| 7 | What service was installed? | Look in the log data for the service name |
| 8 | Is this expected? | Known system service or something unusual? |
Why New Services Matter: Attackers install services for persistence — they want their malware to survive reboots. When you see "new service installed" in a SOC, your first question should always be: "Was this planned by IT, or did an attacker just set up shop?"
Step 7: Trace Alert #3 — A File Integrity Change
Find an alert related to file integrity monitoring (FIM). Wazuh monitors critical system files and alerts when they change. Look for rules mentioning "integrity" or "syscheck."
Complete the same worksheet. Add two extra questions:
| # | Question | Your Answer |
|---|---|---|
| 1–6 | (same as above) | |
| 7 | Which file was modified? | Path and filename |
| 8 | What type of change? | Created, modified, or deleted? |
Three Alert Types, Three Attack Indicators. The alerts you just traced represent three different stages of a real attack: credential theft (failed logins), persistence (new service), and system tampering (file changes). Recognizing these patterns is the foundation of everything you'll learn in Modules 2–4.
Part 4: Connect the Dots
Now that you've traced three individual alerts, zoom out and think about the bigger picture.
Step 8: Map the Data Flow
Without looking at the diagram above, draw or write out the 6-stage pipeline from memory:
Stage 1: __________ → Stage 2: __________ → Stage 3: __________
→ Stage 4: __________ → Stage 5: __________ → Stage 6: __________
If you can fill this in correctly, you understand the fundamental architecture of how a SIEM works. This knowledge applies to every SIEM — not just Wazuh. Splunk, QRadar, Elastic SIEM, and Microsoft Sentinel all follow the same basic pattern.
Step 9: Reflect on Your Traces
Look at your three completed worksheets side by side. Answer:
- Which alert would you investigate first? Why?
- Could any of these alerts be related? (e.g., failed login → new service → file change = possible attack chain)
- What additional information would you want to investigate each alert further?
Analyst Growth: The fact that you can now look at three alerts and ask "could these be related?" means you're already thinking like an analyst. That instinct — connecting seemingly unrelated events into a potential attack narrative — is the most valuable skill in the SOC.
Deliverables Checklist
Before marking this lab complete, verify you have:
- Alert Trace #1 — Failed login alert fully traced with all 6 questions answered
- Alert Trace #2 — New service alert fully traced with all 8 questions answered
- Alert Trace #3 — File integrity alert fully traced with all 8 questions answered
- Data Flow Memory Test — You can write the 6-stage pipeline from memory
- Reflection — You answered the three reflection questions connecting your traces
Key Takeaways
- Wazuh is the SIEM at the center of the SOC — it collects, detects, and alerts
- Every alert follows a 6-stage pipeline: agent → manager → indexer → dashboard → analyst → action
- Alert severity levels (Critical, High, Medium, Low) determine investigation priority
- Tracing an alert backward through the pipeline reveals what happened, where, when, and why it was flagged
- Three fundamental attack indicators: credential theft, persistence, and system tampering
- Connecting alerts into potential attack chains is the key analyst skill
What's Next
In Lab 1.2 — ATT&CK Mapping, you'll take a real-world APT29 attack report and map every technique to the MITRE ATT&CK framework using the free ATT&CK Navigator. This is a browser-only exercise — no cloud lab needed. You'll identify which techniques from the attack could be detected by the alerts you just traced, and where the detection gaps are.
Lab Challenge: Alert Trace
10 questions · 70% to pass
Open the SSH brute force alert (rule 5551) in the Wazuh dashboard. What is the source IP address of the attacker?
Check the full_log field of the SSH brute force alert. Which user account was the attacker targeting?
What severity level did Wazuh assign to the SSH brute force alert (rule 5551)?
Find the 'New Windows service installed' alerts on WIN-SERVER-01. One suspicious service runs from C:\ProgramData\Microsoft\Updater\. What is its service name?
Another suspicious service — SysHealthMonitor — was installed on WIN-SERVER-01. What is the executable path for this service?
Find the File Integrity Monitoring (FIM) alerts on linux-web-01. Which critical system file had its checksum changed?
Find the highest-severity alert in the dashboard (level 15). What event does it describe?
In the level 15 alert (event log cleared), check the data fields. Which account cleared the Windows audit log?
Find a successful SSH login alert (rule 5501) on linux-web-01. The first legitimate login of the day was by user 'devops'. What source IP did they connect from?
Look at the Windows logon success alert (rule 60103) for WIN-SERVER-01. The svc-backup account logged on with Logon Type 5. What does Type 5 mean?
0/10 answered