What GTIG says BlackFile is doing#
Google Threat Intelligence Group says it is tracking an extortion campaign run by UNC6671, a threat actor operating under the “BlackFile” brand. The group targets organizations through voice phishing, or vishing, and then compromises single sign-on accounts.
The campaign is not described as exploitation of a vendor vulnerability. GTIG is explicit on that point. The observed compromises come from social engineering, adversary-in-the-middle credential capture, and abuse of legitimate identity and SaaS access after the victim authenticates.
That matters because the attack path is built around normal enterprise trust. The user receives a call. The caller claims to be internal IT or help desk. The pretext is plausible: a passkey migration, MFA enrollment, or a required authentication update. The victim is sent to a lookalike SSO page. Credentials and MFA responses are captured in real time. The attacker then uses the live session to get into cloud applications and steal data for extortion.
GTIG says UNC6671 has targeted dozens of organizations across North America, Australia, and the UK since emerging in early 2026. The group has also, in at least one case, used the ShinyHunters brand to add credibility to its threats. GTIG assesses BlackFile and ShinyHunters activity as independent, citing separate TOX communication channels, different domain registration patterns, and BlackFile’s own data leak site.
The entry point is a phone call, not a malware drop#
The first move is high-volume vishing. According to GTIG, the callers are often hired by the threat actor. They contact targeted employees on personal mobile phones, which helps move the conversation away from monitored corporate channels and standard support workflows.
The script is simple because it does not need to be exotic. A caller poses as IT. The employee is told that passkey enrollment or MFA migration is mandatory. That pretext gives the victim a reason to visit a new page, enter credentials, respond to MFA prompts, and dismiss warnings as part of the setup process.
GTIG notes that UNC6671 has shifted its credential-harvesting infrastructure. Earlier activity used more organization-tailored domains. Recent campaigns moved toward a subdomain model, with domains often registered through Tucows and subdomains referencing themes such as passkeys, enrollment, or SSO setup. Examples in the report include patterns like:
<organization>.enrollms[.]com<organization>.passkeyms[.]com<organization>.setupsso[.]com
The point is not that these exact domains will remain useful indicators forever. The point is the naming logic. The infrastructure is designed to look like a rushed but plausible identity migration page.
How the MFA bypass works#
This is an adversary-in-the-middle workflow. It does not break MFA cryptography. It uses the victim to complete the authentication ceremony for the attacker.
The victim opens a fake SSO portal. They enter a username and password. The attacker captures those values and immediately submits them to the real SSO provider. When the real service asks for MFA, the attacker relays the challenge back through the social engineering flow. The victim approves a push, enters an SMS code, or provides a TOTP code because they believe they are completing enrollment.
Once inside, GTIG says the actor moves quickly to the user’s security settings and registers a new attacker-controlled MFA device. That creates persistence. The window between initial login and durable access can be short enough that a security operations center may not catch the anomaly before the account is anchored.
This is why standard MFA is not the same thing as phishing-resistant MFA. Push prompts, SMS codes, and TOTP can still be relayed during a live call. Phishing-resistant methods, such as properly deployed passkeys or hardware-backed authentication tied to the legitimate origin, are harder to reuse on an attacker-controlled lookalike site.
What happens after SSO access#
After authentication, the campaign shifts from identity compromise to SaaS data theft. GTIG says the actors focus on Microsoft 365 and Okta environments, then use the compromised accounts to reach SharePoint, OneDrive, and connected applications such as Zendesk and Salesforce.
In some cases, the actors searched internal systems for strings such as “confidential” and “SSN.” That is a direct triage method. They are looking for data that will support an extortion demand, not trying to understand the whole company.
GTIG also observed a move from browser-based reconnaissance to programmatic exfiltration. In multiple engagements, scripts were used to collect data from SharePoint and OneDrive. The reported tooling and methods included Microsoft Graph, Python requests, PowerShell, and direct HTTP GET requests against document resource URLs.
One important detection detail stands out. GTIG says the actor used valid session cookies captured during the initial vishing phase, such as FedAuth, to stream file content directly to attacker-controlled infrastructure. In those cases, the request can resemble a normal web client fetch rather than a formal download operation.
That affects logging. Activity may appear as FileAccessed rather than FileDownloaded. A SOC that mainly watches for high-volume download events may miss or underweight the exfiltration pattern.
What defenders should take from this#
The campaign is a reminder that identity controls are now part of the attack surface. If SSO becomes the central door into cloud applications, then help desk workflows, enrollment pages, MFA reset processes, and user education around authentication become security-critical systems.
The practical lessons are clear:
- Treat unsolicited calls about MFA, passkeys, or SSO changes as high-risk until verified through a known internal channel.
- Move high-risk users and admin roles toward phishing-resistant MFA where possible.
- Watch for new MFA device registration immediately after unusual login activity.
- Monitor suspicious identity-themed domains and subdomains that imitate enrollment or passkey workflows.
- Review SaaS logs for both
FileDownloadedandFileAccessedpatterns, especially at unusual volume or from unusual sessions. - Look for programmatic access to SharePoint, OneDrive, and other SaaS repositories through Graph API, PowerShell, Python clients, or direct document URL fetches.
- Correlate vishing reports with identity events. A phone call to an employee can be the start of the intrusion timeline.
None of this requires assuming a product exploit. That is the uncomfortable part. The attacker is not necessarily breaking the door. They are convincing someone to open it, then registering their own key before anyone looks closely.
What not to overclaim#
The source material does not support treating every vishing incident as BlackFile. It also does not show that Microsoft, Okta, or other named SaaS platforms were compromised at the infrastructure level. GTIG describes abuse of legitimate authentication flows and cloud access after user compromise.
It is also too narrow to frame this as only an MFA failure. The failure chain includes caller pretext, personal-phone targeting, lookalike domains, live credential relay, weak verification of support requests, rapid MFA-device enrollment, and SaaS logging gaps.
BlackFile is useful as a case study because it shows how these pieces connect. The attack is not technically spectacular at every step. It is operationally coherent. That is enough.