Lab 8 — Capstone: File Integrity Monitoring, Active Response, and Correlated Investigation

Objective

Complete the analyst arc from detection to automated action. You will configure File Integrity Monitoring (FIM) on your own lab build — a Wazuh capability you have not yet touched — then wire Active Response so Wazuh acts on a detection automatically, and finally correlate endpoint, network, FIM, and intelligence telemetry into a single incident narrative. This is the capstone: everything you built in Labs 5, 6, and 7 becomes not just something you detect, but something your SOC responds to without waiting for a human.

Overview

Labs 5–7 taught you to find and identify threats and to write detections for them. But detection is only the setup. The question a Security Operations Center exists to answer is the next one: "Now that I've detected it, what do I do?" Two capabilities close that gap, and both are native to Wazuh:

• File Integrity Monitoring (FIM / syscheck) — Wazuh watches critical files and directories and alerts when they are created, modified, or deleted. It is one of Wazuh's core pillars, and the primary detection surface for ransomware, web shells, and unauthorized change.

• Active Response — Wazuh automatically executes a defensive action (block an IP, disable an account, isolate a host) when a chosen rule fires. This is the bridge from knowing to doing.

You will build both, then prove they work by triggering Active Response from two independent detections — showing that Active Response is a general capability, not a one-off:

• A ransomware-style FIM spike (rapid file changes you generate and hunt), and

• A known-bad IP match from your Lab 7 threat-intel CDB list.

Finally, you will correlate the whole picture into one incident timeline and produce a short after-action note. Every activity follows the capstone pattern:

Configure → Generate → Detect → Respond (automatically) → Correlate → Reflect

A safety note up front: Active Response executes real defensive actions (it will really block an IP or isolate a host for the timeout period). Every action in this lab uses a short timeout and a lab-safe target. Never point Active Response at production infrastructure, and always snapshot before testing.

How This Lab Relates to the Vendor Labs

The vendor ransomware lab (Lab 4) showed you FIM alerts and discussed Active Response and containment inside a pre-built cloud environment. This capstone is different: you configure both capabilities yourself, on your own four-VM build, and watch them operate on telemetry you generate. Where Lab 4 taught the incident-response lifecycle (containment, eradication, recovery as analyst decisions), this lab teaches the technical mechanisms Wazuh provides to automate the earliest containment step — complementing, not repeating, the vendor material.

Prerequisites

• Labs 5, 6, and 7 completed. You will reuse your Lab 7 CDB list (lab7-malicious-ips) as one of the two Active Response triggers.

• Wazuh operational; Dashboard at https://192.168.1.30.

• On WAZUH-SRV: sudo access to edit ossec.conf, local_rules.xml, and /var/ossec/etc/lists/.

• On WIN11 and UB2604: Wazuh agents Active; sudo/Administrator access.

• Snapshot all VMs before beginning — Active Response will make real changes.

Lab Environment Recap

Learning Outcomes

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

• Configure Wazuh File Integrity Monitoring (syscheck) on a monitored directory.

• Generate and hunt a ransomware-style rapid-file-change event in FIM telemetry.

• Explain the Active Response mechanism: script, <command>, and <active-response> blocks.

• Configure Active Response to trigger from a chosen rule, on a chosen endpoint.

• Trigger Active Response from two independent detections (FIM spike and threat-intel match).

• Verify an Active Response action executed via the active-response log and the endpoint state.

• Correlate host, network, FIM, and intel telemetry into a single incident timeline.

• Write a concise after-action note connecting detection to automated response.

Key Terms

Task 1.1 — Choose and Prepare a Monitored Directory

On WIN11, create a directory to represent business-critical files:

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

mkdir C:\CriticalData

Place a few dummy files in it (text files standing in for documents).

Why this matters: FIM is only as useful as the directories you point it at. In production you monitor the paths that matter — document shares, web roots, system binaries, configuration directories. Choosing what to watch is an analyst decision: watch too little and you miss the attack; watch too much (like a busy temp directory) and you drown in noise. This is the same specificity judgment you applied to detection rules in Labs 5–6.

Task 1.2 — Enable syscheck on the Directory

FIM is configured in the agent's ossec.conf. On WIN11, open the agent configuration (C:\Program Files (x86)\ossec-agent\ossec.conf) and add a monitored directory inside the block:

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

<syscheck>

  <disabled>no</disabled>

  <directories check_all="yes" realtime="yes">C:\CriticalData</directories>

</syscheck>

Restart the agent:

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

Restart-Service WazuhSvc

Why this matters: check_all="yes" tells Wazuh to record size, permissions, owner, modification time, and cryptographic hashes for every file -- the full fingerprint needed to prove what changed. realtime="yes" means Wazuh reacts the moment a file changes rather than on a periodic scan, which is essential for catching fast events like ransomware encryption. Understanding these two attributes is understanding what FIM can and cannot see.

Task 1.3 — Generate a Baseline

Give Wazuh a moment to establish the baseline (the initial scan), then confirm FIM is active. In the Dashboard, search:

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

agent.name:"win11" and rule.groups:"syscheck"

You should see the initial baseline events for C:\CriticalData.

Why this matters: FIM works by comparing current state against a known baseline. The first scan is that baseline — every future alert is a deviation from it. This is the same principle as the Lab 0 baseline you recorded in your notebook: you cannot detect "changed" without first knowing "normal."

Task 1.4 — Generate a Ransomware-Style File Spike

Now simulate the file behavior ransomware produces: rapid modification of many files. On WIN11, run a benign loop that appends to and renames files in the monitored directory (full script in the Manual Appendix — it only touches files in C:\CriticalData and does no real harm):

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

.\Invoke-Lab8FileSpike_v18.ps1

This rapidly modifies and renames the dummy files, producing a burst of FIM events.

Why this matters: Ransomware's defining telemetry signature is not a specific file or process — it is volume and velocity: many files modified in a very short window. By generating that pattern safely, you learn to recognize it in FIM telemetry the same way you learned to recognize a beacon by its timing in Lab 6. The behavior is the indicator.

Task 1.5 — Hunt the FIM Spike

In the Dashboard, hunt the burst:

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

agent.name:"win11" and rule.groups:"syscheck" and syscheck.path:"C:\\CriticalData*"

Examine the events. Note the syscheck.event (added/modified/deleted), syscheck.path, and the timestamps — the rapid succession is the ransomware signature.

Why this matters: A single file modification is normal; dozens in seconds, all in one directory, is not. Recognizing the rate of change — not any individual event — is the analytical skill. In Part 3 you will turn this exact pattern into an Active Response trigger, so that a future ransomware-style spike is contained automatically.

CONCLUSION: You configured FIM on your own build, established a baseline, generated a ransomware-style spike, and hunted it. You have now used the Wazuh pillar the earlier labs did not touch — and produced the first of your two Active Response triggers.

Task 2.1 — Understand the Active Response Model

Wazuh Active Response requires three components (all documented in the reference literature and Wazuh's manual):

The flow: an event fires a rule → if an <active-response> block matches that rule → the Manager orders the endpoint to run the named script → the action executes → an Active Response alert is generated.

Why this matters: Active Response is powerful and therefore dangerous — a poorly-scoped block can lock you out or disrupt legitimate activity. Understanding that it is rule-triggered is the key safety insight: it acts only when a specific, chosen rule fires. Your job as the analyst is to choose triggers precise enough that the automated action is always warranted. This is the specificity discipline from Labs 5–7 raised to its highest stakes, because now a false positive doesn't just alert — it acts.

Task 2.2 — Inspect the Built-in Scripts

Wazuh ships Active Response scripts out of the box. On WAZUH-SRV and the agents, the Linux scripts live in:

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

ls /var/ossec/active-response/bin/

You will see firewall-drop (adds an IP to the iptables deny list), among others. On Windows, the equivalent directory is C:\Program Files (x86)\ossec-agent\active-response\bin.

Why this matters: You rarely need to write an Active Response script from scratch — the built-ins cover the most common containment actions (block IP, restart agent, null-route). Knowing what ships by default means you reach for a tested, community-maintained script instead of writing risky custom code. firewall-drop is the workhorse: it is how you automatically block a malicious IP.

Task 2.3 — Configure the firewall-drop Command

On WAZUH-SRV, edit the Manager configuration:

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

sudo nano /var/ossec/etc/ossec.conf

The firewall-drop command block is typically present by default. Confirm (or add) it inside <ossec_config>:

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

<command>

  <name>firewall-drop</name>

  <executable>firewall-drop</executable>

  <timeout_allowed>yes</timeout_allowed>

</command>

Why this matters: The block is the declaration -- it tells Wazuh "there is a script named firewall-drop I may want to run." timeout_allowed permits the action to be automatically reversed after a set time, which is a crucial safety feature: a temporary block contains a threat without permanently breaking connectivity if the trigger was a false positive.

CONCLUSION: You understand the three-part Active Response model and have confirmed the firewall-drop command is available. Next, you will bind it to your two triggers.

Trigger A — Block a Known-Bad IP (from Lab 7 Intel)

Task 3.1 — Bind firewall-drop to the Intel Match

Recall your Lab 7 rule 100710, which fires when a Suricata alert's destination IP matches your CDB list of confirmed-malicious IPs. You will now make that detection act: automatically block the IP.

On WAZUH-SRV, add an <active-response> block inside <ossec_config>:

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

<active-response>

  <disabled>no</disabled>

  <command>firewall-drop</command>

  <location>local</location>

  <rules_id>100710</rules_id>

  <timeout>120</timeout>

</active-response>

Why this matters: Read the block as intent. 100710 binds the action to your threat-intel detection -- when a connection to a confirmed-bad IP is detected, this fires. local runs firewall-drop on the endpoint that generated the alert (the sensor). 120 blocks the IP for 120 seconds then automatically un-blocks -- a deliberate safety choice for a lab. You have just connected the full chain from Lab 7: intel → CDB list → detection rule → automated block. Your investigation now defends the network by itself.

Trigger B — Respond to a Ransomware-Style FIM Spike

Task 3.2 — Write a FIM Spike Detection Rule

First you need a rule that fires on the rate of file changes, not a single change. Wazuh's built-in FIM rules fire per-change; to detect a spike, use frequency. Add to local_rules.xml:

::: {custom-style="CodeLabel"} WAZUH-SRV · local_rules.xml :::

<group name="syscheck,lab8,">

  <rule id="100810" level="12" frequency="8" timeframe="10">

    <if_matched_group>syscheck_entry_modified</if_matched_group>

    <same_source_ip />

    <description>Lab8: Rapid file modification spike - possible ransomware (T1486)</description>

    <mitre>

      <id>T1486</id>

    </mitre>

  </rule>

</group>

Why this matters: The frequency="8" timeframe="10" attributes are the key -- this rule fires only when 8 modification events occur within 10 seconds, which is the ransomware velocity signature, not normal file use. This is the Wazuh equivalent of the frequency-based beacon detection you considered in Lab 6: you are alerting on behavior over time, not a single event. Tune the numbers to your environment -- too low and normal saves trigger it, too high and you miss slow ransomware.

Task 3.3 — Bind an Action to the FIM Spike

Bind an Active Response to rule 100810. For a Windows host, a common containment action is isolating the endpoint by blocking outbound traffic (the vendor literature uses a custom fw.cmd/PowerShell script; a simpler lab option is to trigger a log-and-alert Active Response, or reuse a host-isolation script your instructor provides). Add:

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

<active-response>

  <disabled>no</disabled>

  <command>firewall-drop</command>

  <location>local</location>

  <rules_id>100810</rules_id>

  <timeout>120</timeout>

</active-response>

Why this matters: The same firewall-drop command, bound to a different rule, now responds to a different threat class -- ransomware instead of a bad IP. This is the lesson: Active Response is a general mechanism. Once you understand the / pattern, you can automate a response to any detection you can write. Note the safety tradeoff: isolating a host on a FIM spike is aggressive; in production you would weigh auto-isolation against the disruption of a false positive (a legitimate bulk file operation). That judgment is exactly what Task 3.6 asks you to reason about.

Task 3.4 — Validate and Restart

The now-familiar discipline — validate before restart:

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

sudo /var/ossec/bin/wazuh-logtest

sudo systemctl restart wazuh-manager

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

Why this matters: A malformed block can prevent the Manager from starting -- and now the stakes include your automated defenses. Test, then apply, is non-negotiable when the configuration governs actions, not just alerts.

Task 3.5 — Trigger and Verify Both Responses

Trigger A (intel match): Generate a controlled connection toward a CDB-listed IP (a lab-safe listed test IP) so rule 100710 fires. Then verify the response.

Trigger B (FIM spike): Re-run Invoke-Lab8FileSpike_v18.ps1 on WIN11 so rule 100810 fires.

For each, confirm the Active Response actually executed by checking the Active Response log on the responding endpoint:

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

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

And in the Dashboard, find the Active Response alert:

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

rule.groups:"active_response"

Why this matters: The Active Response log is the ground truth that the action ran -- it records the script execution, the target, and the timestamp. Verifying the action (not just the trigger) is the same "prove it fired" discipline you applied to every detection in Labs 5-7, now applied to the response. An automated defense you have not verified is an assumption, not a control.

Task 3.6 — Reason About Automated Response (Analyst Judgment)

In your SOC Engineering Notebook, answer:

• Trigger A blocks an IP for 120 seconds. What are the consequences if the CDB list contained a false positive (a legitimate IP)? How does the timeout mitigate that risk?

• Trigger B responds to a file-change spike. What legitimate activity could trigger it (think backups, software installs, bulk edits)? Would you deploy auto-isolation in production, or alert-only? Justify.

• Active Response with <location>local</location> acts on the alerting endpoint. When would you instead want <location>server</location> or a defined-agent, and why?

Why this matters: Automated response amplifies both your detections and your mistakes. A false positive that used to generate a nuisance alert now takes an action — blocking traffic, isolating a host. Deciding which detections are trustworthy enough to automate, and building in safety nets like timeouts, is the highest-judgment skill in the SOC. There is no universally correct answer; there is only a defensible one, and defending it is the analyst's job.

CONCLUSION: You bound Active Response to two independent triggers, executed both, and verified the actions in the response log. You proved Active Response is a general containment mechanism — and reasoned about the real risk that comes with automation.

Task 4.1 — Assemble the Unified Timeline

Imagine the two triggers were stages of a single intrusion: an attacker connected to known-bad infrastructure (Trigger A) and then deployed ransomware (Trigger B). Build one timeline in your notebook that draws from every source:

Why this matters: No single source tells the whole story — the network sensor saw the C2 connection, FIM saw the encryption, Sysmon saw the process, and Active Response recorded the containment. Only by correlating them do you get the incident: initial contact → payload → impact → automated response. This is the synthesis every prior lab was building toward. A mature analyst does not think in "Suricata alerts" and "FIM alerts" — they think in incidents, assembled from all available telemetry.

Task 4.2 — Determine Scope and Sequence

Answer, using your timeline:

• Which source detected the earliest stage? Which detected the impact?

• Did Active Response contain the threat before or after the file spike? What does the timing tell you about detection-to-response latency?

• If one telemetry source had been unavailable, what part of the incident would you have missed?

Why this matters: Scope and sequence are what an incident commander needs — not a pile of alerts, but "here is what happened, in order, and here is what we already contained." Detection-to-response latency (how fast Active Response acted after the trigger) is a real SOC metric: it is the difference between containing ransomware at 8 files and at 8,000. Correlation is how you measure and communicate it.

Task 4.3 — Write the After-Action Note

Produce a concise after-action note (half a page) covering:

• What happened — the incident in two or three sentences, drawn from the correlated timeline.

• What detected it — which rules/sources fired (100710, 100810, Sysmon, FIM).

• What responded — which Active Response actions executed, and their effect.

• What to improve — detection tuning, response scoping, or telemetry gaps you would address (connecting back to the DFIR "Lessons Learned" phase).

Why this matters: The after-action note is where an incident becomes organizational learning. The vendor DFIR material makes the point that an incident does not end when the malware is removed — documentation, root cause, and detection improvement remain. Your note closes that loop: it records not just what happened, but what the SOC will do better next time. This is the final discipline of the entire course — turning an investigation into a stronger defense.

CONCLUSION: You correlated five telemetry sources into one incident narrative, measured detection-to-response, and produced the after-action record. You have completed the full analyst arc: build the sensor, hunt the threat, write the detection, enrich with intel, automate the response, and correlate the whole into a defensible incident story.

Answer Key

Invoke-Lab8FileSpike_v18.ps1 (runs on WIN11)

The complete, verbatim source of Invoke-Lab8FileSpike_v18.ps1. Type or copy it exactly as shown; everything between the rules below is the script.

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

<#
================================================================================
  Invoke-Lab8FileSpike_v18.ps1
  Lab 8 — Capstone: FIM, Active Response, and Correlated Investigation
  Runs on: WIN11 (192.168.1.40)   |   Run as: Administrator
================================================================================
  PURPOSE
    Simulates the FILE-CHANGE VELOCITY of ransomware (NOT real encryption).
    Rapidly modifies and renames dummy files in a Wazuh-monitored directory so
    File Integrity Monitoring (syscheck) produces a BURST of modification
    events. The burst trips the frequency-based rule 100810 (8 events in 10s),
    which in turn can trigger Active Response.

    The defining ransomware signature here is VOLUME + VELOCITY: many files
    changed in a very short window — not any single file or process.

  SAFE BY DESIGN
    Touches ONLY files inside C:\CriticalData. Renames files to ".locked" and
    immediately back — mimics ransomware's extension-change behavior with NO
    data loss and NO real encryption. Run in an isolated lab VM only.

  BEFORE YOU RUN
    1. SNAPSHOT WIN11 (required — Lab 8 also configures Active Response, which
       makes real firewall changes in later steps).
    2. Ensure FIM is configured on C:\CriticalData (Lab 8, Part 1):
         <syscheck>
           <disabled>no</disabled>
           <directories check_all="yes" realtime="yes">C:\CriticalData</directories>
         </syscheck>
       ...and the agent restarted:  Restart-Service WazuhSvc
    3. Open PowerShell as Administrator.
    4. Allow this session to run the script:
         Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass -Force

  INVESTIGATE
    agent.name:"win11" and rule.groups:"syscheck" and syscheck.path:"C:\\CriticalData*"
    Note the RATE of change — that is the ransomware signature.

  TUNING
    If the burst does not trip rule 100810, increase $count and/or $rounds
    below, or lower the rule's frequency threshold.
================================================================================
#>

$dir    = "C:\CriticalData"
$count  = 12    # number of files to churn
$rounds = 2     # passes over the file set

# Ensure the monitored directory exists and contains files to modify.
if (-not (Test-Path $dir)) { New-Item -ItemType Directory -Path $dir | Out-Null }
1..$count | ForEach-Object {
    $f = Join-Path $dir "doc$_.txt"
    if (-not (Test-Path $f)) { "baseline content $_" | Out-File $f }
}

Write-Host "[*] File spike starting:" (Get-Date -Format o) -ForegroundColor Cyan
for ($r = 1; $r -le $rounds; $r++) {
    Get-ChildItem $dir -Filter *.txt | ForEach-Object {
        # Modify content -> generates a syscheck 'modified' event.
        Add-Content $_.FullName ("changed {0}" -f (Get-Date -Format o))
        # Rename to mimic the ".locked" ransomware pattern, then rename back.
        $enc = "$($_.FullName).locked"
        Rename-Item $_.FullName $enc
        Start-Sleep -Milliseconds 100
        Rename-Item $enc $_.FullName
    }
}
Write-Host "[*] File spike complete:" (Get-Date -Format o) -ForegroundColor Green
Write-Host "[*] Hunt: agent.name:win11 rule.groups:syscheck" -ForegroundColor Green

FIM (syscheck) Configuration Reference

Windows agent ossec.conf (C:\Program Files (x86)\ossec-agent\ossec.conf):

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

<syscheck>

  <disabled>no</disabled>

  <directories check_all="yes" realtime="yes">C:\CriticalData</directories>

</syscheck>

Restart: Restart-Service WazuhSvc

Key attributes: check_all="yes" (full fingerprint incl. hashes), realtime="yes" (immediate reaction). Add report_changes="yes" to see content diffs for text files.

Active Response Configuration Reference (WAZUH-SRV ossec.conf)

Command block (firewall-drop is usually present by default):

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

<command>

  <name>firewall-drop</name>

  <executable>firewall-drop</executable>

  <timeout_allowed>yes</timeout_allowed>

</command>

Trigger A -- block a known-bad IP (binds to Lab 7 rule 100710):

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

<active-response>

  <disabled>no</disabled>

  <command>firewall-drop</command>

  <location>local</location>

  <rules_id>100710</rules_id>

  <timeout>120</timeout>

</active-response>

Trigger B -- respond to a FIM spike (binds to rule 100810):

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

<active-response>

  <disabled>no</disabled>

  <command>firewall-drop</command>

  <location>local</location>

  <rules_id>100810</rules_id>

  <timeout>120</timeout>

</active-response>

FIM spike rule (local_rules.xml):

::: {custom-style="CodeLabel"} WAZUH-SRV · local_rules.xml :::

<group name="syscheck,lab8,">

  <rule id="100810" level="12" frequency="8" timeframe="10">

    <if_matched_group>syscheck_entry_modified</if_matched_group>

    <same_source_ip />

    <description>Lab8: Rapid file modification spike - possible ransomware (T1486)</description>

    <mitre>

      <id>T1486</id>

    </mitre>

  </rule>

</group>

Validate and restart:

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

sudo /var/ossec/bin/wazuh-logtest

sudo systemctl restart wazuh-manager

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

Verify a response executed:

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

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

Rule / SID Registry (Cross-Lab)

To avoid collisions across the custom labs, this course uses:

Keep custom Wazuh rules in the 1005xx–1008xx range and custom Suricata SIDs in the 1000000+ range, well clear of the vendor rulesets.

Instructor Notes

• Snapshot enforcement: Active Response makes real changes (iptables/firewall). Require a snapshot before Part 3 and revert after grading. The 120-second timeout auto-reverses the block, but a snapshot is the guaranteed reset.

• Trigger A test target: Use a lab-safe, CDB-listed IP that is safe to "block" briefly (e.g., a spare lab host or a documentation-range address routed internally). Never point the test at real malicious infrastructure or at a needed service.

• Trigger B tuning: frequency="8"/timeframe="10" suits the generator's defaults; adjust to your class's timing. If the spike does not fire the rule, increase count/rounds in the generator or lower the frequency threshold.

• firewall-drop on Windows: firewall-drop is a Linux (iptables) script. For a true Windows host-isolation response, the reference literature uses a custom fw.cmd + PowerShell (New-NetFirewallRule ... -Direction Outbound -Action Block). For a first pass, binding Trigger B's response on the sensor (UB2604) or using an alert-only/log response on Windows avoids the custom-script complexity; advanced sections can implement the full Windows isolation script.

• Alert-only variant: For sections where automated blocking is too risky on shared infrastructure, configure the <active-response> to run a benign log-only script (or set very short timeouts) so students see the mechanism fire without network impact.

• Correlation seeding: For a richer Part 4, have students also run the Lab 5 Sysmon generator so the unified timeline genuinely spans all five sources.

• This is the capstone: grade Part 4 (correlation + after-action) heavily — it is the synthesis skill the whole course builds toward, and the hardest to fake.