12.2 Incident Briefing: INC-2026-0227-001
Incident Briefing: INC-2026-0227-001
This subsection sets the scenario. Read it as the briefing you receive when you sit down at your workstation and open the incident for the first time. Every detail in this briefing drives the investigation decisions in subsections 11.3-11.14.
The alert
At 09:17 UTC on 27 February 2026, a Sentinel analytics rule fires: P1-InitialAccess-SuspiciousSignInAfterPhishingURLClick. The rule correlates two events within a 30-minute window:
- A user clicked a URL in an email flagged by Safe Links as suspicious (UrlClickEvents).
- The same user’s account was accessed from a new IP address not seen in the previous 90 days (SigninLogs).
The incident is created with High severity. The analytics rule maps to MITRE T1566.002 (Spearphishing Link) and T1078.004 (Valid Accounts: Cloud Accounts). The affected entity is j.morrison@northgateeng.com.
What you know at this point
From the incident details pane (30-second triage):
Affected user: j.morrison@northgateeng.com (Jane Morrison, Finance Manager).
Alert time: 2026-02-27 09:17 UTC.
Phishing URL clicked: https://login-microsoftonline.secure-portal-verify.com/auth/v2.
Click time: 2026-02-27 08:52 UTC.
Subsequent sign-in from new IP: 203.0.113.47 at 2026-02-27 08:54 UTC.
Sign-in result: Success. MFA satisfied. Conditional access: Granted.
User’s normal sign-in IPs (last 90 days): 192.0.2.10 (office), 192.0.2.15 (VPN).
What you do NOT know yet:
Whether the URL was an AiTM proxy (it could be a standard credential phishing page). Whether the session token was stolen (the sign-in from 203.0.113.47 could be the user on a personal device). Whether post-compromise activity occurred (inbox rules, mail forwarding, email access). How many other users received the same phishing email. Whether this is an isolated incident or part of a campaign.
The organisation: Northgate Engineering
500-seat manufacturing and engineering company. Headquartered in the UK with offices in Paris and Houston. M365 E5 licensing. Defender for Office 365 Plan 2. Sentinel deployed with: SigninLogs, AADNonInteractiveUserSignInLogs, AuditLogs, CloudAppEvents, EmailEvents, EmailUrlInfo, UrlClickEvents, DeviceProcessEvents, DeviceNetworkEvents connected.
Conditional access policies: MFA required for all users on all applications. No device compliance requirement (Intune deployment in progress but not enforced). No token binding configured. No FIDO2 deployment. Legacy basic authentication disabled 6 months ago.
SOC structure: 2-person security team. No 24/7 coverage. BlueVoyant as managed SOC partner providing out-of-hours alerting. Sentinel workspace with 90-day Analytics tier retention.
The five attack waves (timeline overview)
This is the complete campaign timeline. You do not know all of this at the start — you discover it through investigation. It is provided here so you understand the full scope of what you will investigate.
Wave 1 — 27 February 08:45-09:30 UTC. Phishing emails sent to 15 Northgate Engineering employees from external sender documents@sharepoint-secure-verify.com. 4 users click the URL. 1 user (j.morrison) enters credentials on the AiTM proxy. Token captured and replayed. Inbox rule created. Mail forwarding established.
Wave 2 — 27 February 14:00-15:30 UTC. Internal phishing emails sent from j.morrison’s compromised mailbox to 30 internal recipients. Different phishing URL hosted on new domain. 6 users click. 2 users compromise credentials. Tokens captured.
Wave 3 — 28 February 03:00-04:00 UTC. Attacker accesses the two new compromised mailboxes (s.chen, a.patel) during off-hours. Creates inbox rules and mail forwarding on both. Registers new MFA method (Authenticator app) on s.chen’s account.
Wave 4 — 28 February 09:00-11:00 UTC. Internal phishing from s.chen and a.patel to 45 internal recipients. New phishing infrastructure (third domain). 8 users click. 3 more credentials compromised.
Wave 5 — 28 February 16:00-17:00 UTC. BEC attempt: attacker uses a.patel’s compromised mailbox (a.patel is an Accounts Payable clerk) to send a vendor payment diversion email to the CFO, requesting a change to banking details on a pending £47,000 invoice. CFO flags the email as suspicious and reports to IT.
Detection timeline: Wave 1 detected by analytics rule at 09:17. Wave 2 detected during Wave 1 investigation. Wave 3 detected via off-hours sign-in hunt during investigation. Wave 4 detected by updated analytics rule (investigator broadened scope). Wave 5 detected by CFO report + investigator correlation.
Containment: All compromised accounts contained by 28 February 18:30 UTC. Zero successful credential replays after containment. Zero financial loss (BEC attempt intercepted by CFO).
Investigation decision point
You have the initial alert. You have the incident details. The first decision:
Is this a standard credential phishing incident or an AiTM attack?
If the URL is a standard credential harvesting page (captures password only), the attacker would need to bypass MFA separately — the investigation focuses on whether MFA was bypassed and how.
If the URL is an AiTM proxy (captures password AND session token), MFA is irrelevant — the attacker already has a valid session. The investigation focuses on token replay, post-compromise activity, and scope.
The answer determines your investigation path. Subsection 11.3 sets up the investigation workspace. Subsection 11.4 analyses the email and URL to determine which type of attack this is. Subsection 11.5 analyses the sign-in logs to identify the token replay pattern that confirms AiTM.
At 09:17, you do not have the luxury of reading this entire module before acting. You have a High-severity alert, a user who may be compromised, and an attacker who may be actively reading email and establishing persistence right now. The investigation and containment must happen in parallel: begin the sign-in log investigation (11.5) while preparing the containment actions (11.7). If the sign-in from 203.0.113.47 looks like token replay, execute containment immediately — do not wait for the full investigation to complete. Contain first, investigate fully after the bleeding stops.
Knowledge check
Check your understanding
1. The alert shows a successful MFA sign-in from IP 203.0.113.47 two minutes after the user clicked a suspicious URL. The user's known IPs are 192.0.2.10 and 192.0.2.15. What is your immediate assessment?
2. The briefing states that Northgate Engineering has MFA enabled for all users but no token binding or FIDO2 deployment. Why is this configuration specifically vulnerable to AiTM?