UNC6040 - Vishing the Help Desk → Victim Authorizes a Fake Data Loader → OAuth Connected App → Bulk Salesforce Exfiltration → Extortion Months Later
Google Threat Intelligence first reported UNC6040 in June 2025: a financially motivated cluster that compromised Salesforce tenants without exploiting a single Salesforce vulnerability. Operators phoned employees at English-speaking branches of multinationals impersonating IT support, walked them through Salesforce's own connected-app authorization page, and had them enter a connection code that authorized an attacker-controlled build of Salesforce's Data Loader tool. From that point the app queried and exported data with the victim's own permissions. Victims included Google's own corporate Salesforce instance, along with fashion houses and technology firms. Extortion arrived separately and sometimes months later - Google tracks that follow-on activity as UNC6240, which demands bitcoin within 72 hours and claims affiliation with ShinyHunters, likely for pressure. The chain that matters here is the one where a legitimate consent screen, shown to a real employee who was told to expect it, is the entire attack.
The same opening as Scattered Spider / MGM two years earlier, aimed at a different endpoint. Voice is chosen deliberately: it carries urgency and social pressure that email cannot, it defeats every mail-based control an organization has bought, and it leaves no artifact for a security team to inspect afterwards. Targeting skewed to English-speaking branches of multinationals, where an unfamiliar accent or an unknown internal name is unremarkable and staff routinely take instruction from a central IT function they have never met. Calls were placed over Mullvad VPN addresses and TOR. In some intrusions the operator also stood up an Okta phishing panel and simply asked for credentials and MFA codes during the call.
Targeting: English-speaking branches of multinational corporations
Why voice: Urgency and pressure, no mail controls, no artifact to inspect later
Infrastructure: Mullvad VPN addresses and TOR for calls and collection
Sometimes also: An Okta phishing panel to capture credentials and MFA codes live
This is the elegant part, and the reason no product vulnerability was needed. Salesforce's Data Loader is a legitimate bulk import and export tool that connects through OAuth as a connected app. The operator supplied a modified build with altered name and branding, not published by Salesforce, and walked the victim through Salesforce's own authorization flow to link it. Everything the employee saw was real: the genuine Salesforce domain, the genuine consent page, a tool name they recognized, and a helpful colleague on the phone explaining why it was needed. The only false element was the identity of the person asking. Consent screens are a poor control at the exact moment they matter most, because a user who has been told to expect one and given a plausible reason will approve it, and the interface offers them nothing that distinguishes this app from the real thing.
Mechanism: Attacker-controlled connected app, authorized via a supplied connection code
Everything genuine: The domain, the consent page, the flow, the tool's apparent name
Only false element: Who was asking, and why
Later evolution: The group moved from Data Loader to custom Python scripts doing the same job
The call ends and the access does not. An OAuth grant is a durable authorization that operates on its own credential, so it survives the user logging out, changing their password, or completing an MFA challenge for something else. Nothing in the victim's normal experience signals its existence, and nothing in the standard account-hygiene playbook revokes it. This is the same structural property that made Salesloft Drift and Vercel / Context.ai so effective, reached here by talking a person into creating the grant rather than by stealing one that already existed. The only reliable kill switch is revoking the connected app itself, and that requires knowing it is there.
Not revoked by: Logout, password change, or later MFA challenges
Visible to the user: Effectively nothing after the initial approval
Only real kill switch: Revoking the connected app, which requires knowing it exists
Google observed a deliberate two-phase pattern: small chunk sizes at first for reconnaissance, working out which objects mattered and what the schema looked like, then a sharp increase in volume to take entire tables once the operator knew what was worth having. Proficiency varied noticeably between intrusions, which suggests different hands on different jobs; in one case only about ten percent of the data was retrieved before detection cut it short. That variance is the encouraging detail, because it means detection latency directly determined loss - the control that mattered was volumetric alerting on export activity, and where it existed it worked.
Phase 2: Sharply increased volume, whole-table extraction
Variance: Operator proficiency differed across intrusions; one victim lost only ~10% before detection
Implication: Detection latency directly determined how much was lost
Control that works: Transaction Security Policies alerting on large exports
Where the operator had also harvested end-user credentials during the call, those were reused to move into other cloud platforms - Okta and Microsoft 365 in particular. That turns a CRM data-theft incident into an identity incident, and it is the reason scoping this to "we lost some Salesforce records" was usually wrong. Okta is the higher-value target of the two by a distance, because control of the identity provider is control of everything federated behind it. Any response to a vishing call that yielded credentials has to assume the identity estate is in scope, not just the application the caller named.
Source: Credentials and MFA codes captured during the vishing call
Why Okta matters most: The identity provider governs everything federated behind it
Scoping rule: A successful vishing call puts the identity estate in scope, not one app
The gap between theft and extortion frequently ran to months, and Google tracks the monetization as a separate cluster, UNC6240, suggesting UNC6040 sells or hands off access rather than extorting directly. Demands came by call or email to employees, wanted bitcoin within 72 hours, and asserted affiliation with ShinyHunters - a claim Google treats as likely pressure tactics rather than established fact, sent from addresses including shinycorp@tuta[.]com and shinygroup@tuta[.]com. Two practical consequences follow. First, an organization can be months past a successful intrusion with no signal at all, so a vishing report from a single employee deserves a real investigation rather than a note. Second, a familiar crew name in a ransom note is a marketing claim, and treating it as attribution will send an investigation in the wrong direction.
Demand: Bitcoin within 72 hours, by call or email to employees
Branding: ShinyHunters affiliation claimed; Google treats it as a pressure tactic
Addresses seen:
shinycorp@tuta[.]com, shinygroup@tuta[.]comEscalation: The actors were preparing a data leak site for additional pressure