Hands-on LabBeginner·~50 min·Includes challenge

Lab 1.1 — Alert Trace

Log into Wazuh, trace 3 real alerts through the data pipeline, and build your Alert Trace Worksheet.

Tools needed:Wazuh Dashboard

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

DetailValue
Lab Profilelab-wazuh
ContainersWazuh Manager, Wazuh Indexer, Wazuh Dashboard, Wazuh Agent
Estimated Time45–60 minutes
DifficultyBeginner
Browser AccessWeb UI — opens directly in your browser
Pre-Loaded Data50 sample alerts from Windows, Linux, and network sources
Deliverable3 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.

PanelLocationWhat It Shows
Top NavigationTop barModules, Management, Agents, Dev Tools
Security EventsMain areaTotal events, alerts by severity, recent activity
Agent StatusAgents tabEndpoints reporting to this Wazuh instance
Alerts SummaryCenter widgetsCounts 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:

LevelColorMeaningExample
Critical (15)RedActive attack or compromise — drop everythingRootkit detected, ransomware encryption
High (12-14)OrangeLikely malicious — investigate immediatelyBrute force success, privilege escalation
Medium (7-11)YellowSuspicious — could be malicious or benign, needs contextFailed logins, new service installed
Low (1-6)Blue/GrayInformational — normal activity, logged for referenceSuccessful 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.

Alert Data Flow — From Endpoint to Response

The Six-Stage Pipeline

Every alert you see traveled through this exact path:

StageComponentWhat Happens
1Endpoint AgentA Wazuh agent on a server/workstation collects local logs (Windows Events, syslog, file changes)
2Wazuh ManagerThe agent sends events to the Manager, which applies 4,000+ detection rules
3Wazuh IndexerAlerts and raw events are stored in the Indexer (OpenSearch) for fast searching
4Wazuh DashboardThe Dashboard queries the Indexer and shows you the alerts in the panels you're looking at
5SOC AnalystYou review the alert, investigate context, and make a triage decision
6Response ActionClose 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:

#QuestionYour Answer
1Which agent sent this event?Check the agent.name or agent.id field
2What log source generated it?Windows Security Event Log? Linux auth.log?
3What rule detected it?Note the rule ID and rule description
4When did it happen?Exact timestamp
5What was the raw log entry?Expand to see the original log
6What 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:

#QuestionYour Answer
1–6(same as above)
7What service was installed?Look in the log data for the service name
8Is 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:

#QuestionYour Answer
1–6(same as above)
7Which file was modified?Path and filename
8What 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:

  1. Which alert would you investigate first? Why?
  2. Could any of these alerts be related? (e.g., failed login → new service → file change = possible attack chain)
  3. 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

1

Open the SSH brute force alert (rule 5551) in the Wazuh dashboard. What is the source IP address of the attacker?

2

Check the full_log field of the SSH brute force alert. Which user account was the attacker targeting?

3

What severity level did Wazuh assign to the SSH brute force alert (rule 5551)?

4

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?

5

Another suspicious service — SysHealthMonitor — was installed on WIN-SERVER-01. What is the executable path for this service?

6

Find the File Integrity Monitoring (FIM) alerts on linux-web-01. Which critical system file had its checksum changed?

7

Find the highest-severity alert in the dashboard (level 15). What event does it describe?

8

In the level 15 alert (event log cleared), check the data fields. Which account cleared the Windows audit log?

9

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?

10

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