M365 Attack Landscape: How Cloud Attacks Chain Together and Why Single-Technique Response Fails

The phishing alert that was three incidents

The SOC received a phishing alert: credential harvest email targeting finance. Standard triage — the analyst confirmed the recipient clicked the link, found a suspicious sign-in from an unfamiliar IP, reset the password, revoked sessions, and closed the ticket. Contained. Except the attacker had already used that compromised account to consent to an OAuth application with Mail.Read permissions. While the analyst was resetting the password, the application was silently reading every email in the finance director's mailbox and forwarding contract documents to an external endpoint. The attacker used the same session to create inbox rules on two other accounts (compromised through the same phishing campaign but not yet reported) that redirected emails containing "wire transfer" and "payment instructions" to an external address. Three weeks later, a vendor reported a fraudulent payment instruction that appeared to come from the finance director's mailbox. The IR team reopened the investigation and found three incidents running in parallel: the credential theft (contained), the OAuth data exfiltration (never detected), and the BEC financial fraud (still active).

The analyst treated the alert as a single-technique event. Phishing → credential theft → password reset → closed. But the attacker was executing a multi-stage campaign: initial access via phishing, persistence via OAuth consent, collection via inbox rules, and action on objective via BEC. Each stage operated through a different M365 service, produced evidence in a different log table, and required a different containment action. The password reset addressed one stage. The other three continued uninterrupted.

How M365 attacks chain together

M365 attacks follow a predictable progression. The specific techniques vary, but the structure is consistent: gain access, establish persistence that survives the inevitable password reset, collect or manipulate data, and achieve the objective. Understanding this structure is what separates a responder who investigates alerts from one who investigates incidents.

The progression maps to the MITRE ATT&CK framework's cloud matrix, but the practical value isn't in the taxonomy. It's in knowing what to look for at each stage and which M365 service produces the evidence.

Initial access gets the attacker into the tenant. Phishing, AiTM proxy attacks, password spray, device code phishing, and OAuth consent phishing are the primary vectors in M365. Each produces different evidence: phishing appears in EmailEvents, sign-in compromise appears in SigninLogs, OAuth consent appears in AuditLogs. The initial access vector determines which log table you check first, but it doesn't determine the scope of the incident. Initial access is the beginning, not the incident.

Persistence ensures the attacker survives your first containment attempt. In M365, persistence takes forms that don't exist on endpoints: OAuth application consent grants, service principal credentials, inbox forwarding rules, mailbox delegate permissions, federated identity provider trust manipulation. Module 6 cataloged seven persistence types. The attacker's persistence choices depend on the permissions the compromised account holds. A Global Admin can create service principals. A regular user can consent to OAuth applications (if consent policy allows) and create inbox rules. Both create persistence that survives password resets.

Privilege escalation expands what the attacker can do. In M365, this means role assignments (adding the compromised account to Exchange Admin, Security Admin, or Global Admin), Conditional Access policy modification (weakening MFA requirements for specific accounts), and PIM role activation if the compromised account has eligible assignments. Privilege escalation produces evidence in AuditLogs under the Directory category with operations like "Add member to role."

Collection is where the attacker gathers what they came for. Email access through MailItemsAccessed, file downloads through FileDownloaded and FileAccessed in OfficeActivity, SharePoint enumeration through search queries. The collection phase produces the most evidence and determines the data exposure scope that the investigation report needs.

Exfiltration and action on objective is the attacker's goal. BEC financial fraud, data theft, ransomware deployment, or persistent surveillance. The objective determines the business impact and the regulatory notification requirements.

M365 attack chain showing evidence sources at each stage. The alert fires at one stage. The investigation must cover all of them.

The attacker's decision tree

Understanding the attacker's choices at each stage helps you predict what evidence to look for. Not every attacker follows the same path, but the branching points are consistent because M365 constrains the options.

After initial access, the attacker evaluates the compromised account's permissions. A standard user gets one set of options. A Global Admin gets a different set. The attacker's first action after landing is almost always a permissions check: "What can this account do?" In M365, that check appears in AuditLogs as Graph API calls to retrieve role assignments, group memberships, and application permissions. Some attackers query the directory explicitly. Others probe by attempting actions and observing the results.

The decision tree branches on permissions:

Standard user (no admin roles). The attacker can consent to OAuth applications (if the tenant's consent policy allows user consent), create inbox rules, set mailbox forwarding, and access the user's email, OneDrive, and SharePoint sites. The attacker's objectives are typically email surveillance, file exfiltration, or using the compromised mailbox for BEC. Persistence options are limited to OAuth apps, inbox rules, and forwarding.

Exchange Admin or Mail-related roles. The attacker can create transport rules that affect the entire organization, modify mail flow connectors, and access any mailbox through administrative delegation. The scope expands from one mailbox to every mailbox. Transport rules are particularly dangerous because they operate at the organization level and survive individual account remediation.

Global Admin or Privileged Role Admin. The attacker can assign any role to any account, create service principals with any permission, modify Conditional Access policies, add federated identity providers, and effectively own the tenant. The investigation scope expands to the entire directory. The attacker can disable security features, clear audit logs (within retention limits), and create hidden persistence that standard admin queries don't reveal.

Why playbooks are not standalone checklists

Each sub in this module covers a specific attack type: the techniques, the evidence, the investigation, and the containment. But these playbooks are not standalone procedures that replace Modules 4 through 6. They are attack-specific overlays on the universal methodology.

The investigation methodology from Module 4 (hypothesis-driven scoping, timeline construction, correlation) applies to every playbook. The evidence collection techniques from Module 5 (sign-in analysis, inbox rule forensics, file access forensics, timeline assembly) are the evidence sources every playbook references. The containment sequence from Module 6 (emergency CA → session revocation → password reset → application remediation → verification) is the containment framework every playbook uses.

What the playbooks add is context. When the alert says "possible BEC," the BEC playbook tells you which evidence to prioritize (MailItemsAccessed for email reading patterns, inbox rules for forwarding, transport rules for organization-wide redirection). When the alert says "consent grant to unknown application," the OAuth playbook tells you which AuditLogs operations to query and what application permissions are dangerous. The playbook narrows the universal methodology to the specific attack type so you're not running every query from Module 5 when only a subset applies.

The playbooks also connect attack types to regulatory and business consequences. A BEC incident with a confirmed fraudulent wire transfer has different notification requirements than an OAuth data exfiltration. A ransomware incident has different recovery procedures than an insider threat. The playbooks map each attack type to its specific business and compliance impact so the investigation report addresses the right questions.

How this module is structured

IR7.2 through IR7.5 cover the attack chain stages: initial access techniques (7.2 and 7.3), execution and persistence (7.4), and collection and exfiltration (7.5). These subs teach you to recognize, investigate, and contain the individual techniques that attackers use at each stage.

IR7.6 through IR7.9 cover the major incident types: BEC, ransomware, insider threat, and supply chain compromise. These subs combine techniques from multiple stages into complete response playbooks. A BEC incident involves initial access (phishing), persistence (inbox rules), collection (email surveillance), and action on objective (financial fraud). The BEC playbook teaches the end-to-end response, referencing the technique-specific details from IR7.2 through IR7.5.

IR7.10 covers multi-vector incidents where the attacker's activity spans multiple playbooks simultaneously. IR7.11 is the guided walkthrough: a multi-stage scenario where BEC escalates to ransomware and the student executes parallel playbooks under competing containment priorities.

Each technique sub and each playbook sub follows the same structure: attack overview → how it works in M365 → evidence and detection → investigation steps → containment actions → recovery and prevention. The structure is consistent so you can navigate any playbook under pressure. When the alert fires at 2 AM, you need to know exactly where to find the investigation steps for this attack type without reading the entire sub first.

IR7.2 starts with the most common initial access vector: phishing, AiTM, and credential attacks.