Inside the Hedge Fund Vishing Campaign: How UNC6671 Weaponized the Passkey Rollout

The call comes to your personal cell. Caller ID shows your company's help desk number. The voice says IT is running a mandatory passkey enrollment and you need to complete yours today.

In the first week of August, employees at Citadel, Point72, Two Sigma, and Millennium picked up that call. None of the four has confirmed a breach. But Reuters ran the crew's 72 phishing domains through DomainTools and urlscan and found company-specific subdomains built for more than 200 organizations across five weeks, including Blackstone, KKR, Apollo, Bain Capital, CME Group, Moody's, Uber, and Zillow. Google says some of them paid.

How the attack works

The entire intrusion is a phone call and a browser session. Companies have spent years building procedures for the help desk to verify employees. Nobody built the reverse. When your help desk calls an employee, that employee has no way to confirm who they're talking to. Caller ID, area code, and the name of whoever they claim to be are the only signals, and this crew spoofs all of them.

Note: Google Threat Intelligence Group has published two technical reports on this crew: a full attack lifecycle in May, and an August 6 update confirming the same playbook against financial and legal targets. The chain below comes from both. Neither report names the hedge funds, so treat this as the crew's documented method rather than a reconstruction of the August 5 calls.

1. The call goes to a personal mobile number. Google documents this as the crew's standing pattern. The caller spoofs the target company's real help desk number, so caller ID confirms the story. Other crews have run the same play over Microsoft Teams voice calls and meetings from spoofed external tenants.

2. The pretext is a program the company is running. The caller says IT is executing an urgent, mandatory security migration. Enroll a FIDO2 passkey. Update your MFA enrollment.

3. The landing page carries the victim's own company name. Subdomains follow the pattern [company].createssopasskey[.]com, built on generic root domains that pair an authentication noun (passkey, sso, mfa, okta) with a verb (add, enroll, activate, setup). Roughly 70 root domains are documented. Seven of the eight still resolving at publication had no wildcard DNS, meaning every subdomain in passive DNS is a company somebody picked by hand. Domains get registered and used within minutes.

4. The page is a proxy, not a form. An adversary-in-the-middle reverse proxy relays the login to the real identity provider in real time, capturing the credential and the session token together. That means SMS one-time codes, push approvals, and TOTP will all be defeated if the employee follows through.

5. Persistence is immediate. Google's May report describes the operator going straight to the account's security settings and registering their own MFA device. From there, the SSO dashboard is the prize: once Microsoft 365 or Okta falls, every federated application downstream comes with it.

6. The mailbox reaches what SSO doesn't. For applications that were never federated, the operator runs password resets from the compromised inbox. Then they delete the evidence: reset confirmations, security notifications, company-wide alerts, and anything generated by MFA or account-security changes. Google flagged this cleanup as new behavior in August, and it's the part that buys the crew days instead of hours.

7. The theft is scripted, and the scripts are boring. The crew queries internal search for terms like "confidential" and "SSN" to decide what to take, then replays captured session cookies to stream file contents rather than issuing download commands. Your logs record that as FileAccessed, not FileDownloaded, which is why most SOCs never flag it. In one case Google documents over a million files pulled from a single victim's SharePoint and OneDrive. No AI involved at any point here. The tooling is Python and PowerShell.

8. The traffic is dressed to fit. Authentication routes through residential IP space at AT&T, Comcast, Starry, and Optimum, so logins sit inside normal employee geography. The exfiltration spoofs the Microsoft Office ClientAppId to satisfy conditional access, while the user agent string still reads python-requests/2.28.1. That mismatch is the cleanest signature in the campaign.

The pretext is the attack

Passkey adoption has accelerated across the enterprise. Okta and Microsoft built enrollment flows, IT departments started running mandatory migrations, and employees see passkey prompts on their personal Google and Apple accounts every week. The concept of "your company is enrolling you in a new authentication method" passes the sniff test before the caller says a word, because the employee has been living it.

UNC6671 turned that into a script. The caller describes a program the employee's own organization may be running, on an urgent timeline that sounds right. Even if the company hasn't started a passkey rollout, the employee has seen enough prompts to believe it's coming. No inside knowledge about the target is required.

The damage goes past the credential. From Google's May report, the line most coverage missed: the IT deployment pretext "provides a logical cover for any subsequent security alerts generated during the compromise." Every alert that fires after the call, the MFA registration, the unfamiliar login, the password reset, fits the story the employee was told twenty minutes ago. The end result is that the employee will be less likely to raise the alarm bells and report to their security team.

Was AI involved?

Coverage of the campaign described voice cloning. Google's technical reports, which contain the forensic detail, do not mention it. Both reports describe human callers hired by the crew, working from scripts, impersonating help desk agents the targets have never met. That labor model matches the commercial vishing market we documented with p1bot: hired callers, scripted pretexts, sold as a service. Whether AI played a role in the calls remains unconfirmed. Voice cloning solves a problem IT impersonation doesn't have, because employees usually don't know what the help desk sounds like.

Who is behind it: BlackFile

Google tracks this actor as UNC6671. The crew called itself BlackFile when it surfaced in early 2026. If you run a security awareness program at a financial services firm, you had no reason to track it.

BlackFile faked a shutdown in May 2026 and resurfaced under four names at once: Redact, Pink, Helix, and Falcon. Each posts stolen data on its own leak site, but Google assessed a single crew behind all four based on shared infrastructure, identical phishing templates, and overlapping victim lists. By July the crew's targeting appeared to have narrowed to financial services.

None of the four funds has described receiving a ransom demand, but the crew's pattern across other victims is documented. Demands run $1 to $3 million, most settle around $750,000, and Google traced $10.69 million in Bitcoin across 18 wallets in five months. The extortion arrives from hijacked internal email and Microsoft Teams accounts, so it lands on channels your employees trust. Go quiet and the escalation turns physical: threatening voicemails to executives and, in severe cases, swatting of company personnel.

How to defend against it

A regulator described this playbook six months before the hedge fund calls. On February 6, New York DFS sent an industry letter to the CISOs of regulated entities: actors posing as IT help desk staff, spoofed caller ID, calls to personal and work phones, employees directed to company-branded fake sites where they hand over credentials and MFA codes.

The department's first control is identity verification that does not depend on caller ID for anyone requesting a credential reset or remote access. Its fourth is a review of MFA controls including who is permitted to enroll a factor. That fourth control is the door. At most organizations a help desk agent can still reset MFA enrollment on the strength of a phone call and a plausible story, which is how the Clorox breach started. Regulated entities also carry a reporting obligation under 23 NYCRR § 500.17 if a vishing attempt results in unauthorized access.

The technical controls are documented in Google's August report: phishing-resistant MFA with WebAuthn origin binding, SSO federation for every business-critical app, session controls with device-bound credentials, trusted network zones, managed devices, and detection rules for anomalous MFA registration and scripted file access. Google also published IOCs as free GTI Collections for the August campaign and the earlier BlackFile activity. Ship all of it.

None of it tests whether an employee complies with a call about passkey enrollment. That gap widens if you're mid-migration, because a company rolling out passkeys is training its employees to expect exactly this call, from exactly this number, about exactly this task.

What closes it is a verification path the attacker can't reproduce:

• Publish a callback number and train people to use it. The employee hangs up and dials the help desk from the intranet directory. Caller ID spoofing stops working the moment nobody trusts caller ID.
• Put a verification code in the ticket. The agent reads a code the employee can see on their own screen. An attacker who isn't in your ticketing system can't produce one.
• Announce migrations before you call. If IT posts to a channel employees already read, an unannounced call about passkey enrollment becomes a question instead of an instruction.
• Never send a link over the phone. Make it a rule your help desk follows without exception, and "go to this site" turns into the tell.
• Give them somewhere to take it, and make hanging up a non-event. Reporting has to be one action in a tool they already have open, and a false alarm has to cost them nothing. The person who took the call is best positioned to report it, and the pretext has already given them a reason not to.

Then find out whether any of it holds.

The channel nobody tests is the one that was used

This campaign reached employees on a channel security doesn't own and doesn't monitor. Most awareness programs measure the corporate inbox and stop there. This attack never touched an email.

Mirage runs AI-generated vishing calls to the numbers your employees answer and social engineering messages through Microsoft Teams, using pretexts like the passkey migration described in this post. Employees who get the call can report it through a Slack or Teams agent they already have open, one message instead of a support ticket. Employees who don't catch it get browser-based coaching mapped to what happened on the call.

What comes back is what a click rate can't measure: whether your people comply when the story matches a program you're running, and whether the verification path you published is one they use when the phone rings.

See a live vishing simulation →