Executive summary
Google Threat Intelligence Group (GTIG) reported on 15 May 2026 that the cluster it tracks as UNC6671 operates under the BlackFile brand, using voice phishing and compromised single sign-on access to steal corporate data. Its investigation describes Microsoft 365 and Okta environments, unauthorised authentication-factor registration and scripted collection from cloud repositories. We assess it is likely (B2) that investigations focused only on password resets and download events will miss material parts of this activity, because GTIG observed persistent identity changes and file retrieval recorded as access rather than download events.
Contextual background
GTIG identifies UNC6671 as distinct from the ShinyHunters cluster it tracks as UNC6240. Although the BlackFile operators borrowed the ShinyHunters brand in at least one instance, Google assesses the operations as independent, citing communication infrastructure, registration patterns and the dedicated extortion website. This article uses those labels within Google’s tracking scheme rather than treating a name used in an extortion message as proof of identity.
The report says these compromises do not result from a security vulnerability in the named vendors’ products or infrastructure. The described entry path combines impersonation with abuse of legitimate authentication and cloud access. That distinction matters for response: a software patch alone does not resolve an unauthorised factor, a stolen session or excessive access granted to a compromised account.
GTIG assesses that the operation targeted dozens of organisations across North America, Australia and the United Kingdom. That is the publisher’s assessment of targeting, not a verified count of organisations that lost data. Keep targeted, accessed and exfiltrated populations separate when using the report to explain risk.
Initial access and identity persistence
The reported calls impersonate internal IT or helpdesk staff and commonly use a supposed passkey migration or multifactor-authentication update as a pretext. Callers direct employees to lookalike sign-on pages while maintaining live contact. GTIG notes that personal mobile numbers are often used, moving the interaction away from familiar corporate support channels.
The report describes adversary-in-the-middle activity that captures credentials and abuses approvals or codes during authentication. It also describes registration of an attacker-controlled authentication factor after access is obtained. The defensive consequence is broader than an exposed password: investigation must account for the account’s factors, sessions and connected applications.
Our recommendation is to make legitimate support changes independently verifiable. Employees should be able to end an unexpected call and contact support through a known directory or established service channel. A caller’s familiarity with an organisation’s terminology, or a plausible explanation for an authentication alert, should not substitute for that verification.
Support teams also need a defined escalation path for reports of suspicious enrolment calls. Preserve the time, claimed support activity, destination domain and affected identity without asking the employee to repeat the interaction. Correlate that report with identity-provider events quickly enough to investigate new factors and sessions while the evidence remains available.
Technical analysis: cloud data collection
GTIG observed the operators using compromised single sign-on access to reach SharePoint, OneDrive and connected services including Zendesk and Salesforce. In several instances, internal searches sought terms associated with sensitive information. That describes observed selection behaviour, not proof that every accessible repository or record was collected.
The investigation describes a transition from interactive reconnaissance to automated retrieval using Python, PowerShell and service APIs. Valid session cookies can be reused to request document content in ways that produce FileAccessed events rather than the FileDownloaded events many teams prioritise. A hunt restricted to the latter can therefore omit relevant evidence.
GTIG also found mismatches between application identity and user-agent information: requests appeared to claim a Microsoft Office application context while telemetry identified scripting tools. Such discrepancies can help prioritise investigation, but neither Python nor PowerShell usage alone establishes malicious activity. Compare the identity, device, application purpose, source infrastructure and volume with approved automation.
In one investigated case, GTIG reports access and download of more than one million individual files from SharePoint and OneDrive. This is a case-specific observation, not a typical loss estimate for every BlackFile incident. Our recommendation is to establish scope from the affected organisation’s own audit records and verified samples rather than extrapolate that figure.
Indicators and hunting leads
Google’s report provides examples of themed phishing domains and warns that infrastructure changes rapidly. It also notes that many associated addresses are commercial VPN nodes. Historical domains and addresses can support retrospective investigation, but they are incomplete as a real-time prevention strategy.
| Lead | Why it matters | Required context |
|---|---|---|
| Unexpected authentication-factor enrolment | Reported persistence after initial access | User confirmation, preceding authentication events and approved support activity |
FileAccessed or FileDownloaded with a scripting user agent |
Reported automated file retrieval | Volume, identity, normal automation and the accessed repositories |
| Application identity inconsistent with the user agent | Observed discrepancy in the investigation | Full event fields and legitimate application configuration |
| Unfamiliar VPN or hosting-origin authentication | Infrastructure characteristic noted by GTIG | User’s normal access pattern and session context |
| Unsolicited call about passkeys or MFA changes | Reported social-engineering pretext | Verification through an established support channel |
Our recommended detection logic combines these signals. For example, an unapproved factor addition followed by unusual bulk file access deserves more attention than a generic scripting user agent from a known administrative job. Preserve the supporting event sequence so analysts can distinguish a meaningful correlation from several unrelated alerts.
Detection and hunting guidance
GTIG recommends reviewing identity-provider factor-setup events and correlating them with failed or abandoned authentication challenges. It also recommends examining both file-access and file-download telemetry for unusually high activity from scripting clients. Adapt those recommendations to the actual log schemas and retention available in the organisation.
Our recommended first pass builds an identity timeline: the reported call, authentication events, factor changes, session activity and subsequent application access. Then examine the data-access sequence within each connected service. A single sign-on event is the beginning of the investigation, not the full account of what the session could reach.
For repository activity, compare volume and cadence with the account’s usual work. Review the breadth of sites accessed, newly visited repositories and whether the client appears automated. Approved migrations, backups and reporting jobs can create substantial legitimate activity. Identify those jobs explicitly rather than setting a universal threshold that labels every large operation as theft.
Record the difference between access evidence and confirmed exfiltration. A log event can establish that a request reached a file, while the precise transfer outcome may require additional context. Conversely, the lack of a download-labelled event does not clear a sequence where direct retrieval is supported by other evidence. Keep that reasoning visible in the incident scope.
Impact and extortion assessment
GTIG describes data theft followed by extortion, including pressure through email, compromised internal communications and threatening calls. It reports severe cases involving swatting against personnel. The response should therefore include the organisation’s established employee-safety and threat-reporting procedures where such threats occur, alongside the technical investigation.
Our recommendation is to treat an extortion note as a claim requiring verification. Preserve the message and any supplied samples, then compare them with known data and access records. Neither a frightening deadline nor a claimed dataset size establishes the actual breach scope. Separate verified material from assertions that remain unsupported.
Involve the owners of affected data and services in that assessment. Cloud access can cross organisational boundaries even when the compromised identity belongs to one team. Determine which repositories the identity could reach, what the logs show and which additional accounts or integrations require examination. Avoid assuming either complete tenant compromise or a scope limited to the user’s personal files.
Incident response guidance
Our recommended containment addresses the full identity state: revoke relevant sessions using the provider’s supported procedures, remove unauthorised authentication factors, reset exposed credentials and review application access. Perform recovery through a trusted administrative path. A password reset should not be used as shorthand for completion of every identity-recovery task.
Preserve the original factor, authentication and cloud-access records before retention or operational changes remove them. Record the timestamps and basis for each containment action. This allows investigators to distinguish activity before containment from possible continued access afterwards and to test whether the intended controls took effect.
Review connected SaaS services separately. Confirm their session behaviour, account permissions and audit evidence rather than assume one identity-provider action immediately resolves every downstream application. Where a service owner cannot establish whether access remains active, keep that issue open with a defined verification action.
After containment, compare subsequent activity with the recovery plan. Recheck factors, privileges and unusual repository access, and confirm that legitimate users can use the restored account through the intended authentication method. Record unresolved data-scope questions separately from restored account availability.
Mitigation recommendations
GTIG recommends phishing-resistant authentication, including FIDO2-compliant security keys or passkeys. CISA’s guidance distinguishes phishing-resistant methods from one-time codes and ordinary push approvals. It also emphasises that multifactor authentication still offers value; weaknesses in some methods are not a reason to remove it.
Our recommended migration plan covers enrolment and recovery as well as everyday sign-in. Identify who can register a factor, what verification support staff require and how unexpected changes are reported. A strong normal sign-in method can be undermined if the recovery process grants equivalent access on the strength of an unverified call.
Review logging before an incident. Ensure identity changes and relevant SaaS access events are retained long enough for investigation, and test a benign scenario that exercises factor enrolment and scripted file access. The purpose is to verify visibility and triage, not to claim that a single analytic will detect every variant of this operation.
Threat intelligence context and outlook
Our ATT&CK mappings are T1566.004: Spearphishing Voice, T1557: Adversary-in-the-Middle and T1213.002: Sharepoint, based on the voice pretext, interception and repository collection described by GTIG. They do not establish a complete intrusion sequence for every victim.
GTIG reports that the BlackFile website briefly returned on 11 May 2026 with a shutdown message before becoming inaccessible again. A brand announcement does not establish that the underlying activity has ceased. The durable defensive priorities remain independently verifiable support interactions, protected identity recovery and visibility into cloud data access.
