Real-World Identity Breaches

Case 1: Midnight Blizzard — password spray to executive mailbox access

In January 2024, Microsoft disclosed that Midnight Blizzard (APT29, the Russian state-sponsored group behind the SolarWinds attack) had been inside Microsoft's corporate environment since November 2023. The attack chain demonstrates how a single unprotected identity leads to enterprise-wide compromise.

Stage 1 — Reconnaissance: Midnight Blizzard identified a legacy, non-production test tenant within Microsoft's environment. Test tenants are common in large organizations — developers create them for application testing, proof-of-concept projects, and training. They are often forgotten, unmonitored, and exempt from production security policies.

Stage 2 — Initial access: The group used password spray to compromise an administrator account in the test tenant. The account had a weak, guessable password. It did not have MFA enabled. Microsoft's own post-incident analysis confirmed that if the account had existed under current policy, mandatory MFA and active protections would have prevented the initial compromise. One unprotected account was enough.

Stage 3 — Persistence and escalation through OAuth: With access to the test tenant admin account, the attackers identified a legacy OAuth application that had been created for testing purposes and subsequently installed in Microsoft's corporate production tenant with elevated permissions — likely Directory.ReadWrite.All, which grants the ability to create users and assign roles. This application had been dormant and possibly forgotten — a common pattern in enterprise tenants where hundreds of application registrations accumulate without lifecycle management.

The attackers added new credentials to this dormant OAuth application, then authenticated as the application using those credentials. Because the application already had elevated permissions in the production tenant, they didn't need to request new permissions or trigger any consent flow. They created a new user account in the corporate tenant and used that account to grant consent to additional attacker-controlled OAuth applications — building redundant access paths so that discovering and removing one application wouldn't eliminate their access.

Stage 4 — Data exfiltration: The malicious OAuth applications were granted the full_access_as_app role for Office 365 Exchange Online — an EWS permission that provides unrestricted access to every mailbox in the organization. The attackers accessed email accounts of Microsoft's senior leadership, security team, and legal team. They specifically targeted communications related to Midnight Blizzard itself, extracting intelligence about what Microsoft knew about the group's operations and techniques. The breach went undetected for over two months — from late November 2023 until January 12, 2024. Residential proxy networks masked the source of the access, making the traffic appear to originate from legitimate IP addresses.

What this course teaches that would have stopped it: MFA on the test tenant account (EI2) would have prevented initial access entirely — password spray succeeds only against accounts without MFA or with weak, guessable credentials. Application permission reviews and lifecycle management (EI9) would have identified the dormant OAuth application with elevated production access long before the attackers found it — a quarterly review of application registrations with Directory.ReadWrite.All would have flagged it immediately. Consent governance through admin consent workflow (EI9) would have required administrator approval before any new application received elevated permissions. Service principal credential monitoring (EI13) would have detected the new credentials added to the legacy application — the audit log event Add service principal credentials is the exact detection point. Monitoring for full_access_as_app permission grants (EI13) would have caught the final escalation. Microsoft's own post-incident analysis concluded that mandatory policy and workflows would have prevented the initial compromise if the legacy tenant existed under current standards.

Case 2: AiTM to BEC — the wire fraud that bypassed MFA

This composite case study reflects a pattern observed across hundreds of production M365 environments — the AiTM-to-BEC pipeline that turns a single phishing click into financial fraud.

Organization: A mid-size professional services firm. 400 users, M365 E3 licensing, Entra ID P1. Conditional Access requires MFA for all users via push notification. No device compliance requirements. No token protection. User consent for applications is allowed.

Stage 2 — Initial access: A senior partner receives an email that appears to be a shared document from a client. The link leads to an EvilProxy phishing kit — an AiTM proxy presenting a pixel-perfect Microsoft sign-in page. The partner enters credentials. The proxy forwards them to Entra ID. MFA challenges, the partner approves the Authenticator push notification. The proxy captures the session token. The attacker replays it from a VPN exit node in the same country. Conditional Access evaluates: MFA satisfied, location acceptable, no device compliance required. Access granted.

Stage 3 — Persistence: Within 15 minutes, the attacker creates an inbox rule forwarding all emails from a specific vendor domain to an external address, marking them as read. The partner sees no indication of the rule — inbox rules operate silently on incoming mail.

Stage 6 — Impact: The attacker reads the partner's email history, identifies an active vendor payment for $47,000 due within three days, and replies to the payment thread requesting updated bank details. The email comes from the partner's real account within the real conversation thread — the vendor has no reason to suspect it's fraudulent. The vendor's accounts payable team processes the updated bank details. The payment goes to the attacker's account. Discovery happens four days later when the vendor contacts the firm about a separate invoice.

The sign-in log recorded every step — the initial token replay showed a different device ID and IP address than the partner's normal device, Identity Protection flagged the sign-in as medium risk, and the audit log recorded the inbox rule creation. But no one was looking. The firm had no Sentinel workspace, no analytics rules, and no monitoring for inbox rule creation events. Every piece of evidence existed — but the detection capability didn't.

What this course teaches that would have stopped it: Phishing-resistant authentication (EI2) would have prevented the AiTM proxy from capturing a usable credential — FIDO2 keys cryptographically reject proxy domains. Token protection (EI7) would have bound the session token to the partner's device, making replay fail. Device compliance requirement (EI4) would have blocked the attacker's unmanaged device. Blocking user consent (EI9) would have prevented any OAuth persistence. Inbox rule creation monitoring (EI13) would have detected the forwarding rule within minutes rather than days. Any one of these controls would have broken the chain.

Case 3: Consent phishing — the invisible supply chain compromise

This case study reflects the growing pattern of OAuth consent phishing that provides persistent, MFA-independent access to organizational data.

Organization: A healthcare technology company. 200 users, M365 E5 licensing, strong Conditional Access policies. MFA required for all users. Device compliance enforced. Risk-based policies enabled. By most assessments, a well-secured environment.

Stage 2 — Initial access: An HR manager receives an email appearing to be from a trusted benefits administration vendor. The email includes a link to "complete annual benefits enrollment." The link triggers an OAuth consent prompt for an application called "BenefitsConnect HR Portal." The application requests Mail.Read, Files.Read.All, and User.Read permissions. The consent dialog looks identical to legitimate Microsoft prompts. The HR manager clicks "Accept."

Stage 3 — Persistence: The malicious application now has an independent identity with its own client credentials. It authenticates through the client credential flow — it never uses the HR manager's password or session token. The permissions are granted to the application, not to the user. Resetting the HR manager's password doesn't affect the application's access. Revoking the HR manager's sessions doesn't affect the application's access. Requiring MFA doesn't affect the application's authentication. The Conditional Access policies that protect user sign-ins don't evaluate application authentication unless Workload Identities Premium licensing is in place with corresponding workload identity policies.

This is what makes consent phishing entirely different from credential theft. The attacker doesn't need to maintain access through the compromised user — they have their own identity, their own credentials, and their own access path. The only remediation is explicitly revoking the consent grant in the Enterprise Applications blade and deleting the application registration.

Stage 5 — Data exfiltration: The application reads the HR manager's email and SharePoint files through Microsoft Graph. It identifies employee health insurance records, salary data, and social security numbers stored in a benefits administration SharePoint site. The data is exfiltrated through normal Graph API calls that appear identical to legitimate application traffic.

Why detection failed: The organization's SOC monitors interactive sign-in logs for anomalous user activity — unusual locations, impossible travel, risk-flagged sign-ins. But application authentication doesn't appear in the interactive sign-in logs. It appears in the service principal sign-in logs (AADServicePrincipalSignInLogs), which the SOC wasn't monitoring and hadn't routed to Sentinel. The Graph API data access appears in the unified audit log, but the SOC had no detection rules for unusual application data access patterns — no baseline for what "normal" application behavior looked like, no alerting on first-time application access to sensitive SharePoint sites.

The breach continued for 6 weeks before a routine application permission audit discovered the unauthorized consent grant. During those 6 weeks, the application made thousands of Graph API calls, accessed hundreds of files, and read email from the HR manager's mailbox daily. Every one of those calls was logged. Every one was available for detection. The monitoring gap wasn't a technology limitation — it was a coverage gap. The organization protected the front door (user sign-ins) but left the service entrance (application authentication) unmonitored.

What this course teaches that would have stopped it: Blocking user consent entirely (EI9) would have prevented the consent grant — the prompt would have told the HR manager to request admin approval. Admin consent workflow (EI9) would have required a security-aware administrator to evaluate the permissions before granting them. Service principal sign-in log monitoring (EI13) would have detected the new application authentication. Workload identity Conditional Access (EI10) would have applied access policies to the application. Application governance in Defender for Cloud Apps would have flagged the new application's data access patterns.

// Detect high-privilege application consent grants
// This is the pattern that enabled both Midnight Blizzard and consent phishing
AuditLogs
| where TimeGenerated > ago(7d)
| where OperationName == "Consent to application"
| extend ConsentedPermissions = tostring(TargetResources[0].modifiedProperties)
| where ConsentedPermissions has_any ("Mail.Read", "Mail.ReadWrite", "Files.ReadWrite.All",
    "Directory.ReadWrite.All", "full_access_as_app")
| extend ConsentingUser = tostring(InitiatedBy.user.userPrincipalName)
| extend AppName = tostring(TargetResources[0].displayName)
| project TimeGenerated, ConsentingUser, AppName, ConsentedPermissions
// Any results require immediate investigation
// High-privilege consent grants are the persistence mechanism in both attack types

This query detects the exact pattern that enabled both Midnight Blizzard (OAuth application granted full_access_as_app) and the consent phishing attack (application granted Mail.Read and Files.ReadWrite.All). Any result from this query should trigger an immediate investigation: verify that the consenting user intended to grant the permission, that the application is legitimate and publisher-verified, and that the permissions are appropriate for the application's stated purpose.

The common thread

All three breaches share the same structural failure: implicit trust in identities that should have been explicitly verified. And all three demonstrate that the controls needed to prevent them are not exotic — they are the standard configurations taught in this course.

Midnight Blizzard exploited implicit trust in a test tenant account (no MFA required), implicit trust in a dormant application (no permission review or lifecycle management), and implicit trust in application consent (no governance workflow). The organization had sophisticated security in production but a gap in a test environment that provided a bridge to production.

The AiTM breach exploited implicit trust in a phishable MFA method (push notification accepted anything), implicit trust in the network (no device compliance requirement meant unmanaged devices could access corporate data), and implicit trust in mailbox activity (no monitoring for inbox rule creation). The organization had "MFA enabled for all users" — which looked complete on a compliance report but failed against the specific attack technique.

The consent phishing attack exploited implicit trust in user consent decisions (any user could grant any permission to any application), implicit trust in application authentication (no Conditional Access for workload identities), and implicit trust in application data access (service principal sign-in logs weren't monitored). The organization had strong user authentication policies but no controls on non-human identities.

Zero Trust, applied systematically through the controls in this course, eliminates each of these implicit trust assumptions. That is not theoretical — it is the specific, verifiable difference between the organizations that get breached and the organizations that don't.