Real-World Identity Breaches

Introduction

Three breaches, each publicly documented, and each prevented by a control this course covers. This section is what they have in common. You will finish able to name the control that would have stopped each, and to recognize that none of the three needed a vulnerability.

Three cases, and the same absence in each.

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.

1. 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.
2. 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.
3. 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 (ARC406) 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 (ARC406) 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.

Read the right-hand column rather than the dates. Every action was logged, in a table this course teaches you to query, and no detection rule existed to read any of it.

Nineteen days of authorized activity, and the record of it was complete throughout.

Four steps, and the second column is the one to read.

Spray a legacy protocol. Needed an account exempt from MFA and a protocol that bypasses Conditional Access, per ei02. Stopped by blocking legacy authentication, which is a configuration change.

Land on an account nobody watched. Needed a non-production account, which is exactly what an exemption group produces. Stopped by the same policy applied to the same population.

Grant an OAuth application high privilege. Needed consent to be permitted, per ei09. Stopped by restricting user consent and an admin consent workflow.

Use the application rather than the account. Needed nothing further, because the account was no longer relevant, so securing it changed nothing at all.

No exploit at any step. Four configuration decisions, each defensible on its own.

Step four is what makes this case worth studying rather than reading. Once the grant existed the compromised account stopped mattering, so every response aimed at that account was aimed at something the attacker had already stopped using.

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 (ARC406) would have detected the forwarding rule within minutes rather than days. Any one of these controls would have broken the chain.

The third case removes the password from the story altogether.

The attacker stood a proxy between the user and the real sign-in page, per 0.4. The user authenticated correctly, MFA completed, and the session was captured.

What the log showed was a successful sign-in with MFA satisfied. No failure, no denial, nothing to triage. Per 0.2 the token carries the decision, so a replay looks like that decision being honored.

What MFA contributed is the finding rather than the failure: it worked. Push and code methods verify the user and do not bind the session to the origin, so completing them correctly hands over a replayable token.

Phishing-resistant methods would have stopped it, per ei02, because the credential is bound to the origin and a proxy on another domain cannot complete the ceremony. Token protection and device binding close it from the other side, per ei07.

  ResultType                 0, success
  AuthenticationRequirement  multiFactorAuthentication
  ConditionalAccessStatus    success
  RiskLevelDuringSignIn      none
  authenticationMethod       Microsoft Authenticator, push
  [not in the record]        that a proxy relayed it

Only the fifth row carries the finding, and only if you know to read it. Per 1.4 the requirement field says multi-factor and is correct; the method one level down says push, and push verifies a user without binding a session.

"We had MFA" is true here and irrelevant.

The distinction in that last line is the one to carry into any conversation about this class of incident. MFA was present, satisfied and correctly recorded, so what failed was the choice of method rather than MFA, and those are different budget lines.

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 (ARC406) would have detected the new application authentication. Workload identity Conditional Access (ARC406) 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.

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.

Five properties, and none of them involves anything going wrong.

No vulnerability was exploited. No CVE, no unpatched system, no zero day. Every step used a documented feature exactly as designed.

Every step was authorized. The platform agreed at every point, so per 0.3 each link handed the next a fact that was true. Nothing malfunctioned and nothing was denied.

The entry point was a configuration decision: legacy auth left open, consent left permitted, a weaker MFA method chosen. Each defensible in isolation, and none of them a mistake anybody would be blamed for.

The persistence outlived the response. Per 0.5 a consent grant and a registered method survive reset and revocation, so securing the account did not end the access.

And all of it was fully logged. The evidence existed in Entra ID throughout. Per 0.1, what was missing was a query rather than a log.

  No vulnerability exploited     documented features, as designed
  Every step authorized          the platform agreed throughout
  Entry was a configuration      each decision defensible alone
  Persistence outlived response  reset and revoke removed none
  All of it fully logged         what was missing was a query

Five properties, zero exploits. That is what an identity breach looks like. Configuration and queries are what answer it, which is why neither patching nor a vulnerability scanner appears anywhere in the modules that follow.

The last property is the one that should change what you do on Monday. In all three cases the telemetry was present and complete, so the gap was never visibility, and an estate with the same logs and the same absence of queries has the same exposure without even the warning a missing log would give.

Each case reduces to one question about your configuration, and all three are answerable today.

Three publicly documented breaches, and none exploited a vulnerability. Every step used a documented feature as designed and every step was authorized, so nothing malfunctioned and nothing was denied. In each case the entry point was a configuration decision defensible in isolation: legacy authentication left open, consent left permitted, a weaker MFA method chosen. In two of the three the persistence outlived the response, because a consent grant and a registered authentication method survive both a password reset and a session revocation. And all three were fully logged in Entra ID throughout, which means the gap was never visibility. What was missing was a query.