Lab 3 — SIEM Analyst Use-Case Walkthrough

Objective

Apply a structured SOC workflow to two scenarios on your own lab: (1) a Windows authentication anomaly — several failed logons followed by a success — and (2) a high-volume attack burst that tests whether raw numbers alone should alarm you. Along the way you will query, correlate, qualify, respond, and recover.

Overview

Modern SOCs rely on centralized visibility, correlation, and response. The threat lifecycle gives every investigation the same backbone:

Collect → Detect → Qualify → Investigate → Respond → Recover

The hard part is rarely finding data — it is deciding what the data means. A pattern of "3 denied then 1 granted" can be a user fumbling their password or a low-and-slow credential attack that finally worked. The difference is context, and drawing it out is the whole job.

Learning Outcomes

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

• Generate a controlled Windows authentication anomaly on WIN11 and observe it in Wazuh.

• Apply the full threat lifecycle to a single scenario.

• Use KQL to correlate multi-event sequences and identify a denied → granted pattern.

• Qualify activity as benign, suspicious, or malicious using explicit, defensible criteria.

• Choose conditional response actions and justify them.

• Interpret a high-volume burst correctly using time compression and baseline deviation.

Lab Environment

CAUTION — Audit policy must log failures

WIN11 must audit logon failures for Event ID 4625 to appear. On most installations local logon-failure auditing is on by default. If your scenario produces no 4625 events, enable Audit Logon (Success + Failure) via secpol.msc → Local Policies → Audit Policy or Group Policy (see Instructor Notes).

Key Terms

MITRE ATT&CK Context

Collect — Generate the Anomaly on WIN11

WHY THIS MATTERS

Generating the scenario yourself gives you ground truth: you know the true story, so you can judge whether your later analysis reconstructs it correctly. The generator below is completely safe — it validates non-existent usernames, so it produces failed-logon events without ever touching or locking a real account.

On WIN11, open PowerShell as Administrator and run:

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

Add-Type -AssemblyName System.DirectoryServices.AccountManagement
$ctx = New-Object System.DirectoryServices.AccountManagement.PrincipalContext('Machine', $env:COMPUTERNAME)

# Three failed attempts against a fake account -> three Event ID 4625 failures
$fakeUser = "j.contractor"
1..3 | ForEach-Object {
    $ok = $ctx.ValidateCredentials($fakeUser, "WrongPass#$_")
    Write-Host ("attempt {0}: {1}" -f $_, $(if ($ok) { 'GRANTED' } else { 'DENIED' }))
    Start-Sleep -Seconds 1
}
Write-Host "Done. Your own interactive session is the 'granted' event to correlate."

COMMAND BREAKDOWN — What this command does

Add-Type ... AccountManagement — load the .NET class that can check a Windows credential.

PrincipalContext('Machine', ...) — check credentials against the local machine, not a domain.

ValidateCredentials($fakeUser, "WrongPass#$_") — attempt to validate a non-existent user with a wrong password. This fails safely and writes a 4625 Audit Failure to the Windows Security log.

1..3 | ForEach-Object — repeat three times, producing three consecutive failures.

Because the username does not exist, no real account can be locked out — this is the safe way to generate failed-logon telemetry.

The three failures are your "3 denied." The granted event you will correlate against is your own legitimate interactive logon to WIN11 (already recorded as Event ID 4624). Together they form the classic 3 denied → 1 granted sequence.

CHECKPOINT

PowerShell prints three DENIED lines. On WIN11, open Event Viewer → Windows Logs → Security and confirm three 4625 Audit Failure events for j.contractor. Ground truth established.

Detect — Find It in Wazuh

WHY THIS MATTERS

Wazuh reads the Windows Security channel via the agent, so those 4625 events arrive as decoded alerts. Detecting them here proves the host telemetry pipeline works and gives you searchable, correlatable data.

• In Discover (index wazuh-alerts-*, Last 15 minutes), run the query below.

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

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

COMMAND BREAKDOWN — Reading the query

agent.name:"win11" — only events from the Windows endpoint (lowercase agent name).

data.win.system.eventID:"4625" — Windows failed-logon events. Windows fields nest under data.win; the indexed path in Discover is data.win.system.eventID.

NOTE — Decoder field vs. indexed field

If you write a custom rule you reference the field as win.system.eventID (decoder view). In Discover you search data.win.system.eventID (indexed view). Both are correct — they are the same data seen from two sides of the pipeline.

CHECKPOINT

Three failed-logon alerts for j.contractor appear. Expand one and note data.win.eventdata.targetUserName and the timestamp.

Qualify — Benign or Concerning?

WHY THIS MATTERS

Qualification is the critical-thinking gate. Act too fast and you disrupt legitimate users on false positives; act too slow and a real intrusion advances. Explicit criteria keep the decision defensible.

A "3 denied → 1 granted" sequence has a benign and a concerning reading. Decide using context, not instinct:

Write a preliminary judgment. When context is thin, the correct label is "Suspicious — Requires Validation," not a definite verdict.

Investigate — Correlate the Sequence

WHY THIS MATTERS

Correlation is what turns scattered events into a story. By ordering the failures and the success on one timeline and checking their source attributes, you can tell "same user fixing a typo" from "unfamiliar source that eventually got in."

• Expand each 4625 and record: targetUserName, source workstation/IP, and exact time.

• Find the matching success: agent.name:"win11" and data.win.system.eventID:"4624" in the same window.

• Lay the four events on a timeline (T1–T3 denied, T4 granted).

• Compare source attributes across all four. Do they share the same origin?

NOTE — The decisive question

Do the denied attempts and the granted attempt share the same account, source, and device? If yes → almost certainly benign. If the granted event originates elsewhere → escalate.

Respond — Conditional Actions

WHY THIS MATTERS

Response must be proportionate to confidence. Premature account lockouts and isolations cause real operational harm; doing nothing on a real intrusion is worse. Conditional actions resolve the tension.

Recover — Root Cause & Detection Tuning

WHY THIS MATTERS

Recovery converts one incident into lasting resilience. Naming the root cause and improving detection logic means the next occurrence is caught faster — or prevented.

• Root cause: human error, misuse, or malicious intent? State which and your evidence.

• Improvement: propose one policy or monitoring change (e.g., alert when ≥3 failures precede a success within 2 minutes).

• Detection idea (conceptual): a rule condition such as rule.level >= 6 AND data.win.eventdata.targetUserName exists, refined to your environment.

Collect — Generate the Burst

On WIN11, run a larger version of the Lab 1 SSH loop against UB2604 to create a rapid burst of authentication failures:

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

$target = "192.168.1.10"

1..50 | ForEach-Object {

    ssh -o BatchMode=yes -o StrictHostKeyChecking=no -o ConnectTimeout=2 `

        "user$_@$target" "exit" 2>$null

}

Write-Host "50 attempts sent in a tight window."

COMMAND BREAKDOWN — What changed from Lab 1

1..50 — fifty attempts instead of twelve, each with a unique invalid username user1..user50.

No Start-Sleep — attempts fire as fast as possible, maximizing time compression.

This produces a sharp, unmistakable spike in the histogram.

Qualify — Is 50 a Lot?

By itself, 50 blocked attempts is low-signal. Internet-facing SSH, RDP, and web services routinely absorb credential stuffing, port scans, and botnet probing — hundreds to thousands of hits a day is unremarkable. The raw number is not the story.

What makes it significant is deviation from baseline and time compression:

In Discover, set the time picker to Last 15 minutes, then Last 24 hours, and compare the spike against the flat baseline. State whether your burst deviates enough to warrant action, and why.

CHECKPOINT

You can articulate a rule of thumb: escalation depends on baseline deviation and time compression, not the raw count. That sentence is the entire point of Scenario B.

Answer Key