The call lands on a personal cellphone, never a work line. A calm voice says IT is finishing a company-wide switch to passkeys, spoofs a helpdesk number the employee half-recognizes, and walks them through "verifying" a login at a domain like createssopasskey[.]com. Ninety seconds later, the caller holds a username, a password, a valid MFA code, and a live session cookie for Microsoft 365, Okta, or Salesforce, and none of it touched a device the company's EDR agent has ever seen.
That script belongs to UNC6671, a data-extortion operation Google Threat Intelligence documented on August 6 running under at least five leak-site brands since January: BlackFile, Redact, Pink, Helix, and Falcon, all sharing phishing kit code and infrastructure behind the rebrands. Pink is not a new name to readers here: it is the same crew Okta Threat Intelligence and Unit 42 tracked in July under the narrower designations O-UNC-066 and CL-CRI-1147 for the Entra passkey-enrollment abuse we covered at the time. Google's August report is the first to tie that brand and four others together under one operator. Google's researchers tie 141.65 tracked Bitcoin, roughly $10.69 million, to just the first four months of the operation, with 53% of negotiations ending in payment at a median of about $750,000. By July, the group's targeting had narrowed hard onto financial services, private equity firms, and law firms, the entities holding deal documents, litigation records, and capital-deployment data worth extorting twice: once for the decryption, once for silence.
If your organization already mandates FIDO2 or platform-passkey MFA for every identity and blocks federation from devices that fail a compliance check, UNC6671's opening move does not work on you. WebAuthn's cryptographic origin binding is exactly what defeats an adversary-in-the-middle proxy sitting between a victim and a lookalike domain, so skip ahead to the detection section. If any part of your workforce still enrolls MFA or resets a passkey over a phone call, or if personal phones and unmanaged laptops can reach Microsoft 365, Okta, or Salesforce without a device check first, this is yours. For a forty-person advisory firm, a stolen M&A dataset is not a line item on an incident report. It is the client relationship the firm was built on.
How a phone call becomes a live session
The pretext is consistent across every UNC6671 brand: an urgent, company-mandated move to passkeys or updated MFA, delivered by someone posing as helpdesk staff over a spoofed internal number, aimed specifically at the employee's personal mobile device rather than a work line or a managed laptop. That device choice is deliberate. It sits outside whatever mobile device management or endpoint detection the company runs, so nothing in the security stack sees the call happen.
The victim gets steered to a subdomain built for the occasion, patterns like [company].createssopasskey[.]com or [company].addssopasskey[.]com, sitting behind reverse-proxy infrastructure that relays traffic to the real Microsoft, Okta, or Salesforce login endpoint while capturing everything that passes through: username, password, MFA code, and the session cookie issued at the end. Google's writeup lists proxy IPs tied to the campaign, including addresses on Private Layer AS51852 in Switzerland and DDOS-GUARD AS57724 in Russia, and notes that identical phishing templates get redeployed across supposedly separate brands, evidence that the five leak sites are marketing fronts for one technical operation, not five competitors.
What happens after the call ends
A stolen session cookie buys persistence, not just one login. Attackers use the compromised account to trigger password resets on applications that sit outside single sign-on, then delete the resulting confirmation emails, security alerts, and MFA-change notifications before anyone reads them. The company's own audit trail still exists; the inbox copy the security team was counting on to flag it does not.
From there, exfiltration runs on scripts, not clicks. Google's telemetry shows python-requests and WindowsPowerShell user agents pulling files from SharePoint and OneDrive, and authenticating to Okta and Microsoft 365 through residential proxy IPs on carriers like AT&T, Comcast, and Optimum, so the traffic looks like an employee logging in from home rather than a scraper. The operational tempo backs up the automation: UNC6671 registered new phishing domains roughly once every 2.2 days in April and May, accelerated to once every 1.6 days by June and July, and spiked to seven domains in 72 hours between July 20 and 22. That is infrastructure provisioning at a pace no human operator sustains by hand.
UNC6671 did not start with financial services. Google's researchers trace three targeting phases since the campaign's public emergence in January. From April through May, the group ran a broad, high-volume sweep against manufacturing, real estate, healthcare, and insurance, harvesting whatever credentials it could reach. In June, the focus tightened onto large technology, transportation, and hospitality companies holding intellectual property and source code worth stealing on its own. By July, the operation had concentrated almost entirely on private equity firms, law firms, and financial rating agencies, the businesses sitting on merger documentation, litigation records, and capital-deployment plans that are worth far more to a counterparty or a competitor than the ransom demand itself.
That progression describes a group learning which victims pay fastest and negotiating accordingly. A firm advising on a pending acquisition cannot afford six weeks of a leak-site countdown while regulators or the other side of the deal watch, and UNC6671's median settlement of roughly $750,000 against initial demands north of $3 million suggests the group already knows that. A twenty-person boutique advisory shop carries the same deal data as a bulge-bracket bank and the same phone-vishing exposure, without the security budget to match either.
Finding the machine-speed part of a human-speed attack
The vishing call is hard to catch in the moment. The automated exfiltration that follows leaves a pattern a log query can find, because a script reading thousands of files in an hour does not look like a person reading files, even when it authenticates with a valid session.
// Sentinel / Log Analytics: SharePoint and OneDrive reads at
// automation scale, arriving as ordinary "access" events rather
// than flagged downloads
OfficeActivity
| where RecordType == "SharePointFileOperation"
| where Operation in ("FileAccessed", "FileAccessedExtended")
| where UserAgent has_any ("python-requests", "WindowsPowerShell", "Go-http-client")
| summarize FileAccessCount = count(), DistinctFiles = dcount(SourceFileName)
by UserId, ClientIP, UserAgent, bin(TimeGenerated, 1h)
| where FileAccessCount > 50
| order by FileAccessCount descRun the same logic against Okta's System Log for the setup side of the attack: an MFA or passkey enrollment event that was not preceded by a normal authentication.
# Okta System Log: MFA/passkey enrollment events, cross-referenced
# against whether a legitimate auth challenge preceded them
curl -s -H "Authorization: SSWS $OKTA_TOKEN" \
"https://$OKTA_DOMAIN/api/v1/logs?filter=eventType+eq+%22system.multifactor.factor.setup%22&since=$(date -u -d '7 days ago' +%Y-%m-%dT%H:%M:%SZ)" \
| jq '.[] | {actor: .actor.alternateId, ip: .client.ipAddress, outcome: .outcome.result, published: .published}'Both queries key on a detail Google's guidance calls out directly: treat a scripted FileAccessed event with the same weight as a FileDownloaded event, and treat an MFA enrollment with no matching prior authentication as a finding, not noise.
Where the smaller-firm defense actually breaks
None of UNC6671's tradecraft is exotic. What makes it work against professional-services firms specifically is a handful of gaps that show up more often the smaller the IT team gets.
The gaps this campaign is built to find
- Personal phones authenticate to company SaaS with no device-compliance check first, so the call and the resulting session never cross anything the security team monitors.
- Helpdesk MFA and passkey reset requests get honored over the phone with no callback to a number already on file, so a spoofed caller ID is enough.
- Single sign-on covers the well-known apps but not every app, and the gaps are exactly what the attacker uses to survive a password reset on the SSO account.
- Session lifetimes run long with no continuous re-evaluation, so a stolen cookie from a Tuesday vishing call is still valid Thursday.
- Security alerting lives only in the mailbox the attacker already controls, with no copy forwarded somewhere the account holder cannot delete it from.
- Nobody has run a live vishing drill against the firm's own helpdesk, so the first real test of the verification process is the one an attacker administers.
A twenty-person firm rarely has a security operations center watching sign-in logs in real time, and that is the actual gap UNC6671 is pricing in when it moves down-market from Fortune 500 targets to professional-services firms. The controls below do not require a SOC. They require turning on settings most identity providers already ship.
Move MFA and passkey enrollment off the phone entirely
The fix that closes UNC6671's opening move is specific, not a general hardening checklist. Require phishing-resistant, FIDO2-based MFA or passkeys tenant-wide, since WebAuthn's origin binding is what an adversary-in-the-middle proxy cannot forge no matter how convincing the lookalike domain looks. Gate federation to Microsoft 365, Okta, and Salesforce on device compliance so personal, unmanaged hardware cannot complete a login at all. Require any MFA or passkey enrollment or reset request to route through a callback to a number already on file, never a number the caller supplies. Shorten session lifetimes and turn on continuous access evaluation so a stolen cookie expires in hours, not days. Forward security and MFA-change alerts to a channel the account holder cannot purge from their own inbox.
We assess identity infrastructure for exactly this failure mode, the trusted call, the unmanaged device, the session nobody re-checks, as part of our Active Directory and Entra ID engagements. Book a session to walk through where your helpdesk-verification and device-compliance gaps actually sit.
Primary sources: Google Threat Intelligence's UNC6671 writeup, The Hacker News's coverage of the campaign, CISA's Implementing Phishing-Resistant MFA fact sheet, and Microsoft's Continuous Access Evaluation documentation.
Need help hardening your identity infrastructure?
We assess Active Directory and Entra ID environments for the misconfigurations attackers actually exploit, including the helpdesk-verification and device-compliance gaps this campaign is built to find. Book a session to discuss your environment.