Student lab

Alerts to Answers

Lab 2 — SIEM Configuration & Attack Analysis

Lab 1 taught you to find an attack. This lab teaches you to investigate one. It is designed not to teach you where to click, but how to think like an analyst. Throughout, keep asking the one question every SOC analyst lives by: "Does this look normal — and if not, why?"

Introduction

Objective

Take the SSH brute-force data you generated in Lab 1 and run it through the complete analyst workflow: build situational awareness, analyze over time, investigate alerts and raw logs, search and pivot, form an evidence-based hypothesis, document a case, and recommend a response — the real day-to-day loop of a SOC.

Overview

Modern environments generate enormous volumes of data. A SIEM exists to collect, organize, and help you interpret it — but the SIEM does not draw conclusions. You do. This lab builds three competencies that separate an operator from an analyst:

Situational awareness — understanding what is happening in your environment.
Analytical reasoning — deciding whether activity is normal or suspicious, and why.
Investigative workflow — following the data from an alert to a defensible conclusion.

NOTE — You need Lab 1 data

This lab analyzes the brute-force attack from Lab 1. If your Discover window is empty, simply re-run the Lab 1 attack loop on WIN11 first, then set the time picker to Last 1 hour here. The data is the raw material for everything below.

Learning Outcomes

By the end of this lab you will be able to:

Navigate the Wazuh dashboard and read it as a "security story" (headline → type → location).
Use time-based analysis to separate steady background noise from a real spike.
Move from an alert to the raw decoded log that produced it.
Write targeted KQL queries and pivot on key fields (IP, user, agent) to expand an investigation.
Form an evidence-based hypothesis and record it in a structured case file.
Recommend a proportionate response and write a leadership-readable incident summary.

Lab Environment

System	Hostname	Agent Name	IP Address	Role
Wazuh Server 4.14.5	WAZUH-SRV	—	192.168.1.30	SIEM — Manager, Indexer, Dashboard
Ubuntu 26.04 Sensor	UB2604	u2604	192.168.1.10	SSH target from Lab 1 + Wazuh Agent
Windows 11 Pro	WIN11	win11	192.168.1.40	Analyst workstation + Sysmon

Key Terms

Key Term	Description
Situational Awareness	A current, accurate mental model of what is happening across your environment.
Baseline	The recorded "normal" against which anomalies are judged.
Pivot	Using one confirmed value (an IP, user, or host) to find every other event connected to it.
Hypothesis	A testable, evidence-based statement about what the activity means — not a guess.
False Positive	An alert that fired on benign activity.
Indicator of Compromise (IOC)	An observable (IP, hash, filename, pattern) associated with malicious activity.
MTTD / MTTR	Mean Time To Detect / Mean Time To Respond — headline measures of SOC effectiveness.
Neutralization	Action that stops an incident from getting worse (block, isolate, disable).

MITRE ATT&CK Context

This lab investigates the same technique you generated in Lab 1 — T1110 (Brute Force) — but now the focus is the analytic process, not the detection.

Activity 1 — Confirm Access and Data

WHY THIS MATTERS

An investigation built on missing or partial data reaches wrong conclusions. Analysts validate data availability first — this mirrors real SOC readiness checks at the start of every shift.

Log into the Dashboard at https://192.168.1.30 (admin credential from Lab 1).
Open Explore → Discover, index wazuh-alerts-*, time range Last 1 hour, click Update.
Confirm both agents u2604 and win11 appear as sources, and that Lab 1's failure events are present.

CHECKPOINT

You can see the brute-force events from Lab 1. If not, re-run the Lab 1 loop on WIN11, wait ~30 seconds, and refresh.

Activity 2 — Explore the Dashboard (Read the Story)

WHY THIS MATTERS

The Overview page condenses thousands of raw events into visual patterns. Reading those patterns quickly is how analysts triage — you cannot inspect every event individually at scale.

Open Home → Overview. Read each panel as part of a security story:

Panel	Question It Answers	Story Role
Top alerts	What events are occurring?	The headline
Rule groups	What type of activity is this?	The category of incident
Agents	Where is it happening?	The location
Severity levels	How urgent is it?	The priority

Note which rule groups dominate. After Lab 1 you should see authentication_failures and sshd prominently for agent u2604.

CHECKPOINT

You can state, in one sentence, what the environment is currently showing — e.g., "A cluster of authentication failures against u2604 from a single source." That sentence is situational awareness.

Activity 3 — Time-Based Analysis

WHY THIS MATTERS

Security events are never isolated — meaning lives in when and how fast they occur. The same 12 failures mean nothing over a day and a great deal over five seconds. This is called time compression, and it is the single most useful lens for separating noise from attacks.

In Discover, set the time picker to Last 24 hours and click Update. Note the shape of the event histogram — mostly flat background noise.
Now set it to Last 15 minutes. The Lab 1 attack appears as a sharp spike.
Hover over the spike bar to read its count and timestamp.

Ask: does the pattern stay consistent, or does a spike stand out? Consistency usually means normal; a sudden deviation from baseline is what warrants investigation.

CHECKPOINT

You can point to a specific time bucket containing the attack and state how many events it holds versus the surrounding baseline.

Activity 4 — Investigate the Alerts

WHY THIS MATTERS

An alert is the system saying "this is worth your attention" — it is a starting point, not a conclusion. The analyst's job is to evaluate significance, not just acknowledge the alert.

Filter to the attack: run rule.groups:"authentication_failures" and agent.name:"u2604".
Click the > arrow beside a high-level alert to expand it.
For each expanded alert, ask the three analytical questions below.
What triggered this alert (which rule, what condition)?
Does it align with expected behavior for this host?
What context is missing that I need before I decide?

Activity 5 — Log Analysis (The Raw Truth)

WHY THIS MATTERS

Alerts are summaries; logs are evidence. Each raw log line is one fact. Individually they look trivial; assembled in order they form a timeline. Comfort with raw logs underpins all detection work.

Expand an alert and locate the decoded fields. Map each field back to the raw line it came from:

Decoded Field	Meaning	Analyst Use
data.srcip	Source IP of the attempt	Pivot to find everything from this attacker
data.srcuser / data.dstuser	Username attempted	Was a real or invalid account targeted?
rule.id / rule.description	Which detection fired	Classify the event
rule.level	Severity 0–15	Prioritize; level ≥ 10 = correlated pattern
agent.name	Which host reported it	Locate the activity
full_log	The original raw line	Ground truth — what actually got written

NOTE — Wazuh severity scale

Wazuh rule levels run 0-15. Low levels (2-5) are routine; 10+ generally indicates a correlated or high-impact condition. The correlated brute-force alert from Lab 1 is level 10 -- that is Wazuh telling you "pattern," not "single event."

Activity 6 — Searching (Noise → Signal)

WHY THIS MATTERS

A SIEM holds vast data. Efficient searching is how you narrow focus, isolate relevant events, and find patterns. A skilled analyst uses queries to move from noise to signal in seconds.

Run these queries in Discover, reading each one as a sentence:

Every auth failure against the Linux sensor

::: {custom-style="CodeLabel"} Wazuh Dashboard · Discover query :::

agent.name:"u2604" and rule.groups:"authentication_failures"

Only the attacker's traffic

::: {custom-style="CodeLabel"} Wazuh Dashboard · Discover query :::

data.srcip:"192.168.1.40"

Only correlated, high-severity detections

rule.level >= 10

Combine: high-severity auth failures from this source

data.srcip:"192.168.1.40" and rule.level >= 10

COMMAND BREAKDOWN — KQL building blocks

field:"value" — exact field match; quote values with dots.

and / or — combine conditions.

=, >, <= — numeric comparison, used with rule.level.

field:* — field exists with any value; useful to check whether a field is even populated.

Activity 7 — Pivot and Form a Hypothesis

WHY THIS MATTERS

Pivoting turns one fact into a full picture. From a single source IP you can find every account it touched, every host it hit, and the exact time span — the raw material for a hypothesis you can defend with evidence rather than assumption.

Starting from data.srcip:"192.168.1.40", list every distinct data.dstuser (or data.srcuser) the attacker tried.
Note the first and last timestamps — the attack window.
Check whether any attempt succeeded (search for a successful-login rule/EventID from that source in the same window).
Write your hypothesis in one testable sentence.

NOTE — A good hypothesis is falsifiable

Example: "Between 14:02 and 14:03, host 192.168.1.40 attempted 12 logins to u2604 across 12 invalid usernames; none succeeded; this is consistent with automated password guessing (T1110), not a user typo." Every clause can be checked against the data.

Activity 8 — Document the Case

WHY THIS MATTERS

Security work is not finished until it is written down. A case file lets others review, validate, and act on your analysis — and protects you when decisions are questioned later.

Complete this structured case record in your notebook:

::: {custom-style="CodeLabel"} Analyst notebook · Case record template :::

SOC Incident Report

-------------------

Incident ID:      LAB2-<date>-01

Detected (UTC):   <first timestamp>

Analyst:          <your name>

Status:           Closed - Lab Exercise

Summary:          <2-3 sentences: what happened, plain language>

Affected system:  u2604 (192.168.1.10), SSH service

Source:           192.168.1.40 (WIN11)

Technique:        MITRE ATT&CK T1110 - Brute Force

Evidence:

  - Wazuh rule <id> (level 10) correlated brute-force alert

  - N individual failures, rules <id>/<id>

  - Raw confirmation in /var/log/auth.log on u2604

Assessment:       <benign lab activity / would be Suspicious in production>

Did any attempt succeed?  <yes/no + evidence>

Recommended actions:

  - <e.g., account lockout policy, Active Response IP block, restrict SSH exposure>

Lessons / gaps:   <e.g., is SSH exposure necessary? is MFA in place?>

Activity 9 — Response (Neutralization)

WHY THIS MATTERS

Detection without response is just paperwork. Neutralization stops the problem from advancing while minimizing disruption to normal operations — a balance, not a reflex.

For this attack, weigh proportionate responses. Match each to when it is appropriate:

Response	When Appropriate	Trade-off
Block source IP (firewall / Active Response)	Source is clearly hostile and external	Blocks a legitimate host if the IP is shared/internal
Account lockout after N failures	Any environment, as a standing control	A tool for attacker-driven denial of service
Disable the targeted account	A specific real account is under attack	Disrupts a legitimate user
Isolate the host	Evidence the host is compromised, not just targeted	Removes a production system from service
Monitor only	Low-confidence or known-benign activity	Risk of acting too late if it escalates

For this lab, the correct answer is monitor + note — the source is a known internal lab host and no attempt succeeded. State that judgment and your reasoning in the case file.

Activity 10 — Reporting & Recovery

WHY THIS MATTERS

A report closes the loop: it communicates results to people who did not watch the investigation, and it turns one incident into a lasting improvement. Leadership reads outcomes, not queries.

Write a three-sentence executive summary in plain language, then record two measures and one improvement:

MTTD — how long from the first failure to your detection?
MTTR — how long from detection to a decision?
One improvement — a control gap this incident revealed (e.g., missing account lockout, unnecessary SSH exposure).

Knowledge Check

The same 12 failures span 24 hours in one scenario and 5 seconds in another. Which is more concerning and why?
You have an alert but "not enough context to decide." Name two specific fields you would pivot on next.
What is the difference between an alert and a hypothesis?
Why is "block the source IP" sometimes the wrong first move, even for a real attack?
Leadership asks "were we breached?" Which single question in your investigation answers that, and how did you check it?

Answer Key

Q	Answer
1	The 5-second version. Time compression — 12 failures in seconds exceeds any human typo rate and indicates automation; spread over a day the same count is background noise.
2	Any two of: data.srcip (find everything from the attacker), data.dstuser/data.srcuser (which accounts were targeted), agent.name (which hosts), timestamp range (the attack window).
3	An alert is the system flagging activity for attention; a hypothesis is the analyst's testable, evidence-based statement about what that activity means.
4	If the IP is internal or shared, blocking it can cut off a legitimate host or many users; proportionality and context come before action.
5	"Did any attempt succeed?" — checked by searching for a successful-login event (Linux success rule / Windows 4624) from the same source in the attack window. None here → not breached.

Discussion Questions

You read the Overview dashboard as a "story." Where does that metaphor help a new analyst, and where might it mislead one?
Your hypothesis was built from a known ground-truth attack. How does the process change when you don*'*t already know what happened?
The lab told you to choose "monitor only." What single new piece of evidence would flip that to "isolate the host," and why?
MTTD and MTTR reward speed. What analyst behavior might those metrics accidentally discourage?

What Comes Next

You now own the full analytic loop: awareness, time analysis, investigation, pivoting, hypothesis, documentation, response, and reporting. Lab 3 applies this exact loop to a fresh scenario — a Windows authentication anomaly on WIN11 — and then stress-tests your time-compression judgment with a high-volume event burst. The workflow stays the same; the data gets harder.