An extortion group called Pink (tracked as O-UNC-066) phones employees pretending to be internal IT and walks them through registering a new passkey in Microsoft 365. The site is fake, an operator drives the call live, and by the end the credential left active on the real account belongs to the attacker. FIDO2 cryptography is not broken: what is abused is the enrolment step, which is governed by Conditional Access and helpdesk verification rather than the passkey standard.
The line for months has been that a passkey is the credential phishing cannot steal. Cryptographically that holds: a FIDO2 passkey is bound to the legitimate domain and will not travel through a fake form. But the campaign that Okta Threat Intelligence documented from April 2026 found the crack in it. It does not go after the passkey; it goes after the moment the passkey is enrolled.
There is nothing sophisticated about the method: a phone call and a cloned page. Someone rings an employee, claims to be from the company's IT team, and asks them to enrol a new passkey for security reasons. On the other end sits an operator steering the conversation in real time. When the employee believes the task is done, the passkey now registered on their Microsoft 365 account answers to the caller, not to them.
Who runs it and who gets the call
Okta tracks the actor as O-UNC-066 and has watched the campaign since April 2026 against organisations in food and beverage, technology, healthcare, automotive, construction and aviation. Palo Alto Networks Unit 42 tracks the same group as Pink, an extortion brand that, as reported by The Hacker News and BleepingComputer, sits in the orbit of The Com, the loose criminal network associated with the earlier emergence of Scattered Spider, ShinyHunters and LAPSUS$.
The group steals data and extorts; encryption is not part of the plan. It stood up a leak site in late May 2026 to pressure victims, and its extortion messages —sent from already-compromised Teams and email accounts— tend to allow a short window to pay. Those figures and deadlines are the attacker's own claims and should be read as such, not as verified fact.
How the call plays out
The pretext: a legitimate prompt turned into cover
The hook works because it matches something organisations now see routinely. Microsoft has spent months pushing the move to passwordless with registration campaigns that nudge users to enrol a passkey at sign-in, and in some cases that prompt appears by default. A call insisting you set up a passkey does not feel odd: it sounds like the policy the organisation has just switched on.
The kit and the cloned page
The operator sends the victim to an address with the word passkey in the domain and mirrors the real Entra enrolment portal down to the victim organisation's own branding. The page is not static: the attacker adapts the screens to whichever second factor the account uses —an SMS code, an authenticator prompt or a push notification— because a person is steering every step. That live control is what lets thevishing slip past automated defences: there is no fixed pattern for a filter to recognise.
Enrolling the attacker's passkey
With the password and one-time code the victim has just typed, the attacker signs in to the real Microsoft 365 account and adds their own FIDO2 passkey through the legitimate security information portal. From that point the victim is no longer needed. The attacker holds a passwordless credential registered in their name inside the tenant, at first glance indistinguishable from any correct enrolment.
Why the usual controls wave the enrolment through
The FIDO2 guarantee covers authentication, not the enrolment ceremony. When someone registers a new authentication method, what decides whether that registration is legitimate is the tenant's Conditional Access policy and, before anything else, the human check on who is asking for the change — not the passkey standard. That is exactly where the campaign reaches in.
The second problem is persistence. Because the attacker's passkey is a credential enrolled through the correct channel, the access does not fall away with a password reset or a session revocation, the reflex moves in almost any playbook. As long as the authentication method stays registered, the door stays open.
The third is the absence of noise. There is no malware for an EDR to catch and no exploit to leave a trace in an IDS. There is a legitimate sign-in followed by a clean credential enrolment. To catch it you have to look in the right place.
Detection: where the trail is
The enrolment is recorded in the Entra audit logs. The starting signal is an authentication-method registration event —passkey or FIDO2— tied to a user, especially when it arrives from a device or location the account had not used and shortly after a sign-in flagged as risky. Correlating that registration with the sign-in logs usually rebuilds the whole sequence: a session from an anomalous IP and, minutes later, a new credential.
It pays to alert specifically on passkey enrolments that happen outside managed devices or outside the planned registration campaigns, and to check whether the affected account took a call or a support contact in that window. Where the detection team leaves this window uncovered, it is the very window the campaign exploits; having a threat hunting capability over identity events can be the difference between catching it in hours and finding it when the extortion note lands.
How to lock down credential enrolment
The decisive control is to treat authentication-method enrolment as a sensitive operation rather than a formality. Conditional Access can apply a policy to the Register security information user action, so a method can only be enrolled from a trusted device or under a strong condition, and can be blocked when Entra ID Protection detects user or sign-in risk.
On top of that, authentication strengths define which methods are allowed to complete an operation, and it helps to narrow who can self-enrol passkeys through scoped registration campaigns instead of leaving it open to everyone. None of these pieces is new; what the campaign shows is the cost of running them unrefined.
The layer Okta puts at the centre is human: verify the identity of anyone contacting the helpdesk, and never make a credential change off the back of an inbound call. The message to users is just as blunt —the IT team does not phone to walk you through enrolling a passkey— and it belongs to the same work of defending identity that holds up the rest of the tenant. It is the same ground as other Microsoft 365 takeovers, from AiTM token theft to device-code phishing, and the same abuse of trust that powers deepfake CEO fraud.
On the regulatory side, identity and access management and incident reporting fall squarely within the scope of NIS2 and DORA for the entities they cover. An account takeover with a persistent credential can be a reportable incident under the applicable framework, with the board answerable for whether reasonable controls were in place. Hardening credential enrolment and keeping an incident response capability ready to strip out fraudulent methods is part of that diligence. Where the inventory of service accounts and automated credentials is still loose, the same problem extends to non-human identities.
What this case makes plain
The flaw is not in the passkey but in the human step that binds a credential to an account. Passwordless removes the password, not the front desk: someone still decides, at some point, that this method is let in. As long as that moment rides on an unverified phone call, the attacker needs to break nothing. It is enough that the door is opened for them.
The operational question the Pink campaign leaves is concrete and measurable: who can add a credential in the tenant, from where, and after what check. An organisation that can answer it with a policy and a log, rather than the goodwill of whoever picks up the phone, has shut the vector without depending on who answers the call.
This article describes the campaign for defensive and detection purposes. The references to Conditional Access and to Entra audit events should be validated in a test environment and adapted to each tenant's configuration before being applied in production. Figures and deadlines circulated by the extortion group are cited as unverified attacker claims; group attributions may evolve as the investigation continues.