Lab 0 — Wazuh & Suricata: Initial Lab Testing and Validation

Objective

Validate that every component of your Enterprise Security Operations Center laboratory is operational, communicating, and producing trustworthy telemetry — before you attempt a single investigation.

This lab is not busywork. It is the same discipline a professional SOC applies every time new infrastructure is deployed: prove the pipeline works before you rely on it. An analyst who cannot trust their data cannot trust their conclusions.

Overview

The four vendor labs that follow (Labs 1–4) place you in a pre-built cloud environment. This lab does something more valuable: it teaches you to validate an environment you built yourself — the four-VM topology constructed in Chapter 3 and Appendix A.

Throughout this lab you will trace security telemetry through the complete detection pipeline:

Event → Sensor → Log → Wazuh Agent → Manager → Indexer → Dashboard

Every activity follows the same engineering pattern used throughout this textbook:

Generate → Observe Locally → Observe in Wazuh → Explain Why

If any stage of the pipeline fails, you will stop, isolate the failure using the methodology in Appendix D, and correct it before continuing. By the end of this lab, you will have positive, evidence-based proof that your SOC is investigation-ready.

Learning Outcomes

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

• Verify the health of the Wazuh Manager, Indexer, and Dashboard services.

• Confirm Wazuh agent enrollment and connectivity from both the server and the endpoint.

• Trace a Linux authentication event from generation to a rendered Dashboard alert.

• Validate that Suricata is capturing packets on the correct interface and matching Emerging Threats (ET Open) signatures.

• Validate Sysmon telemetry (Event IDs 1, 3, and 22) from Windows 11 into Wazuh.

• Correlate network-based and host-based telemetry describing the same activity.

• Apply the source-to-SIEM troubleshooting methodology when a validation step fails.

Lab Environment

This lab uses the standardized textbook topology (see Lab_Topology-v1.png and Appendix A).

UB2604 contains two network interfaces. Precision matters — always refer to interfaces by their Linux names:

This lab was validated with the following component versions; record any differences in your notebook:

Note on hostnames vs. agent names: The machine hostnames are UB2604 and WIN11 (uppercase), but the Wazuh agent names — the values you query in the Dashboard — were set at enrollment as u2604 and win11 (lowercase). Wazuh queries are case-sensitive: agent.name:"u2604" finds events; agent.name:"U2604" finds nothing. Record this mapping in your SOC Engineering Notebook — the hostname/agent-name distinction is a classic source of "empty query" confusion.

Credentials

Wazuh does not ship with a default password. The installer generated a strong random password for the admin account and printed it at the end of the wazuh-install.sh run. If you did not record it, retrieve it from the installer archive on WAZUH-SRV:

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

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

Locate the line beginning admin and use that password for all Dashboard logins in this lab.

Key Terms

MITRE ATT&CK Context

Even a validation lab maps to adversary behavior. The benign test activity you generate in this lab produces the same telemetry categories real attacks produce:

Learning to recognize what these techniques look like in telemetry — under controlled, known conditions — is the foundation of threat hunting. In later labs you will hunt for the same techniques without knowing in advance that they occurred.

Task 1.1 — Verify Wazuh Services

Log into WAZUH-SRV and check the status of every Wazuh component:

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

sudo /var/ossec/bin/wazuh-control status

Expected result: every service reports running, including:

• wazuh-analysisd — applies decoders and rules to incoming events

• wazuh-remoted — receives encrypted traffic from agents (TCP 1514)

• wazuh-authd — handles agent enrollment (TCP 1515)

• wazuh-modulesd, wazuh-logcollector, wazuh-monitord, wazuh-execd, wazuh-db, wazuh-apid

Why this matters: Each daemon owns one stage of the pipeline. If wazuh-remoted is down, agents cannot deliver events; if wazuh-analysisd is down, events arrive but no alerts are generated. Knowing which service maps to which pipeline stage lets you isolate failures instead of guessing.

If any service is not running:

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

sudo /var/ossec/bin/wazuh-control restart

Then re-run the status command and confirm. Never assume a restart succeeded — verify.

Task 1.2 — Verify Dashboard Access

From a browser on your host machine or WIN11, browse to:

https://192.168.1.30

Accept the self-signed certificate warning (expected in the lab — the Dashboard uses a locally generated certificate). Log in as admin with the password retrieved earlier.

Why this matters: The Dashboard is the Indexer's front end. A successful login proves three things at once: the Dashboard service is up, the Indexer is answering queries, and your credentials are correct. Analysts think in terms of what a successful test proves, not just whether it passed.

Task 1.3 — Record Your Baseline

In your SOC Engineering Notebook, record:

• Wazuh version shown in the Dashboard (should be 4.14.5)

• Output of wazuh-control status

• Date and time of this validation

Why this matters: Version and baseline records turn future troubleshooting from archaeology into lookup. When something breaks after an update, your notebook tells you what "working" looked like.

CONCLUSION: You have confirmed the SIEM core is operational — services running, Indexer answering, Dashboard rendering. Every subsequent activity depends on this foundation.

Task 2.1 — Verify from the Dashboard

In the Dashboard, navigate to:

Wazuh → Agents (Endpoints Summary)

Verify both agents report Active:

Task 2.2 — Verify from the Server Command Line

Analysts should never depend on a single view of the truth. Confirm the same fact from the Manager's CLI:

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

sudo /var/ossec/bin/agent_control -l

Expected result: both agents listed with status Active, along with their assigned agent IDs.

Why this matters: The Dashboard reads from the Indexer; agent_control reads directly from the Manager. If the two disagree, you have just localized a problem to the Manager → Indexer stage of the pipeline — a diagnosis you could never make from one console alone. Cross-checking independent data sources is a core investigative habit.

Task 2.3 — Verify from the Endpoints

On UB2604:

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

sudo systemctl status wazuh-agent

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

sudo tail -n 20 /var/ossec/logs/ossec.log

Look for a recent line indicating Connected to the server.

On WIN11, open PowerShell as Administrator:

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

Get-Service WazuhSvc

Expected result: Status Running.

Why this matters: Agent-side logs show the connection from the endpoint's perspective — including enrollment errors, DNS failures, and dropped keepalives that the server side may summarize as merely "disconnected." When an agent misbehaves, the endpoint log is where the real story lives.

If either agent is disconnected, restart it and re-verify:

Windows:

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

Restart-Service WazuhSvc

Ubuntu:

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

sudo systemctl restart wazuh-agent

CONCLUSION: You have verified agent connectivity from three independent vantage points — Dashboard, Manager CLI, and endpoint logs. You now know how to localize an agent problem to a specific pipeline stage rather than guessing.

Task 3.1 — Generate a Known Event

On UB2604, deliberately fail an authentication. Run the following and enter a wrong password three times:

su - fakeuser

Or fail a sudo attempt by entering an incorrect password:

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

sudo -k

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

sudo whoami

Why this matters: You are creating ground truth — an event whose time, host, and nature you know exactly. Validation always begins with a known input. If you cannot find an event you deliberately created, you certainly cannot find an event an attacker tried to hide.

Task 3.2 — Observe the Event Locally

Confirm the operating system logged it:

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

sudo tail -n 20 /var/log/auth.log

Expected result: lines containing authentication failure or FAILED su with your username and a timestamp.

Why this matters: This is pipeline stage one. If the event does not exist in the local log, no amount of Wazuh troubleshooting will ever make it appear in the Dashboard. Always verify the source first — this is the Troubleshooting Rule from Appendix D.

Task 3.3 — Observe the Event in Wazuh

In the Dashboard, navigate to:

Explore → Discover

Set the index pattern to wazuh-alerts-*, set the time range to Last 15 minutes, and enter this query:

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

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

Open the matching document and examine these fields:

Why this matters: These fields are the vocabulary of every investigation you will conduct in this course. rule.level drives triage priority. full_log is your evidentiary record. decoder.name tells you how Wazuh understood the event — which becomes critical in Chapter 5 when you write detection rules of your own.

Task 3.4 — Trace the Pipeline in Your Notebook

Write out the path your event just traveled:

su failure → /var/log/auth.log → Wazuh Agent (logcollector) → Manager (remoted → analysisd: decoder → rule) → Indexer → Dashboard

CONCLUSION: You generated a known Linux event and recovered it through the SIEM with full field-level detail. The Linux telemetry path is validated. More importantly, you can now name every stage the event passed through — which means you can troubleshoot any stage that fails.

Task 4.1 — Verify the Interface Configuration

The most common cause of a silent sensor is not Suricata — it is the capture interface. Validate the interface configuration in four steps before touching the Suricata engine.

Step 1 — Verify the interface is up and promiscuous

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

ip link show ens192

Expected output (flags line):

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

<BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP>

Success criteria:

• Interface is UP (administratively enabled)

• Interface is LOWER_UP (physical/virtual link established)

• Interface displays the PROMISC flag

Why this matters: Suricata can only inspect packets that reach its monitored interface. Without PROMISC, ens192 discards every frame not addressed to UB2604 — which is nearly all of the traffic you care about. UP without LOWER_UP means the interface is enabled but has no link: check the VMware adapter connection.

Step 2 — Verify the promiscuous-mode service

Promiscuous mode set manually with ip link does not survive a reboot. This lab build makes it permanent with a systemd unit. Verify it:

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

sudo systemctl status promisc-ens192.service --no-pager

Expected output:

Loaded: loaded Active: active (exited)

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

ExecStart=... status=0/SUCCESS

Why this matters: "Active (exited)" is the correct state for a oneshot service — it ran once at boot, succeeded, and stays flagged active. This unit removes one of the most common failure modes in student labs: rebooting the sensor and silently losing promiscuous mode. A sensor that forgets its capture configuration after every reboot is not a sensor — it is a liability.

If the service does not exist on your build, create it:

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

sudo tee /etc/systemd/system/promisc-ens192.service << 'UNIT'

[Unit]

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

Description=Enable promiscuous mode on ens192

After=network-online.target

Wants=network-online.target

[Service]

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

Type=oneshot

ExecStart=/usr/sbin/ip link set ens192 promisc on

RemainAfterExit=yes

[Install]

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

WantedBy=multi-user.target

UNIT

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

sudo systemctl daemon-reload

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

sudo systemctl enable --now promisc-ens192.service

Then repeat Steps 1 and 2.

Step 3 — Verify the interface roles

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

ip link show ens192

Expected result: the flags include PROMISC and UP. There is deliberately no inet line for ens192 — confirm this with ip -4 addr show ens192, which should return no output at all. An address on this interface would mean it was misconfigured.

Now confirm the management interface:

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

ip -4 addr show ens160

Expected output:

inet 192.168.1.10/24

Finally, prove that the silent interface is actually capturing:

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

sudo tcpdump -i ens192 -n host 192.168.1.30

Expected result: traffic between 192.168.1.10 and 192.168.1.30 on port 1514 — the Wazuh Agent talking to the Manager. You are watching ens192 capture frames addressed to a different interface. That is promiscuous mode doing its job, and it is stronger proof than any flag: the capture path is verified end to end. Press Ctrl+C to stop.

Why this matters: Interface roles must never be ambiguous. ens160 (192.168.1.10) is how you manage the sensor and how the Wazuh Agent reaches the Manager; ens192 — silent, addressless, promiscuous — is where Suricata listens. If these are swapped, or if suricata.yaml names the wrong interface, every downstream validation fails while every service reports "running."

Analyst Corner — Why Does Our Monitoring Interface Have No IP Address?

Students who research IDS deployments will encounter both designs. This lab uses the one production SOCs prefer.

Our lab design (UB2604): ens192 has no IP address and runs in promiscuous mode. This configuration means:

• ens192 receives every frame on the segment, including traffic between other machines.

• The interface cannot be addressed, scanned, or attacked over the network.

• Management, updates, SSH, and the Wazuh Agent all travel over ens160 instead.

• The capture path and the management path stay cleanly separated — a compromise of one does not reveal the other.

The alternative — an addressed sensor: some laboratory builds give the capture interface an address as well:

Giving the capture interface an address makes administration marginally simpler. It also makes the sensor discoverable: an attacker scanning the segment finds a host that answers, learns that a monitoring device exists, and can target it. That trade is usually judged not worth making. In the silent design the capture interface is connected to a SPAN/mirror port or a network TAP and never transmits — it only listens.

See it in your own lab: SO14 uses the same silent design — its eth1 capture interface runs promiscuous with no IP address. What differs between the two sensors is role, not addressing: UB2604 is a dual-homed host that manages itself on ens160 and captures on ens192, while Security Onion is a dedicated appliance built for nothing but capture. Knowing why each design exists — and what each trades away — is the kind of architectural judgment that separates an analyst from a tool operator.

Step 4 — Verify the Suricata service

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

sudo systemctl status suricata --no-pager

Expected output:

Active: active (running)

Why this matters: Only after the interface layer is proven do you check the engine. This ordering is deliberate: it mirrors the Appendix D rule of working from the source toward the SIEM. An analyst who checks Suricata first and the interface never will chase rule-tuning ghosts for hours while the real fault sits one layer down.

Task 4.2 — Prove Packet Visibility with tcpdump

Before trusting Suricata, prove the interface itself sees traffic. Start a capture on the monitoring interface:

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

sudo tcpdump -i ens192 -nn icmp

While tcpdump runs, generate traffic from a different host. On WIN11:

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

ping 192.168.1.30

Expected result: tcpdump displays ICMP echo request/reply packets between 192.168.1.40 and 192.168.1.30 — traffic that is not addressed to the sensor yet is visible on ens192.

Stop the capture with Ctrl+C.

Why this matters: This single test separates two very different failure domains. If tcpdump sees the packets, any detection failure lies in Suricata's configuration or rules. If tcpdump sees nothing, the problem is upstream — VMware networking or promiscuous mode — and no Suricata setting will fix it. tcpdump is the analyst's ground truth for "did the packets arrive?"

Task 4.3 — Validate the Suricata Configuration and Ruleset

Test the configuration file syntax before touching the service:

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

sudo suricata -T -c /etc/suricata/suricata.yaml -v

Expected result: the test completes with no fatal errors ("Configuration provided was successfully loaded").

Confirm the installed Suricata version and build features:

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

suricata --build-info

Expected result: the first line reports This is Suricata version 8.0.x RELEASE (this lab was validated on 8.0.6 with LibHTP v8.0.6). A patch-level difference is expected and fine; a major version difference is not. Record the version, the enabled features (AF_PACKET, PCRE_JIT, JA3/JA4, RUST), and the LibHTP version in your SOC Engineering Notebook.

Why this matters: The major version determines which configuration syntax, output fields, and detection features are available — Suricata 8's eve.json schema and JA3/JA4 TLS fingerprinting differ from earlier releases. Recording build features, not just the version number, tells you at a glance whether capabilities your rules depend on (PCRE JIT, RUST protocol parsers) are actually compiled in. When a signature behaves differently than the documentation implies, the build-info output is the first place a professional looks.

Update the Emerging Threats Open ruleset and restart:

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

sudo suricata-update

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

sudo systemctl restart suricata

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

sudo systemctl status suricata

Count the loaded signatures (suricata-update writes its merged ruleset to /var/lib/suricata/rules/ by default):

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

sudo grep -c '^alert' /var/lib/suricata/rules/suricata.rules

Expected result: tens of thousands of rules — record the exact count in your notebook.

Why this matters: suricata -T is the professional habit of validating syntax before a restart, so a typo never takes your sensor offline. The rule count is a health indicator: if next month the count is suddenly zero, you will know your rule updates broke — before an attacker demonstrates it for you.

Task 4.4 — Trigger a Known Signature

Generate traffic that matches a specific, harmless ET/GPL signature. From WIN11, open PowerShell:

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

Invoke-WebRequest http://testmyids.com -UseBasicParsing

(Equivalent test from UB2604: curl http://testmyids.com)

The testmyids.com service returns a response crafted to match the signature GPL ATTACK_RESPONSE id check returned root (SID 2100498). Nothing malicious occurs — the response content simply looks like the output of a compromised web server.

Why this matters: This is the network equivalent of the EICAR file — a safe, deterministic trigger for a known signature. Deterministic triggers are how professionals validate detection systems: you know exactly which rule should fire, so any deviation is diagnostic.

Task 4.5 — Observe the Alert Locally in eve.json

On UB2604, confirm Suricata recorded the alert:

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

sudo grep '"event_type":"alert"' /var/log/suricata/eve.json | tail -n 5

For readable output, install and use jq — a command-line JSON processor every analyst should know:

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

sudo apt install jq

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

sudo tail -n 200 /var/log/suricata/eve.json | jq 'select(.event_type=="alert") | {timestamp, src_ip, dest_ip, signature: .alert.signature, sid: .alert.signature_id}'

Expected result: an alert with signature GPL ATTACK_RESPONSE id check returned root and signature_id 2100498.

Why this matters: eve.json is the sensor's authoritative record. Suricata logs far more than alerts — flow records, HTTP transactions, DNS queries, TLS metadata — all as structured JSON. Learning to slice eve.json with jq turns a wall of text into precise answers, a skill you will use constantly in Labs 6 and 7.

Task 4.6 — Observe the Alert in Wazuh

In the Dashboard, go to Explore → Discover, time range Last 15 minutes, and query:

::: {custom-style="CodeLabel"} UB2604 · Expected output :::

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

Open the alert document and examine:

Why this matters: Notice the layering: Suricata detected the traffic, wrote it to eve.json, the Wazuh Agent collected the JSON, and the Manager wrapped it in a Wazuh alert. Two detection systems, one pane of glass. Pivoting on data.src_ip across both Suricata and Sysmon events is how you will reconstruct attacks in later labs.

CONCLUSION: You proved every stage of the network detection pipeline independently: packets reach ens192 (tcpdump), the configuration is valid (suricata -T), rules are loaded (rule count), a known signature fires (eve.json), and the alert reaches the SIEM (Dashboard). When any future network detection fails, you now know exactly which five checks isolate the break.

Task 5.1 — Verify the Services

On WIN11, open PowerShell as Administrator:

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

Get-Service Sysmon64

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

Get-Service WazuhSvc

Expected result: both services report Running.

Task 5.2 — Generate Known Sysmon Events

Run three commands, each designed to trigger a specific Sysmon Event ID:

notepad Resolve-DnsName www.microsoft.com

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

Invoke-WebRequest https://www.microsoft.com -UseBasicParsing

Close Notepad after it opens.

Why this matters: Event IDs 1, 3, and 22 are the analyst's bread and butter. Nearly every Windows intrusion — from phishing payloads to ransomware — appears in telemetry as processes starting, resolving names, and connecting out. You are learning the normal shape of this telemetry now so that abnormal shapes stand out later.

Task 5.3 — Observe the Events Locally

Open Event Viewer and navigate to:

Applications and Services Logs → Microsoft → Windows → Sysmon → Operational

Verify recent events with IDs 1, 3, and 22, and open the Event ID 1 entry for notepad.exe. Note the fields Sysmon captures: Image, CommandLine, ParentImage, Hashes, User.

Why this matters: ParentImage and CommandLine are two of the most powerful investigative fields in existence. "Who started this process, and with what arguments?" answers more incident questions than any other single query. Sysmon records this for every process — Wazuh makes it searchable at scale.

Task 5.4 — Observe the Events in Wazuh

In the Dashboard, go to Explore → Discover, time range Last 15 minutes, and query:

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

agent.name:"win11" and data.win.system.eventID:"1"

Locate the notepad.exe process-creation event and examine data.win.eventdata.image, data.win.eventdata.commandLine, and data.win.eventdata.parentImage.

Repeat for Event IDs 3 and 22 by changing the eventID value in the query.

Why this matters: Note the field path — data.win.system.eventID — because Wazuh nests Windows event fields under data.win. Getting field paths exactly right is the difference between a query that finds the attacker and a query that silently returns nothing. Precision with field names is a recurring theme in this course.

Task 5.5 — Validate Malware Detection with EICAR

From a browser on WIN11, download the industry-standard antivirus test file:

https://secure.eicar.org/eicar.com.txt

Expected result: Microsoft Defender immediately quarantines the file. Confirm under:

Windows Security → Virus & threat protection → Protection history

Then, in the Wazuh Dashboard, search the last 15 minutes for:

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

agent.name:"win11" and data.win.system.providerName:"Microsoft-Windows-Windows Defender"

(Alternatively, a free-text search for EICAR within the time range.)

Why this matters: EICAR is a harmless text string that every antivirus vendor has agreed to detect as if it were malware — the definitive safe test of an AV pipeline. You have now proven that if Defender detects real malware on this endpoint, the SOC will know about it within seconds.

CONCLUSION: The Windows endpoint telemetry path is validated: Sysmon captures process, network, and DNS activity; Defender detects malware; and both reach the SIEM with full field-level detail.

Task 6.1 — Generate the Activity

On UB2604, install nmap if needed and run a SYN scan against the Windows endpoint:

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

sudo apt install nmap

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

sudo nmap -sS 192.168.1.40

Why this matters: A port scan is frequently the first observable act of an intrusion — reconnaissance (ATT&CK T1046, Network Service Discovery). It is also an ideal validation event because it is loud, fast, and matched by multiple ET Open scan signatures.

Task 6.2 — Find the Network Evidence

In the Dashboard (Explore → Discover, last 15 minutes):

::: {custom-style="CodeLabel"} UB2604 · Expected output :::

rule.groups:"suricata" and data.src_ip:"192.168.1.10"

Expected result: one or more ET SCAN alerts identifying 192.168.1.10 scanning 192.168.1.40.

Task 6.3 — Find the Host Evidence

Now pivot to the target*'*s perspective:

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

agent.name:"win11"

Examine what the Windows endpoint recorded during the same time window (Windows Firewall and system events vary by configuration — part of the exercise is discovering what your endpoint actually logged).

Task 6.4 — Build the Timeline

In your SOC Engineering Notebook, construct a mini incident timeline:

Answer in writing:

• Which source detected the activity first?

• Which source provided more detail about the attacker? Which about the target?

• If you had only one of the two sources, what part of the story would you lose?

Why this matters: No single telemetry source ever tells the complete story. Network sensors see the attacker's behavior; host sensors see the victim's experience. The discipline of pivoting between them — on IP, on time window, on hostname — is the core mechanical skill of every investigation in Labs 1–8.

CONCLUSION: You correlated network and host telemetry describing a single event, built a timeline, and articulated what each source contributes. This is the analyst workflow in miniature — you will repeat it, at increasing depth, for the rest of this course.

Answer Key