Microsoft has tracked the campaigns since May, with attackers posing as IT staff and asking employees to update a security setting.

 

What happened

Attackers calling employees and claiming to be IT support have been talking them into updating a passkey, multifactor authentication setting, or single sign-on configuration, then using that to take over Microsoft 365 accounts, TechRepublic reported, citing Microsoft research. The campaigns date back to May and several separate groups are involved. A passkey is a login credential kept on one device and unlocked with a fingerprint, face scan, or PIN, built to replace passwords. Once inside an account, the attackers survey what the organization has, then go after data in SharePoint, OneDrive, and Exchange Online.

 

Going deeper

A passkey is tied to the device holding it, which stops anyone stealing and reusing it elsewhere. That protects the credential but it does not stop the account itself being signed into legitimately on a second device, and that is what these campaigns exploit. There are two routes, one puts a phishing site between the employee and Microsoft's real login service, relaying the exchange both ways and keeping the session token, which is the credential a browser holds after signing in. The other has the attacker begin a genuine Microsoft sign-in on their own device, receive a short code, and talk the employee into typing it on Microsoft's real authentication page. Microsoft then issues the token to the attacker, the passkey is never broken either way.

 

What was said

The attackers "are not cracking the passkey," TechRepublic noted in its account of Microsoft's findings, describing them as manipulating users into authorizing access or capturing the session created after a legitimate sign-in. Microsoft attributes the activity to groups it tracks as Storm-3121 and Storm-3032, linking the first to initial-access work feeding ShinyHunters and Falcon, and the second to operators who split from BlackFile and now work under the Helix name. Google identified the same pattern as UNC6671.

 

In the know

Microsoft observed attackers adding their own authentication methods to accounts they had taken over, registering a passkey or second factor against the victim's identity. An account treated that way survives a password reset. The attacker's method stays bound to it and keeps working. NIST addresses this directly, noting that associating a new authenticator with an account is a more sensitive transaction than a routine authentication, since an attack at that point that nobody spots can give an attacker ongoing access. Before making contact, the operators research targets through public sources to work out which employees are worth approaching. Some approaches arrive through accounts they already control, reaching further victims over trusted channels such as Microsoft Teams.

 

The big picture

Microsoft's sequence is to revoke active sessions and tokens, strip out unauthorized authentication methods and mailbox rules, reset affected credentials, then make the user register authentication again from scratch. Prevention sits earlier, at enrollment, where organizations can limit who may register or reset authentication methods and apply stronger checks to those actions specifically. NIST requires identity providers to keep a record of every authenticator bound to an account, with the date and time of each binding and, where available, the address or device it came from. That log is what makes an unauthorized registration visible afterward. Healthcare organizations rolling out passkeys have a particular reason to alert on enrollment events, since clinical staff being migrated to new authentication are a population already expecting to be asked.

 

FAQs

Does this mean passkeys are not worth deploying?

No. Passkeys end password reuse, credential stuffing, and the theft of reusable secrets, and none of that changes here. These campaigns go after the process around the credential, which is why enrolment controls and session monitoring belong alongside the rollout.

 

How would an organization spot an unauthorized authentication method?

Through directory audit logs recording authentication method registration, either by alerting or periodic review. A registration that happens outside a known onboarding or recovery event, particularly from an unfamiliar address, is the signal.

 

Why does a password reset not end the compromise?

The attacker's method is bound to the account separately from the password. Resetting the password changes one credential and leaves another in place, so the account keeps authenticating for whoever holds the registered method.

 

What does restricting enrolment involve?

Limiting which users or roles can register new authentication methods, requiring extra verification before a registration completes, and routing recovery requests through a defined process rather than self-service. Self-service enrolment is often on by default.

 

Why do attackers research targets first?

Knowing someone's role, reporting line, and recent activity makes the approach specific enough to sound real, and it identifies who holds access worth taking. Public profiles supply most of it.