Microsoft watched a single adversary-in-the-middle campaign compromise more than 35,000 users across 13,000 organizations in 26 countries in just three days in April 2026, per its Microsoft Security analysis of the "code of conduct" phishing operation. The victims did nothing obviously wrong. They opened an HR-themed message, passed a CAPTCHA, signed in on what looked like Microsoft, and completed multi-factor authentication exactly as trained. That is the problem. As Microsoft puts it, "AiTM attacks intercept authentication traffic in real time, bypassing non-phishing-resistant multifactor authentication (MFA)." The login was genuine. The stolen thing was the session that came after it.
Three forces made this the defining identity attack of 2026. Obsidian Security found that MFA failed to prevent the attack in 84% of its incident responses, and that 99% of SaaS compromises originate at the identity provider. AitM tooling has commoditized: Microsoft reported that the Tycoon2FA kit alone pushed tens of millions of phishing messages at more than 500,000 organizations monthly, with panel access starting around US$120 (Microsoft Security). And the sibling technique, OAuth consent phishing, is scaling in parallel: Proofpoint tracked malicious OAuth apps that targeted nearly 3,000 accounts across 900+ Microsoft 365 environments with a success rate over 50%. This post is written for CISOs, identity and detection engineers, incident responders, and the security buyers who have to answer the board question: "We rolled out MFA, so why is this still happening?"
This is the Stingrai research team's canonical 2026 reference for adversary-in-the-middle and OAuth consent phishing, framed for defenders. It is not an attacker how-to: it explains the concept and why MFA fails, then spends the majority of its length on detection and defense. It carries attributed statistics from five primary publishers, Microsoft, Obsidian Security, Proofpoint, Push Security, and MITRE ATT&CK, with lead campaign data drawn from 2026 telemetry, the freshest available. Every figure links back to its primary publisher so any claim can be audited inline. Read it alongside its sibling technique in device code phishing and ClickFix, which beats MFA by a different route.
TL;DR: the numbers that matter
Single-campaign blast radius (April 2026): more than 35,000 users across 13,000 organizations in 26 countries, 92% of them in the US, hit by one AitM "code of conduct" campaign in three days (Microsoft Security, Breaking the code).
MFA is not enough on its own: MFA failed to prevent the attack in 84% of incident responses (Obsidian Security, 2025 SaaS Security Threat Report).
The identity layer is the front line: 99% of SaaS compromises originate at the identity provider (Obsidian Security).
AitM is now the default, not the exotic option: AitM attacks rose 146% in a year, with nearly 40,000 incidents detected daily (Obsidian Security).
Kits are cheap and industrial: Tycoon2FA pushed tens of millions of messages at 500,000+ organizations monthly, with access from about US$120 (Microsoft Security, Tycoon2FA).
OAuth consent phishing scales alongside it: malicious OAuth apps impersonating 50+ brands hit nearly 3,000 accounts across 900+ Microsoft 365 environments, succeeding more than half the time (Proofpoint).
Attackers move fast once inside: fastest observed time from initial access to data exfiltration was 9 minutes (Obsidian Security).
Phishing has left the inbox: roughly 1 in 3 phishing attacks were delivered outside of email in 2025 (Push Security, 2025 top phishing trends).
This is well-charted tradecraft: AitM maps to MITRE ATT&CK T1557, session-cookie theft to T1539, and OAuth token abuse to T1528 (MITRE ATT&CK).
Key takeaways
AitM is not a broken MFA prompt. It rides a completed authentication. The victim performs the real sign-in and the real MFA challenge, and the attacker's proxy quietly copies the session token that the identity provider issues afterward. Because the login genuinely succeeds, an authenticator app, an OTP, or a push approval never fires an alarm (Microsoft Security).
MFA protects the login, not the session behind it. Obsidian Security states the failure mode plainly: "MFA protects the authentication moment, not the authenticated session." Once a token is issued, it is a bearer credential, and whoever holds it is trusted (Obsidian Security).
OAuth consent phishing is the quieter twin. Instead of stealing a live session, it convinces a user to grant a malicious app standing delegated access. There is no password to reset and no session to expire: the app keeps its token until an admin revokes the grant, which is why Proofpoint saw these campaigns succeed more than half the time (Proofpoint).
The technique has commoditized from bespoke tradecraft to a subscription. What used to require a skilled operator is now a hosted phishing-as-a-service panel that captures cookies in real time; Microsoft describes Tycoon2FA operators capturing "the session cookie" and gaining "real-time access without needing further authentication, even if the password was changed later" (Microsoft Security).
Detection and defense are structural, and they live after the login. The controls that actually help are token binding, conditional access with continuous access evaluation, session and token anomaly detection, rapid revocation, and OAuth consent governance, not another authentication factor bolted onto the front door (Microsoft Security).
Methodology
This explainer draws on primary sources published between January 2025 and May 2026, with a research cutoff of July 1, 2026. The sources and their data windows: Microsoft Security's "code of conduct" AitM campaign analysis (May 2026) and Tycoon2FA kit teardown (March 2026); Microsoft's identity-attack defense guidance (May 2025); Proofpoint's OAuth app impersonation threat insight (July 2025); Obsidian Security's 2025 SaaS Security Threat Report (January 2025) and its 2026 token-based-attack analysis; Push Security's 2025 phishing-trends review; MITRE ATT&CK technique references; and Microsoft Entra and Defender documentation on consent-phishing defense.
Every numeric claim was verified against the named primary publisher during the research pass. Figures that could not be confirmed against a primary source on at least one verification pass were dropped rather than estimated or hedged. Attribution is inline throughout the body and consolidated in the References section.
What adversary-in-the-middle phishing actually is
Classic phishing steals a password. That model broke the moment MFA became common, so attackers moved the goal one step later in the login process. Adversary-in-the-middle phishing does not try to answer your MFA challenge. It gets you to answer it, on the real page, and then takes what the identity provider hands back.
Conceptually, an AitM page is a relay. It sits between the victim and the genuine identity provider and forwards each request in real time. The victim sees a login that looks and behaves exactly like Microsoft, Google, or Okta, because behind the scenes the proxy is showing them the real thing. The victim types their password, the proxy passes it on, the identity provider issues its MFA challenge, the victim satisfies it, and the identity provider returns a valid session token. That token, the browser cookie that proves "this session already authenticated," is what the attacker copies. MITRE ATT&CK catalogs the positioning as T1557 Adversary-in-the-Middle and the payoff as T1539, Steal Web Session Cookie.
The important part for defenders is what is not happening. The attacker never needs to know your password long-term, never needs your phone, and never triggers a failed-login signal, because there was no failed login. Microsoft's Tycoon2FA teardown describes operators who "capture the session cookie and gained real-time access without needing further authentication, even if the password was changed later" (Microsoft Security). Rotating the victim's password after the fact does nothing, because the stolen artifact is the session, not the credential.
This has moved from artisanal to industrial. Microsoft reported Tycoon2FA sending tens of millions of messages at more than 500,000 organizations monthly, with panel access starting around US$120, hosted behind rotating infrastructure with 24-to-72-hour domain lifetimes (Microsoft Security). Push Security notes that "the vast majority of phishing attacks today use a reverse proxy," and that roughly 1 in 3 phishing attacks it detected in 2025 arrived outside of email entirely, through chat, ads, and collaboration tools (Push Security).
How the session theft actually happens
At the conceptual level, the chain has four moving parts. This is a defender's mental model, not a build guide.
Lure. The victim receives a message with a pretext that fits their day: a shared document, an HR notice, a voicemail, a code-of-conduct review. The April 2026 campaign Microsoft analyzed used HR and compliance themes with PDF attachments and routed victims through CAPTCHA pages to shake off automated scanners (Microsoft Security).
Relay. The link lands on an attacker-controlled page that proxies the real identity provider. Everything the victim sees is forwarded from the genuine login, so the branding, the domain-in-the-flow behavior, and the MFA prompt are all real.
Genuine MFA. The victim authenticates for real. SMS, TOTP, and push all get satisfied, because the victim is answering a legitimate challenge. This is the step defenders keep expecting to save them, and it does not.
Token capture and replay. The identity provider issues the session token to the flow, the proxy copies it, and the attacker replays it from their own machine. They now hold an authenticated session with the completed-MFA claim baked in, and they move quickly. Obsidian measured a fastest access-to-exfiltration time of 9 minutes (Obsidian Security).
The reason this scales is that steps 1 through 3 look identical to a normal, healthy login from the victim's side, and step 4 looks like a normal session from the application's side. Nothing in the sequence resembles a brute-force attempt or a credential-stuffing spray.
OAuth consent phishing: the sibling that skips the session entirely
AitM steals a live session. OAuth consent phishing takes a different road to the same destination: it asks the victim to grant a malicious application standing access, so the attacker never needs a session token at all.
The lure is a consent screen. The victim receives what looks like a routine "an app wants access to your files" request, often impersonating a familiar brand. Proofpoint tracked campaigns impersonating more than 50 applications, including RingCentral, SharePoint, Adobe, DocuSign, and OneDrive, that funneled victims toward malicious OAuth apps and, in some variants, on to AitM credential harvesting (Proofpoint). If the user clicks accept, the app receives a delegated-access token scoped to whatever it requested: read your mail, maintain access to your files, and so on. MITRE tracks this as T1528, Steal Application Access Token.
Two properties make consent phishing dangerous. First, it bypasses MFA for the same structural reason AitM does: the grant happens after a legitimate login, so the second factor is already satisfied. Second, it is persistent in a way a stolen cookie is not. A session token expires; a consent grant lasts until an administrator revokes it, surviving password resets and MFA re-enrollment. Proofpoint saw these campaigns confirm compromise in more than half the environments where users authorized the app (Proofpoint). That durability is why OAuth app governance belongs in the same defensive conversation as AitM, not a separate one.
Why MFA, and even passkeys, do not automatically stop it
Most MFA guidance quietly assumes the attacker is trying to defeat the authentication challenge. AitM and consent phishing do not fight the challenge. They wait for the victim to pass it and take what comes next. Obsidian Security frames the gap precisely: "MFA protects the authentication moment, not the authenticated session" (Obsidian Security).
That single fact explains why each MFA type behaves the way it does:
SMS, TOTP, and push MFA: the victim satisfies all of these on the real identity provider through the relay. The attacker never has to see or reproduce the code, so these factors are simply consumed as designed.
Number matching and app-based approval: the victim approves a sign-in that is genuinely happening, so the "is this you?" prompt is answered honestly.
FIDO2 passkeys and phishing-resistant MFA: this is the nuance defenders most often get wrong. A passkey is cryptographically bound to the real origin, so against a lookalike-domain relay it refuses to sign, and it stops the AitM login cold. That is exactly why passkeys are worth deploying. But two gaps remain. If passwords or weaker fallback factors are still allowed for the same account, the attacker steers the victim to the fallback and the passkey never comes into play. And a passkey defends the login, so it does nothing about a consent grant a user approves after a legitimate passkey sign-in, or about a session token replayed if the token is not bound to the device.
So passkeys are necessary and powerful, and they are not a complete answer by themselves. The login is only one of two layers. AitM targets the session that sits behind the login, and consent phishing targets the authorization that sits behind it. Defending both layers is the whole game, which is why Microsoft's own guidance pairs "passwordless solutions like passkeys" with risk-based conditional access and app consent policy rather than treating any one control as sufficient (Microsoft Security).
This is also what separates AitM from its cousin, device code phishing. In device code phishing the attacker uses the real Microsoft domain with no lookalike at all, which is a distinct failure mode covered in our companion post on device code phishing and ClickFix. AitM does present a lookalike domain, which is precisely why a properly enforced passkey can reject it, and why closing the fallback gap matters so much.
The detection surfaces defenders actually have
Because the authentication succeeds legitimately, you will not catch AitM by watching for failed logins. You catch it after the token lands, in identity telemetry and session behavior. These are the surfaces that carry real signal.
Impossible travel and geo-velocity
The victim authenticates from their normal location; minutes later the same session is used from the attacker's infrastructure, often a datacenter ASN in another region. A sign-in and a session action that are physically incompatible in time are one of the clearest AitM tells. Alert on impossible-travel and on session activity from hosting-provider IP ranges that the user never legitimately uses.
New-device and new-fingerprint token use
A replayed token arrives on hardware and a browser fingerprint the user has never presented before. Flag a known user session suddenly operating from an unfamiliar device, user agent, or TLS fingerprint, especially when it appears immediately after a successful sign-in from the real device.
Token reuse and session anomalies
The same session token appearing from two divergent contexts at once, or a refresh token being redeemed from a new network, is the core artifact of session theft. Continuous access evaluation exists to catch exactly this: it lets the identity provider re-check session validity mid-session instead of trusting a token blindly until it expires. Wire session and token anomalies into your SIEM and treat token-context divergence as high severity.
Mail-rule and post-compromise behavior
Once inside, AitM operators frequently create inbox rules to hide replies, register a new MFA method to establish their own persistence, or send internal business-email-compromise messages. Alert on new MFA-method registration right after a sign-in anomaly, on suspicious inbox-forwarding or hide-rule creation, and on first-time mass-mail behavior from an account.
OAuth consent and app-grant anomalies
For the consent-phishing side, the signal is a new delegated-access grant to an unverified or newly registered app, a spike in permissions requested, or an app requesting mail and file scopes it has no business reason to hold. Microsoft's app governance in Defender for Cloud Apps surfaces which user-installed OAuth apps have access and what permissions they hold, and its risky OAuth app investigation workflow is built for triaging exactly these grants.
The layered defense playbook
Prioritize the controls that remove capability over the ones that merely add friction. In rough order of leverage:
1. Deploy phishing-resistant, token-bound authentication, and close the fallback
Roll out FIDO2 passkeys and phishing-resistant MFA, and then do the part organizations skip: remove or tightly restrict the weaker fallback factors for the same accounts, so an attacker cannot route around the passkey. Where the platform supports it, bind tokens to the device so a copied token fails off-device. Microsoft calls passwordless "essential," paired with conditional access (Microsoft Security).
2. Enforce conditional access with continuous access evaluation
Require compliant or managed devices for sensitive applications, restrict access from anonymizing and hosting-provider networks, and turn on continuous access evaluation so a session can be re-evaluated and cut mid-flight when risk rises, rather than trusting a token until it expires. This is the control that turns a stolen token from a 90-minute problem into a 90-second one.
3. Shorten token lifetimes and make revocation fast
The window a stolen token stays useful is a policy choice. Shorter sign-in frequency for high-value apps and a rehearsed, one-click revoke-all-sessions capability shrink the blast radius. When Obsidian is measuring 9-minute exfiltration times, revocation speed is a frontline control, not a cleanup step (Obsidian Security).
4. Govern OAuth consent
Restrict end-user consent so users can only approve apps from verified publishers requesting low-risk permissions, and route everything else to admin review. Microsoft's managed consent policy, enabled by default from July 2025, already blocks users from granting third-party apps access to their files and sites out of the box (Microsoft Entra). Layer app governance monitoring on top to catch grants that slip through.
5. Instrument the session layer and rehearse the response
Feed identity and session telemetry into detection, alert on the surfaces above, and practice the response: isolate the account, revoke sessions and refresh tokens, remove attacker-added MFA methods and inbox rules, and hunt for the OAuth grants and lateral movement that follow. Detection without a rehearsed revoke-and-evict runbook still loses the 9-minute race.
6. Train against the specific pattern, not generic phishing
Awareness training that says "look for a suspicious sender" does not inoculate against a relay that shows the real login. Teach the specific tells that matter here, reinforce reporting, and, most importantly, test the controls rather than trusting the slide deck.
How Stingrai helps
No AitM or consent-phishing control is proven until an adversary actually tries it against your people and your tenant. A conditional access policy that looks correct in the portal can still leave a fallback factor or a legacy authentication path open, a passkey rollout can quietly still permit password login, and a workforce that passed last year's phishing test can still complete MFA on a relayed login page.
Stingrai is an offensive security and PTaaS firm founded in 2021, headquartered in Toronto with a London office, and a firm-level CREST-accredited penetration testing service provider. Our social engineering and phishing simulation work tests exactly this failure mode: whether your users complete authentication on a relayed login, whether your conditional access and passkey enforcement actually block the session theft, whether a consent prompt gets approved, and whether your detection and response teams catch the impossible-travel, new-device, and token-reuse anomalies before an attacker pivots to business email compromise. Our adversary simulation and red team engagements chain an initial identity foothold into the lateral movement and data access a real operator would attempt, so you see the full blast radius, not just a click rate. For the broader data behind these lures, see our 2026 phishing statistics reference.
The output is evidence you can act on and evidence your auditors accept. Stingrai's penetration testing and social engineering assessments support your SOC 2, ISO 27001, PCI DSS, and HIPAA compliance programs by demonstrating that your identity controls hold under realistic attack. For engagement scoping and pricing, see the Stingrai pricing page.
Frequently asked questions
What is adversary-in-the-middle (AitM) phishing and how does it bypass MFA?
AitM phishing places an attacker-controlled relay between the victim and the real identity provider. The victim signs in and completes MFA on the genuine login through the relay, and the attacker copies the session token the identity provider issues afterward, then replays it. It bypasses MFA because the authentication genuinely succeeds; the victim performs it, so no SMS, TOTP, or push factor is ever defeated (Microsoft Security). Obsidian Security found MFA failed to prevent the attack in 84% of its incident responses.
Can passkeys stop AitM phishing?
Mostly, if enforced correctly. A FIDO2 passkey is bound to the real origin, so it refuses to authenticate on a lookalike relay domain and stops the AitM login. The catch is the fallback: if the same account still allows a password or a weaker MFA method, an attacker simply steers the victim to that path and the passkey never engages. Passkeys are essential, but they must be paired with removed fallbacks, conditional access, and session controls to fully close the gap (Microsoft Security).
What is OAuth consent phishing and how is it different from AitM?
OAuth consent phishing tricks a user into granting a malicious application standing delegated access through a legitimate consent screen, so the attacker gets a durable app token instead of a stolen session. It bypasses MFA for the same reason AitM does, the grant happens after a real login, but it is more persistent: the access survives password resets and lasts until an admin revokes the grant. Proofpoint tracked malicious apps impersonating 50+ brands that succeeded in more than half the environments where users authorized them (Proofpoint).
How do I detect AitM and session-token theft?
Watch the session and identity layers, not failed logins. The highest-signal detections are impossible travel and sign-ins from hosting-provider networks, a known session appearing on a new device or browser fingerprint, the same token used from two contexts at once, and post-login anomalies such as new MFA-method registration or inbox hide-rules. Continuous access evaluation lets the identity provider re-check and cut a risky session mid-flight rather than trusting a token until it expires (Obsidian Security).
How do I prevent OAuth consent phishing?
Restrict end-user consent so users can only approve apps from verified publishers requesting low-risk permissions, and send everything else to admin review. Microsoft's managed consent policy, on by default since July 2025, already blocks users from granting third-party apps access to their files and sites, and app governance in Defender for Cloud Apps surfaces risky and over-permissioned grants for revocation (Microsoft Entra).
How fast do these attacks move once they succeed?
Fast enough that revocation speed is a frontline control. Obsidian Security observed a fastest time from initial access to data exfiltration of just 9 minutes, and AitM operators routinely establish persistence within minutes by adding their own MFA method or mailbox rules (Obsidian Security). A rehearsed revoke-all-sessions and evict runbook is what closes that window.
References
Microsoft Security. Breaking the code: Multi-stage code of conduct phishing campaign leads to AiTM token compromise. May 2026. https://www.microsoft.com/en-us/security/blog/2026/05/04/breaking-the-code-multi-stage-code-of-conduct-phishing-campaign-leads-to-aitm-token-compromise/. Analysis of a three-day AitM campaign hitting 35,000+ users across 26 countries, with real-time token capture and defensive guidance.
Obsidian Security. 2025 SaaS Security Threat Report. January 2025. https://www.obsidiansecurity.com/news/obsidian-security-launches-2025-saas-security-threat-report. Telemetry showing MFA failed in 84% of incident responses, 99% of SaaS compromises originating at the identity provider, a 300% breach surge, and 9-minute exfiltration.
Obsidian Security. Token-Based Attacks: How Attackers Bypass MFA. 2026. https://www.obsidiansecurity.com/blog/token-based-attacks-how-attackers-bypass-mfa. Analysis of token theft, a 146% rise in AitM attacks, and why MFA protects the login moment but not the session.
Proofpoint. Microsoft OAuth App Impersonation Campaign Leads to MFA Phishing. July 2025. https://www.proofpoint.com/us/blog/threat-insight/microsoft-oauth-app-impersonation-campaign-leads-mfa-phishing. Documentation of malicious OAuth apps impersonating 50+ brands, hitting nearly 3,000 accounts across 900+ Microsoft 365 environments with over 50% success.
Microsoft Security. Inside Tycoon2FA: how a leading AiTM phishing kit operated at scale. March 2026. https://www.microsoft.com/en-us/security/blog/2026/03/04/inside-tycoon2fa-how-a-leading-aitm-phishing-kit-operated-at-scale/. Teardown of a phishing-as-a-service kit sending tens of millions of messages monthly and capturing session cookies in real time.
Microsoft Security. Defending against evolving identity attack techniques. May 2025. https://www.microsoft.com/en-us/security/blog/2025/05/29/defending-against-evolving-identity-attack-techniques/. Guidance pairing passkeys with risk-based conditional access and app consent policy against AitM and consent phishing.
Push Security. 2025's top phishing trends. 2026. https://pushsecurity.com/blog/2025-top-phishing-trends. Analysis showing most phishing now uses a reverse proxy and roughly 1 in 3 attacks arrive outside of email.
Microsoft Entra. Protect against consent phishing. Microsoft Learn. https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/protect-against-consent-phishing. Configuration guidance for user-consent restriction, the default managed consent policy, and app governance.
Microsoft Defender for Cloud Apps. Investigate and remediate risky OAuth apps. Microsoft Learn. https://learn.microsoft.com/en-us/defender-cloud-apps/investigate-risky-oauth. Workflow for detecting over-permissioned and anomalous OAuth grants and revoking them.
MITRE ATT&CK. Adversary-in-the-Middle (T1557), Steal Web Session Cookie (T1539), Steal Application Access Token (T1528). https://attack.mitre.org/techniques/T1557/. Technique references mapping AitM positioning, session-cookie theft, and OAuth token abuse.
