13.2 The Incident Briefing
Incident INC-2026-0227-001
Before you start investigating, understand the environment and the incident context. This is the information you would receive in a real SOC briefing at shift handover, or in the initial alert notification from your SIEM.
Organisation profile: Northgate Engineering
| Attribute | Value |
|---|---|
| Employees | ~500 across 3 offices (London, Manchester, Edinburgh) |
| M365 licensing | E5 (all users) |
| Defender stack | Defender for Endpoint P2, Defender for Office 365 P2, Defender for Identity, Defender for Cloud Apps, Entra ID P2 |
| Sentinel | Deployed, Log Analytics workspace, M365 Defender connector, Entra ID connector |
| Conditional access | MFA required for all users (authenticator app). No device compliance requirement. Legacy auth not explicitly blocked. |
| MFA method | Microsoft Authenticator push for all users. No FIDO2. No certificate-based auth. |
| Managed SOC | BlueVoyant provides 24/7 alert monitoring. Internal team handles investigation and response. |
| Industry | Engineering / manufacturing. Handles sensitive client IP and financial data. |
Read the organisation profile again. Two critical gaps are visible: no device compliance requirement in conditional access, and no phishing-resistant MFA. If you identified these immediately, you are thinking like an attacker — and like the analyst who needs to harden this environment after the incident.
Incident timeline overview
| Day | Time (GMT) | Event |
|---|---|---|
| Day 1 | 09:14 | Wave 1: 23 phishing emails delivered (voicemail lure, finance department) |
| Day 1 | 09:17 | First user clicks link |
| Day 1 | 09:22 | Compromised sign-in via AiTM proxy (j.morrison) |
| Day 1 | 09:25 | Attacker creates inbox rule |
| Day 1 | 09:37 | ZAP removes email from 4 mailboxes |
| Day 1 | 09:40 | Defender XDR alert: “Email messages containing malicious URL removed after delivery” |
| Day 1 | 09:42 | SOC analyst begins triage |
| Day 1 | 09:50 | Containment complete (sessions revoked, password reset, inbox rule removed) |
| Day 1 | 21:00 | Wave 2: 41 emails (document sharing lure, all-staff) |
| Day 2 | 09:00 | Wave 3: 8 emails (IT password reset lure, executives) |
| Day 3 | 06:00 | Wave 4: 15 emails (benefits lure, HR) |
| Day 3 | 18:00 | Wave 5: 31 emails (project update lure, engineering) |
| Day 3 | 22:00 | Campaign concluded. All waves contained. Zero successful replays in Waves 2-5. |
Available data sources
For this investigation, you have access to:
| Data source | Table(s) | What it provides |
|---|---|---|
| Defender for Office 365 | EmailEvents, EmailUrlInfo, EmailPostDeliveryEvents, UrlClickEvents | Email delivery, URL verdicts, click tracking, ZAP actions |
| Entra ID | SigninLogs, AADNonInteractiveUserSignInLogs, AuditLogs | Authentication events, token activity, directory changes |
| Defender for Cloud Apps | CloudAppEvents | Inbox rule creation, mail forwarding, file access |
| Purview Audit | OfficeActivity (or unified audit log) | MailItemsAccessed, detailed mailbox operations |
| Defender for Endpoint | DeviceProcessEvents, DeviceNetworkEvents | Endpoint activity (less relevant for this scenario) |
MITRE ATT&CK mapping — expected techniques
Based on the AiTM attack pattern, these are the techniques you expect to find:
Your investigation objectives
At the end of this module, you will have answers to these questions:
- How many users were targeted? How many clicked? How many were compromised?
- What did the attacker access during the compromise window?
- Did the attacker establish persistence (inbox rules, forwarding, OAuth grants)?
- Did the attacker send lateral phishing from compromised accounts?
- What is the phishing kit’s infrastructure pattern (for blocking future waves)?
- What hardening changes prevent this attack from succeeding again?
- What detection rules catch this attack pattern automatically?
Try it yourself — before you start
An experienced analyst typically starts with these three:
1. Scope the phishing campaign — EmailEvents filtered by threat type or sender domain. How many emails, how many recipients, what was the delivery action?
2. Who clicked? — UrlClickEvents filtered by the phishing URL. Which users clicked through Safe Links?
3. Token replay check — AADNonInteractiveUserSignInLogs for the clicked users, looking for sign-ins from IPs not in their baseline.
If your list matches, you are thinking like a SOC analyst. If it differs, that is fine — there is more than one valid starting point. The important thing is that you had a plan before executing.