Lab 1 — SIEM Familiarization & Your First Detection

Introduction

Activity 1 — Log Into the Wazuh Dashboard

WHY THIS MATTERS

The Dashboard is your entry point into the operational view of the whole network. Before you can analyze anything, you need reliable access and the correct credential. Getting locked out at step one is the single most common lab stall — so we handle credentials deliberately.

sudo tar -O -xvf wazuh-install-files.tar wazuh-install-files/wazuh-passwords.txt

sudo -- run as root; the archive is root-owned.

Activity 2 — Establish Your Baseline

WHY THIS MATTERS

You cannot recognize "abnormal" until you know "normal." Every investigation in this book compares what you see against a baseline. Two minutes spent here will make the attack in Activity 4 obvious instead of invisible.

• From the left menu, open Explore → Discover.

• At the top-left, make sure the index pattern is set to wazuh-alerts-*. This is the index that holds Wazuh alerts.

• Set the time picker (top-right) to Last 24 hours and click Update.

Look at the event histogram and the fields on the left. Ask yourself the three baseline questions and jot the answers in your notebook:

• What alert types appear most often right now?

• Which agents (agent.name) are active — you should see u2604 and win11.

• Roughly how many events per hour is "quiet"?

CHECKPOINT

You have a rough sense of the normal event volume and which agents are reporting. Keep this Discover tab open — you will return to it after the attack.

Activity 3 — Understand the Log Source

WHY THIS MATTERS

An alert does not appear by magic. It starts as a plain text line written by a service on a host. Knowing exactly where that line is born makes every later step — and every troubleshooting session — make sense.

On Linux, the SSH daemon (sshd) writes every authentication result to /var/log/auth.log. The Wazuh agent on UB2604 is configured to read that file and forward each new line to the Manager. Confirm the agent is watching it:

::: {custom-style="CodeLabel"} WAZUH-SRV · Terminal :::

sudo grep -A2 "auth.log" /var/ossec/etc/ossec.conf

COMMAND BREAKDOWN — What this command does

::: {custom-style="CodeLabel"} WAZUH-SRV · Terminal :::

grep "auth.log" -- search the agent config for the log-source definition.

-A2 — also print the 2 lines After each match, so you see the full <localfile> block.

The block should show <location>/var/log/auth.log</location> with <log_format>syslog</log_format> — proof the agent is forwarding this file.

The journey a single failed-login line takes:

sshd writes to auth.log → Wazuh agent (u2604) tails the file → Manager (WAZUH-SRV) decodes it into fields and matches a rule → Indexer stores it → Dashboard renders it as an alert you can search.

Activity 4 — Generate the Attack (Controlled Brute Force)

WHY THIS MATTERS

A brute-force attack is the "hello world" of detection: high-volume, noisy, and unambiguous. Generating it yourself gives you ground truth — you know exactly what happened and when, so you can verify that the SIEM saw it correctly. This is how detections are validated in the real world.

On WIN11, open PowerShell and run this bounded loop. It attempts SSH logins to UB2604 with a list of invalid usernames. BatchMode=yes disables the interactive password prompt, so each attempt fails immediately and cleanly — no key, no password, just a recorded failure.

::: {custom-style="CodeLabel"} WIN11 · PowerShell :::

$target = "192.168.1.10"
$users  = @("admin","oracle","backup","student","root","guest","dbadmin","ubuntu","postgres","svc","operator","test")

foreach ($u in $users) {
    ssh -o BatchMode=yes -o StrictHostKeyChecking=no -o ConnectTimeout=3 "$u@$target" "exit" 2>$null
    Write-Host "attempted: $u@$target"
    Start-Sleep -Milliseconds 400
}

COMMAND BREAKDOWN — What this command does

$target / $users — the target IP and the list of invalid usernames to try.

foreach ($u in $users) — loop once per username.

ssh ... "$u@$target" "exit" — connect as that user and immediately run exit; the login fails before exit ever runs.

-o BatchMode=yes — never prompt for a password; fail fast instead. This is what makes the loop non-interactive.

-o StrictHostKeyChecking=no — do not stop to ask about UB2604's host key the first time.

-o ConnectTimeout=3 — give up after 3 seconds if the host does not answer.

2>$null — discard SSH's error text so your screen stays readable (the failure is still recorded on UB2604).

Start-Sleep -Milliseconds 400 paces the attempts so all twelve land inside Wazuh's brute-force detection window.

CHECKPOINT

You should see twelve attempted: lines in PowerShell. Twelve failed logins in about five seconds is well above any human typo rate — exactly the pattern a brute-force detector looks for.

Activity 5 — Observe It Locally (Ground Truth)

WHY THIS MATTERS

Before trusting the SIEM, confirm the raw evidence exists at the source. If it is not in auth.log, no amount of SIEM tuning will show it. Analysts always establish ground truth first.

On UB2604, view the tail of the authentication log:

::: {custom-style="CodeLabel"} UB2604 · Terminal :::

sudo tail -n 40 /var/log/auth.log | grep -Ei "invalid|failed|authenticating"

COMMAND BREAKDOWN — What this command does

::: {custom-style="CodeLabel"} UB2604 · Terminal :::

tail -n 40 /var/log/auth.log -- show the last 40 lines of the auth log.

| — pipe those lines into the next command.

::: {custom-style="CodeLabel"} UB2604 · Terminal :::

grep -Ei "invalid|failed|authenticating" -- keep only lines matching any of these words; -E enables the | "or", -i makes it case-insensitive.

You should see lines such as Invalid user admin from 192.168.1.40 and Connection closed by authenticating user. Note the source IP 192.168.1.40 — that is WIN11, your attacker.

CHECKPOINT

Multiple failure lines from 192.168.1.40 appear in auth.log. Ground truth confirmed. Now prove the SIEM caught the same thing.

Activity 6 — Observe It in Wazuh

WHY THIS MATTERS

This is the payoff: the same twelve raw lines, now decoded, correlated, and prioritized for you. You will see how Wazuh distinguishes a single failed login from a brute-force pattern — the difference between noise and an incident.

• Return to your Explore → Discover tab (index wazuh-alerts-*).

• Set the time picker to Last 15 minutes and click Update.

• In the search bar, run the queries below one at a time. Press Enter after each.

Query 1 — everything from the attacker agent:

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

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

Query 2 — narrow to the source IP you saw locally:

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

data.srcip:"192.168.1.40"

Query 3 — isolate the brute-force correlation alert (higher level):

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

rule.groups:"authentication_failures" and rule.level >= 10

COMMAND BREAKDOWN — Reading these KQL queries

field:"value" — match a field exactly; quotes handle values with dots or spaces.

and — both conditions must be true.

rule.groups:"authentication_failures" — Wazuh tags every auth-failure rule with this group, so you catch them all without memorizing rule IDs.

rule.level >= 10 — keep only high-severity alerts. Individual failures are low level; the correlated brute-force alert is level 10, which is how the SIEM says "this is a pattern, not a typo."

Expand any alert with the > arrow and read the decoded fields. Confirm data.srcip is 192.168.1.40, note the rule.id and rule.description, and compare the low-level single-failure rules against the high-level aggregate rule.

NOTE — Exact rule IDs vary — read yours

In the default ruleset, individual SSH failures decode to rules like 5710 (invalid user) and 5716 (authentication failed), and the brute-force correlation is 5712 / 5720 (level 10). Rather than memorizing numbers, record the actual IDs your environment produced — that habit of verifying against your own data is the real skill.

CHECKPOINT

Query 3 returns at least one alert. That single high-level alert — built from many low-level failures — is your first SIEM detection. You saw it happen, you saw it locally, and you saw the SIEM name it.

Going Further (Optional) — Corroborate with Suricata

WHY THIS MATTERS

Host telemetry (auth.log) tells you what happened inside UB2604. Network telemetry (Suricata) tells you what happened on the wire. Correlating the two is the core analyst skill you will use for the rest of the book.

If your VMware port mirror includes the WIN11↔︎UB2604 segment, Suricata on UB2604's ens192 capture interface will also have recorded the SSH flow. On UB2604:

::: {custom-style="CodeLabel"} UB2604 · Terminal :::

sudo grep '"event_type":"flow"' /var/log/suricata/eve.json \

| grep '192.168.1.40' | tail -n 5

You may also see an Emerging Threats scan signature (e.g., ET SCAN Potential SSH Scan) depending on timing and ruleset. If your mirror does not carry this segment, that is expected — note it and move on. You will build a dedicated network-detection lab later.

Triage & Document

You have detected the attack. A real analyst now writes it down. Complete a short case note in your SOC Engineering Notebook:

• What: SSH brute-force attempt (T1110).

• Source / Target: 192.168.1.40 (WIN11) → 192.168.1.10 (UB2604).

• Evidence: auth.log failure lines + Wazuh rule (level 10) alert; record the rule IDs.

• Assessment: Known lab activity; in production this would warrant checking whether any attempt succeeded and whether the source IP is expected.

• Response idea: account lockout policy, fail2ban / Wazuh Active Response, and restricting SSH exposure.

Knowledge Check

• A single Failed password line appears in auth.log. Is that an incident? Why or why not?

• Your Query 1 returns results but Query 3 returns nothing. What does that tell you about the attack?

• You typed agent.name:"U2604" and got zero results even though the agent is active. What is wrong?

• Which field in the decoded alert tells you the attacker's IP, and where did you independently confirm that same value?

• Why is generating the attack yourself ("ground truth") more useful for validating a detection than waiting for a real one?

Discussion Questions

• The correlated brute-force alert is level 10 while each single failure is low level. What does Wazuh's use of severity levels let a SOC do that a flat "alert / no alert" system cannot?

• This attack came from a known internal host. How would your assessment change if data.srcip were an unfamiliar external address?

• You confirmed the attack in both auth.log and Wazuh. In a SOC with 5,000 endpoints, why can't you rely on tail-ing log files — and what does the SIEM give you instead?

• What single control would most reduce the impact of this attack, and what would it cost in usability?

What Comes Next

You logged in, learned what a SIEM is, and detected your first attack end to end. The brute-force data you just generated is not thrown away — Lab 2 uses this same dataset to teach the full analytic workflow: baselining, time-based analysis, pivoting, hypothesis testing, and writing a formal case. Keep your notebook and your Discover queries handy.