The Guardian at the Gate Was the Intruder: How Passkey Phishing Turns Identity Security Against You
The most convincing intruder does not always try to break through the gate.
Sometimes, they stand beside it wearing the uniform of the person supposed to protect you.
That is the logic behind a cloud intrusion campaign documented by Microsoft since May 2026. Threat actors impersonated corporate IT help desks and contacted employees about urgent problems involving passkeys, MFA or SSO. The objective was not simply to steal a password. It was to convince victims to participate in the authentication process themselves.
Once the false guardian was trusted, the attackers could get through the gate, install their own key and begin systematically searching the Microsoft cloud environment for valuable information.
Here is how the attack unfolded, phase by phase.
Phase 1 — Study Who Lives Behind the Gate
Before impersonating the guardian, the attackers needed to know their victims.
Microsoft observed signs of extensive pre-attack research, likely using public sources such as social networks and professional profiling platforms to understand employees and organizational structures.
The attackers also registered domains themed around passkeys, SSO enrollment, account activation and identity verification, sometimes incorporating the targeted organization’s name into a subdomain.
The disguise was being prepared before the first conversation even began.
Phase 2 — Put On the Guardian’s Uniform
Then came the approach.
The attackers called or messaged employees on their personal phones while claiming to represent the organization’s IT help desk.
The warning created urgency: update your passkey, MFA or SSO configuration now or risk losing access.
In some cases, already-compromised Microsoft Teams accounts were also used to distribute similar passkey-themed messages.
The attacker did not look like someone trying to defeat security.
They looked like someone trying to help enforce it.
Phase 3 — Convince the Victim to Open the Gate
Victims were directed through SMS messages to counterfeit websites designed to resemble legitimate Microsoft authentication experiences.
From there, attackers guided them through adversary-in-the-middle or device-code authentication flows.
This distinction matters. In one attack pattern documented by Microsoft, device-code phishing allowed the attacker to gain control of an account without needing to steal the victim’s credentials or cookies, effectively bypassing the protection expected from MFA.
The gate was not forced open.
The victim was persuaded to authorize the person standing outside it.
Phase 4 — Make a Copy of the Key
Getting inside was only the beginning.
Microsoft observed attackers registering authentication methods under their own control, including new phone numbers, authenticator applications and software-based OTP tokens.
That transformed a temporary compromise into something far more valuable: persistence.
With an attacker-controlled second factor combined with valid credentials or sessions that had not been revoked, the threat actor could return to the corporate account without requiring the victim to participate again.
The false guardian was no longer borrowing the key.
They had installed their own.
Phase 5 — Learn Every Corridor
Once persistent access was established, the attackers began reconnaissance.
Using Microsoft Graph APIs, they could inventory users, groups, permissions, resources and accessible content across the tenant. They inspected roles, high-value accounts and service identities that could potentially provide opportunities for privilege escalation.
Mailbox messages, folders and attachment metadata could also be enumerated for intelligence collection.
Rather than immediately drawing attention to themselves, the intruders first learned what was behind every door and which doors were worth opening.
Phase 6 — Empty the Vault
Reconnaissance was followed by collection.
Microsoft observed high-volume access and downloads targeting SharePoint Online and OneDrive for Business and, in some cases, Microsoft Exchange Online.
The resulting data exfiltration could continue for several hours or multiple days, depending on how much information was available through the compromised identity.
The attackers also rotated infrastructure throughout the operation, using different IP addresses for authentication, reconnaissance and exfiltration to make network-based detection more difficult.
By this point, what began as an apparent IT support request had become sustained access to corporate cloud data.
Phase 7 — Identify the False Guardian
Defending against this attack requires looking beyond individual authentication events.
Unexpected IT requests involving passkeys, MFA or SSO should be independently verified through trusted corporate channels. Unsolicited enrollment links should never be treated as legitimate simply because they reproduce familiar Microsoft branding.
Organizations should also monitor newly registered authentication methods, sign-ins from unmanaged devices and suspicious changes to MFA configurations, while rapidly revoking compromised credentials and active sessions when suspicious activity is identified.
But Microsoft’s investigation highlights another important challenge: a single Microsoft Graph API call may appear completely legitimate.
The signal emerges from the sequence of behavior.
Authentication. New persistence. Reconnaissance. Mailbox enumeration. High-volume SharePoint or OneDrive access. Exfiltration.
Detection therefore needs to correlate activity across the entire progression rather than judge each event independently.
Because when an attacker knows how to impersonate the person protecting the entrance, simply strengthening the gate is not enough.
You also need to know who is holding the keys.
Comentarios