Phishing-proof MFA stops help-desk AiTM vishing

A spoofed help-desk number, a rushed passkey-migration script, and an organisation-branded sign-in page that quietly relays every password and MFA response. That combination is how the Canadian Centre for Cyber Security's AL26-028 campaign turns workforce trust into attacker-held Microsoft 365 sessions. According to the Canadian Centre for Cyber Security advisory published 28 October 2026, callers impersonating internal IT direct employees onto adversary-in-the-middle pages that complete a real identity-provider login for the actor, then register attacker-controlled MFA methods and pull SharePoint and OneDrive content before extortion. Phishing-resistant origin-bound factors shrink the relayable surface this help-desk AiTM wave exploits; phishing-proof device-bound MFA across the full identity lifecycle closes the coached fake-login path that conventional OTP and push leave open.

Help-desk calls that finished real M365 logins for attackers

Public reporting on AL26-028 describes a voice-led path into cloud workforce identity, not malware dropped on the first ring.

Callers claim urgent passkey migration, MFA enrolment, or password changes. They hit personal mobiles, office phones, or Microsoft Teams, and may spoof legitimate help-desk numbers so the ring looks internal. Once the employee accepts the urgency, the script points them at lure hostnames that pair the organisation name with domains such as onetimesso[.]com, registermymfa[.]com, and SSO-styled sso[.]com names. Action words sit next to passkey, MFA, and SSO terms so the hostname reads like a temporary enrolment portal. Those domains rotate often enough that blocklists trail the campaign.

An adversary-in-the-middle attack is a reverse-proxy login path that sits between the user and the real identity provider, capturing what the user types and what the MFA channel returns while still completing a valid sign-in at the real IdP. That is the page these victims land on after the call. According to the Cyber Centre, "The page relays credentials and MFA responses to the legitimate identity provider, providing the actor with an authenticated session." The same advisory states the campaign "bypasses conventional multi-factor authentication (MFA) through real-time relay and frequently rotates lure domains, limiting the effectiveness of blocklists."

Finance and legal organizations have taken the brunt. Related infrastructure naming Canadian organizations was identified from January 2026, with heavier finance and legal targeting from July and a legal-sector concentration in October 2026. Specific victim organization names are not disclosed. Exact victim or record counts have not been published. Ransom dollar figures are not in the disclosure.

With a live session, operators register attacker-controlled MFA methods or devices, delete password-reset and MFA-change notifications, reset passwords on non-SSO applications, and access Microsoft 365 content including SharePoint and OneDrive through Microsoft Graph and connected SaaS before sending extortion demands.

The advisory notes that tradecraft and infrastructure are consistent with publicly reported financially motivated operations, with footnotes pointing at UNC6671 multi-brand vishing extortion activity and adjacent BlackFile reporting. That is tradecraft alignment, not a courtroom naming of every intrusion to one crew.

If you want more detailed information about this attack, read the related post on legacymfa.sucks: Canadian help-desk vishing that stole M365 sessions.

Why conventional second factors still fed the AiTM proxy

The failure is not that MFA was missing. The failure is that the second factor was transferable in real time.

On the branded page the employee enters a password and completes whatever conventional factor the organisation still accepts. The proxy forwards both to the legitimate identity provider live. A correct OTP, SMS code, or push approval does not save that login. The factor worked. It also worked for the attacker, because the ceremony completed through the proxy. The IdP sees a normal successful authentication and issues session material the actor can reuse against Microsoft 365 and connected SaaS without another prompt at the real origin.

SSO and federation amplify the damage. One stolen cloud session becomes a skeleton key across mail, files, chat, and other integrated apps without a fresh proof at each boundary. Zero-trust language says never trust and always verify. Classic SSO auto-sign-on does the opposite once that token exists.

Public materials do not name a specific MFA product brand beyond conventional MFA. They also do not pin a precise identity provider beyond the Microsoft 365 flows implied by later Graph, SharePoint, and OneDrive access.

Persistence after the login is a second problem with the same root. Session-authenticated self-service lets the actor add their own MFA methods or devices, silence security mail, and reset passwords on apps outside SSO. Login cryptography alone does not unwind work already done with a session the IdP already issued. If the coached AiTM login never completes, the session used for factor enrollment and Graph collection never exists.

Removing the transferable factor stops this attack path. Malware on a machine that already holds a legitimate session is a different and harder problem.

Device-bound phishing-proof authentication against this wave

The Cyber Centre recommends phishing-resistant MFA such as FIDO2 security keys, device-bound passkeys, or platform authenticators. That recommendation targets the exact ceremony AL26-028 abuses.

Phishing-resistant login factors bind the signature to the real origin. A reverse proxy on a lookalike hostname cannot complete the same relay that harvests passwords and OTP or push responses. The private key never leaves the enrolled device, and there is no reusable secret for the help-desk coach to harvest on the fake page. Device-bound phishing-proof authentication goes further: no phishable factor appears at registration, device onboarding, authorisation, authentication, or decommissioning. That full-lifecycle coverage is what moves the control from resistant at login to proof across identity.

Against AL26-028 that means two concrete outcomes. First, the branded AiTM page has nothing useful to capture. The employee cannot type a password or approve a push that the proxy can forward, because those factors are not part of the ceremony. Second, adding a new device requires an already-enrolled device, not a coached enrolment code or a session-only self-service click after a phished login. The phone call still happens. The harvestable surface does not.

For sessions already issued before a cutover, revoke access and refresh tokens, tighten continuous access evaluation, and hunt for attacker-registered authenticators. That is cleanup. It is not a substitute for closing the login path. Shortening token lifetime only forces the attacker to re-use or re-steal sooner. If they already enrolled their own factor during the window, lifetime limits stop mattering.

Classic SSO still conflicts with zero trust even after the login is hardened. One shared federation cookie remains a multi-app blast radius if anything else ever issues it. Secure Explicit Sign-On keeps the same one-tap user experience while authenticating each application with its own fresh, device-bound signature. No shared reusable token exists to replay across mail, files, and SaaS after a single proof. That architecture shrinks the skeleton-key problem AL26-028 turns into extortion leverage.

The prevention-focused design treats the coached fake page as a wrong origin with no secret to steal, not as a detection problem after the fact. The enrolment model keeps device onboarding on already-trusted hardware so a stolen cloud session is not enough to plant a durable attacker factor.

Passkeys and FIDO2 against reverse-proxy login

FIDO2 and device-bound passkeys put a key pair on the enrolled hardware. The private key never leaves that hardware. Each login produces an origin-bound signature that a lookalike host cannot replay to the real identity provider. Industry language correctly calls that phishing-resistant for the authentication act. On a generic enterprise IdP that issues only hardware-bound signatures, the employee taps an already-enrolled device; the proxy on registermymfa-style infrastructure receives no OTP, no push approval, and no password to forward. That is the control surface the Cyber Centre is pointing Canadian organisations toward for this wave.

Closing enrollment after the passkey-migration lure

AL26-028's social script leans on passkey migration and MFA enrolment urgency. That is not accidental. Phishing-resistant login still leaves a gap if enrollment, recovery, or new-device onboarding reintroduces email codes, SMS, or session-only self-service factor add. An attacker who already holds a cloud session can register their own method and look legitimate on the next visit. Phishing-proof coverage forbids phishable factors at every lifecycle stage, so the migration lure has no enrolment secret to coach and no soft path to plant a second device after a stolen session. Tailor policy to this campaign: require an already-enrolled device for any authenticator change, alert out-of-band on factor adds, and treat help-desk identity claims as untrusted until verified on a published callback path.

Key Takeaways for Defenders

• Replace password-plus-OTP or push at the workforce IdP with origin-bound, device-bound authenticators so branded AiTM pages cannot complete a live relay.
• Require an already-enrolled device for any new MFA method, passkey migration, or recovery action; block session-only self-service factor add.
• Monitor and alert on MFA method registration, security-notification deletion, and password resets on non-SSO apps after any suspected help-desk contact.
• Prefer per-app device-bound proof over classic SSO auto-login so one cloud session is not a skeleton key across Graph-connected SaaS.
• Keep revoke, Conditional Access, and endpoint controls for residual malware after a legitimate login; do not treat them as the primary answer to this vishing-plus-AiTM path.

Canadian legal and finance teams still accepting transferable second factors are offering exactly the surface this playbook is built to harvest. Close the ceremony, and the reverse proxy has nothing left to sell.

FAQ

Would FIDO2 or device-bound passkeys have stopped the AL26-028 login relay?

FIDO2 or device-bound passkeys would have stopped the AL26-028 login relay at the authentication ceremony because those factors are origin-bound and do not produce a reusable OTP, SMS code, or push approval a reverse proxy can forward. According to the Canadian Centre for Cyber Security, AL26-028 succeeds by relaying credentials and conventional MFA responses to the legitimate identity provider; phishing-resistant hardware-bound signatures remove that transferable surface. Full phishing-proof coverage still matters for enrollment and recovery after any other path issues a session.

Does phishing-proof MFA undo SharePoint theft after AL26-028 already holds a session?

Phishing-proof MFA does not undo SharePoint or OneDrive theft after AL26-028 already holds an authenticated Microsoft 365 session. Authentication has already succeeded, and Graph access with that session is post-login work. Stopping the AiTM page from minting the session is what prevents that access. Revoke tokens, remove attacker-registered MFA methods, and hunt exfiltration for cleanup.

Why recommend Secure Explicit Sign-On instead of classic SSO after this campaign?

Secure Explicit Sign-On is the better fit after AL26-028 because classic SSO turns one stolen cloud session into multi-app access across mail, files, and connected SaaS without a fresh proof. SES keeps one-tap UX while each application receives its own fresh device-bound signature, so there is no shared federation cookie to replay as a skeleton key. That design matches zero-trust "always verify" better than auto-login from a single IdP token.

How should enrollment change when attackers use passkey-migration vishing scripts?

Enrollment should require an already-enrolled device for any passkey migration, MFA add, or recovery step when attackers use AL26-028-style passkey-migration vishing scripts. Session-only self-service factor registration is how operators plant durable access after a stolen login. Phishing-proof lifecycle policy removes email OTP, SMS, and other transferable enrollment secrets so the help-desk coach has nothing to harvest on a fake migration page.

What is the first control change Canadian workforce IdPs should make against AL26-028?

The first control change Canadian workforce IdPs should make against AL26-028 is retiring password-plus-OTP or push at interactive cloud login in favor of origin-bound device-bound authenticators. The Cyber Centre explicitly recommends phishing-resistant MFA such as FIDO2 security keys, device-bound passkeys, or platform authenticators because real-time relay defeats conventional MFA. Pair that login change with hardened enrollment so attacker MFA registration cannot follow any residual session.