Executive Summary

The latest threat intelligence report from Okta details a sophisticated vishing and phishing campaign that exploits the newly rolled out passkey enrollment feature in Microsoft Entra. The actors, identified as O-UNC-066 (also reported by Palo Alto Networks Unit 42 as CL-CRI-1147), employ phone calls to persuade employees of enterprise customers across food & beverage, technology, healthcare, automotive, construction and aviation sectors to “register a new passkey.” In doing so they funnel victims into an operator‑controlled phishing kit that mimics the Microsoft sign‑in experience. The attacker then captures credentials, bypasses MFA, enrolls their own passkey in the victim’s account, and leaves no visible traces for the user. The goal is data extortion: by compromising a high‑value account the actor can demand payment for “non‑disclosure” of confidential information or threaten to expose it.

Actor Motivation & TTPs

O-UNC-066 operates a Data Leak Site (DLS) named Pink, hosting stolen data and offering it for sale. Their modus operandi relies on social engineering rather than purely technical intrusion. They register subdomains under passkey‑related domains (e.g., exampleentity[.]setpasskey[.]com), host the phishing kit behind DDoS‑Guard or IQWeb FZ‑LLC, and use a real‑time control panel that allows the attacker to adapt the user interface based on the victim’s MFA configuration. The vishing calls are scripted: “Your Microsoft account requires a new passkey for compliance; let me walk you through it.” This combines a technical pretext with human manipulation, allowing rapid credential harvesting and passkey hijacking.

Phishing Kit Architecture

The kit is not an Adversary‑in‑the‑Middle (AitM) proxy but a PHP operator panel that presents the victim with pages closely resembling Microsoft’s sign‑in flow:

1. /gate: anti‑analysis checks.
2. /identify: username prompt.
3. /password: password capture.
4. Operator authenticates to the real Microsoft portal, observes MFA prompts and selects the appropriate page sequence (/submit-otp, /submit-authenticator or /approve-authenticator).
5. After successful login, the victim is redirected to /passkey/register, where they are asked to “save your recovery key” from a list of BIP‑39 phrases. The kit does not actually create a passkey; it merely tricks the user into believing the registration was legitimate.

The final page, /done, confirms success, sending Microsoft an email that appears to notify the victim of a new passkey. In reality the attacker has already enrolled the key and retains full control of the account.

Infrastructure & Domains

Investigators identified several domain families used for subdomain generation:

• assignpasskey[.]com (registered 2026-06-14, DDoS‑Guard)
• deploypasskey[.]com (2026-04-21, DDoS‑Guard)
• passkeydeploy[.]com (2026-04-23, DDoS‑Guard)
• passkeyadd[.]com (2026-05-08, DDoS‑Guard)
• setpasskey[.]com (2026-05-23, IQWeb FZ‑LLC)

All infrastructure was hosted behind DDoS‑Guard (AS57724, Russia) and IQWeb FZ‑LLC (AS59692, US). The use of well‑known domain registrars and a DDoS protection service helps obscure the attacker’s origin.

Impact

Affected organizations report that once an account is compromised, attackers can perform data exfiltration, modify file shares, or leverage privileged accounts for lateral movement. The passkey hijack also undermines MFA defenses, allowing the attacker to remain undetected while maintaining credential persistence.

Recommendations

The following controls mitigate this threat:

• Enforce strong authenticators (Okta FastPass, passkeys or smart cards) and disable basic password fallback for sensitive applications.
• Educate users on the proper look‑and‑feel of Microsoft’s passkey enrollment dialogs; emphasize that a recovery key dialog is unusual during registration.
• Validate helpdesk identity via out‑of‑band verification (e.g., call back to known number) before any password reset or account changes are performed.
• Restrict access to Okta and Microsoft applications by geolocation, ASN, IP range and device management status; deny requests from untrusted locations.
• Configure Okta notification policies for every authenticator lifecycle event (addition, removal, change) so users receive alerts of unauthorized actions.

For Okta customers: implement the supplemental policy guidance available at hxxps://security[.]okta[.]com/product/oktathreatintelligence/vishing-actors-target-microsoft-entra-passkey-enrollment to prevent account manipulation and enforce device‑based access restrictions.

Further Reading

Okta’s public blog post on vishing adaptations (hxxps://www[.]okta[.]com/en-au/blog/threat-intelligence/vishing-actors-target-microsoft-entra-passkey-enrollment-) and the AlienVault Pulse (hxxps://otx[.]alienvault[.]com/pulse/6a50a4940ab558de7013e787) provide additional insights into the actor’s tactics.