By now, defenders should be very familiar with the device code authorization phishing technique leveraged by a wide range of threat actors, from advanced financially motivated cybercrime gangs to script kiddies who bought the full EvilTokens suite for about $1,500. If you haven’t already read my post on ways to detect and automate response to a suspected EvilTokens campaign, take a look at that post here. While device code phishing is still certainly one of the most prominent forms of phishing, a new technique has emerged in alignment with Microsoft’s release of passkeys as a new default authentication method in the March/April 2026 timeframe. In this post we will explore how passkey authentication works, what this new phishing campaign seeks to do differently, and dive into how an emerging Com-adjacent cybercrime group, tracked by Okta as O-UNC-066, has been launching campaigns targeting Entra ID passkeys.
Entra ID Passkey Authentication
Various sites and blogs such as this one state that passkey authentication in Microsoft Entra ID entered General Availability (GA) around March/April of this year. Passkeys are an implementation of the FIDO2/WebAuthn standard, built upon public-key cryptography rather than shared secrets, which earns them the title of being “phishing-resistant”. It’s a bold claim, and true in the sense that you can’t phish a user into “providing” a passkey to gain access in the same sense that you could with a username and password. But attackers like to bend the rules.
The high-level overview of passkeys is this: a new passkey is created via an enrollment ceremony in which a binding is created between a credential and an origin, enforced by a browser. The origin is the domain the credential is being bound to - a generalized example would be login.microsoftonline.com, though in reality there is a bit more nuance to it than that. When the passkey is created, the authenticator (the device the private key is stored on; a laptop or phone, most likely) holds the key pair, and the browser records which origin (again, the legitimate domain to be authenticated to) the ceremony happened on, and that origin is baked into the signed data the relying party stores alongside the public key. Every time this key pair is used in the future, the browser ensures to only offer it to the legitimate origin used when first created. So if a user gets phished and attempts to authenticate to l0gin-micros0ft.com using this passkey in this example, the browser won’t produce an assertion as the origin doesn’t match, and authentication fails.
So, in the intended sense, passkeys are un-phishable (is that a word yet?). But as I said, attackers like to bend the rules. What if a threat actor could, for example, trick a user into helping them register a new attacker-controlled passkey on the victim’s account, with the legitimate login.microsoftonline.com domain as the origin?
Enter O-UNC-066 And The Passkey Vishing Campaign
In a threat intelligence blog post made by Okta in July of this year, they explain how an emerging cybercrime group tracked as O-UNC-066 (also known as “Pink” extortion brand, or CL-CRI-1147 by Palo Alto Networks’ Unit 42) has been launching phishing attacks against organizations in the food and beverage, technology, healthcare, automotive, construction, and aviation industries, with the aim of tricking victims into enrolling new attacker-controlled passkeys into Microsoft 365 accounts. Additionally, Palo Alto Networks’ Unit 42 asserts this group is likely a Com-affiliated threat actor, as evidenced by similar techniques seen by ShinyHunters (Bling Libra) and Blackfile/Redact (CL-CRI-1116). Google’s Threat Intelligence Group, GTIG, additionally tracks Blackfile as UNC6671, and provides further supporting evidence on their connections to The Com by citing similar SaaS data-theft techniques, though also highlighting their distinction from ShinyHunters via the use of separate TOX chats, different domain registration patterns, and creation of a standalone BlackFile data leak site.
While the vishing campaigns launched by O-UNC-066 aren’t groundbreaking, the most important factor to highlight here is the timing. Microsoft began rolling out the passkey authentication option in Entra ID around April 2026, and campaigns began shortly thereafter around May 2026. With Microsoft themselves stating that passkeys will become the default authentication experience for users beginning Sept 1, 2026, this sharp uptick in campaign activity falls directly in line with an expected shift of organizations towards using passkeys as a main authentication method. Threat actors know that users are being directed to register passkeys as a new authentication method for their accounts, and are preying on the less tech savvy users by calling and posing as IT help desk members reaching out to assist with enrolling in this new authentication method.
The actual process the threat actor uses to enroll a malicious passkey is quite tricky. In this attack chain, the phishing page a user lands on once instructed to navigate to it by the malicious actor on the phone utilizes a kit that contains an operator-controlled PHP panel that the threat actor is able to modify in real time to display content matching the victim’s specific authentication flow. After the victim is talked into entering their username and password, which the attacker collects and relays to a legitimate Microsoft login page, the attacker captures the specific type of MFA prompt (SMS, OTP, MFA push notification) and dynamically alters the page displayed to the victim to match what they would expect to see.
Once a user accepts the MFA prompt, they are displayed with a bogus passkey registration page to “set up a passkey”, while behind the scenes, the threat actor is the one actually enrolling the real passkey on the victim’s account. Critically, this enrollment happens from within the authenticated session the operator established, not by re-submitting the password. The victim navigates the few simple steps, and characteristically reaches a final “recovery key” page populated with 12 seed phrases adhering to the BIP-39 standard, which they are prompted to note somewhere safe, and confirm this action by entering in the final seed phrase on screen. This, of course, is all bogus, and serves to distract the user with a task to provide the attacker ample time to complete the actual passkey enrollment process on their end. With the threat actor-controlled passkey now enrolled on the user’s profile, the attack has established persistence for this user’s account.
Considerations of a Successful Passkey Enrollment, and Prevention Measures
There is an important distinction to make in this campaign that should be explicitly stated. The first half of this campaign - talking a user into providing a username, password, and accepting an MFA prompt to authenticate to a bogus passkey enrollment portal provides the attackers initial access into the organization. In that sense, this falls in line with any run-of-the-mill phishing attack. Where this differs is in the threat actor enrolling a new passkey to establish persistence. The passkey survives a standard password reset, so if it is not caught, access remains until the passkey is fully revoked as an authentication method for the compromised account. If a user falls victim to this attack, the proper eradication process should be: Revoke/remove malicious passkey –> Revoke all current session tokens –> Reset user password. The compromised passkey must be removed first to ensure confidence that the attacker no longer has access to the account.
When it comes to preventing threat actors from successfully registering passkeys, the best option, if available, is to create a Conditional Access policy preventing non-compliant devices from registering new security information on a user account. A general guideline for creating such a policy is as follows:
- Create a new CA policy in Entra ID (Entra ID –> Conditional Access –> New Policy) with a fitting name.
- Users: include All users (being sure to exclude break-glass accounts and guests - guests likely do not have org-compliant devices).
- Target Resources –> User Actions: Check “Register security information”.
- Grant: Require device to be marked as compliant (Or “hybrid-joined”, depending on environment).
- As a precaution, run in report-only mode to begin to prevent unintended lockouts. Monitor for efficacy, and switch to enforcement once confirmed.
While not a complete guarantee, this is the single best bet to give yourself the best chance of stopping this attack in its tracks. Attackers are most likely not operating from organizationally compliant devices, but rather via a relayed authentication session from the harvested creds the user provided. Ultimately, it depends on how the “Register security information” user action evaluates device state in that relayed session context. Anyone who’s worked in Entra ID long enough knows it’s impossible to say for sure when it comes to authentication.
If for any reason the above is not a feasible approach, the next best option is sticking with the boring and bland security basics. Block account logon access from regions your company has no business or employees in. Monitor for authentication methods being added from geographically distinct IPs from a user’s baseline location. Routinely hunt and audit all authentication method changes and review your findings for anomalies. And as always, continually train users on new and emerging phishing methods such as what was covered in this article, and foster a security-first mindset throughout the entire org, so users feel comfortable coming forward if something feels “off”.
Final Thoughts
Defenders and attackers are always playing a game of cat and mouse: defenders continually find better ways to lock their systems down and as a result, attackers must come up with increasingly clever ways to make their way inside. This year alone we’ve seen several examples of this: ClickFix has risen to the number one malware dropper method, generalized phishing has shifted to device code phishing, and now vishing attacks with threat actors posing as IT help desk seek to trick users to add new forms of modern authentication to their accounts.
What makes the passkey campaign worth watching isn’t the technical novelty; the kit is a PHP panel and a phone call. Instead, it’s the target. O-UNC-066 didn’t break WebAuthn, the origin binding held exactly as designed. But rather they attacked the one seam the cryptography was never meant to cover: a human being nudged toward an unfamiliar enrollment flow, at precisely the moment their organization is telling them to expect exactly that. The “phishing-resistant” credential did its job, it just got issues tothe wrong person, with the victim’s help.
Strip all the flashy techniques away, and one thing still remains true over time: humans are a known weakpoint, they’re unpatchable, and attackers know this. But the more important lesson for defenders is that “phishing-resistant” describes the ceremony, not the account. The enrollment flow, the revory path, the help desk call; those are still left up to defenders to protect against, and this campaign is a preview of where the next several are going to live.