UNC6671: How fake IT calls become cloud data extortion

Updated September 12, 2026

This article originally focused on Pink. We now use UNC6671 for the broader campaign covered by Google, while preserving each research team's attribution for related activity. This update adds Microsoft's September investigation and revisits the naming, targeting and defensive guidance. The original publication date is retained.

Which name should defenders use?

Google's August assessment connects UNC6671 intrusions to several extortion brands through infrastructure, phishing templates and targeting overlaps. Google favors a coordinated operation but also discusses splintering, shared services and outsourced extortion as possible explanations.

• UNC6671: Google's intrusion-cluster label and our main reference for that campaign.
• Pink, BlackFile, Redact, Helix and Falcon: public extortion brands associated with the activity by Google. They are not interchangeable names for every operator.
• Storm-3121 and Storm-3032: Microsoft's separate initial-access clusters. Storm-3121 leads to ShinyHunters and Falcon extortion; Storm-3032 covers BlackFile splinter actors using Helix.
• O-UNC-045 / CORDIAL SPIDER: the tracking used in Okta's related vishing research.
• Pink / CL-CRI-1147: the narrower reporting retained in our Pink dossier.

These are source-specific relationships, not a universal alias list. Similar tactics do not establish common operators. BleepingComputer's interview with Google also distinguishes UNC6671 from Scattered Spider. Falcon disputed parts of Google's grouping; that is an actor claim, not independently verified attribution.

What the September investigation adds

Microsoft's September 9 investigation covers activity since May across multiple operators, without assigning every case to UNC6671.

1. Create urgency. A supposed helpdesk contact demands a passkey or SSO update, sometimes reaching a personal phone.
2. Obtain access. Adversary-in-the-middle (AiTM) phishing intercepts authentication, or device-code phishing persuades the employee to authorize the attacker's client on a legitimate Microsoft page.
3. Establish persistence. Attackers add a phone, authenticator or software OTP method they control.
4. Map and collect. Microsoft Graph reconnaissance precedes SharePoint, OneDrive and Exchange data access. Collection can continue for hours or days.

Sign-in records alone do not prove downloads. Microsoft supplies hunting queries that correlate identity and workload events. A python-httpx user agent alone is not proof of malicious activity. BleepingComputer's September 11 coverage provides a companion summary of the investigation.

A passkey lure does not mean passkeys are broken

The pretext and the authentication control are different things. A caller can borrow the language of a security rollout to make an unauthorized request sound routine.

Microsoft's authentication-strength guidance distinguishes ordinary MFA from phishing-resistant authentication. Enabling a stronger method is different from requiring it for access. Review the actual Conditional Access requirements and permitted fallback methods for sensitive resources.

Device-code authorization needs its own policy review. Microsoft's authentication-flow guidance recommends restricting it to necessary uses. Inventory legitimate dependencies, test with report-only policies and define narrow exceptions before enforcement. Users should never enter a caller-supplied code just because the page itself belongs to Microsoft.

The tools can serve more than one operator

Okta's Work Panel research describes a platform built for multiple independent deployments. Callers contact employees; managers control live phishing sessions and captured credentials; administrators provision infrastructure. The caller cannot see the credentials they help obtain. Okta observed the console in at least one cluster covered by its tracking, not as an exclusive identifier for Pink.

That distinction matters when investigating shared tooling: a matching panel can connect technical evidence without proving that two extortion names have the same membership.

SOCRadar's Pink investigation documents environmental checks and operator approval that can hide the lure from scanners. A spinner, blocked screenshot or empty page is an incomplete observation. Preserve the URL, registration and certificate history, and the employee's account of what appeared during the call.

Financial-sector targeting needs careful language

BleepingComputer reported targeting involving Point72, Millennium, Two Sigma, Citadel and private-equity firms. It reported that Point72 had found no evidence of stolen client data and that Two Sigma said it blocked an intrusion attempt without evidence of affected systems or data. Being targeted is not the same as a confirmed breach.

The updated GuidePoint infrastructure study now describes 104 phishing subdomains representing 83 organizations, superseding the smaller snapshot cited in our original article. These are targeting observations across broader infrastructure, not 83 verified compromises or a Pink-only victim count.

Use indicators as evidence, with their source and date

Google's infrastructure analysis includes passkeyhelpdesk[.]com, passkeydeploy[.]com, oskeysync[.]com and keysyncos[.]com. Target names can appear in subdomains of a shared root. These are historical research examples, not a live blocking list or proof that every matching name belongs to UNC6671.

GuidePoint also documents reusable phishing-kit clues:

• request path api_FyekIDWY.php
• response ETag W/"1c-xHTlhvqhxGIJKu5AJR5p+il839Y"
• static asset d15faff9a15a05e605bc9cfadacdfb4f16ff2c9d.svg
• static asset okta-logo-end-user-dashboard.svg

Preserve the response and collection time behind a match. Infrastructure can change owners, legitimate assets can be copied, and a familiar filename does not establish an intrusion. Our Pink dossier remains the place for its narrower reviewed evidence; its counts should not be presented as totals for the entire ecosystem.

What a useful investigation should produce

SecurityAlert analysis: build a timeline with four separate conclusions: how the employee was contacted, what access was granted, what persistence was added, and what data was actually retrieved. Record the supporting event for each conclusion and mark missing evidence explicitly.

Give the identity team the affected account and authentication changes. Give the cloud team the relevant applications, permissions, sessions and data-access window. Give the helpdesk the reported caller details and a verified callback process. Give the incident lead a documented assessment of data loss. Microsoft's compromised-account response guide provides the containment and recovery workflow.

The brand name helps route research. The evidence determines the response.