1. Executive summary
Google Threat Intelligence Group's 6 August 2026 report describes continuing UNC6671 data-theft extortion despite the announced retirement of the BlackFile brand. Google reports helpdesk impersonation, including calls to personal mobiles, followed by credential and session interception and access to enterprise cloud data. It associates several extortion brands with the activity while retaining alternatives including shared services, splintering and outsourced negotiation. Likely (B2), defenders will gain more from following identity changes and unusual cloud access than from treating a change of extortion name as evidence that the intrusion pattern has ended; this is our assessment of Google's reported continuity and attribution limits.
2. Contextual background
Google's 15 May 2026 investigation described UNC6671 activity under the BlackFile name, focusing on voice phishing, single sign-on access and data theft from Microsoft 365 and Okta-connected environments. It explicitly characterised the compromises as social engineering rather than exploitation of a vulnerability in those providers. Google's May 2026 assessment also distinguished UNC6671 from the ShinyHunters activity it tracked as UNC6240, despite brand borrowing.
The August 2026 update reports targeting involving financial services, private equity and professional services. That is Google's observation of the campaign, not evidence that only those sectors are exposed. The operational question for another organisation is whether an employee can be persuaded to grant the same kinds of access through a believable support conversation.
For an internal assessment, begin with the actual account-recovery and security-enrolment workflows. Identify who is authorised to request a change, how the employee verifies the request and where the resulting event appears in audit records. A familiar technology brand in a call script does not establish the caller's authority.
3. Technical analysis
Google describes callers posing as helpdesk staff and directing employees to lookalike authentication portals under security-migration pretexts. Its May 2026 report documents subsequent registration of an attacker-controlled authentication device. The August 2026 report describes continued interception of credentials and multi-factor authentication material, along with account-level persistence and automated cloud collection. These are findings attributed to Google; no exploitation procedure is required to understand the defensive problem.
The important distinction is between the employee completing a legitimate-looking authentication step and the organisation approving the resulting access. Our assessment is that a support process should establish both. Verify the requesting person and the business purpose through a known channel, then check what identity or device received access. A successful authentication event does not by itself answer either question.
Google's May 2026 analysis describes file retrieval recorded as FileAccessed rather than FileDownloaded, including scripted activity using captured session material. Its August 2026 guidance consequently recommends examining both event types when scripting user agents or unusual volumes are present. The distinction matters for a detection programme that treats one operation as inherently low risk.
We recommend reconstructing the session's activity across the identity provider and each relevant application. Record the initial authentication, enrolment changes, application access and subsequent data operations. A timeline confined to the login service can leave the data question unresolved; a file-access investigation without the identity timeline can miss the means of continued access.
The security-migration pretext should not be confused with a demonstrated cryptographic failure of passkeys. Google recommends phishing-resistant authenticators, including security keys and passkeys, in its hardening guidance. Our recommendation is to distinguish the technology being requested from the identity of the person requesting it, and then validate the destination and resulting account change through a trusted process.
4. Impact assessment
The immediate impact described in the cited reports is theft of business information and extortion. Google's reporting does not support an assumption that every incident involved endpoint encryption. An organisation should therefore evaluate confidentiality and continuing account access even when its systems remain available.
Our recommended scoping method separates accessible information from information demonstrably accessed or transferred. Start with the compromised identity's permissions, then narrow the finding using application events and preserved evidence. Avoid describing all data in a connected service as stolen solely because the account had access. Equally, do not treat a lack of download events as conclusive when the reported collection path can produce access events.
For business owners, the useful output is a list of affected identities, the services investigated, the evidence of activity, and the unresolved intervals. Where retention or permissions limit the investigation, explain that limitation directly. This gives legal, communications and operational teams a factual basis for decisions without treating the criminal's assertions as verified.
5. Indicators and hunting guidance
The following are selected observations from Google's August 2026 report, with supporting authentication and audit context in its May 2026 investigation.
| Observation | Source context | Defensive use |
|---|---|---|
passkeyhelpdesk[.]com |
Google reports use in targeting associated with multiple extortion brands | Historical domain pivot, correlated with the affected identity |
createssopasskey[.]com |
Reported authentication-enrolment themed infrastructure | Search retained browser, proxy and authentication evidence |
python-requests/2.28.1 |
Reported scripting user agent | Review application, account and volume context |
system.multifactor.factor.setup |
Google's recommended identity-log pivot | Investigate unexpected enrolment following failed or abandoned challenges |
FileAccessed and FileDownloaded |
Reported audit events relevant to scripted collection | Review both rather than relying on one event class |
Google cautions that infrastructure changes rapidly and that many observed addresses belong to commercial proxy or hosting services. Its August 2026 domain list is primarily useful for historical investigation and naming-pattern context. Do not convert shared-provider addresses into an assertion that every customer of that provider is hostile.
Our proposed hunt starts with an unexplained enrolment or suspicious support report and expands to the same account's cloud activity. Compare scripting activity with approved automation and the user's usual working pattern. A generic Python user agent can be legitimate; the stronger finding is an unexpected combination of account changes, application access and data operations.
Where an enrolment appears legitimate, confirm the matching support case with its actual owner. Compare the request time, approved method and affected account with the audit event. A ticket created after an alert should not automatically explain earlier activity; document whether the request and approval genuinely preceded the change. This is our proposed validation step, not an additional behaviour attributed to UNC6671.
For triage, retain the underlying event identifiers and source timestamps. Establish whether an alert concerns an actual enrolment, a failed attempt or a user-reported conversation with no matching activity. Those distinctions prevent a support report from being silently promoted into a confirmed breach.
6. Incident response guidance
Our recommended containment plan should cover the account, its authentication methods and its connected applications. Confirm the affected person's identity through a trusted channel and avoid sending recovery material through the account under investigation.
Review authentication methods and device enrolments, revoke unauthorised access and assess active sessions using the provider's supported controls. Record which actions were completed and validate the result. A password change alone should not be used as the closure criterion for a case involving session material and additional authentication methods.
Preserve identity and application logs before retention limits remove the relevant period. Ask each service owner to supply the evidence they can actually retrieve, rather than assuming one central log contains all of it. Record gaps by service and time range. Preserve extortion communications separately so investigators can compare their assertions with observed access.
The August 2026 report describes deletion of security and password-reset notifications. Investigators should therefore compare underlying audit events with the user's recollection and mailbox contents. A missing notification does not settle whether an account change occurred. This finding also supports retaining independent administrative audit trails for sensitive identity changes.
Coordinate containment with the business owner of automated processes using the affected identity. Verify whether legitimate jobs fail after access is removed, and restore only the permissions needed for approved work. The purpose is to recover a trusted account state while documenting, rather than silently recreating, previous access.
7. ATT&CK context
These are our mappings of the reported behaviour to MITRE ATT&CK definitions. They do not constitute independent attribution by MITRE.
| Technique | Reported behaviour supporting the mapping |
|---|---|
| T1566.004: Spearphishing Voice | Helpdesk impersonation through voice calls |
| T1557: Adversary-in-the-Middle | Interception during the authentication interaction described by Google |
| T1550.004: Web Session Cookie | Google's May 2026 report describes reuse of captured session cookies for data retrieval |
The mappings help distribute detection work between the support team, identity administrators and application owners. A voice-phishing report creates a collection lead; authentication and application evidence determine what followed. Avoid claiming that a telephone conversation alone proves token theft or exfiltration.
We recommend an exercise in which staff receive a benign, clearly controlled simulation of a support request and responders must trace its consequences through the authorised test account. Measure whether the team can verify the request, locate any resulting identity change and inspect subsequent service access. Do not collect real credentials as part of the exercise.
8. Mitigation recommendations
Google recommends phishing-resistant authentication and consistent identity controls across connected applications. Its August 2026 guidance also covers managed-device requirements, session controls and behavioural auditing of cloud access. Implementations should be tested against the organisation's own support and recovery paths so that a stronger normal login does not leave an unexamined exception.
Our recommendation is to make genuine helpdesk requests independently verifiable. Publish a known support route and ensure staff can pause an unsolicited call without losing access or being penalised. Test whether the support team can confirm an actual migration or account change without relying on the caller's supplied link or telephone number.
Review access to sensitive repositories through both human and automation identities. Give approved scripts identifiable accounts, documented purposes and expected data scope. Then investigate activity that falls outside that scope. This makes a scripting user agent a useful context field without treating it as a verdict.
For identity changes, retain enough detail to establish the actor, method, target account and time. The review should distinguish a routine user enrolment from an administrator-assisted recovery. Set an explicit owner for investigating exceptions, especially where a critical application does not use the organisation's normal sign-on policy.
9. Historical context and attribution limits
The May 2026 report treated BlackFile's shutdown notice as a possible transition rather than a demonstrated end to UNC6671 activity. Google's August 2026 update associates BlackFile, Redact, Pink, Helix and Falcon through infrastructure and operational overlaps, but explicitly discusses alternative explanations. This article preserves that uncertainty instead of publishing those names as proven interchangeable aliases.
For collection, retain the exact name used in a communication and the publisher's cluster identifier as separate fields. An extortion brand is a useful observation; it is not sufficient evidence of the individuals behind the intrusion. Similar techniques can support comparison without establishing common ownership.
10. Outlook and assessment
Likely (B2), the continuity of helpdesk pretexts and identity-centred collection will remain more useful to defenders than a count of apparent brand changes. This judgement is limited to the operational pattern Google documents and does not predict a specific new campaign or victim.
Evidence that would sharpen the assessment includes independently observed reuse of the same access methods and infrastructure across further cases. Evidence of distinct operators or divergent procedures would support separating activity that currently appears related. Defensive teams can continue investigating suspicious enrolments and cloud access while those attribution questions remain open.
