The M365 Threat Landscape

The attackers adapted

Five years ago, a phishing email with a malicious attachment would trigger multiple detection layers: email gateway, endpoint antivirus, behavioral EDR, and SIEM correlation. An attacker who relied on basic credential phishing or commodity malware faced a stack of automated defenses that caught the attempt before it succeeded or detected it within minutes. Detection engineering got better. So the attackers changed.

Techniques dominating the current M365 threat landscape are not the ones that detection engineering was built to stop. They are the ones specifically engineered to bypass it. Each technique category maps to a structural limitation from Section 0.2 and to the hunt campaigns that address it later in this course.

A typical M365 BEC attack chain. The phishing alert fires at Stage 1. The four post-compromise stages operate in the detection gap, each using a different M365 service and logging to a different table.

AiTM session hijacking: the defining technique

Adversary-in-the-middle phishing is the dominant M365 attack technique of 2024–2026. The attacker hosts a reverse proxy (Tycoon2FA, EvilGinx, or a custom framework) between the user and the real Microsoft login page. The user sees the legitimate page, enters credentials, completes MFA, and receives a session token. That proxy captures the token in transit. Tycoon2FA's effectiveness came from closely mimicking legitimate authentication processes while intercepting both credentials and session tokens, enabling bypass of nearly all commonly deployed MFA methods including SMS codes, one-time passcodes, and push notifications.

Scale alone makes the case. In October 2025, Microsoft Defender for Office 365 blocked over 13 million malicious emails linked to Tycoon2FA alone. Between April 14 and 16, 2026, Microsoft observed a three-day "code of conduct" phishing campaign targeting more than 35,000 users across over 13,000 organizations in 26 countries. Healthcare and life sciences were the most targeted sector at 19%, followed by financial services at 18%. Campaign emails were disguised as internal compliance notifications, not traditional spam, which made them harder for content-based email rules to catch. Russian-linked actors have been using device-join phishing since April 2025, tricking targets into authorizing domain-join of an attacker-controlled device. Phishing-as-a-service platforms have industrialized AiTM. Storm-1747 (Tycoon2FA's operator) leases infrastructure and sells ready-made kits that impersonate enterprise login pages with custom branding pulled from the target's own Entra ID configuration.

In parallel, device-code phishing has emerged as an AI-assisted social engineering variant. Microsoft reported in April 2026 that attackers are combining AI-generated lures with device-code authentication flows, where the victim is tricked into entering a code on a legitimate Microsoft device authorisation page. Stolen tokens were used for email exfiltration and persistence through the creation of malicious inbox rules, while attackers simultaneously conducted Graph API reconnaissance to map organizational structure and permissions.

Why detection rules struggle. The sign-in that uses the stolen token is technically valid. The token has the correct MFA claim. If the attacker routes through a residential proxy in the same geography as the user, even the location looks plausible. Microsoft's Identity Protection generates risk detections for some AiTM patterns (anomalousToken, tokenIssuerAnomaly) but these are probabilistic. They catch some variants and miss others. The variants they miss require hunting: looking for authentication patterns where non-interactive token refreshes originate from IPs that do not match any recent interactive sign-in for that user. TH4 (Hunting Identity Compromise) covers this as a full hunt campaign.

Living-off-the-cloud

Just as living-off-the-land describes attackers using legitimate system binaries on endpoints, living-off-the-cloud describes attackers using legitimate M365 and Azure services for attack objectives. SharePoint for staging and exfiltration. OneDrive for file transfer. Teams for internal phishing. Power Automate for automated data collection. Microsoft Graph API for organizational reconnaissance.

Storm-2949, disclosed by Microsoft in May 2026, is the most instructive recent example, disclosed by Microsoft in May 2026. Storm-2949 compromised privileged accounts (IT personnel, administrators, and senior leadership) through social engineering that abused Microsoft's Self-Service Password Reset process. Once inside, Storm-2949 did not deploy malware. Instead, they used Graph API to map users, groups, and permissions. They accessed OneDrive and SharePoint to download thousands of files in a single action, targeting IT documents related to VPN configurations and remote access procedures. They escalated through Azure RBAC permissions to reach Key Vaults, storage accounts, SQL databases, and production web applications, all through legitimate Azure management features. Operations spanned SaaS, PaaS, and IaaS layers. Every action they took was a standard administrative operation.

Why detection rules struggle: the traffic goes to Microsoft-owned domains. The API calls use standard Graph API endpoints. The authentication is a valid user session. Every individual operation (uploading a file, querying Key Vault, creating a Power Automate flow) is a normal business operation performed by thousands of legitimate users every day. The distinction between legitimate use and attacker abuse is not in the operation itself but in the pattern: who is performing it, when, in what sequence, at what volume, and against what baseline. Pattern analysis at that level of contextual depth is hunting, not rule matching.

// Threat landscape check: user-consented high-privilege applications
// Each result is a potential OAuth persistence mechanism
AuditLogs
| where TimeGenerated > ago(90d)
| where OperationName == "Consent to application"
| where Result == "success"
| extend ConsentedBy = tostring(InitiatedBy.user.userPrincipalName)
| extend AppName = tostring(TargetResources[0].displayName)
| extend Permissions = tostring(
    TargetResources[0].modifiedProperties)
| where Permissions has_any (
    "Mail.ReadWrite", "Files.ReadWrite.All",
    "Mail.Send", "Directory.ReadWrite.All")
| project TimeGenerated, ConsentedBy, AppName, Permissions
| sort by TimeGenerated desc

If this returns results, you have user-consented applications with permissions sufficient to read all email, access all files, or send messages on behalf of users. Some will be legitimate productivity tools your organization has approved. Some may be consent phishing. Applications that obtained access through social engineering now have persistent, password-reset-surviving access to corporate data. TH6 (Hunting Application Compromise) teaches you to distinguish between the two.

OAuth and application-layer persistence

OAuth application abuse has become the preferred persistence mechanism for sophisticated M365 attackers. The attacker, through consent phishing or compromised admin credentials, grants an application access to mailbox data, files, or directory information. OAuth applications authenticate with their own credentials (client secret or certificate), independent of any user's password or MFA configuration. This access survives password resets. It survives session revocation. It survives MFA re-enrollment. It survives conditional access policy changes unless the policy specifically restricts application access.

Microsoft has observed campaigns where attackers combine OAuth consent phishing with AiTM as a fallback: even if the user declines the consent prompt, the redirect sends them to an AiTM domain for a second phishing attempt. Neither attack depends on a single technique succeeding. It chains two techniques so that blocking one still exposes the user to the other.

Why detection rules struggle: the OAuth consent event is a standard Entra ID operation. Thousands of legitimate applications are consented to in enterprise M365 tenants. A rule that alerts on every application consent generates unmanageable noise. A rule that alerts only on specific application names or permission scopes is evaded by the next campaign using a different name. The distinction between a legitimate productivity application and a malicious data exfiltration tool is the application's behavior after consent: what it accesses, how often, what data it reads. This requires monitoring over time, not a single-event rule.

Hybrid identity and cross-plane exploitation

Organizations running hybrid M365 environments (Azure AD Connect synchronizing between on-premises Active Directory and Entra ID) have an attack surface that spans both planes. An attacker with on-premises domain admin can compromise Azure AD Connect's synchronization account and escalate to cloud Global Admin. An attacker with cloud credentials can authenticate to the VPN through pass-through authentication and pivot to on-premises resources.

Storm-2949 demonstrated the cross-plane risk from the cloud side. After compromising identities through SSPR abuse, the threat actor used privileged Azure RBAC permissions to pivot from Microsoft 365 into Azure infrastructure. They accessed VMs using the Run Command feature, attempted to steal managed identity tokens from the Azure Instance Metadata Service, and queried Key Vaults for production secrets. The lateral movement crossed from SaaS into PaaS and IaaS, spanning three different resource layers, three different log sources, three different monitoring teams.

Why detection rules struggle: cloud security teams monitor cloud logs. Infrastructure teams monitor on-premises logs. Azure operations teams monitor resource manager logs. The lateral movement between planes crosses monitoring boundaries. A sign-in anomaly in Entra ID followed by a VPN connection followed by Azure Resource Manager operations followed by VM Run Command execution is four events in four different data sources. Each is individually unremarkable, but collectively indicating a cross-boundary pivot. No single detection rule spans all four. Correlating across these sources requires a hunting campaign that joins SigninLogs, VPN logs, AzureActivity, and IdentityLogonEvents in a single investigation. TH10 (Hunting Lateral Movement) covers this.

Why the landscape demands hunting

A common thread runs across these technique categories: is that none of them involves exotic zero-day exploitation or novel malware. They are operationally sophisticated, not technically exotic. They use the victim's own infrastructure, the victim's own credentials, and the victim's own services to achieve their objectives. Storm-2949 stole data from OneDrive, SharePoint, Key Vaults, and SQL databases without ever deploying a payload. The April 2026 AiTM campaign hit 35,000 users with emails that looked like internal compliance notifications, not malicious attachments. Device-code phishing generates tokens from a legitimate Microsoft authentication page that the user interacts with voluntarily.

Convergence is also structural. These techniques are not used in isolation. They are chained. A single compromise can begin with AiTM token theft, pivot to OAuth consent for persistence, use Graph API for reconnaissance, and then cross into Azure infrastructure for data exfiltration. Each stage uses a different M365 service, generates logs in a different table, and appears unremarkable in isolation. The attacker who chains four legitimate operations across four services has created an attack sequence that no single-table detection rule can detect without generating thousands of false positives against normal administrative workflows.

What separates the attacker from the legitimate user is behavioral context: who is performing this action, in what sequence, compared to what baseline, and does the pattern match known attacker tradecraft. That contextual analysis is hunting. Detection rules match individual events against predefined patterns. Hunting correlates sequences of events across multiple data sources, applies business context that no rule can encode, and evaluates patterns that would generate unmanageable false positive rates as automated alerts. The M365 threat landscape has evolved to the point where the most dangerous techniques are specifically the ones that produce individual events indistinguishable from normal business operations. This detection gap is not accidental. It is engineered by the attacker.