Passkey and Identity Phishing Evolutions: Beyond the Pretext — AiTM, Device Code, and Helpdesk Social Engineering Defenses

Adversary-in-the-middle proxies, device code abuse, and a phone call to the helpdesk have replaced the fake login page as the way attackers get past MFA. Here's what the current playbooks look like and what actually stops them.

MFA killed off the old style of credential phishing, and for a while it worked. Then attackers stopped trying to guess or steal passwords outright and started stealing the thing that comes after a successful login: the session itself. That shift is why 2025 and 2026 have been dominated by three techniques that don't defeat authentication so much as ride along behind it — adversary-in-the-middle (AiTM) proxies, device code phishing, and a much older trick, the phone call, aimed squarely at IT helpdesks.

This piece builds on Microsoft's own research into these techniques and lays out the current attacker playbooks, what the evidence actually supports about each one, and the layered defenses — Conditional Access, phishing-resistant authentication, and helpdesk process controls — that close the gaps.

Why MFA alone stopped being enough

Traditional MFA — SMS codes, authenticator app push notifications, time-based one-time passwords — proves that a person has a second factor at the moment they log in. It says nothing about what happens to the session token issued afterward. Microsoft's Deputy CISO for Identity, Igor Sakhnov, wrote in May 2025 that despite the rise of MFA and passwordless adoption, social engineering remains a core part of how these attacks succeed.[1] Among Microsoft Incident Response cases where the initial access vector was identified, close to a quarter involved phishing or social engineering.[1]

That's the pattern running through all three techniques below. None of them "break" MFA cryptographically. They route around it by targeting the session, the token-issuance flow, or the human being on the other end of a support ticket.

AiTM phishing: stealing the session, not the password

An AiTM attack works by putting a reverse proxy between the victim and the real login page. The victim thinks they're on Microsoft's sign-in page. They aren't — they're on a near-identical copy hosted by the attacker, which quietly forwards every keystroke, password, and MFA response to the genuine identity provider in real time. Because the session really is authenticating, the MFA prompt goes through normally. Push notifications get approved. Authenticator codes get accepted. The user has no reason to suspect anything is wrong.

What the attacker actually wants is the session cookie issued at the end of that exchange. Once captured, it can be loaded into the attacker's own browser to impersonate the victim without triggering another MFA prompt — the session is already validated. Microsoft Defender Researchers documented one such campaign in January 2026 that targeted multiple organizations in the energy sector by abusing SharePoint file-sharing links as the phishing delivery mechanism.[2] The lure came from an email address belonging to a trusted, likely already-compromised, vendor, and used subject-line mimicry consistent with legitimate SharePoint sharing notifications to get the click.[2] Once inside, the attacker signed in from a separate IP address, created an inbox rule to delete and mark all incoming mail as read, then used the compromised account to send more than 600 phishing emails to the victim's own contacts and distribution lists, sourced from recent email threads.[2] Recipients who questioned the emails' legitimacy got replies from the attacker, posing as the victim, reassuring them — then those replies were deleted from the mailbox to keep the victim unaware.[2] That's the business email compromise (BEC) pivot: AiTM as the entry point, mailbox manipulation as the persistence and profit mechanism.

This isn't a one-off. Microsoft's own May 2025 identity report tracked Storm-0485 directing targets to Evilginx AiTM infrastructure using payment-remittance and shared-document lures, and noted the same open-source Evilginx framework has been used by threat actors ranging from commodity phishing operators to the Russian state-linked actor Star Blizzard.[1] Separately, Sekoia's threat research team identified 11 distinct AiTM phishing kits operating commercially between January and April 2025, with the kit known as Tycoon 2FA leading in prevalence.[3] Microsoft has published its own technical breakdown of how that kit operates at scale, and the Canadian Centre for Cyber Security's review of more than 100 AiTM campaigns against Entra ID accounts found that by August 2024, nearly all observed campaigns had shifted from simple credential harvesting to proxy-based session theft, with the large majority pivoting into BEC.[3]

The remediation detail worth sitting with: Microsoft's guidance is explicit that a password reset alone does not remediate an AiTM compromise, because the stolen session cookie remains valid independent of the password.[2] Organizations have to revoke active sessions, check for attacker-created inbox rules, and review whether MFA methods were altered during the compromise window.[2]

Device code phishing: abusing a flow built for TVs and printers

Device code authentication exists for a legitimate reason: it lets a device with no keyboard or browser — a smart TV, a CLI tool, a conference room system — get a user to authenticate on a separate device instead. The flow generates a short code, the user visits a generic sign-in page on their phone or laptop, types the code, and approves. It's genuinely useful, and it's also become one of the more effective phishing techniques of the past two years, because the entire authentication happens on Microsoft's real login page. There's no fake site to spot.

Microsoft first disclosed this technique publicly in February 2025, attributing an active campaign to a threat cluster it tracks as Storm-2372, assessed with moderate confidence to align with Russian state interests.[4] The activity had reportedly been running since August 2024, targeting governments, NGOs, and organizations across telecom, healthcare, defense, and energy sectors in Europe, North America, Africa, and the Middle East.[4][5] Microsoft has since updated its assessment to place Storm-2372 as an initial-access sub-cluster of the broader group it tracks as Midnight Blizzard.[4]

The social engineering here is patient rather than urgent. The attacker builds rapport first — impersonating a known contact over WhatsApp, Signal, or Teams — before sending what looks like a genuine online meeting invitation.[5][6] The invite contains an attacker-generated device code. Clicking through takes the victim to Microsoft's actual device-login page, where entering the code hands the attacker a valid access and refresh token, enough to read email and pull data through the Graph API without ever needing the victim's password.[6]

The technique hasn't stayed niche. Microsoft's May 2025 identity report separately flagged Storm-1249, a China-based actor, using generic tax and civil-service themed lures for the same device code technique.[1] By late 2025 and into 2026, security researchers reported the tactic spreading into commercial phishing-as-a-service kits — Huntress documented a March 2026 surge tied to a kit called EvilTokens, and noted other criminal platforms building device code phishing into their offerings.[7] The Hacker News, citing threat intelligence from Amazon and Volexity, reported in March 2026 that a device code phishing wave had hit more than 340 Microsoft 365 organizations across five countries, with attackers routing malicious links through legitimate security-vendor redirect services from Cisco, Trend Micro, and Mimecast to slip past spam filters.[8]

Microsoft has also observed the technique used for lateral movement after an initial compromise: Storm-2372 sends internal emails from already-compromised accounts containing new device code payloads, exploiting the fact that colleagues are more likely to trust a message from someone they know.[1] Because device codes expire after roughly 15 minutes, this shows up as repeated waves of internal phishing rather than a single attempt.[1]

Helpdesk social engineering: the pretext that skips the technology entirely

Not every identity attack needs a phishing kit. The technique most associated with the group tracked as Scattered Spider (also known as UNC3944 or Octo Tempest) doesn't touch the authentication protocol at all — it targets the humans responsible for resetting it.

The joint advisory from CISA, the FBI, and international partners, updated July 29, 2025, describes the pattern directly: threat actors pose as company IT or helpdesk staff over phone calls or SMS to obtain credentials, and separately pose as employees calling the helpdesk to get a password reset or have MFA transferred to a device they control.[9] The advisory notes the group conducts reconnaissance on business-to-business sites first to establish an employee's role, then runs the social engineering across several calls — first learning what a helpdesk requires to process a reset, then gathering that specific information for a targeted employee, and only then placing the call that requests the actual reset.[9] The advisory also documents MFA fatigue as a parallel tactic — bombarding a target with repeated approval prompts until one gets accepted out of exhaustion.[9]

This is deliberately low-tech, and that's the point. There's no malware to detect and no phishing link to flag, because the compromise happens through a legitimate support channel doing exactly what it's designed to do — just for the wrong person. A July 2026 Justice Department complaint against an alleged member of the group described helpdesk social engineering and MFA resets tied to more than 100 intrusions.[10] Because the CISA advisory and years of incident write-ups have made the playbook public, security researchers now report copycat and lower-tier actors running the same MFA-reset pretexts against smaller organizations that never expected to be a Scattered Spider target.[10]

CVSS and severity: why this category resists a single score

Unlike a single CVE, these techniques don't have a CVSS score, because none of them exploit a software vulnerability. AiTM, device code phishing, and helpdesk social engineering all abuse legitimate, correctly functioning features — reverse proxies, an OAuth device authorization grant, and a support process. Microsoft has stated plainly that device code phishing reflects an industry-standard authentication flow being abused, not a vulnerability unique to Microsoft's codebase.[4] Severity here is better measured by blast radius and detection difficulty than by a technical score: a successful AiTM or device code compromise hands the attacker a fully authenticated session that legacy MFA cannot distinguish from the real thing, and a successful helpdesk pretext hands them account control outright.

Layered defenses that actually close these gaps

No single control stops all three techniques, which is why Microsoft, CISA, and the broader identity security community converge on the same layered approach rather than a silver bullet.

Phishing-resistant authentication

CISA's guidance identifies exactly two authentication approaches that meet the phishing-resistant bar: FIDO2/WebAuthn (including passkeys) and PKI-based authentication such as PIV and CAC smart cards.[11] The reason is structural rather than a matter of degree. FIDO2 binds the authentication assertion cryptographically to the legitimate site's origin using a private key that never leaves the user's device, so there's no shared secret — no code, no push approval — for an AiTM proxy to intercept and relay.[11][12] SMS codes, TOTP apps, and standard push approvals are explicitly excluded from CISA's definition of phishing-resistant, because all three can be captured or relayed by a well-built proxy.[12] Microsoft's own recommendations echo this directly, pointing organizations toward FIDO2 security keys, passkeys through Microsoft Authenticator, and certificate-based authentication, with phishing-resistant MFA prioritized first for privileged and admin accounts.[1]

Conditional Access, scoped to the actual risk

Conditional Access policies don't replace strong authentication, but they narrow the window an attacker can operate in even after a token is stolen. Microsoft recommends risk-based Conditional Access that evaluates sign-in requests against signals like device compliance, IP location, and group membership, and specifically calls out requiring compliant or managed devices as a control that forces an attacker to either compromise a managed endpoint or fail the check entirely.[2] Microsoft's Entra team has also detailed network-boundary restrictions that confine token issuance to defined IP ranges, and continuous access evaluation (CAE), which allows session risk signals to revoke a token in near real time rather than waiting for the next sign-in.[2][13]

For device code phishing specifically, Microsoft's advice is more direct: block the device code authentication flow entirely where it isn't operationally needed, and where it is needed, scope it through Conditional Access authentication flow policies rather than leaving it open tenant-wide.[1] The same report flags two related flows worth locking down alongside it — OAuth consent phishing, mitigated through app consent policies that restrict which applications users can authorize, and device join phishing, mitigated by requiring authentication strength for device registration.[1]

Helpdesk process controls

Technology doesn't fix a helpdesk that trusts urgency over verification. CISA's advisory and follow-on industry analysis both point to the same fix: out-of-band identity verification before any password reset or MFA re-enrollment, meaning the helpdesk confirms the request through a channel the attacker doesn't control — a callback to a number already on file, a supervisor confirmation, or camera-on verification — rather than accepting whatever detail the caller supplies.[9][10] Security Boulevard's 2026 review of the group's ongoing activity put it plainly: the strongest phishing-resistant key in an organization's deployment doesn't help if the helpdesk can be talked into replacing it after one convincing phone call.[10] CISA further recommends pairing this with policies that restrict who can approve a factor enrollment or recovery in the first place, and running realistic vishing simulations against helpdesk staff the same way phishing simulations are run against general employees.[9][10]

Monitoring and user awareness

Detection still matters because prevention won't be perfect. Microsoft Defender XDR raises specific alerts for stolen session cookie reuse and possible AiTM attempts, drawing on signals from Defender for Cloud Apps and Entra ID Protection, including anomalous token and impossible-travel detections.[2] Attack simulation training — including simulated phishing delivered through Teams, not just email — is part of Microsoft's standing recommendation, on the reasoning that as lure quality improves with AI assistance, technical controls need a trained human backstop rather than relying on people to spot a bad link.[1]

What defenders should prioritize first

Given limited time and budget, the evidence points toward a rough order: privileged and admin accounts move to FIDO2 or passkeys first, since that's where Microsoft's own guidance places the priority.[1] Device code flow gets blocked or scoped tenant-wide next, since it's a narrow, well-defined control with low operational cost for most organizations.[1] Helpdesk reset procedures get an out-of-band verification step added, since this closes the one technique in this article that no amount of cryptography prevents.[9][10] And Conditional Access policies requiring compliant devices and risk-based sign-in evaluation get layered on top, since they reduce the blast radius of whichever technique still gets through.[2]

Security takeaway

The throughline across AiTM, device code phishing, and helpdesk social engineering is that each one treats a real, correctly functioning system feature as the attack surface — a session cookie, an authentication flow built for headless devices, a support process built to help people who are actually locked out. None of that is a bug to patch. It's why phishing-resistant authentication, Conditional Access, and helpdesk verification controls have to work together: authentication strength closes the door that AiTM and device code phishing walk through, and process controls close the door that no authentication method can close on its own.

Sources & References

1. [1] Microsoft Security Blog — Igor Sakhnov — "Defending against evolving identity attack techniques" — May 29, 2025 — View source
2. [2] Microsoft Defender Security Research Team — "Resurgence of a multi-stage AiTM phishing and BEC campaign abusing SharePoint" — January 21, 2026 — View source
3. [3] Startup Defense — "Adversary-in-the-Middle Phishing: How AiTM Bypasses MFA" — 2025 (citing Sekoia Threat Detection & Research, 2025, and the Canadian Centre for Cyber Security) — View source
4. [4] Microsoft Security Blog — "Storm-2372 conducts device code phishing campaign" — published February 13, 2025, updated through July 31, 2026 — View source
5. [5] H-ISAC — "TLP White Threat Bulletin: Storm-2372 Conducts Device Code Phishing Campaign" — February 14, 2025 — View source
6. [6] NASCUS (citing Microsoft) — "Microsoft: Hackers Steal Emails in Device Code Phishing Attacks" — 2025 — View source
7. [7] Huntress — "We Need to Talk About Device Code Phishing" — 2026 — View source
8. [8] The Hacker News — "Device Code Phishing Hits 340+ Microsoft 365 Orgs Across Five Countries via OAuth Abuse" — March 2026 — View source
9. [9] CISA, FBI, RCMP, ASD's ACSC, AFP, CCCS, NCSC-UK — Joint Cybersecurity Advisory AA23-320A, "Scattered Spider" — originally published November 16, 2023, updated July 29, 2025 — View source
10. [10] Security Boulevard — "Scattered Spider's Playbook: What You Need to Know in 2026" — September 2026 — View source
11. [11] TokenCore — "Understanding CISA's Phishing-Resistant MFA Recommendations" — View source
12. [12] ScrambleID — "What Is Phishing-Resistant MFA? The Authentication Bar That AI Cannot Defeat" — View source
13. [13] Microsoft Tech Community, Microsoft Entra Blog — "Defeating Adversary-in-the-Middle phishing attacks" — View source

Disclaimer: This article summarizes publicly available threat intelligence and vendor guidance current as of publication. Threat actor tactics evolve quickly; verify Conditional Access and authentication policy recommendations against your identity provider's current documentation before deployment.