A spear-phishing email hits pioneer@ficsit-pioneer.corp (Pioneer Research) via the typosquat domain pioneer-updates.svc.net (registered 6 days prior). A macro-enabled Excel attachment drops a PowerShell stager that connects to C2 at 185.220.101.47. The attacker dumps credentials from LSASS, moves laterally via SMB to RESEARCH-STATION-01, and uses stolen credentials to access james.okafor's SharePoint files. Data is exfiltrated via C2 (547 MB) and Dropbox via m.blake (14.7 GB, 847 files), then ransomware renames 847 files with the .encrypted extension. Threat actor TA-001 IRON CHIMNEY (Eastern Europe, RaaS). This is the main scenario and shows up across all 10 tools and all 5 labs.
Click each step to expand it. Open the linked tool page, show students what to look at, then ask the discussion questions before moving on.
Open MailGuard and go to the Threats page. Find THREAT-001 and open it. This is the original spear-phishing email sent to pioneer@ficsit-pioneer.corp from pioneer-updates.svc.net — a domain registered just 6 days before the attack, spoofing the display name "Ficsit Research Platform." Show the macro-enabled Excel attachment (MAM_Update_Q4_2026.xlsm), the header analysis showing the C2 IP 185.220.101.47 in the relay chain, and the SPF/DKIM pass that let it through. The email looks like a legitimate internal platform update, which is the whole point.
Open the SIEM and go to Alerts. Point out ALT-7278 (PowerShell encoded command execution on RESEARCH-STATION-01 — this fired when the Excel macro ran and launched the encoded PowerShell stager) and ALT-7287 (large outbound transfer to 185.220.101.47 detected). Then navigate to Investigations and open INV-2024-0087. Walk through the investigation timeline from the first alert through to ransomware deployment. This is the full picture of the incident in one view.
Open the EDR and go to Detections. Walk through the detection chain: DET-0039 (PowerShell encoded command, parent chain outlook.exe → cmd.exe → powershell.exe — Outlook should never spawn cmd.exe), DET-0040 (LSASS memory read by svchost32.exe on PIONEER-WS-01/EP-002 — a svchost32 impersonating the real svchost32 is a classic Mimikatz trick), DET-0038 (C2 beacon: 547 MB exfil to 185.220.101.47 from pioneer_research_tool.exe), and DET-0041 (ransomware: 847 files renamed to .encrypted in under 4 minutes on RESEARCH-STATION-01/EP-001). Point out the risk score of 94 on RESEARCH-STATION-01.
Still in the EDR, navigate to the Timeline page for EP-001 RESEARCH-STATION-01. Walk through the process tree: outlook.exe spawns cmd.exe, which spawns powershell.exe -EncodedCommand (base64-encoded payload, always suspicious), which downloads and runs pioneer_research_tool.exe. That process then reads LSASS, opens the C2 beacon, and eventually deploys the ransomware payload. This is the full execution chain in one view.
Open Identity and go to Sign-ins. Filter by james.okafor and compare SI-016 (legitimate Denver sign-in at 14:20 UTC) alongside SI-015 (successful sign-in from Lagos, Nigeria at 14:23 UTC, just 3 minutes later — physically impossible). Then go to Risk Detections and open RISK-001 (Impossible Travel: Denver to Lagos in 3 minutes) and RISK-008 (Mass Access to Sensitive Files: 147 SharePoint Finance documents accessed in 4 minutes from Lagos after the anomalous sign-in). This is the attacker using stolen credentials from the phishing to access james.okafor's files.
Open the firewall and go to Threats. Find IPS-5821 (C2 beacon: periodic HTTPS connections to 185.220.101.47 consistent with C2 staging from PIONEER-WS-01) and IPS-5820 (anomalous outbound volume: 547 MB in 3 minutes to the same IP — far above baseline). Then find TRF-98177 in Traffic, which shows the actual 547 MB session to 185.220.101.47. The traffic was initially allowed (the block rule hadn't fired yet); this is a good moment to discuss why reactive blocking is sometimes too slow.
Open CASB and go to DLP. Find DLP-001: m.blake uploaded 847 files (14.7 GB) to a personal Dropbox account in 47 minutes, during the same window as the ransomware deployment. This is the primary data exfiltration path and the reason the attacker maintained the m.blake account access. Then find DLP-011: earlier that day, m.blake also attempted to access Mega.nz via Tor Browser, which was blocked at the NGFW. The two together show a staged exfil strategy: try an anonymous channel first, fall back to Dropbox when it's blocked. Point out that m.blake is a separate user acting as an exfil mule, not the initial phishing target.
Open the TIP and go to Actors. Find TA-001 IRON CHIMNEY. Show the actor profile: Eastern European RaaS group, active since 2022, known for AiTM phishing and ransomware deployment. Then go to Campaigns and find CAM-001 Operation SMELTING which links this incident to a broader campaign. Then check IOCs and show the 12 indicators tied to this actor including the C2 domains and IPs.
Open SOAR and go to Cases. Find CASE-2024-0087. Then navigate to Playbooks and open PB-001 AiTM Phishing Response. Walk through each step: isolate the host, quarantine the mailbox, revoke active sessions, block the phishing domain, block C2 IPs at the firewall, block Dropbox/Telegram endpoints at CASB, and inject decoys into the attacker's lateral movement path. Show how the SOAR is orchestrating actions across multiple tools automatically.
Open Queue and go to Tickets. Find IR-001. Show how the incident is tracked: the parent ticket with 10 sub-tasks (IR-001-1 through IR-001-10) distributed across the team, plus the linked ticket IR-002 (Post-Incident Review) and IR-004 (m.blake Account Investigation, opened separately on need-to-know basis). Point out IR-001-7 (Investigate m.blake account anomaly) and how it connects back to the CASB exfiltration story. This shows the project management side of incident response that often gets overlooked when teaching just the technical tools.