Module 12 Lesson 6 of 6 🕑 ~55 min

> cat module-12-6-practical-exercise.md

Practical Exercise & Assessment

The final lesson: you run the incident yourself. A 10-inject ransomware simulation drops new evidence and new pressure on you one step at a time, followed by the common mistakes to avoid, interview questions, and the module's final practical assessment.

Capstone – Safe Ransomware Simulation

🦡 10-inject live exercise

This exercise uses no real ransomware or destructive malware — the objective is incident response, not malware development. Build it with isolated virtual machines and synthetic logs: a Windows Server Domain Controller, a Windows Server file server, a Windows 11 workstation, and a Linux log/SIEM server (Sentinel, Elastic Security, Splunk Free, Wazuh, Sysmon, Defender or Wireshark all work). Keep the virtual network isolated from production and preferably from the Internet, and snapshot everything before you start.

You work for CyberCafe International, which has just discovered suspicious activity. Form an incident-response team — possible roles: Incident Commander, SOC Analyst, Endpoint Investigator, Identity Investigator, Network Investigator, Communications Lead. Work through each inject below in order; don't peek at the next one until you've answered the current one.

🔮 Inject 1 – Initial Alert

ALERT  Severity: Critical
Hostname: FS01  Time: 09:12 UTC
Detection: Mass file modification
Files modified: 4,829  User: svc_backup

What do you do first?

Reveal the expected response

Validate the alert while preparing immediate containment in parallel — don't wait for full certainty before isolating FS01, but don't declare a confirmed incident on one alert alone either (Module 11, Lesson 3's triage discipline applies directly here).

🔮 Inject 2 – User Report

Service Desk Ticket
Users report documents on the shared drive will not open.
Files now have extension: .locked
A file called RECOVER_FILES.txt has appeared in multiple directories.

How does this change your assessment?

Reveal the expected response

This is now almost certainly ransomware — escalate severity immediately (Module 12 hub, Section 5).

🔮 Inject 3 – Endpoint Evidence

10:03:14  WINWORD.EXE
10:03:22  powershell.exe
10:03:27  powershell.exe -> external connection
10:06:42  unknown.exe
10:07:01  Rapid file modifications detected

Construct the likely attack chain.

Reveal the expected response

Document opened → Word spawns PowerShell → PowerShell reaches out externally → a payload (unknown.exe) is dropped → mass file modification begins — the exact Office-to-PowerShell-to-payload pattern from Lesson 1's IOA discussion.

🔮 Inject 4 – Authentication Evidence

02:14  jsmith VPN login
02:31  jsmith -> WS044
02:47  jsmith -> APP01
03:05  administrator -> APP01
03:19  administrator -> DC01
03:41  svc_backup -> BACKUP01

What does this sequence suggest?

Reveal the expected response

Potential lateral movement — the same account touching multiple systems in a short window, escalating from a workstation to an application server to a Domain Controller, and finally to backup infrastructure. This is the scoping process from Lesson 1 in action.

🔮 Inject 5 – Network Evidence

03:17  APP01 -> 203.0.113.45:443
03:21  APP01 -> 203.0.113.45:443
03:26  DC01 -> 203.0.113.45:443

What should you do with this IP?

Reveal the expected response

Search every firewall, proxy and EDR log across the enterprise for anything else communicating with 203.0.113.45 — exactly the IOC-driven threat hunt from Lesson 1, Section 7.

🔮 Inject 6 – Business Pressure

The CFO asks: "Can you just reconnect the finance file server? Payroll must run in 40 minutes."

How do you respond?

Reveal the expected response

Explain, clearly and without jargon, why reconnecting an untrusted server could worsen the incident — the exact security-vs-business tension from Lesson 2, Section 2. This is a communication test as much as a technical one.

🔮 Inject 7 – Executive Pressure

The CEO asks: "How many systems are affected? Was customer data stolen? When will everything be restored?"

How do you structure your answer?

Reveal the expected response

Separate known facts from suspected facts from unknown facts explicitly — never invent certainty you don't have (Lesson 3, Section 5's situation-report discipline).

🔮 Inject 8 – Data Exfiltration

02:00-03:00 average outbound traffic: 400 MB
03:00-04:00: 27 GB

What must you now investigate?

Reveal the expected response

Whether ransomware was preceded by data theft — a 67x spike in outbound traffic right before encryption began strongly suggests double extortion (Lesson 5, Section 1), which changes your regulatory posture (Lesson 4, Section 1) as well as your technical response.

🔮 Inject 9 – Backup Problem

You discover: the backup management account was accessed, several snapshots were deleted, but an offline backup from the previous night remains intact.

How does your recovery plan change?

Reveal the expected response

Verify the surviving offline backup is genuinely clean before relying on it, and adjust your Recovery Point Objective accordingly — you may be recovering from a slightly older point than planned (Lesson 2, Section 8).

🔮 Inject 10 – Regulatory Question

Legal learns customer personal information may have been stolen and asks: "When did we become aware of the potential personal-data breach?"

Why does this question matter so much?

Reveal the expected response

Regulatory clocks (GDPR's 72 hours, NIS2's staged deadlines) start from the moment of awareness, not confirmation — which is exactly why an accurate incident timeline (Lesson 1, Section 5) matters far beyond the technical investigation itself.

1 Student Tasks & Incident Documentation

From the simulation above, produce an incident report containing: an Executive Summary in plain English; a chronological Incident Timeline; Scope (affected users, endpoints, servers, accounts, potentially affected data); an Initial Access Hypothesis with supporting Evidence; a Containment Plan; an Eradication Plan; a Recovery Plan (what order systems return, and why); a Communications Plan (internal and external stakeholders); and Lessons Learned.

Throughout a real incident, every important action gets logged as it happens, not reconstructed afterward from memory:

09:14  Incident declared SEV1.               Owner: Sarah
09:16  FS01 isolated through EDR.             Owner: Ahmed
09:19  svc_backup account disabled.           Owner: Maria
09:24  Domain Controllers checked for IOC.    Owner: John
09:31  Firewall block added for malicious IP. Owner: Li
09:42  External DFIR provider contacted.      Owner: Incident Commander

This gives the response accountability in real time and makes accurate reconstruction possible later — both for the post-incident review (Lesson 3) and for any regulatory or legal process that follows.

2 Common Incident Response Mistakes

Reimaging too quickly
Help Desk sees malware and immediately wipes the machine — important forensic evidence disappears before anyone can preserve it (Lesson 1, Section 8).
Assuming the first alert is the whole incident
Everyone focuses on the one infected workstation while the attacker already controls multiple servers elsewhere.
Resetting one password
The compromised user's password gets reset, but the attacker still holds a refresh token, API key, session cookie, OAuth grant, or service-account credential. Identity containment (Lesson 2, Section 3) has to consider every authentication mechanism, not just the password.
Turning everything off without coordination
Emergency shutdowns can destroy volatile evidence and disrupt critical operations unnecessarily — containment has to be coordinated, not panicked.
Restoring too quickly
Servers get restored before attacker persistence is fully removed — the attack simply begins again.
Poor documentation
Teams perform hundreds of actions but nobody records them — later, nobody knows what happened, who changed what, which passwords were reset, or which systems were rebuilt.
Poor communication
Executives receive contradictory updates from different technical teams instead of one structured incident-command process (Lesson 3, Section 5).
Treating ransomware as only an encryption problem
Data may have been stolen days before encryption even began (Lesson 5, Section 1) — missing that changes both your regulatory exposure and your actual severity assessment.

3 Interview Questions

Beginner — What is incident response?
The structured process of detecting, investigating, containing, eradicating, recovering from and learning from a security incident.
Beginner — Event vs alert vs incident?
An event is something that happened; an alert is security logic flagging it as potentially suspicious; an incident is confirmed or credible enough evidence of compromise to justify formal handling.
Intermediate — EDR reports ransomware on one workstation. What do you do?
Contain immediately (isolate the endpoint), then investigate scope before assuming it's limited to that one machine — don't treat the first alert as the whole incident.
Intermediate — Why isolate a machine rather than shut it down?
Isolation blocks network communication while preserving the machine's state (including volatile evidence like RAM) and often keeps it manageable by the security platform — shutting down can destroy exactly the evidence you need.
Advanced — A Domain Admin account is compromised. How does your response change?
Treat the Domain Controller itself as potentially compromised — assume the attacker could create admins, deploy via Group Policy, or manipulate authentication. This usually escalates from endpoint-scale to enterprise-wide identity remediation (Lesson 2, Section 3).
Advanced — What if the backup environment has also been compromised?
Verify every backup's integrity before trusting it for recovery — check for accessed backup-admin accounts, deleted snapshots, or stolen credentials, and fall back to older or offline/immutable copies if needed (Lesson 2, Section 8).

Final Practical Assessment

🦡 Assessed exercise

You'll receive a folder of realistic evidence — Windows Security logs, EDR alerts, firewall logs, VPN logs, DNS logs, email evidence, proxy logs, cloud authentication logs, Help Desk tickets, a ransom note, a network diagram, and an asset inventory — without being told what happened. Your job is to investigate and reconstruct: initial compromise → compromised user → affected workstation → privilege escalation → lateral movement → compromised servers → data exfiltration → backup attack → ransomware deployment. Present your findings as though briefing a CISO.

A strong lab progression for the whole module, if you want to build your own additional practice: (1) investigate a suspicious login, (2) investigate a compromised endpoint, (3) investigate a phishing incident, (4) investigate a privileged-account compromise, (5) investigate lateral movement, (6) investigate possible data exfiltration, (7) run a full ransomware incident end to end, (8) present the incident to executives. This progressively builds both technical and professional skills — the same combination this whole module has been building toward.

Module 12 Outcome

Incident response is not about immediately knowing every answer. During the first hour of a major incident, responders may know very little — and that's normal. The professional approach is:

Identify what is known↓ Identify what is unknown↓ Preserve evidence↓ Protect critical assets↓ Contain confirmed threats↓ Continue investigating↓ Document decisions↓ Communicate clearly↓ Restore systems carefully↓ Learn from the incident

A strong incident responder doesn't panic when information is incomplete — they create structure from uncertainty. Across all 6 lessons, you should now be able to move a real incident through the full lifecycle: Detect (something suspicious happened) → Investigate (what, how, when, where, who, how far) → Contain (stop additional damage) → Eradicate (remove attacker access and persistence) → Recover (restore trusted systems and services) → Learn (understand what failed and improve).

Modern incident response has to work across endpoints, networks, Active Directory, cloud, SaaS, identity, applications, APIs, databases, mobile devices, legacy infrastructure and OT environments — and across security, IT, business leadership, legal, privacy, compliance, communications, business continuity, external specialists, regulators and law enforcement. That breadth is exactly why incident response is one of the best subjects for showing what professional cybersecurity actually looks like.

The most important lesson of this module: the goal of incident response is not simply to remove malware. The goal is to understand the compromise, stop the attacker, protect the business, restore trusted operations, and make the organisation harder to compromise next time.