The call sounds routine. Someone who knows your name, your company, and the fact that you live in Microsoft 365 tells you the security team is rolling out passkeys this week and your account is next. They stay on the line and read you a web address with the word "passkey" in it. The page carries your company logo, your colors, and a Microsoft sign-in you have seen a thousand times. You type your password, approve the push on your phone, and click through a few screens to "finish enrolling your passkey." By the time you hang up, an attacker has registered their passkey on your real account, and they will sign in as you for as long as that credential lives.
Okta Threat Intelligence detailed this campaign on July 10, tracking the operator as O-UNC-066. Palo Alto Networks Unit 42 follows the same cluster as CL-CRI-1147 and ties it to the extortion brand "Pink," a member of the loose criminal network known as The Com, the same orbit as Scattered Spider and LAPSUS$. The crew has run this since April 2026 against organizations in food and beverage, technology, healthcare, automotive, construction, and aviation. There is no CVE here and nothing to patch. The technique abuses a Microsoft feature that was switched on by default two months ago.
Why a phone call beats your MFA
Passkeys are the strongest authenticator most companies can deploy right now. A FIDO2 passkey is bound to the origin it was registered against, so a fake Microsoft page cannot replay it - the browser refuses to hand the credential to a domain that does not match. That property is exactly why so many teams have spent the last year moving users onto them, and it holds up here. The passkey the victim already has is never the target.
The target is the enrollment step. Registering a new passkey is a normal, expected event - Microsoft began nudging users to enroll one by default in May 2026, which is the pretext the crew leans on. Pink does not try to steal the credential you own. It gets you to authenticate to the real tenant on the attacker's behalf, then adds a passkey it controls as a second, fully trusted sign-in method on your account. Now the attacker holds a phishing-resistant credential of their own, and the same origin-binding that protects you protects them.
The relevance verdict: this is a Microsoft Entra ID and Microsoft 365 problem. If your users sign in to Microsoft 365 and can self-service enroll a passkey or FIDO2 key, you are in scope, whether you have ten seats or ten thousand. If you run a pure Google Workspace shop with no Entra tenant, this specific kit will not touch you today - but the pattern, hijacking the enrollment ceremony of a strong authenticator, reaches any identity provider that lets a user add one over the phone. Read the rest as the shape of what lands on your IdP next.
Inside the kit: nine pages built to keep you busy
What makes this work is timing, not sophistication. Okta describes an operator-controlled PHP panel - a human on the other end driving the flow in real time, polling the victim's state on a roughly one-second heartbeat, rather than a transparent proxy. The panel walks the caller and the victim through a fixed sequence of pages, each one staged with the victim organization's own branding pulled per subdomain:
/gateand/identify- anti-analysis checks, then capture the username./password- harvest the password and POST it tobackend.php./processing- stall the victim while the operator signs in to the real tenant with those credentials./submit-otp,/submit-authenticator,/approve-authenticator- decoy MFA screens that adapt to whatever the victim actually uses: SMS OTP, TOTP, or push with number matching. Whatever the victim types or approves, the operator relays into the live session./passkey/register,/passkey,/passkey/check,/done- the fake enrollment finale, including a screen that asks the victim to "save a recovery key" as a seed phrase.
While the victim is busy copying down a recovery phrase, the operator completes an actual passkey registration on the compromised account inside the real Entra flow. The infrastructure is disposable and obvious in hindsight: domains such as setpasskey[.]com, deploypasskey[.]com, and passkeyadd[.]com, registered between April and June 2026, with per-victim subdomains like yourcompany.setpasskey[.]com, hosted behind DDoS-Guard (AS57724) and IQWeb (AS59692). After access, Pink pulls data from SharePoint and OneDrive, then sends the extortion note - and internal Teams messages - from the victim's own account, with a 72-hour deadline and a leak site to back the threat.
The step real passkey enrollment never has
There is one detail worth teaching every user, because it separates the real flow from the fake one cleanly. Genuine passkey creation happens in a native operating-system or browser dialog - Windows Hello, a Face ID or Touch ID prompt, a security-key tap. It never asks you to type or "save" a recovery seed phrase on a web page, and it is never something a stranger on the phone needs to walk you through. The BIP-39-style recovery-key screen in this kit exists only to occupy the victim for the seconds the operator needs to finish enrolling their own credential.
Give your people two rules that cost nothing. First, no one from IT will ever call and stay on the line while you set up security. A real rollout is an email and a self-service portal you reach on your own. Second, if a passkey setup asks you to type a recovery phrase into a website, stop and report it. For the owner or office manager reading this: the business exposure is a stranger reading the CEO's mail, forwarding invoices from a real internal account, and holding your SharePoint for ransom - all without tripping an "impossible travel" alert, because they logged in as a trusted user with a valid strong credential.
Hunt for the passkey nobody issued
The single highest-value detection is a new FIDO2 or passkey registration you cannot tie to a known enrollment. Entra writes every authenticator-method change to the audit log, so if you feed AuditLogs to Microsoft Sentinel or any Log Analytics workspace, hunt the last week of registrations and eyeball the source:
AuditLogs
| where TimeGenerated > ago(7d)
| where OperationName has_any ("registered security info", "security info registered")
| where Result == "success"
| mv-expand TargetResources
| extend Method = tostring(TargetResources.displayName)
| where Method has_any ("Passkey", "FIDO2", "passwordless")
| extend UPN = tostring(TargetResources.userPrincipalName),
IP = tostring(InitiatedBy.user.ipAddress)
| project TimeGenerated, UPN, Method, IP
| sort by TimeGenerated descCorrelate each hit with that user's sign-in log for the same minute. A passkey registration from an ASN or country the user has never signed in from, moments after a successful sign-in from that same new location, is the campaign's fingerprint. If you do not run Sentinel, the same events live in the Entra admin center under the user's Authentication methods and in the audit log filtered to the "Register security info" activity. You can also enumerate every registered passkey in the tenant through Microsoft Graph and review anything added in the incident window:
Get-MgUserAuthenticationFido2Method -UserId user@contoso.com |
Select-Object DisplayName, CreatedDateTime, ModelLock enrollment to authenticators you control
You cannot patch a phone call, but you can shrink what a hijacked enrollment is allowed to add. Three settings in the Entra Passkey (FIDO2) authentication-methods policy do most of the work. Turn on attestation and set an AAGUID allow-list so users can only register passkeys from device models you have decided to trust; an operator trying to add a random platform passkey then gets rejected at the door. Scope passkey enrollment to a specific group rather than every user, so enrollment is a deliberate act you provision, not an always-open self-service door. And require a fresh multi-factor check within the last five minutes before any registration, which Entra already supports.
Two controls outside that policy matter as much. Turn on end-user notifications for every authenticator lifecycle event, so the victim - and your help desk - get a "you added a security method" message the moment the operator's passkey lands, which is often the first human-visible signal. And gate Microsoft 365 behind a Conditional Access policy that requires the phishing-resistant MFA authentication strength, ideally combined with a network-zone or managed-device condition so a sign-in from a fresh hosting ASN faces a harder challenge than the operator's relay can satisfy. Read the primary write-ups from Okta Threat Intelligence and Unit 42 for the full indicator set. If you want a second set of eyes on your Entra authentication-methods policy and Conditional Access before someone tests it for you, that is the assessment we run.
Need help hardening your identity infrastructure?
We assess Active Directory and Entra ID environments for the misconfigurations attackers actually exploit, including passkey enrollment policy, authentication strength, and Conditional Access gaps. Book a session to walk through your tenant.