Skip to content

Passkey Phishing Is Turning Cloud Accounts Into Data Hubs

Attackers are using fake passkey and single sign-on requests to compromise cloud identities, add their own authentication methods, and quietly collect Microsoft 365 data.

Passkey Phishing Is Turning Cloud Accounts Into Data Hubs

On this page

A new wave of passkey-themed social engineering is showing how attackers can use a trusted security concept as the opening move in a much larger cloud intrusion. Microsoft says it has tracked active attacks since May in which victims were persuaded to complete fake passkey or single sign-on steps, followed by unauthorized authentication methods, Microsoft Graph reconnaissance, and large-scale access to SharePoint, OneDrive, and email data.Β 

The passkey story is only the bait

The attacks often begin with a phone call or message from someone posing as an IT helpdesk employee. The victim is told that a passkey, multifactor authentication, or single sign-on setting needs to be updated immediately, then directed toward a sign-in page designed to look like a legitimate Microsoft service. Microsoft says the passkey itself is frequently not the attacker's real objective. Instead, the story creates a believable reason to push the victim into an adversary-in-the-middle phishing flow or a device-code authentication process.

An adversary-in-the-middle attack places the attacker between the victim and the real authentication service, allowing credentials or session information to be captured. Device-code phishing works differently: the victim enters a code on a genuine authentication page and unknowingly authorizes an attacker-controlled session. That distinction matters because a successful attack does not necessarily require the attacker to steal a password in the traditional way. A legitimate authentication event can become the mechanism that gives the attacker access.

One stolen session can open much more than email

Once an identity is compromised, the attackers move quickly from authentication into reconnaissance. Microsoft observed compromised sessions being used to inspect applications, users, groups, permissions, and cloud resources through Microsoft Graph, the programming interface that lets applications interact with Microsoft 365 services. The same access can then reach SharePoint and OneDrive files and, in some cases, Exchange Online email.

This is the part that makes the campaign more serious than an ordinary phishing attempt. The attacker is not simply trying to read one mailbox or steal one password. The compromised identity becomes a map into the organization's cloud environment. Microsoft describes activity in which attackers systematically searched cloud resources before collecting documents and email, with some collection continuing for hours or days rather than arriving as one obvious burst.Β 

Attackers are adding their own authentication method

Microsoft also observed attackers registering new authentication methods after gaining access. This can include a phone number, authenticator application, or software-based one-time-password method controlled by the attacker. The practical effect is important: the intruder is trying to turn an initial compromise into persistence, so access can survive even after the original phishing interaction has ended.

That creates a detection opportunity for security teams. A new authentication method appearing shortly after an unusual sign-in is far more meaningful than either event viewed alone. Microsoft recommends investigating the sequence rather than relying on a single IP address, domain, or user-agent string, because the infrastructure can change while the underlying behavior remains recognizable.Β 

Microsoft saw automated cloud data collection

The later stages of the attacks show why cloud logs need to be treated as security telemetry, not merely administrative records. Microsoft observed high-volume SharePoint and OneDrive access, along with email collection through application programming interfaces. In some cases, activity showed characteristics of automation, including use of the Python httpx client library, although Microsoft cautions that the user-agent string alone is not proof of malicious activity.

The more useful signal is the combination of events. An unusual sign-in followed by a new authentication method, directory enumeration, application discovery, and a sudden increase in file or mailbox access tells a much stronger story than any individual alert. Microsoft says some campaigns deliberately kept collection below 1,000 files or emails per hour, apparently helping the activity blend into normal enterprise traffic while still allowing substantial amounts of information to be gathered over time.

Passkeys themselves are not the weakness

There is an important distinction here because the attack can easily be misunderstood as evidence that passkeys are unsafe. Passkeys are designed to resist phishing by binding authentication to the legitimate service, and Microsoft has been moving Entra ID toward passkeys as its default phishing-resistant authentication method. The new campaign instead shows how attackers can abuse the enrollment process, user expectations, helpdesk workflows, or weaker authentication paths surrounding an otherwise stronger credential.Β 

That distinction has practical consequences. Replacing passwords with passkeys can remove major classes of credential theft, but it does not eliminate social engineering. If an employee can be persuaded to approve an attacker-controlled authentication flow, the strength of the underlying credential does not solve the problem. The safer approach is to make authentication enrollment itself subject to strong policy and verification.

Why personal phones create a blind spot

Microsoft notes that the first stage can be difficult to investigate when the victim receives the call or text on a personal phone. If the device is outside the organization's endpoint monitoring system, security teams may see little or no evidence of the original interaction. The first useful forensic clue may instead appear later as an unusual cloud sign-in or authentication-method change.

That means security teams should not treat the employee's account of a phone call as an informal detail. It can be the missing link between an otherwise unexplained cloud session and the eventual data-access activity. Investigators need to correlate identity logs, authentication events, Microsoft Graph activity, SharePoint and OneDrive access, and mailbox activity to reconstruct the complete chain.

The strongest defenses are about the whole chain

Microsoft recommends removing unauthorized authentication methods, revoking active sessions and refresh tokens, resetting compromised credentials, and requiring secure re-registration after an identity compromise. It also recommends phishing-resistant multifactor authentication, managed-device requirements for sensitive cloud services, tighter controls around authentication-method registration, and restrictions on device-code authentication where there is no business need.

For organizations using Microsoft 365, the most useful detection rule is therefore not simply "block suspicious passkey domains." Domains can be replaced quickly. A more durable approach is to look for the sequence: an unusual identity event, followed by authentication-method changes, cloud reconnaissance, and abnormal access to files or email. That behavioral chain is much harder for an attacker to hide completely.

What security teams should watch next

The timing makes this especially relevant for organizations adopting passkeys now. Microsoft began rolling out passkeys as the default phishing-resistant authentication experience in Entra ID on September 1, 2026, meaning more employees are likely to encounter passkey enrollment prompts as part of normal account security.

That creates an obvious opportunity for attackers to make fraudulent enrollment requests look routine. The defensive lesson is not to slow down passkey adoption, but to make the enrollment path as trustworthy as the credential itself: employees should know which requests are legitimate, helpdesk teams should verify identity before changing authentication settings, and security monitoring should connect identity changes with subsequent cloud activity. The password may be disappearing, but the human decision around authentication remains a security boundary.

D

Written by

Daniel Ahmed

I’m interested in cybersecurity, online threats, privacy, and the technologies used to protect digital systems. I enjoy researching vulnerabilities, security incidents, malware, and new defensive techniques. My goal is to explain security issues clearly and share practical information that helps people stay safer online.

37 posts published

All posts by this author

0 Comments

No comments yet. Be the first to share your thoughts.

Join the conversation

Log in or create a free account to leave a comment. You can edit or delete your own comments any time.