The MFA Identity Trap: How Attackers Pass Authentication and What Defenders Must Detect Instead

A hard truth is circulating through the security community, crystallized in a recent SecurityWeek analysis: organizations are conflating identity verification, authentication, and threat detection — and attackers are walking straight through the gap. The pattern is now routine in our incident response engagements. A user "successfully" completes MFA. Conditional Access evaluates the session as compliant. And yet the person on the other end of that session is an adversary who phished the credentials, proxied the MFA challenge in real time, and replayed a stolen session cookie from an infrastructure thousands of miles away.

Every control in the chain did exactly what it was designed to do. The attacker was still authenticated.

This is the MFA identity trap: authentication answers the question "did the user present the right factors?" — it does not answer "should this session be trusted right now?" Organizations that treat a passed MFA challenge as proof of legitimacy are building their entire security model on a question attackers have already learned to game.

The Technical Reality: How Attackers Pass MFA

Modern identity attacks no longer attempt to defeat MFA cryptographically. They defeat it operationally. The dominant techniques we see in active intrusions:

Adversary-in-the-Middle (AiTM) phishing. Frameworks reverse-proxy the real identity provider login page. The victim enters credentials and completes MFA against the legitimate IdP — the attacker simply sits in the middle and harvests the resulting session cookie. From the IdP's perspective, authentication succeeded with MFA satisfied. The attacker then replays the cookie from their own infrastructure, inheriting a fully authenticated session. No MFA prompt ever fires again because the token is already valid.

Token and session cookie theft. Infostealer malware and hands-on-keyboard actors extract browser session cookies (Chrome Cookies SQLite database, Local State DPAPI key, Edge/Firefox equivalents) from endpoints and replay them from attacker infrastructure. MFA is irrelevant — the session is post-authentication by definition.

MFA fatigue (push bombing). Attackers with valid passwords flood push notifications until a user approves one to make it stop, or helpdesk-assisted resets are socially engineered. Again: the IdP logs a "successful" MFA completion.

SIM swapping and SMS interception. Phone-number-based factors remain vulnerable to carrier-level attacks, which is precisely why NIST deprecated SMS as an out-of-band authenticator.

The common thread: the authentication event is genuine; the session context is malicious. Detection has to move from the authentication event to session behavior and post-authentication telemetry.

Why This Matters Now

Identity is the control plane for nearly every SaaS and cloud environment we defend. When a session token is replayed successfully, the attacker inherits not just mailbox access but OAuth-granted application permissions, SharePoint/OneDrive data, Teams, and — in hybrid environments — a pivot point into on-premises resources. The downstream incidents (business email compromise, data exfiltration, OAuth consent abuse, inbox rule manipulation) all trace back to a single log line that reads authenticationSucceeded.

Defenders must operationalize three distinct layers and stop treating them as interchangeable:

1. Identity verification — proving the human is who they claim (at enrollment, at recovery, at helpdesk interactions). This is where most MFA reset attacks succeed.
2. Authentication — validating factors at sign-in. Necessary, but a point-in-time check.
3. Threat detection on the session — continuous evaluation of token origin, device posture, network context, and post-auth behavior. This is the layer most organizations are missing.

Detection: Hunting the Session, Not the Sign-In

The detections below target the observable behaviors of AiTM phishing, token replay, MFA fatigue, and cookie theft. They are built for production SOC use — tuned to fire on the anomalies these attacks actually produce, not on volume.

Sigma Rules

---
title: Non-Browser Process Accessing Browser Cookie or Credential Stores
id: 4f7c2a91-6e83-4b1d-9c52-8a3e7f10d2b4
status: experimental
description: Detects processes other than the browser itself accessing browser session cookie databases or encryption key stores, a hallmark of session token theft for MFA bypass via cookie replay.
references:
  - https://attack.mitre.org/techniques/T1539/
  - https://attack.mitre.org/techniques/T1555/003/
author: Security Arsenal
date: 2026/02/14
tags:
  - attack.credential_access
  - attack.t1539
  - attack.t1555.003
logsource:
  category: file_event
  product: windows
detection:
  selection_paths:
    TargetFilename|contains:
      - '\AppData\Local\Google\Chrome\User Data\Default\Network\Cookies'
      - '\AppData\Local\Google\Chrome\User Data\Local State'
      - '\AppData\Local\Microsoft\Edge\User Data\Default\Network\Cookies'
      - '\AppData\Local\Microsoft\Edge\User Data\Local State'
      - '\AppData\Roaming\Mozilla\Firefox\Profiles\'
  filter_browsers:
    Image|endswith:
      - '\chrome.exe'
      - '\msedge.exe'
      - '\firefox.exe'
  condition: selection_paths and not filter_browsers
falsepositives:
  - Enterprise browser backup or DLP agents reading profile data (tune by Image hash/path)
  - Legitimate EDR/AV scanning of profile directories
level: high
---
title: Azure Sign-In With Risk Detail Indicating Anomalous Token or Unfamiliar Session Properties
id: 8b3e5d12-2f49-4c77-a1d6-5e9b3c08f741
status: experimental
description: Detects Entra ID sign-ins flagged with risk details consistent with token replay or unfamiliar session characteristics, commonly observed after AiTM phishing where a valid session cookie is replayed from attacker infrastructure.
references:
  - https://attack.mitre.org/techniques/T1550/004/
author: Security Arsenal
date: 2026/02/14
tags:
  - attack.defense_evasion
  - attack.t1550.004
logsource:
  product: azure
  service: signinlogs
detection:
  selection_risk:
    RiskDetail:
      - 'unfamiliarFeatures'
      - 'anonymizedIPAddress'
      - 'maliciousIPAddress'
      - 'suspiciousFeatures'
  selection_result:
    ResultType: 0
  condition: selection_risk and selection_result
falsepositives:
  - Users on VPN or privacy relays may trigger anonymizedIPAddress; correlate with device compliance and ASN before escalation
level: high

KQL — Microsoft Sentinel / Defender

This query hunts the two highest-signal identity patterns: session replay from anomalous network origin (sign-in succeeds, then an established session appears from a new ASN/geography within a short window) and MFA fatigue culminating in success (multiple denials/timeouts followed by approval).

let lookback = 14d;
let window = 2h;
// Part 1: Impossible-travel / ASN-shift indicative of session cookie replay
SigninLogs
| where TimeGenerated >= ago(lookback)
| where ResultType == 0
| summarize Signins = make_set(pack_array("time", TimeGenerated, "ip", IPAddress, "loc", Location, "app", AppDisplayName)), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated) by UserPrincipalName
| extend SigninCount = array_length(Signins)
| where SigninCount > 1
| mvexpand Signins
| evaluate bag_unpack(Signins)
| project UserPrincipalName, TimeGenerated = todatetime(time), IPAddress = tostring(ip), Location = tostring(loc), AppDisplayName = tostring(app)
| extend Country = tostring(split(Location, ",")[-1])
| sort by UserPrincipalName asc, TimeGenerated asc
| extend PrevCountry = prev(Country), PrevTime = prev(TimeGenerated), PrevIP = prev(IPAddress)
| where UserPrincipalName == prev(UserPrincipalName)
  and Country != PrevCountry
  and datetime_diff("minute", TimeGenerated, PrevTime) <= 120
  and IPAddress != PrevIP
| project UserPrincipalName, PrevIP, PrevCountry, PrevTime, IPAddress, Country, TimeGenerated, AppDisplayName;
// Part 2: MFA push fatigue - repeated denials followed by a success (run as separate hunt)
AADSignInEventsBeta
| where TimeGenerated >= ago(lookback)
| where ErrorCode in (500121, 500113) // MFA denied / timed out
| summarize DenialCount = count(), DenialTimes = make_list(TimeGenerated) by AccountUpn, bin(TimeGenerated, 1h)
| where DenialCount >= 4
| join kind=inner (
    AADSignInEventsBeta
    | where TimeGenerated >= ago(lookback)
    | where ErrorCode == 0
    | project AccountUpn, SuccessTime = TimeGenerated, IPAddress, Application
) on AccountUpn
| where SuccessTime between (TimeGenerated .. TimeGenerated + window)
| project AccountUpn, DenialCount, DenialTimes, SuccessTime, IPAddress, Application

Velociraptor VQL — Endpoint Hunt for Cookie Store Access

Use this artifact to sweep endpoints for processes that have opened browser credential/cookie stores — a direct indicator of token theft tooling staging for MFA bypass.

-- Hunt for non-browser processes holding handles to browser cookie/credential stores
SELECT Pid,
       Name,
       Exe,
       CommandLine,
       Username,
       CreateTime
FROM pslist()
WHERE (CommandLine =~ 'Cookies'
    OR CommandLine =~ 'Local State'
    OR CommandLine =~ 'Login Data'
    OR Exe =~ '(?i)(appdata|temp|programdata)\\\\[^\\\\]+\.exe$')
  AND NOT Exe =~ '(?i)(chrome|msedge|firefox|brave)\.exe$'
ORDER BY CreateTime DESC

Remediation and Hardening Script

Detection catches what slips through; hardening shrinks the surface. The script below audits an Entra ID tenant for the highest-risk conditions: users registered only for phishable MFA methods (SMS/voice), missing Conditional Access enforcement of phishing-resistant authentication, and legacy authentication still enabled.

# Requires: Microsoft.Graph PowerShell SDK (Identity.SignIns, Identity.Policy scopes)
# Connect-MgGraph -Scopes "UserAuthenticationMethod.Read.All","Policy.Read.All","Directory.Read.All"

# 1. Identify users whose ONLY registered MFA methods are phishable (SMS / voice)
$weakUsers = @()
$users = Get-MgUser -All -Property Id,UserPrincipalName
foreach ($u in $users) {
    $methods = Get-MgUserAuthenticationMethod -UserId $u.Id
    $types = $methods.AdditionalProperties.'@odata.type'
    $hasStrong = $types -match 'fido2|windowsHelloForBusiness|microsoftAuthenticator'
    $hasWeak   = $types -match 'phoneAuthenticationMethod'
    if ($hasWeak -and -not $hasStrong) {
        $weakUsers += [pscustomobject]@{ User = $u.UserPrincipalName; Methods = ($types -join ',') }
    }
}
$weakUsers | Export-Csv -Path .\PhishableMFAOnlyUsers.csv -NoTypeInformation
Write-Host "[!] $($weakUsers.Count) users rely solely on phishable MFA methods. Results exported."

# 2. Verify Conditional Access requires phishing-resistant MFA for privileged roles
$policies = Get-MgIdentityConditionalAccessPolicy -All
$resistant = $policies | Where-Object {
    $_.State -eq 'enabled' -and
    $_.GrantControls.AuthenticationStrength.AllowedCombinations -match 'fido2|windowsHelloForBusiness|certificateBasedAuthentication'
}
if (-not $resistant) {
    Write-Host "[!] NO enabled CA policy enforces phishing-resistant auth strength. Create one scoped to admin roles."
} else {
    Write-Host "[+] Phishing-resistant auth strength enforced by: $($resistant.DisplayName -join '; ')"
}

# 3. Check whether token protection / continuous access evaluation is enforced for Exchange & SharePoint
$tokenProt = $policies | Where-Object {
    $_.State -eq 'enabled' -and
    $_.SessionControls.SecureSignInSession.IsEnabled -eq $true
}
if (-not $tokenProt) {
    Write-Host "[!] Token protection (session binding) NOT enforced. Enable CA session controls to bind tokens to devices and blunt cookie replay."
}

# 4. Confirm legacy authentication is blocked
$legacyBlock = $policies | Where-Object {
    $_.State -eq 'enabled' -and
    $_.Conditions.ClientAppTypes -contains 'exchangeActiveSync' -and
    $_.GrantControls.BuiltInControls -contains 'block'
}
if (-not $legacyBlock) { Write-Host "[!] Legacy auth does not appear to be blocked tenant-wide. Block it - it bypasses MFA entirely." }

Remediation: Closing the Trap

1. Deploy phishing-resistant MFA where it matters most. FIDO2 security keys, Windows Hello for Business, or certificate-based authentication for all privileged accounts first, then high-value targets (finance, executives, helpdesk). These methods cryptographically bind the authentication to the origin domain — an AiTM proxy cannot satisfy them because the origin will not match.

2. Bind tokens to devices. Enable Conditional Access token protection (sign-in session controls) for Exchange Online and SharePoint Online so session cookies replayed from foreign infrastructure fail device-binding validation. This directly neutralizes the cookie-replay attack path.

3. Harden the recovery and helpdesk layer — this is identity verification, not authentication. Enforce verified-ID or manager-callback workflows for MFA resets and SIM/port changes. Most MFA fatigue and reset attacks succeed because the verification step before re-enrollment is weaker than the authentication step that follows it.

4. Kill SMS and voice as factors. Migrate phone-based authentications to Authenticator app with number matching enabled (defeats blind push bombing) and disable SMS/voice registration for privileged users.

5. Instrument session-layer detection. Deploy the queries above; alert on ASN/geography shifts on established sessions, risk-flagged sign-ins, and MFA denial storms. Correlate identity events with endpoint cookie-store access telemetry.

6. Shorten token lifetimes for sensitive apps and revoke on signal. Configure Continuous Access Evaluation, and wire your detections to revokeSignInSessions — a detected replay is only useful if the stolen token dies with the alert.

7. Audit OAuth grants. Post-token-theft persistence frequently lives in consented applications. Review enterprise app consents for mail-read and offline-access scopes monthly.

The lesson of the MFA identity trap is not that MFA is broken — it is that MFA was never the whole answer. Authentication is a gate; detection is the guard force behind it. Build both, or accept that your logs will faithfully record the successful authentication of your attackers.

Related Resources

Security Arsenal Managed SOC Services AlertMonitor Platform Book a SOC Assessment soc-mdr Intel Hub