In this section
How Cloud Incidents Actually Unfold: AiTM to BEC to Identity Persistence
Scenario
A finance team member at Northgate Engineering clicks a link in what looks like a SharePoint sharing notification. Ninety minutes later, the attacker has a stolen session token, has read six months of email, has created an inbox rule that hides replies from a vendor, has sent a fraudulent payment redirect email from the compromised mailbox, has consented to an OAuth application with Mail.Read and Files.Read.All permissions, has downloaded 340 documents from the finance SharePoint site, and has created a service principal credential that will survive the inevitable password reset. The SOC's first alert fires at minute 47 — a risky sign-in detection. By that point, the attacker has been operating for fifteen minutes. Every minute of this attack produced evidence in a different cloud log source. An investigator who checks only sign-in logs sees the stolen session but misses the BEC email. An investigator who checks only email sees the inbox rule but misses the OAuth consent. This section walks the full attack so the rest of the course has a concrete shape to investigate.
Estimated time: 40 minutes.
Figure IR0.1. One cloud incident produces evidence across four distinct domains. Each domain has different log sources, different retention periods, and different query surfaces. An investigation that covers only one domain produces incomplete containment.
Why cloud incidents require a different investigation
A cloud incident does not leave a binary on a filesystem. There's no Prefetch entry, no Amcache hash, no registry Run key. The attacker operates through the same APIs and portals that legitimate administrators use. The evidence is audit log entries that record what happened, when, and from where — but those entries expire. Entra ID sign-in logs disappear after 30 days unless you've configured Sentinel to ingest them. The Unified Audit Log retains records for 180 days on E5 licensing, less on lower tiers. MailItemsAccessed — the single most important evidence source for proving what email the attacker read — has throttling behavior that aggregates multiple access events into single records, hiding the true scope of email exposure.
This means two things for the investigator. First, the clock is always running. Evidence you don't preserve in the first hours may not exist when you need it for the regulatory notification or the legal proceeding. Second, no single log source tells the complete story. The sign-in log proves the attacker authenticated. The mailbox audit proves they read email. The SharePoint audit proves they downloaded files. The Entra ID audit log proves they created persistent access. Four different log sources, four different query surfaces, four different retention clocks. The investigation that queries only one of them produces a finding that's technically correct but operationally incomplete.
The endpoint investigation discipline — forensic imaging, artifact parsing, timeline construction from filesystem metadata — doesn't apply here. If you need those skills, Windows Field Forensics (FOR501) teaches them. This course teaches the cloud investigation discipline: the logs, the queries, the correlation, and the analytical reasoning specific to M365 and Entra ID.
The attack, minute by minute
The scenario that follows is a composite of real AiTM-to-BEC incidents. The timestamps, evidence, and attacker behavior are drawn from investigation experience. Northgate Engineering provides the organizational context. The attack chain represents the most common M365 compromise pattern in 2025–2026 threat data.
14:31 — The phishing email arrives
The attacker sends a SharePoint sharing notification to j.morrison@northgate-eng.co.uk, a senior accounts payable clerk. The email is sent from a compromised mailbox at a legitimate supplier — not from a spoofed domain. The link points to an AiTM proxy hosted on a recently registered domain that serves a pixel-perfect Microsoft sign-in page.
The evidence: EmailEvents in Defender XDR records the inbound email. If Defender for Office 365 is configured, the URL is logged in EmailUrlInfo. The email passes SPF, DKIM, and DMARC because it's sent from the supplier's real domain. No email filter catches it because the sender is trusted.
14:32 — The user clicks and authenticates
Morrison clicks the link and enters her credentials on the AiTM proxy page. The proxy relays those credentials to the real Microsoft login page in real time. Microsoft prompts for MFA. Morrison approves the push notification on her phone. The proxy captures both the password and the session token that Microsoft issues after MFA completion. Morrison sees a generic "Document not found" error and moves on. She doesn't report anything.
The evidence: SigninLogs records a successful interactive sign-in from Morrison's IP address. The sign-in shows MFA satisfied, compliant device (if she was on a managed device), Conditional Access policies evaluated and passed. Everything looks legitimate because, from Entra ID's perspective, the authentication was legitimate — the real user provided the real credentials and completed the real MFA challenge. The AiTM proxy is invisible to the identity provider.
Anti-Pattern
Filtering sign-in logs for "failed MFA" to find compromised accounts. AiTM attacks produce successful MFA completions. The user completes MFA on the proxy page, and the proxy relays the completed session to Microsoft. The sign-in log shows MFA: satisfied. Every field says this sign-in is legitimate. The attacker's subsequent token replay is where the investigation evidence starts — not the initial authentication.
14:36 — Token replay from the attacker's infrastructure
The attacker replays the stolen session token from their own infrastructure — a VPS in a different country. A new sign-in appears in SigninLogs. Same user, different IP, different location, different user agent. The sign-in type is non-interactive because the attacker is using the stolen token, not entering credentials. The Conditional Access evaluation shows the original device compliance state from the legitimate session, not the attacker's actual device.
The evidence: SigninLogs records this as a non-interactive sign-in. The IP address and location differ from Morrison's normal pattern. But the critical fields — MFA status, device compliance, CA policy evaluation — all show the values from the original session. Entra ID Identity Protection may flag this as an "anomalous token" or "atypical travel" sign-in, but the risk detection often fires after the attacker has already acted.
This is the first moment where the investigation timeline diverges from the user's legitimate activity. Everything before this point was the real user on the real sign-in page. Everything after this point is the attacker operating with the stolen token.
This is what the sign-in record looks like in Sentinel. The fields that matter for investigation are annotated:
Every field says this sign-in is legitimate. MFA wasn't prompted because the token already satisfies it. CA policies passed because the evaluation inherits the original session's device state. Risk level is "none" because Identity Protection's anomalous token detection hasn't fired yet — it often lags by minutes. The only indicators are the IP address and location, and those only stand out if you know Morrison's normal pattern.
14:38–14:52 — Mailbox reconnaissance and email reading
The attacker accesses Morrison's mailbox. They search for keywords: "payment," "invoice," "wire," "bank details," "account change." They read six months of email threads with Northgate's top three vendors. They identify an active payment thread with a construction supplier — an invoice for $287,000 due in four days.
The evidence: MailItemsAccessed logs every email the attacker opens (bind operations) and every folder they sync (sync operations). But MailItemsAccessed throttles: if the attacker reads 50 emails in quick succession, many of those accesses are aggregated into fewer log entries with a shared SessionId. The throttling doesn't eliminate the evidence — it compresses it. The investigator must understand the SessionId grouping to accurately scope the email exposure.
14:46 — Inbox rule creation
The attacker creates an inbox rule that moves replies from the construction supplier to the RSS Subscriptions folder and marks them as read. This hides the supplier's responses to the fraudulent email the attacker is about to send. The rule name is "." — a single period, invisible in the Outlook UI unless you know where to look.
The evidence: OfficeActivity records the New-InboxRule operation. The rule parameters are logged: the sender filter, the destination folder, the mark-as-read action. This is one of the strongest forensic indicators of BEC — legitimate users don't create rules that hide replies from specific senders.
The rule name "." is a deliberate evasion technique. In the Outlook desktop client and OWA, a single-period rule name renders as nearly invisible in the rules list. The attacker isn't hiding from the audit log — they're hiding from the user and from the analyst who remediates by checking the Outlook UI instead of querying OfficeActivity.
14:58 — The BEC email
The attacker sends a reply in the existing payment thread from Morrison's mailbox to the construction supplier's accounts receivable contact. The email contains updated banking details and requests that the upcoming $287,000 payment be directed to the new account. The email is sent from the real mailbox, in the real thread, with the real signature. No email filter catches it because it's a legitimate reply from a legitimate sender.
The evidence: OfficeActivity records the Send operation. EmailEvents in Defender XDR records the outbound email. The email content is available through Content Search or eDiscovery. The timestamp correlation between MailItemsAccessed (the attacker reading the invoice thread) and the Send operation (the BEC reply) establishes the attack sequence.
15:04–15:31 — Data exfiltration and lateral activity
The attacker pivots to SharePoint. Using the stolen session, they browse the Finance team site, identify the contracts library, and begin downloading documents. Over 23 minutes, they download 340 files. They create an anonymous sharing link for a folder containing sensitive financial projections.
Simultaneously, the attacker sends two internal phishing emails from Morrison's mailbox to other Northgate employees, attempting to expand their access.
The evidence: OfficeActivity (SharePointFileOperation) logs every file download with FileDownloaded operations. CloudAppEvents provides additional context. The anonymous sharing link creation is logged as an AnonymousLinkCreated operation. The internal phishing emails appear in EmailEvents.
15:18–15:44 — Identity persistence
This is the stage most investigations miss. The attacker consents to an OAuth application with Mail.Read and Files.Read.All permissions. Then they create a new app registration in Entra ID, add a client secret credential to it, and grant it application-level API permissions. This service principal can authenticate without any user interaction — no sign-in prompt, no MFA, no Conditional Access evaluation. When the SOC resets Morrison's password, revokes her sessions, and removes the inbox rule, this service principal continues operating.
The evidence: AuditLogs records the consent grant (Consent to application), the app registration creation (Add application), the credential addition (Add service principal credentials), and the permission grant (Add app role assignment to service principal). Each of these audit events has a different OperationName and a different TargetResources structure. AADServicePrincipalSignInLogs records the service principal's subsequent authentications — a log table most analysts never check.
The app name "NE-Backup-Sync" is social engineering aimed at the analyst who eventually reviews the directory. It looks like a legitimate backup integration. The client secret has a one-year expiry — if nobody finds it, the attacker has persistent access for twelve months after the user's password was reset, sessions were revoked, and the incident was closed.
This is what the service principal's ongoing authentication looks like — a log table most analysts never check:
Three days after the SOC reset Morrison's password and closed the incident, the attacker's service principal is still authenticating successfully from the same IP address. No user sign-in alert fires. No CA policy evaluates. The service principal operates outside the controls designed for user authentication.
15:47 — The SOC responds
The SOC analyst sees the risky sign-in alert that fired at minute 47. They check the sign-in logs, see the anomalous IP, reset Morrison's password, and revoke her sessions. The inbox rule is eventually found and removed. The analyst closes the incident as "contained."
The service principal the attacker created at 15:42 continues to authenticate via AADServicePrincipalSignInLogs. It reads email through the Graph API using application permissions. It accesses SharePoint files. No alert fires because service principal sign-ins don't trigger the same detections as user sign-ins. The attacker maintains access for weeks.
What a single-domain investigation misses
An investigator who checks only sign-in logs sees the token replay and the anomalous IP. They reset the password and revoke sessions. They miss the inbox rule, the BEC email, the data exfiltration, and the service principal persistence.
An investigator who checks only email sees the inbox rule and the BEC reply. They remove the rule and flag the fraudulent email. They miss the OAuth consent, the SharePoint downloads, and the service principal.
An investigator who checks only files sees the bulk downloads and the anonymous sharing link. They revoke the link and review the downloaded files. They miss everything else.
The only investigation that produces complete containment is the one that covers all four evidence domains: identity, email, files, and directory. That's what this course teaches.
What this course covers and what it doesn't
This course teaches the cloud investigation — the four evidence domains, the queries, the correlation, and the containment. If the attacker in this scenario had also dropped a Cobalt Strike beacon on Morrison's endpoint (and in many real incidents, they do), the endpoint investigation is a separate discipline. Windows Field Forensics (FOR501) teaches endpoint artifact analysis. Applied Memory Forensics (FOR502) teaches memory investigation. Ransomware Response (FOR402) teaches the full ransomware lifecycle including preparedness and reporting. This course stays in the cloud because the cloud investigation is deep enough to demand its own curriculum.
Section 0.2 maps the cloud evidence landscape in detail — every log source, what it proves, and when it expires.