Lab 4 — SIEM Ransomware Investigation

Introduction

Activity 1 — Configure File Integrity Monitoring

WHY THIS MATTERS

FIM is off for most paths by default because watching everything is noisy. You deliberately scope it to a folder that matters and put it in realtime mode so ransomware's speed works against it — the faster it changes files, the louder the signal.

New-Item -ItemType Directory -Force -Path "C:\LabData\Vault" | Out-Null

Write-Host "Created C:\LabData\Vault"

<directories realtime="yes" report_changes="yes" check_all="yes">C:\LabData\Vault</directories>

Restart-Service -Name WazuhSvc

Get-Service WazuhSvc

Get-Service WazuhSvc

Activity 2 — Establish the FIM Baseline

WHY THIS MATTERS

A quiet folder is your control condition. Seeing zero FIM activity now means every alert in Activity 3 is unambiguously caused by the simulation — clean cause and effect.

• In Discover (index wazuh-alerts-*, Last 15 minutes), run: agent.name:"win11" and rule.groups:"syscheck".

• Expect little or nothing. That silence is your baseline.

CHECKPOINT

The syscheck query is quiet. Baseline confirmed — the folder is calm before the storm.

Activity 3 — Trigger the Ransomware Simulation

WHY THIS MATTERS

Detection engineering needs ground truth. By producing the exact behavior of ransomware — safely — you can confirm FIM catches it and learn the alert signature you will recognize in the wild.

On WIN11, run this benign simulator in PowerShell. Read the breakdown before running it.

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

$vault = "C:\LabData\Vault"

# 1) Seed 30 "victim" documents
1..30 | ForEach-Object {
    Set-Content -Path "$vault\report_$_.docx" -Value "Quarterly data $_"
}
Start-Sleep -Seconds 2

# 2) Simulate encryption: rewrite + rename each to .locked (no real crypto)
Get-ChildItem "$vault\*.docx" | ForEach-Object {
    Set-Content -Path $_.FullName -Value "ENCRYPTED_PLACEHOLDER"        # modify
    Rename-Item  -Path $_.FullName -NewName ($_.BaseName + ".locked")   # rename
}

# 3) Drop a ransom note
Set-Content -Path "$vault\README_RESTORE_FILES.txt" `
    -Value "Your files are encrypted. (This is a lab simulation.)"

Write-Host "Simulation complete: 30 files locked + ransom note dropped."

COMMAND BREAKDOWN — What this simulator does

Seed — creates 30 ordinary .docx files so there is something to "encrypt."

Modify — Set-Content overwrites each file's contents (FIM sees a modification).

Rename — Rename-Item changes each extension to .locked (FIM sees a deletion of the old name and creation of the new one — the classic ransomware fingerprint).

Note — drops README_RESTORE_FILES.txt, the high-confidence ransom-note indicator.

No encryption library is called; the word "ENCRYPTED_PLACEHOLDER" is literal text. It is fully reversible.

CHECKPOINT

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

C:\LabData\Vault now contains 30 .locked files and a README note. On to detection.

Activity 4 — Discovery

WHY THIS MATTERS

Ransomware manifests as high-volume, high-severity clusters. Learning to focus on the pattern — the spike — rather than any single file event is what lets you catch it in the first minute instead of the first hour.

• In Discover, Last 15 minutes, run: agent.name:"win11" and rule.groups:"syscheck".

• Watch the histogram: a dense spike of file events appears where before there was silence.

• Expand a few alerts and read the decoded fields.

Map what you see to FIM's three event types:

NOTE — Confirm your own rule IDs

Default FIM rules are commonly 550 (modified), 553 (deleted), and 554 (added), grouped under syscheck. Record the actual IDs your environment shows — verifying against your own data is the habit this book keeps reinforcing.

CHECKPOINT

A tight cluster of dozens of syscheck alerts sits in the last few minutes, versus the flat baseline from Activity 2. That density is the ransomware signature.

Activity 5 — Qualify the Threat

WHY THIS MATTERS

Not every alert is an incident, but ransomware is high-impact and high-likelihood once indicators appear — so analysts operate with a bias toward early containment. Delay means data loss. The framework below keeps that urgency disciplined rather than panicked.

Grade what you found against the triage framework:

Your simulation lands squarely in row 1: .locked extensions, a ransom note, and a mass-modification spike. That combination is a confirmed-indicator scenario.

NOTE — Practical rule of thumb

If encryption or a ransom note exists → escalate immediately. If behavior matches a ransomware playbook → treat as imminent. If uncertain → investigate quickly; do not ignore.

Activity 6 — Investigate & Correlate

WHY THIS MATTERS

Confirming ransomware is only the start — you must scope it. Which user, which host, which process, which paths? Scoping determines what you isolate and how far the damage reaches.

• Extract key entities from the alerts: the user context, the agent/host (win11), and the file paths (C:\LabData\Vault).

• Check suspicious-path patterns ransomware favors: C:\Users\Public\, C:\Windows\Temp\, C:\ProgramData\, ...\AppData\...\Temp\.

• If Sysmon process telemetry is present, pivot to find the process behind the changes: agent.name:"win11" and data.win.system.eventID:"11" (Sysmon FileCreate) around the same timestamps.

• Build a timeline: seed → modify → rename → note, with first and last timestamps (this is your MTTD input).

NOTE — Network vs. host — where each helps

FIM (host) proves what happened to the files. In a real incident you would also check network telemetry for C2 beaconing or exfiltration before the encryption. Correlating both is how you tell "encryption only" from "steal-then-encrypt."

Activity 7 — Respond (Containment First)

WHY THIS MATTERS

With confirmed ransomware, the cost of waiting is measured in encrypted files per second. Containment comes before tidy investigation — you stop the bleeding, then finish the analysis on a frozen scene.

NOTE — Optional — Active Response

Wazuh can automate containment. A conceptual design: a rule matching the FIM spike triggers an Active Response command that disables the host's network adapter or isolates it. You built the Active Response mechanics in Lab 8; here you decide whether automating this is wise (speed vs. the risk of auto-isolating on a false positive).

Activity 8 — Recovery & Lessons Learned

WHY THIS MATTERS

Recovery restores service and hardens against recurrence. The best incident output is a control that prevents the next one — or catches it faster.

• Root cause (in a real incident): initial access vector — phishing, exposed RDP, unpatched service? State how you would determine it.

• Recovery: restore from known-good backups; verify backups were not also encrypted (a key ransomware objective).

• Detection improvement: propose a correlation rule that fires on N file modifications within T seconds on a monitored path — turning the spike itself into a single high-severity alert.

• Compute MTTD from your timeline: first FIM event → your detection. Discuss a realistic production target.

Remove-Item "C:\LabData\Vault\*" -Force

Write-Host "Vault cleared."

Knowledge Check

• Which single FIM behavior — added, modified, or deleted — most strongly signals encryption-in-progress, and why does a rename generate two of them?

• The simulator never calls an encryption library. Why is it still a faithful detection test?

• Your triage framework puts this scenario in "act now." Name the two indicators that place it there.

• Why is containment ordered before completing the investigation for ransomware, unlike the auth anomaly in Lab 3?

• Backups exist, so is ransomware "not a problem"? Explain.

Discussion Questions

• FIM realtime mode is powerful but noisy. Which directories are worth watching in a real enterprise, and which would drown you in false positives?

• The lab detected ransomware after encryption began. What earlier (pre-ransomware) indicators from the triage framework would give you more warning, and where would you look for them?

• Automating containment via Active Response is fast but risky. Describe a false positive that would make auto-isolation harmful, and how you would guard against it.

• You correlated FIM with Sysmon to find the process. What could an attacker do to make that process-level correlation fail?

What Comes Next

You have now completed the four foundational labs: familiarization and first detection (Lab 1), the full analytic workflow (Lab 2), the threat lifecycle (Lab 3), and a high-impact FIM investigation (Lab 4). From here the book moves to your custom investigation series — Lab 5 (Sysmon), Lab 6 (Emerging Threats), Lab 7 (Threat Intelligence), and Lab 8 (Capstone) — where these workflows deepen against progressively harder telemetry.