Attack Patterns You Will Defend Against

Attack-driven defense

This course is organized around attack techniques, not product features. You don't learn Conditional Access because it's a feature — you learn it because it stops specific attacks. Every module maps to one or more of the following seven patterns. When you understand the attack, the defense makes sense. When you don't, the defense feels like arbitrary configuration.

AiTM credential phishing

The adversary-in-the-middle attack is the most dangerous identity technique in production today because it defeats standard MFA. The attacker hosts a proxy server — typically using EvilGinx, Modlishka, or similar toolkits — that sits between the user and the real Entra ID sign-in page. The proxy presents a pixel-perfect copy of the Microsoft sign-in experience. The user enters their email address and password. The proxy forwards these credentials to the real Entra ID endpoint in real time. Entra ID challenges for MFA. The user completes MFA normally — they approve the push notification, enter the TOTP code, or tap their phone. The proxy captures the session cookie and access token that Entra ID returns after MFA completes.

The critical detail: the attacker never needs to defeat MFA. They let MFA complete successfully and capture what comes after it. The session token has already satisfied all authentication requirements. When the attacker replays it from their own device, Entra ID sees a valid token that has passed Conditional Access evaluation, password verification, and MFA — because it did. This is what the token replay looks like in the sign-in log:

{
  "userPrincipalName": "c.walker@contoso.com",
  "appDisplayName": "Microsoft Office 365",
  "authenticationRequirement": "singleFactorAuthentication",
  "tokenIssuerType": "AzureAD",
  "status": { "errorCode": 0 },
  "ipAddress": "185.234.xx.xx",
  "location": {
    "city": "Bucharest",
    "countryOrRegion": "RO"
  },
  "deviceDetail": {
    "operatingSystem": "Linux",
    "browser": "Chrome 120"
  },
  "authenticationDetails": [
    {
      "authenticationMethod": "Previously satisfied",
      "succeeded": true
    }
  ],
  "riskLevelDuringSignIn": "none",
  "conditionalAccessStatus": "success"
}

The record looks legitimate — status success, Conditional Access passed. But the indicators are there if you know where to look. The authenticationRequirement is singleFactorAuthentication despite MFA being required for this user. The authenticationMethod is "Previously satisfied" — meaning a token was presented, not a live authentication. The location and device don't match the user's normal pattern. The sign-in log contains every signal you need to detect AiTM replay. EI1 teaches you to read these fields; EI13 teaches you to build detection rules on them.

The defense is architectural, not behavioral. FIDO2 and passkeys cryptographically bind authentication to the real login.microsoftonline.com domain. A proxy page at a different domain cannot produce a valid cryptographic response because the domain doesn't match — the authentication fails silently, and the user sees an error rather than a successful sign-in. Token protection then binds the issued token to the device that completed authentication, so even if a token were somehow captured, replaying it from a different device fails validation. A compliant device requirement adds a third layer — the attacker's unmanaged machine fails the compliance check regardless of token validity.

Password spray

The attacker tries a small set of common passwords against a large number of accounts at low velocity to avoid lockout thresholds. Password spray exploits the statistical reality that in any organization with hundreds of accounts, some will use passwords like Spring2026! or Company123. The attacker tries one password against every account, waits an hour, tries the next password. Smart lockout tracks failed attempts per IP, but distributed spray campaigns use hundreds of source IPs to stay below the threshold.

The attack predominantly targets legacy authentication protocols — IMAP, POP3, SMTP AUTH, Exchange ActiveSync with basic authentication — because these protocols don't support MFA. A successful spray against an IMAP-enabled account gives the attacker mailbox access with no MFA challenge at all. Even in organizations that have "MFA enabled for all users," legacy protocol access can bypass MFA entirely if legacy authentication isn't explicitly blocked in Conditional Access.

The defense is layered. Block legacy authentication protocols in Conditional Access — this eliminates the most common spray path and should be the first Conditional Access policy deployed in any environment. Enable smart lockout, which tracks failed attempts by IP address rather than just by account. Deploy custom banned password lists that include company-specific terms, city names, and industry jargon. Require MFA for all sign-ins with no exceptions for any protocol or application. Detection queries in EI13 identify spray patterns by correlating multiple failed sign-ins from the same IP across different accounts within a short window — a pattern that is normal for no legitimate user but characteristic of every spray campaign.

MFA fatigue

The attacker already has the user's password — obtained from a previous breach, a credential stuffing list, a spray campaign, or a dark web purchase. They authenticate repeatedly against Entra ID, triggering push notifications on the user's phone. Each authentication attempt generates a new push prompt. After the tenth notification at 2 AM, the exhausted or confused user taps "Approve." The attack exploits the fundamental weakness of push notifications: the user receives a prompt with no context about what they're approving or who initiated the sign-in.

The Lapsus$ group's breach of Uber in September 2022 demonstrated this technique at scale — the attacker bombarded an employee with push notifications while simultaneously messaging them on WhatsApp, posing as IT support, and instructing them to approve the prompt. The combined social engineering pressure was enough to bypass MFA on a high-value target.

Number matching, now the default in Microsoft Authenticator, forces the user to enter a two-digit number displayed on the sign-in screen. This stops blind approval because the user must be looking at the attacker's screen to see the number — which they're not. Additional context information shows the application name, geographic location, and IP address on the notification, giving the user visible information to assess whether the sign-in is legitimate. Phishing-resistant methods eliminate the attack entirely because there's no prompt to fatigue — FIDO2 keys require physical presence at the sign-in screen, and passkeys require biometric confirmation on the device.

Token theft and replay

The attacker extracts tokens from a compromised device — access tokens from application caches (Outlook's credential manager, Teams' local storage, browser session cookies), refresh tokens from the Web Account Manager, or the PRT from the CloudAP plugin using tools like ROADtools, AADInternals, or mimikatz. They replay these tokens from their own machine. Because the tokens have already satisfied MFA, no additional authentication challenge fires.

The detection challenge is that token replay looks identical to legitimate usage in most log fields. The token carries valid claims, the authentication was legitimate when it occurred, and the access pattern may be consistent with the user's normal behavior. The distinguishing signals are subtle: a different IP address, a different device identifier, impossible travel between the legitimate device's location and the replay device's location, or a user-agent string that doesn't match the application that originally obtained the token.

Refresh tokens are the highest-value target because of their long lifetime — 90 days with a sliding window for confidential clients. An attacker who extracts a refresh token can silently generate new access tokens for months without triggering any authentication event. The refresh token renewal appears as a non-interactive sign-in, which many organizations don't monitor with the same rigor as interactive sign-ins.

Token protection binds access tokens to the device that requested them. A token extracted from Device A and presented from Device B fails validation at the resource provider. Continuous Access Evaluation monitors for critical events — password changes, user disablement, high-risk detection — and can revoke tokens mid-session. Sign-in frequency controls in Conditional Access force periodic re-authentication, limiting the window during which a stolen token remains valid. A compliant device requirement ensures that only managed, healthy devices can authenticate in the first place — reducing the attack surface for token extraction.

OAuth consent phishing

The attacker registers a malicious application — often with a name mimicking a legitimate service like "Microsoft Security Update" or "IT Department Access Review" — and sends the user a link that triggers the OAuth consent prompt. The user sees a dialog that looks like a standard Microsoft permissions request. It asks for Mail.Read, Files.ReadWrite.All, or User.Read. The user clicks "Accept." That single click grants the attacker's application persistent API access to the user's mailbox, files, and profile.

This attack is uniquely dangerous because it bypasses the entire authentication flow. The attacker doesn't steal credentials or tokens — they get their own. The malicious application authenticates with its own client secret or certificate and accesses the user's data through Microsoft Graph. These permissions survive password resets, MFA enrollment changes, and session revocations because the application has an independent identity. The only remediation is revoking the consent grant explicitly — which requires knowing it exists.

The primary defense is blocking user consent entirely and routing all application permission requests through an admin consent workflow. When user consent is blocked, the consent prompt displays a message telling the user to request admin approval. Administrators review the requested permissions and the application's publisher verification status before granting or denying. Application governance policies in Defender for Cloud Apps provide monitoring for suspicious application behavior after consent is granted. Detection queries in EI13 alert on new consent grants, especially those requesting high-privilege permissions like Mail.ReadWrite or Directory.ReadWrite.All.

Privilege escalation through directory roles

The attacker who has compromised a standard user account attempts to escalate to administrative privileges. The escalation paths include adding themselves directly to the Global Administrator role (if they've compromised an account with Privileged Role Administrator permissions), adding credentials to an existing service principal that has administrative Graph API permissions, modifying Conditional Access policies to create exceptions for their compromised account, or exploiting consent grants on service principals that have the Directory.ReadWrite.All or RoleManagement.ReadWrite.Directory permissions.

The subtlety of this attack is that the escalation often uses legitimate administrative operations — adding a role assignment, adding a credential, modifying a policy. Each individual action is a normal administrative operation. The detection challenge is distinguishing the attacker's escalation from a legitimate administrator's work.

PIM converts standing privilege assignments to eligible roles that require explicit activation with additional verification. Even if an attacker compromises a PIM-eligible account, they cannot activate the role without passing the activation requirements — which can include phishing-resistant MFA, a justification reason, and approval from another administrator. Monitoring for role assignment changes, Conditional Access policy modifications, and service principal credential additions in audit logs provides the detection layer. EI6 covers PIM design, and EI13 builds the detection rules.

Workload identity abuse

Service principals and application registrations — the non-human identities — often have broader permissions than any individual user and no MFA requirement. In a typical enterprise tenant, hundreds of service principals exist with permissions ranging from Mail.Send to Directory.ReadWrite.All. Many were created for integrations that are no longer active. Many have credentials that haven't been rotated in years. Most have no defined owner who reviews their activity.

The attacker adds new credentials (a client secret or certificate) to an existing service principal, then authenticates as that service principal using the injected credential. This persistence mechanism is invisible to most monitoring because the service principal was already authorized — the new credential simply provides an additional way to authenticate as that identity. The attacker doesn't need to create anything new; they exploit what's already there.

Workload identity governance includes credential lifecycle management (alerting on new credentials, enforcing expiration policies, rotating credentials on a defined schedule), application ownership requirements (every service principal must have an accountable owner), permission reviews (periodic audits of what each service principal can access), and Conditional Access for workload identities (available with Workload Identities Premium licensing). Detection queries monitor the Add service principal credentials and Update application – Certificates and secrets management audit log operations — these are the specific events that fire when an attacker injects credentials.

// Which attack patterns are you most exposed to right now?
// Check authentication method distribution for phishable vs resistant
SigninLogs
| where TimeGenerated > ago(7d)
| where ResultType == "0"
| extend AuthMethod = tostring(AuthenticationDetails[0].authenticationMethod)
| extend IsPhishingResistant = AuthMethod in ("FIDO2 security key", "Passkey (Microsoft Authenticator)", "X.509 Certificate")
| summarize
    TotalSignIns = count(),
    PhishingResistant = countif(IsPhishingResistant),
    Phishable = countif(not(IsPhishingResistant))
| extend PhishablePercent = round(100.0 * Phishable / TotalSignIns, 1)
// PhishablePercent is your exposure to AiTM and MFA fatigue

This query tells you what percentage of your successful sign-ins used phishable authentication methods. If the result shows 95% phishable, your environment is exposed to AiTM credential phishing and MFA fatigue on nearly every sign-in. If it shows 60% phishing-resistant, you've made progress but still have a significant attack surface through the remaining 40%. The goal is 100% phishing-resistant for privileged accounts and as close to 100% as operationally possible for all accounts. Run this query weekly — the percentage is your single best indicator of identity security posture improvement over time.