A help-desk number on the caller ID, a rushed story about mandatory passkey migration, and a link that looks like the company SSO page. That combination is how an ongoing campaign tracked as AL26-028 has been turning Canadian workforce logins into attacker-held Microsoft 365 sessions. According to the Canadian Centre for Cyber Security advisory published 28 October 2026, callers impersonating internal IT or help desk staff direct employees to organisation-branded adversary-in-the-middle sign-in pages that relay live credentials and conventional MFA responses to the legitimate identity provider, so the IdP issues a real authenticated session to the actor. Finance and legal organizations have taken the brunt, with related infrastructure noted from January 2026, heavier finance and legal targeting from July, and a legal-sector concentration in October 2026.
How fake IT calls steered staff onto branded sign-in lures
The opening move is not a novel exploit against the identity stack. It is a voice call that borrows trust from the help desk.
Callers claim urgent passkey migration, MFA enrolment, or password changes. They reach personal mobiles, office phones, or Microsoft Teams. Spoofed numbers make the ring look internal. The script piles on time pressure so the employee does not pause to verify through a known channel or a published IT callback path.
Once the victim accepts the story, the caller points them at a lure built to feel like the organisation's own sign-in or migration portal. The advisory notes lure hostnames that place the target organisation's name with domains including onetimesso[.]com and registermymfa[.]com, plus SSO-styled names built around sso[.]com. Action words sit next to passkey, MFA, and SSO terms so the hostname reads like a temporary enrolment site rather than a random phishing domain. Those hostnames 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.
Coaching someone through a fake login and talking support into handing over a recovery secret sit in the same social-engineering class. Public reporting on AL26-028 describes the coached fake-login path: the help-desk persona is the delivery mechanism for the branded AiTM page. The advisory does not document Temporary Access Pass handoffs or helpdesk password resets as the stated mechanism for this wave. Specific victim organization names are not disclosed in the Cyber Centre materials, and exact victim or record counts have not been published.
Similar reverse-proxy harvesting of workforce sessions showed up against UK industrial targets earlier in 2025, and helpdesk impersonation has unlocked employee password resets in other retail cases. AL26-028 pairs the voice trust play with a live MFA relay kit aimed at Canadian legal and financial workforces.
How the reverse proxy turned passwords and MFA into live sessions
On the branded page, the employee enters a password and completes whatever conventional second factor the organisation still accepts. The proxy forwards both to the legitimate identity provider in real time.
According to the Canadian Centre for Cyber Security, "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."
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.
| Control surface | What happened in AL26-028 | Why it failed |
|---|---|---|
| Caller ID trust | Spoofed help-desk numbers | Voice identity is forgeable |
| Password at login | Captured on branded AiTM page | Typed secret is transferable |
| Conventional MFA | OTP or push completed live | Response relayed to real IdP |
| Domain blocklists | Rotating org-branded lures | Lists trail new hostnames |
SSO and federation multiply the blast radius. One 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 reporting does not name a specific MFA product brand beyond conventional MFA. It also does not pin a precise identity provider beyond the Microsoft 365 flows implied by later Graph, SharePoint, and OneDrive access.
Key takeaways from the login stage:
- The phone call does not need malware on the endpoint to succeed.
- The branded lure exists to complete a real IdP ceremony for the actor.
- Conventional MFA that can be typed, approved, or read aloud is exactly what the relay consumes.
- Rotating org-themed domains blunt simple URL blocklists.
Attacker MFA methods, deleted alerts, and cloud data theft
With a live session, the operators do not stop at a one-time mailbox peek.
They register attacker-controlled MFA methods or devices so later access no longer depends on the original employee phone. They delete password-reset, MFA-change, and other security notifications that might tip the real user or the SOC. They reset passwords on non-SSO applications to widen the foothold. Then they access and exfiltrate data from Microsoft 365, including SharePoint and OneDrive, through Microsoft Graph and connected SaaS, and follow with extortion demands after theft.
That stretch is post-authentication work. No redesign of the login ceremony unwinds files already copied 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.
The Cyber Centre notes that tradecraft and infrastructure are consistent with publicly reported operations by a financially motivated threat actor. Footnotes point at UNC6671 multi-brand vishing extortion activity and adjacent BlackFile reporting. That is tradecraft alignment in the advisory, not a public naming of every AL26-028 intrusion to one courtroom-proven crew. Ransom dollar figures have not been reported in the disclosure.
Canadian defenders still running password-plus-OTP or push at the workforce IdP are offering the relayable surface this playbook is built to harvest. The Cyber Centre recommends phishing-resistant MFA such as FIDO2 security keys, device-bound passkeys, or platform authenticators, which change the login ceremony so a reverse proxy cannot complete the same relay. A fix that closes the social-engineering path across authentication and enrollment exists; the companion piece covers that path.
If you want to skip the attack details and go straight to what can stop this, read the related article on mfa2point0.com: how phishing-resistant MFA shrinks help-desk AiTM vishing.
FAQ
How did the AL26-028 attackers obtain Microsoft 365 access?
The AL26-028 attackers obtained Microsoft 365 access by coaching employees through organisation-branded adversary-in-the-middle sign-in pages after help-desk voice phishing calls. According to the Canadian Centre for Cyber Security, those pages relayed credentials and conventional MFA responses to the legitimate identity provider, which then issued authenticated sessions the actors could reuse.
Why did conventional MFA fail against this Canadian help-desk campaign?
Conventional MFA failed against the Canadian help-desk campaign because the second factor was completed on a reverse-proxy page that forwarded the live response to the real IdP. The OTP, SMS code, or push approval was valid; the actor simply received the session the IdP minted after that successful relay.
What did attackers do after they held a session in AL26-028?
After they held a session in AL26-028, attackers registered their own MFA methods or devices, deleted password-reset and MFA-change notifications, reset passwords on non-SSO applications, and accessed Microsoft 365 content including SharePoint and OneDrive via Microsoft Graph before sending extortion demands. Public materials do not publish victim names, record counts, or ransom amounts for those thefts.
Is AL26-028 the same as a helpdesk Temporary Access Pass handoff?
AL26-028 is not publicly described as a helpdesk Temporary Access Pass handoff. The Canadian Centre for Cyber Security details callers directing staff onto branded AiTM login pages that relay passwords and MFA responses. Helpdesk recovery social engineering and coached fake logins are the same attack class in principle, but this advisory's stated mechanism is the coached AiTM page.
Did the Cyber Centre name UNC6671 as the confirmed AL26-028 actor?
The Cyber Centre did not publish a definitive courtroom attribution of every AL26-028 intrusion to UNC6671. The advisory states that tradecraft and infrastructure are consistent with publicly reported financially motivated operations, with footnotes referencing UNC6671 multi-brand vishing extortion reporting and adjacent BlackFile coverage.
