Attack Patterns You Will Defend Against

Introduction

Seven attack patterns account for the overwhelming majority of identity compromise, and each is answered by a specific control rather than by identity security in general. This section is that mapping. You will finish able to name what each attack needs to succeed, and which module answers it.

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.

Four entry points, seven ways of reaching them.

The entry points are only four: a credential, a session, a consent grant, or a standing privilege. All seven patterns below are one of those four, acquired a different way, which is why the list is shorter to defend than it is to read.

Count the rows that involve a password. There are two. A defense built around the password, which is what most identity programs are, answers two of the seven and leaves the other five untouched, and per 0.1 those five are where the damage in this course comes from.

The count in that last line is the reframing worth taking from this sub. Five of the seven take a session, an approval, a grant or a standing privilege, and none of those is prevented by a stronger password or by requiring one more often.

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; ARC406 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.

A proxy sits between the user and the real sign-in page. The user authenticates correctly, and the attacker keeps the session.

It defeats passwords, and it defeats MFA by push, SMS or code. The user completes the challenge honestly and nothing fails at any point. It defeats user vigilance too, because as far as the browser is concerned the page is the real page.

It does not defeat phishing-resistant methods. FIDO2 and passkeys bind the credential to the origin, per ei02, so a proxy sitting on another domain cannot complete the ceremony at all. Token protection and device binding close it from the other end, per ei07.

That asymmetry is why "we have MFA" is an incomplete answer, and why ei02 is a module about methods rather than about whether MFA is switched on.

The middle block is the one to be precise about. The user does nothing wrong and no control malfunctions, so there is no failure anywhere in the record to investigate, which is what separates this from every attack that leaves a denied sign-in behind.

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 ARC406 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.

This is not a brute force, and the distinction is what makes it work. One or two passwords are tried against many accounts, slowly, from many addresses, so the per-account failure count never approaches a lockout threshold.

What it targets is the accounts nobody looks at: service accounts, shared mailboxes, departed staff, and anything exempted from MFA "temporarily".

What makes it visible is distinct accounts per source, per ei01, rather than failures per account. The second number stays small on purpose, which is the whole design. Count the wrong thing and this is invisible.

// EI0.4: one source, many accounts, few failures each
SigninLogs
| where TimeGenerated > ago(7d)
| where ResultType in (50126, 50053, 50055)
| summarize Accounts = dcount(UserPrincipalName), Attempts = count()
    by IPAddress, tostring(AutonomousSystemNumber)
| extend PerAccount = round(todouble(Attempts) / Accounts, 1)
| where Accounts > 10 and PerAccount < 3
| order by Accounts desc
// PerAccount stays under the lockout threshold. Accounts is the signal

What answers it is blocking legacy authentication first, per ei02, because legacy protocols bypass Conditional Access entirely and are where spray actually succeeds. Smart lockout and password protection follow.

The counting point is the whole detection. A per-account failure threshold is designed not to fire on this, so an estate can have lockout configured correctly, alerting configured correctly, and no visibility of a spray at all.

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.

Which is the distinction the next pattern turns entirely on.

The attacker already has the password and triggers approval prompts repeatedly, at night, until somebody taps Approve to stop the noise.

Nothing is broken. The protocol did exactly what it was designed to do, and a person made a decision under fatigue, which is precisely why hardening the protocol does not address it.

Number matching answers it, per ei02, by turning a one-tap approval into a value the user has to read from the thing they are signing in to. Phishing-resistant methods answer it by removing the approval altogether. And it presupposes a stolen password, so everything that answers spray answers this one step earlier.

This is the one pattern where the vulnerability is a person at 2 a.m., and the fix is still technical.

The last line is worth stating because the instinct here is training. The approval is a design feature being used as designed, so the durable answer changes the prompt rather than the person, and number matching is the smallest change that does it.

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.

This targets the token rather than the credential. Per 0.2, four steps decide and the fifth hands over a bearer credential carrying that decision.

The token comes from an AiTM proxy, or from the token broker on a compromised device. A PRT is the highest-value version, because it reaches every application rather than one.

Replay is hard to see for a reason that no amount of tuning fixes: the token is valid, and the sign-in it came from was recorded as a success. What changes is the context of use, which is why ei07 is a module about the session rather than about the authentication.

Token protection and device binding answer it, along with shorter lifetimes, continuous access evaluation, and revoking sessions rather than resetting passwords. A password reset does not end a stolen session.

  "UserPrincipalName": "p.sharma@ne.com"
  "ResultType": 0
  "ConditionalAccessStatus": "success"
  "AuthenticationRequirement": "multiFactorAuthentication"
  "authenticationStepResultDetail": "MFA claim in token"
  "IPAddress": "45.83.220.14"
  "AutonomousSystemNumber": 202425
  "DeviceDetail": {}

Read the last three lines against the first five. Nothing above them failed: the sign-in succeeded, a policy evaluated it, and MFA was satisfied. The claim, the unfamiliar network and the empty device block are the whole of the evidence, and none of them is an error.

That final line is the operational consequence and it is the most commonly skipped step in identity incident response. Resetting a password stops future authentication and leaves an existing session working, so an incident closed on a reset alone is an incident still running.

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 ARC406 alert on new consent grants, especially those requesting high-privilege permissions like Mail.ReadWrite or Directory.ReadWrite.All.

The user clicks a link, sees a genuine Microsoft consent dialog, and grants an application permission to read their mail or files. The dialog is real and the flow is the intended one.

What the attacker gets is access belonging to an application rather than to a session. There is no credential to reset, no session to revoke, and MFA never enters it.

Which is why it survives incident response. The standard playbook is reset the password and revoke sessions, and neither touches a consent grant, so the access continues quietly after the incident is closed.

Restricting user consent answers it, with an admin consent workflow and a review of existing grants, per ei09. This row breaks the assumption that identity compromise means a stolen credential, and it is worth breaking early.

// EI0.4: who granted what to which application, and when
AuditLogs
| where TimeGenerated > ago(90d)
| where OperationName has "Consent to application"
| extend Actor = tostring(InitiatedBy.user.userPrincipalName)
| extend App = tostring(TargetResources[0].displayName)
| project TimeGenerated, Actor, App, Result
| order by TimeGenerated desc
// Every row survives a password reset and a session revocation

The survival property is what makes this pattern worth its own module. A consent grant is persistence that no credential action removes, so it outlives the response, and it is only found by looking for it rather than by anything the response naturally touches.

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 ARC406 builds the detection rules.

This looks like a role assignment, a group membership change, or an application permission grant: each an ordinary administrative action performed with the correct tools.

Nothing fails, because the account had the privilege to do it. That is the definition of the problem rather than a gap in a control, and it is why detection here cannot be built on something going wrong.

What makes it visible is the audit log rather than the sign-in log, per ei01: who assigned what, to whom, and whether a change record exists.

PIM answers it, per ei06, by making privilege eligible rather than active, so standing privilege stops being standing. Approval and justification on activation, and access reviews per ei12, follow.

// EI0.4: role and permission grants, with who did them
AuditLogs
| where TimeGenerated > ago(30d)
| where Category == "RoleManagement"
| where OperationName startswith "Add member to role"
| extend Actor = tostring(InitiatedBy.user.userPrincipalName)
| extend Role = tostring(TargetResources[0].displayName)
| summarize Grants = count(), Roles = make_set(Role, 6) by Actor
| order by Grants desc
// Nothing here failed. The question is which rows have a change record

The discriminator is contextual rather than behavioral: whose account, from where, against which approved change. No query answers that on its own, which is why the last column of the result is a conversation.

The contextual point is the recurring difficulty with privileged activity. Legitimate administration and escalation are the same actions against the same objects, so nothing about the action separates them and the only discriminator is whether somebody approved it.

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.

Each pattern has one control that answers it, which makes this seven questions rather than a posture review.

Seven patterns account for most identity compromise and they share only four entry points: a credential, a session, a consent grant, or a standing privilege. Two of the seven involve a password at all, which is why a defense built around passwords answers two rows. AiTM takes the session and completes MFA honestly, so it is the attack that makes "we have MFA" an incomplete answer. Consent phishing takes a grant with no password anywhere and survives both halves of the standard reset-and-revoke playbook. Role escalation uses privilege that was already there, so nothing fails and the discriminator is contextual. And workload identities have no user, no prompt and no session, which means every control in this course misses them.