Passkey enrolment as a phishing pretext in Microsoft 365

On 9 September 2026, Microsoft Threat Intelligence published an analysis of a social engineering campaign that uses passkey enrolment as a pretext to obtain Microsoft Entra ID sessions.  With observed activity dating to no later than April 2026. The intrusions end in scripted collection of SharePoint, OneDrive and Exchange data, followed by extortion.

What follows is the attack chain, the detection signals it produces, where attribution currently stands, and the configuration changes that remove the largest parts of it. It also addresses a question the campaign's framing raises directly: whether passkey authentication was defeated. On the published evidence it was not, and the distinction matters for how organisations respond.

The pretext

The initial contact is a voice call to an employee's personal mobile number, with caller ID spoofed to the organisation's helpdesk line. Microsoft records that the caller asserts that "a passkey, multifactor authentication (MFA), or single sign-on (SSO) configuration must be updated immediately," and an SMS follows containing a link to a lookalike Microsoft sign-in page. In some investigated intrusions the operator spoofed the target's direct manager by name instead of the helpdesk.

The pretext works largely because it is true. Passkey migrations are in progress at many organisations and they are mandatory, so the premise matches what employees have already been told to expect. The enrolment flow is unfamiliar, which makes being talked through it by telephone plausible. And awareness training has spent years positioning passkeys as the phishing-resistant option, so the caller is nominally offering to improve the target's security.

Contact on a personal device places the interaction outside organisational controls entirely. There is no mail gateway involved, no logging, and no artefact available for post-incident review. Independent reporting describes the same script in other campaigns, characterising it as a false pretext of an urgent helpdesk mandate to enable FIDO2 passkeys or update multi-factor authentication enrolment.

Attack chain

Session capture methods

Microsoft states that "the passkey narrative serves as a convincing pretext to guide victims through adversary-in-the-middle (AiTM) phishing or device-code authentication flows." The two routes leave very different evidence behind.

The adversary-in-the-middle route uses a reverse proxy positioned between the victim and the genuine Microsoft login endpoint, forwarding each field and prompt so that the victim completes a real authentication including MFA, while the proxy retains the resulting session cookie. The authentication that Entra ID records is valid in every respect.

Device-code phishing is the method most frequently confirmed as the entry point in independently investigated incidents. The operator initiates a device-code flow and guides the victim through entering the resulting code in their own browser, so authentication completes on the victim's managed, compliant corporate device. No credential is transmitted to the attacker at any point, and nothing is typed into a spoofed page.

The consequence is that device-posture and location conditions in Conditional Access evaluate correctly and permit the sign-in, because the device and location are genuine. Disabling the flow is therefore the highest-impact single mitigation against this entry route.

Persistence and containment

Following initial sign-in, the actor registers an authentication method under their own control. Microsoft records that "the actor enrolled an MFA method under their control, typically by registering a new phone number, authenticator application, or software-based one-time password (OTP) token," describing this as transforming temporary compromise into a durable foothold, and maps it to MITRE T1556.006. Independent incident reporting places the registration within minutes of initial sign-in, originating from the same residential proxy address used to capture the session.

This defeats the standard containment sequence. A password reset leaves the attacker-registered factor in place, allowing re-authentication. Effective containment requires four steps in order:

• Revoke active sessions and refresh tokens. A credential reset alone does not invalidate issued tokens.
• Audit all registered authentication methods on the account against what the user recognises, and remove those that are unrecognised. This must precede the reset, otherwise access is re-established through the remaining method.
• Reset the credential through a verified out-of-band channel, not the helpdesk channel the actor has demonstrated the ability to impersonate.
• Re-enrol authentication under supervision, and check for attacker-registered devices in Entra ID in addition to authentication methods.

Collection activity and detection signals

Collection is scripted. That is the main detection opportunity. Microsoft observed the python-httpx user agent associated with high-volume SharePoint and OneDrive access. Other vendors investigating comparable intrusions recorded a different Python HTTP library, python-requests/2.28.1, and in some cases WindowsPowerShell/5.1 with the client application identifier spoofed to Microsoft Office while the recorded user agent still identified a scripting library.

Two further characteristics reduce visibility. Volume is held below about 1,000 files or messages an hour, which sits beneath common alerting thresholds, and the activity is spread across hours or days instead of arriving in one burst. Access is also often recorded as FileAccessed and not FileDownloaded, so both events need equal weight in detection logic where the user agent identifies a scripting library or the volume exceeds interactive browsing.

Detection signals, roughly in order of value:

• Registration of a new authentication method within one hour of a sign-in flagged as risky, from an unfamiliar device, or from a residential proxy or hosting provider address range.
• Graph reconnaissance spanning three or more categories (directory, privilege, application, repository, mailbox) within a 30-minute window from a single identity.
• Any scripting-library user agent presenting a delegated user token to Graph, SharePoint or Exchange.
• Wildcard or contentclass:STS_Site SharePoint search queries, which enumerate all reachable sites and have minimal legitimate interactive use.
• Sustained file access from a single identity at a rate that is both elevated and uniform, interactive access being characteristically irregular.
• Device-code authentication events, where the flow has not been disabled.

These detections depend on telemetry that is not enabled by default in all tenants. Graph activity logs and mailbox auditing must be enabled and retained for a period long enough to investigate an intrusion that unfolds over several days.

Attribution

Microsoft's wording is frequently paraphrased inaccurately as naming two groups. The published statement is that the initial access activity "is used by a range of threat actors, including Storm-3121, Storm-3032, and others." Storm-3121's initial access is described as leading to ShinyHunters and Falcon extortion; Storm-3032 is described as a set of actors that splintered from the BlackFile group and now operate under the Helix extortion banner.

Other vendors assessing the same tradecraft have drawn the cluster boundaries differently. The lineage is an assessment, not an established fact.

No published assessment maps the Storm designations to UNC6671, so any equivalence between them is inference, not published assessment. On 7 August 2026, REDACT publicly denied affiliation with Helix and Pink, stating that Falcon is its only affiliate and that former affiliates had replicated its techniques. This is an adversary claim and carries no evidential weight, but indicates the lineage is disputed within the ecosystem as well as between analysts.

For defenders the disagreement matters little. Every published account describes the same playbook, the same infrastructure pattern and the same persistence mechanism. Defend against the technique, which several crews now share, not against a named group.

Infrastructure characteristics

The operators do not provision separate infrastructure per target. They register generic passkey-themed root domains and create a victim-named subdomain for each organisation. Microsoft records that the actor "creates domains following the pattern companyname[.]maliciousdomain[.]com." This is also why a single root domain has been observed serving organisations subsequently extorted under two different brands. The August 2026 infrastructure census identified 63 root domains supporting more than 104 victim subdomains, with the interval between registration and operational use measured in hours.

Published root domains include, defanged:

secure-passkey[.]com        add-passkey[.]com         setupmypasskey[.]com
createssopasskey[.]com      addssopasskey[.]com       myssopasskey[.]com
passkeyhelpdesk[.]com       passkeydeploy[.]com       integratedsso[.]com
oktasession[.]com           oskeysync[.]com           keysyncos[.]com
// served as companyname.<root>

Block them, but do not mistake blocklisting for a control. The domains are disposable, they rotate on a timescale of hours, and published lists are historical by the time anyone consumes them. The durable detection is the structural pattern: a recently registered domain carrying the organisation's own name as a subdomain. Certificate transparency monitoring for organisational brand strings identifies this class of infrastructure during the window in which the activity remains external to the tenant.

Whether passkey authentication was defeated

No reporting in this campaign demonstrates a failure of WebAuthn. Passkeys are bound to the origin for which they were created, so a passkey registered for one domain cannot produce a valid assertion when presented to a lookalike domain. Microsoft's own framing is that the passkey narrative functions as a pretext, not as a defeated control.

Two real weaknesses do exist. Neither is a defect in the standard.

Phishable fallback methods

Where an account can authenticate with either a passkey or a weaker method, an adversary-in-the-middle proxy can modify the page it serves so that the passkey option is not presented, causing the user to authenticate with the phishable fallback. Security researchers documented this technique, termed MFA downgrade, in July 2025 and demonstrated it against Windows Hello for Business and two other major passkey implementations. It was independently reproduced against Entra ID in August 2025 by spoofing a Safari-on-Windows user agent to induce Entra to offer a weaker method. The conclusion is an architectural one. Where a phishing-resistant method exists but a weaker backup method stays registered, the account is still phishable at the level of that weaker method.

Two things qualify the finding. Where an authentication policy enforces phishing resistance, only phishing-resistant methods are accepted and the downgrade attempt is blocked and logged, so the technique applies to configurations that retain a weaker method, which is the majority. The researchers who reproduced it against Entra ID stated in August 2025 that they had not observed downgrade attacks in the wild. No published reporting connects MFA downgrade to the 2026 campaigns described here. The technique has been demonstrated; it has not been observed in this activity, and the two should not be conflated.

Attacker-registered passkeys

Entra ID supports FIDO2 keys and passkeys as standalone passwordless credentials. An actor holding a valid session can therefore register a key under their own control, after which authentication is possible without the password or the legitimate device, and the capability survives a credential reset. That is how the product is designed; it is not a defect. Microsoft has constrained the registration step: it requires an ngcmfa claim minted within about 15 minutes, and tenants can restrict which authenticator models are permitted by AAGUID. The practical implication is that registered authentication methods need the same monitoring as credentials.

Recommended changes

Ordered by how much of the chain each one removes:

• Block device code flow and authentication transfer in Conditional Access, with a narrow exception group. This removes the entry method most frequently confirmed in these intrusions, and existing tenants are not covered by the July 2026 default.
• Enforce phishing-resistant authentication and remove fallback methods. Deploying passkeys while retaining SMS, voice or OTP registration for the same accounts leaves the downgrade path available. Prioritise privileged roles and finance functions.
• Treat authentication method changes as security events and alert on every registration, not only those on privileged accounts. This is a low-cost detection covering the step that converts a stolen session into a persistent intrusion.
• Strengthen helpdesk identity verification in both directions. Verify callers through a channel the caller did not select, and publish an internal standard that the helpdesk will not telephone staff to guide them through authentication changes, so that the pretext is itself anomalous.
• Require managed, compliant devices for Exchange, SharePoint and Graph-privileged applications. This constrains but does not eliminate device-code phishing, which completes on the victim's compliant device.
• Restrict user consent for applications, requiring administrative approval for high-privilege Graph permissions including Mail.Read, Files.Read.All and Directory.Read.All.
• Limit unmanaged device sessions to web-only access with downloads blocked, and disable anonymous sharing links in SharePoint and OneDrive.
• Enable Graph activity logs and mailbox auditing, with retention sufficient to investigate multi-day intrusions.
• Monitor certificate transparency for organisational brand strings to identify victim-named subdomains prior to use.
• Update awareness training for this pretext. Existing training addresses credential phishing by email; it does not typically address telephone contact regarding a passkey or MFA migration.