EI0.5 Attack Patterns You Will Defend Against

The attacks and the defenses

This course is organized around attack techniques, not product features. You do not learn conditional access because it is a feature — you learn it because it stops specific attacks. Every module maps to one or more of the following attack patterns.

AiTM credential phishing

Adversary-in-the-middle credential phishing is the most significant identity attack technique in production today. The attacker sends a phishing email that directs the user to a proxy page — a server controlled by the attacker that sits between the user and the real Entra ID sign-in page. The user sees what appears to be a legitimate Microsoft sign-in experience. They enter their username and password. The proxy forwards these credentials to the real Entra ID endpoint. Entra ID challenges for MFA. The user completes the MFA challenge — approves a push notification, enters a code, taps their security key. The proxy captures the session token that Entra ID issues after successful authentication.

The attacker now possesses a valid session token that has already satisfied MFA. They replay this token from their own device, and Entra ID grants access because the token is valid. The user's MFA did not fail — it succeeded. The attacker simply intercepted the result.

This is why MFA alone does not stop AiTM. The defense requires a combination of controls: phishing-resistant authentication methods (FIDO2/passkeys, which verify the domain cryptographically and cannot be proxied), compliant device requirements (which ensure the token is issued to a managed device), and token protection (which binds the token to the device that completed authentication). EI2 covers the authentication methods, EI4 builds the conditional access policy combination, and EI7 covers token protection deployment.

Password spray

Password spray attacks target the authentication endpoint directly. The attacker tries a small number of common passwords (such as "Spring2026!" or "Welcome1") against a large number of accounts. Unlike brute force, which tries many passwords against one account, spray distributes the attempts across many accounts to stay below account lockout thresholds.

Password spray succeeds when users choose predictable passwords and when legacy authentication protocols (IMAP, POP3, SMTP Basic Auth) are still enabled — legacy protocols do not support MFA, so a correct password grants full access. The defense combines blocking legacy authentication (the single most impactful change), enabling Entra ID Password Protection with custom banned word lists, enforcing MFA for all users, and deploying Identity Protection to detect the spray pattern. EI2 covers password protection, EI4 builds the conditional access policies, and EI13 teaches the detection rules.

MFA fatigue

MFA fatigue exploits push notification MFA. The attacker has the user's password (from spray, breach data, or phishing) and repeatedly initiates sign-in attempts, each triggering a push notification to the user's Authenticator app. After receiving dozens of unexpected push prompts, some users will approve one — either out of confusion, to make the notifications stop, or because they believe the system is malfunctioning.

The primary defense is number matching — instead of a simple "Approve/Deny" prompt, the Authenticator shows a two-digit number that the user must enter from the sign-in screen. The attacker cannot see this number because they are not looking at the sign-in screen (it is on the real user's browser). Additional context (showing the application name and sign-in location on the prompt) further helps the user identify suspicious prompts. The ultimate defense is replacing push MFA with phishing-resistant authentication (passkeys or FIDO2 keys), which eliminates the prompt entirely. EI2 covers the method configuration and EI4 builds the policy enforcement.

Token theft and replay

Token theft occurs after successful authentication. The attacker obtains a valid access token, refresh token, or PRT from a compromised device — through malware that extracts browser cookies, through AiTM session capture, or through physical access to an unlocked workstation. They then replay this token from their own device.

The most common method is information-stealing malware — families like Raccoon Stealer, RedLine, and Lumma target browser cookie databases and extract session tokens for cloud services including Microsoft 365. The attacker does not need to know the user's password or bypass MFA — the token was issued after the user already completed both. The stolen cookie is imported into the attacker's browser, and they have a fully authenticated session. Sign-in logs may show the original legitimate authentication from the user's device, but the subsequent token usage from the attacker's device may appear as a non-interactive sign-in or may not generate a new sign-in event at all if the token is used directly against a resource API.

Consent phishing

Consent phishing does not steal the user's credentials at all. Instead, the attacker creates a malicious OAuth application and tricks the user into granting it permissions. The phishing email contains a link that opens the Entra ID consent prompt: "This application is requesting permission to: Read your email, Send email on your behalf, Access your files." If the user clicks "Accept," the attacker's application receives the requested permissions and can access the user's data directly through the Microsoft Graph API — without ever knowing the user's password.

What makes consent phishing particularly dangerous is persistence. The permissions granted through consent survive password resets, MFA re-enrollment, and session revocation. The attacker's application has its own credentials — it does not depend on the user's authentication state at all. Even if you detect the compromise and reset every aspect of the user's account, the malicious application retains its granted permissions until someone explicitly reviews and revokes the consent grant. Many organizations do not have a process for reviewing application consent grants, which means the attacker's access can persist indefinitely.

Privilege escalation

Once inside an environment, attackers escalate privileges to expand access and establish persistence that survives remediation. The techniques are specific and well-documented:

Directory role modification — the attacker adds the compromised account (or a new account they created) to a privileged role such as Global Administrator, Exchange Administrator, or Application Administrator. With Global Administrator access, the attacker controls the entire tenant and can disable the security controls designed to detect them.

Workload identity abuse

Service principals and application registrations have credentials (client secrets or certificates) that can be stolen like any other credential — but they cannot use MFA and often have broad permissions. An attacker who obtains a service principal's client secret can authenticate as that application and access any resource the application has permissions to.

The scale of the problem is significant. In a typical enterprise M365 tenant, workload identities outnumber human identities by a factor of five to ten. Many of these applications were registered years ago for projects that have since ended. Their credentials have not been rotated. Their permissions have not been reviewed. Their owners have left the organization. Each one is a potential entry point.

// EI0.5 — What does a password spray look like in your logs?
SigninLogs
| where TimeGenerated > ago(24h)
| where ResultType == 50126  // Invalid username or password
| summarize FailedAttempts = count(), TargetedAccounts = dcount(UserPrincipalName)
    by IPAddress
| where TargetedAccounts > 5
| order by TargetedAccounts desc
// IPs targeting 5+ accounts with wrong passwords = potential spray
// This is the DETECTION pattern you will build into a full rule in EI13