In this section

M365 Incident Response Foundations Summary: Shared Responsibility, Threat Landscape, Frameworks, and Regulatory Context

Module 1 · Free

What you learned in this module

This module established the foundations every subsequent module depends on. Five sections covered why M365 IR is different, what you're defending against, how the frameworks apply, what the regulations require, and what the evidence looks like when you query it.

Shared responsibility. Microsoft secures the infrastructure. You secure everything inside your tenant: the identities, the configurations, the detections, the evidence retention, and the incident response. The shared responsibility model isn't a data protection concept — it's an IR design constraint. Every decision about logging, containment tooling, and detection capability is yours to make before the incident happens.

Identity as the attack surface. Attackers don't breach firewalls to reach M365. They steal credentials and session tokens. AiTM phishing, token theft, device code phishing, and OAuth abuse all target the identity layer. The investigation starts with SigninLogs, not with a disk image. The containment targets the identity, not the device. The scope follows identity relationships, not network paths.

The threat landscape. AiTM phishing increased 146% year-over-year. BEC caused $3.04 billion in losses from 24,768 complaints. Token theft accounted for 31% of M365 breaches. Commodified phishing kits cost $120-350/month. The infostealer economy connects credential theft to BEC and ransomware through a supply chain of specialized actors. These are the threats this course prepares you to respond to.

IR frameworks. NIST SP 800-61 Rev 3 and SANS PICERL both apply, but every phase looks different in M365. Preparation means configuring log retention and pre-building emergency CA policies. Detection means reading sign-in logs, not endpoint alerts. Containment means revoking sessions, removing OAuth consents, and deleting inbox rules across multiple channels simultaneously. Post-incident improvement means deploying detection rules and hardening CA policies based on what the incident revealed.

Regulatory context. GDPR Article 33 gives you 72 hours from awareness. NIS2 gives you 24 hours for the early warning. SEC gives you 4 business days from materiality determination. HIPAA gives you 60 days but with compressed operational windows. The clocks start before you're ready. The investigation must produce the data these notifications require while the response is still in progress.

First investigation queries. You ran KQL queries against SigninLogs to find anomalous sign-ins. You examined the 12 fields in a sign-in record that matter for investigation. You collected evidence through the Graph API and exported it for preservation. You searched the Unified Audit Log and identified what an attacker's activity pattern looks like. These are the building blocks. The rest of the course assembles them.

Scenario 1. Your organization runs M365 E3. During an incident investigation, you need to determine which specific emails the attacker read from the compromised mailbox. You search for MailItemsAccessed events in the Unified Audit Log and find nothing. What's the most likely explanation?

The attacker deleted the MailItemsAccessed logs to cover their tracks.

Incorrect.

MailItemsAccessed events in the UAL cannot be deleted by a tenant user — they're managed by Microsoft. The logs are either generated or they aren't, depending on licensing.

The events aged out because the retention period expired before the investigation started.

Possible but not the most likely explanation for E3.

Retention could be an issue, but E3 retains UAL events for 180 days. The more fundamental problem is whether MailItemsAccessed events are generated at all on E3.

MailItemsAccessed requires E5 or the Audit Premium add-on. On E3, these events are not generated, regardless of retention settings. This evidence source simply doesn't exist for your tenant.

Correct.

MailItemsAccessed is an Audit Premium feature. Without E5 or the add-on, Microsoft doesn't generate these events. You can't retain what was never created. This is a shared responsibility gap: Microsoft provides the capability, but the organization must license and configure it. This decision was made months or years before the incident, and it now constrains what the investigation can prove.

MailItemsAccessed only captures Outlook Web Access. The attacker used a Graph API application to read email, which appears in a different log.

Incorrect.

MailItemsAccessed captures email access across all clients, including Graph API applications, Outlook desktop, OWA, and mobile apps. That's what makes it valuable for investigation — it captures programmatic access by OAuth applications, which is how attackers typically read email at scale.

Scenario 2. A sign-in record for a compromised account shows: ResultType: 0 (success), MFA: satisfied, ConditionalAccessStatus: success, RiskLevelDuringSignIn: none. Based on this record alone, can you determine whether this sign-in is legitimate or an AiTM token replay?

Yes — MFA satisfied and risk level "none" confirm this is a legitimate sign-in.

Incorrect.

AiTM token replay produces exactly this record. The attacker replays a stolen session token that already has a valid MFA claim embedded. Entra ID sees a valid token with MFA satisfied and evaluates it as legitimate. The risk level shows "none" because the token replay doesn't trigger Identity Protection's default risk detections.

No — an AiTM token replay produces an identical record: MFA satisfied, CA passed, risk none. The only indicators are the IP address and location compared to the user's normal pattern, and whether the AuthenticationDetails show "Previously satisfied" for the MFA claim.

Correct.

This is why AiTM is the dominant M365 attack technique. The sign-in record looks legitimate on every field except the IP/location context. An analyst who checks only "was MFA satisfied?" misses the compromise entirely. Module 5 teaches how to identify AiTM replays by examining the AuthenticationDetails field and correlating IP addresses against the user's baseline.

No — you need to check whether the user actually completed MFA at that time by reviewing the MFA service logs separately.

Partially correct but not the primary method.

MFA service logs can provide additional context, but the primary AiTM indicator is in the sign-in record itself: the AuthenticationDetails field shows whether MFA was completed in this session ("MFA requirement satisfied by claim in the token") or replayed from a prior session ("Previously satisfied"). The sign-in record is the first evidence source, not the MFA service logs.

Yes — if Conditional Access passed, the sign-in met all policy requirements. An attacker's token wouldn't pass CA evaluation.

Incorrect.

Conditional Access evaluates the token's claims, not the token's origin. A replayed token with a valid MFA claim passes CA policies that require MFA — because the MFA claim is present and valid. Only CA policies requiring phishing-resistant authentication methods (FIDO2, Windows Hello for Business) or compliant/managed devices would block an AiTM token replay.

Scenario 3. Your IR team resets a compromised user's password, revokes all sessions, and removes the inbox rules the attacker created. 72 hours later, MailItemsAccessed shows the attacker is reading the user's email again. How is this possible?

The password reset didn't propagate properly. Re-run the reset.

Incorrect.

Password resets propagate within minutes in Entra ID. If the attacker is reading email 72 hours later, the access channel is not password-based. The attacker is using a different authentication method entirely.

The attacker phished the user again and obtained new credentials.

Possible but unlikely to be the primary explanation.

Re-compromise is possible, but the more likely explanation for email access resuming exactly after containment is a persistence mechanism that the containment actions didn't address.

The session revocation has a propagation delay of up to 72 hours for cached tokens.

Incorrect.

Session revocation takes effect within approximately one hour for most token types. A 72-hour delay isn't a propagation issue — it's a different access channel the attacker is using.

The attacker consented to an OAuth application with Mail.Read permissions during the initial compromise. The application authenticates with its own credentials (a client secret), not the user's password or session. Password resets and session revocations don't affect OAuth application access.

Correct.

This is the persistence gap. OAuth consent grants and service principal credentials operate independently of the user account. The containment checklist must include auditing and revoking OAuth consents, not just resetting passwords and revoking sessions. Module 6 teaches the complete multi-channel containment methodology that addresses every persistence tier.

Scenario 4. Your SOC confirms at 14:00 UTC that a compromised account accessed emails containing salary data for 200 employees in the UK. Your CISO asks: "When does the GDPR notification clock start?" What's your answer?

The clock started at 14:00 UTC when you confirmed the compromised account accessed personal data. The 72-hour deadline for GDPR Article 33 notification is now running. File the initial notification by 14:00 UTC Saturday at the latest.

Correct.

GDPR Article 33 requires notification "without undue delay and, where feasible, not later than 72 hours after having become aware." Awareness is when you have a reasonable degree of certainty that personal data was compromised. Confirming that a compromised account accessed salary data for 200 UK employees crosses that threshold. The 72 hours runs from 14:00 UTC today.

The clock hasn't started yet. GDPR awareness requires a completed investigation that determines the full scope of affected individuals. We know 200 employees so far, but the number may change.

Incorrect.

GDPR does not require a completed investigation before awareness. Supervisory authorities have consistently held that organizations cannot delay awareness by failing to investigate promptly. Article 33(4) explicitly allows phased notification — submit what you know now and supplement as the investigation progresses.

The clock started when the SOC first detected the compromised account, even before confirming personal data access.

Arguably earlier, but the confirmed access is the clearer trigger.

The initial detection of a compromised account might constitute awareness if the account had obvious access to personal data. In practice, the confirmation that personal data was actually accessed (salary data for 200 employees) is the unambiguous trigger. Either way, the clock is running by 14:00 UTC.

GDPR doesn't apply because the salary data belongs to employees, not customers. Employee data is covered by employment law, not data protection law.

Incorrect.

GDPR applies to all personal data processing, including employee data. Salary information is personal data. A breach affecting employee personal data triggers the same Article 33 notification obligation as a breach affecting customer data.

Scenario 5. You're reviewing a colleague's IR investigation. They queried SigninLogs for the compromised user and found sign-ins from a suspicious IP address. They then immediately reset the user's password and revoked all sessions. What's wrong with this sequence?

Nothing — fast containment is always the right priority. The faster you revoke access, the less damage the attacker can do.

Incorrect.

Speed matters, but sequence matters more. In M365, containment actions can destroy evidence that hasn't been preserved yet. The sequence of actions has consequences.

They should have notified legal counsel before taking any containment action.

Legal notification should happen early but shouldn't delay containment.

Legal counsel should be notified as early as possible, but waiting for legal before revoking access to an actively compromised account adds unnecessary risk. The sequence issue is about evidence preservation, not legal notification.

They skipped evidence preservation. Before resetting the password and revoking sessions, they should have exported the sign-in logs, placed litigation holds on the mailbox, and preserved the current state of inbox rules and OAuth consents. Containment actions modify the environment, and some evidence may be lost if not preserved first.

Correct.

In M365, the correct sequence is Detect → Preserve → Contain → Investigate. Resetting a password before exporting sign-in logs doesn't destroy the logs, but revoking OAuth consents before documenting which apps had access, or removing inbox rules before capturing the rule configuration, loses evidence the investigation needs. The emergency CA policy (blocking sign-ins from non-corporate IPs) is the containment action that stops the attacker without modifying the evidence state.

They should have investigated the full scope of the compromise before taking any containment action.

Incorrect.

Waiting for a complete investigation before any containment is the opposite extreme. The attacker remains active while you investigate. The correct approach: preserve evidence, deploy the emergency CA (which stops the attacker without modifying evidence), and then investigate with the attacker locked out.

Scenario 6. Your organization has Defender XDR licensed with all components enabled. The CISO states that the organization's detection capability is "fully operational." What question would you ask to verify this claim?

"Are all Defender XDR licenses assigned to users?" — Licensing gaps mean some users aren't covered.

Valid but not the most revealing question.

License assignment matters, but fully licensed doesn't mean fully operational. The question doesn't address whether anyone is actually monitoring what the licensed tools produce.

"When was the last time a SOC analyst reviewed and acted on a Defender XDR alert?" — Detection tooling that nobody monitors is a logging system, not a detection capability. Licensed and enabled is not the same as operational.

Correct.

This question tests whether the detection capability is operational, not just deployed. An organization with every Defender component licensed, enabled, and generating alerts — but no SOC analyst reviewing those alerts — has zero detection capability despite having full tooling. The shared responsibility model means Microsoft provides the detection tools. Making them operational (monitoring, reviewing, acting) is the organization's responsibility.

"Which MITRE ATT&CK techniques are covered by your analytics rules?" — Coverage gaps mean some attacks won't be detected.

Good question, but assumes the basics are operational.

ATT&CK coverage is important for maturing the detection program, but it assumes someone is monitoring the alerts the existing rules produce. If the basic operational question (is anyone reviewing alerts?) hasn't been answered, coverage optimization is premature.

"What's your Microsoft Secure Score?" — Secure Score measures the security posture including detection configuration.

Incorrect.

Secure Score measures configuration against Microsoft's recommended settings. A high Secure Score indicates that many recommended settings are configured, but it doesn't measure whether the resulting detections are being monitored. A tenant with a 90% Secure Score and no SOC has excellent configuration and no detection capability.

Scenario 7. You run the KQL query from IR1.5 against your tenant's SigninLogs for the past 24 hours. The results show 15 successful sign-ins from a single IP address across 12 different user accounts. The IP belongs to a residential ISP in a city where your organization has an office. Is this suspicious?

Yes — 12 accounts from the same IP is a clear indicator of password spray or credential stuffing.

Possibly, but not enough context to conclude.

Multiple accounts from the same IP could indicate an attack, but it could also be a legitimate scenario. The IP is from a residential ISP in a city where the organization has an office — not from a VPS or hosting provider.

No — the sign-ins were successful, which means MFA was satisfied. Credential spray attacks produce failed sign-ins.

Incorrect.

Successful sign-ins from multiple accounts on the same IP deserve investigation regardless. If the credentials were obtained through an infostealer (pre-compromised, with valid passwords and session tokens), the attacks would show as successful, not failed.

Yes — immediately deploy the emergency CA policy to block all sign-ins from this IP.

Premature without investigation.

Blocking a residential ISP IP without investigation could block legitimate users. The IP is in a city with an office — this could be a shared network (coffee shop, coworking space) that multiple employees use. Investigate first, contain if confirmed.

It warrants investigation but isn't conclusive either way. Check whether the 12 accounts are employees in the office city (legitimate shared network) or scattered across departments with no reason to share an IP. Check the sign-in times — did all 15 sign-ins happen within minutes (more suspicious) or spread across the day (more likely legitimate)?

Correct.

Context determines whether this is an anomaly or normal behaviour. Multiple accounts from a residential IP in an office city could be employees at a coffee shop, a coworking space, or a home office on a shared ISP. The investigation looks at timing (clustered vs spread), user roles (related or unrelated), and whether this IP has appeared before. This is the analyst reasoning that Module 4 formalizes into a triage methodology.

Scenario 8. A publicly listed UK company with US operations discovers that an AiTM phishing attack compromised an executive's M365 account. The attacker accessed email containing employee salary data (UK staff), customer contract terms (US clients), and board meeting minutes discussing a pending acquisition. Which regulatory frameworks apply?

GDPR (UK employee personal data), potentially SEC (material incident at a public company — the pending acquisition information may affect materiality assessment), and potentially state-level US breach notification laws (US customer data). Multiple frameworks apply simultaneously with different deadlines and different notification content.

Correct.

This scenario triggers overlapping obligations: GDPR for the UK employee salary data (72-hour notification), SEC disclosure if the executive account compromise is deemed material (the acquisition information adds materiality weight — 4 business days after determination), and US state breach notification laws for the customer contract data (varies by state, typically 30-60 days). If the company is an essential entity under NIS2, that adds a 24-hour early warning. Module 8 teaches how to manage these overlapping obligations.

Only GDPR — the company is UK-based so UK data protection law applies. SEC and US state laws only apply to US-headquartered companies.

Incorrect.

The company has US operations and is publicly listed (potentially on a US exchange). SEC disclosure rules apply to companies registered under the Securities Exchange Act regardless of headquarters location. US state breach notification laws apply based on where the affected individuals reside, not where the company is based.

Only SEC — the pending acquisition information makes this a material event. GDPR doesn't apply to executive email access.

Incorrect.

GDPR applies whenever personal data of EEA/UK individuals is compromised, regardless of whose mailbox it was in. The salary data for UK employees is personal data under GDPR. The executive's account being compromised is the breach event — the data it contained determines which notification obligations trigger.

No regulatory notification is required. The attacker accessed email but didn't exfiltrate data — reading email is not a breach.

Incorrect.

Under GDPR, unauthorized access to personal data constitutes a personal data breach, regardless of whether the data was exfiltrated. The attacker reading emails containing salary data is unauthorized access to personal data. The breach occurred at access, not at exfiltration.

💬

How was this module?

Your feedback helps us improve the course. One click is enough — comments are optional.

Thank you — your feedback has been received.

You've finished the free tier. The investigation starts now.

IR0 established the incident shape — how Microsoft-stack attacks cross the cloud-endpoint boundary in minutes — and gave you the five-step reasoning chain and three-statement evidence discipline that every subsequent module applies. IR0 also covered the current NIST SP 800-61 Rev 3 / CSF 2.0 vocabulary for the reports you will write. IR1 got your forensic workstation built: KAPE, the Eric Zimmerman Tools suite, Velociraptor, Volatility 3, and the Microsoft 365 investigation stack installed, validated, and ready. From here, every module applies the reasoning chain against real evidence.

Phase 2 — Windows Endpoint Forensics (IR2–IR7) — evidence acquisition and chain of custody, execution and persistence artefacts, filesystem and registry forensics, event log analysis, memory forensics with Volatility 3, lateral movement and credential theft
Phase 3 — Microsoft 365 Cloud Investigation (IR8–IR12) — identity compromise, Exchange Online and email forensics, SharePoint/OneDrive/Teams investigation, Entra ID persistence, Defender XDR as the unified investigation platform
Phase 4 — Investigation Scenarios (IR13–IR16) — ransomware, business email compromise, insider threat, and advanced persistent threat. Each a complete worked investigation integrating Phase 2 and Phase 3 skills
Phase 5 — Reporting, Readiness, and Capstone (IR17–IR19) — technical and executive reporting, regulatory notifications under current law (GDPR, NIS2, SEC), IR readiness building, and the IR19 end-to-end capstone investigation
Worked practical content throughout — every content subsection contains annotated KQL queries, walked-through tool output, real artefact data with interpretation, and procedures you run yourself

Unlock the Full Course See Course Agenda

← Previous Next →