According to the FBI/IC3 FLASH dated 12 September 2025, UNC6040 operators voice-phished workforce users at Salesforce customer organizations while posing as IT or support. Callers induced victims to share credentials and multifactor authentication codes on the phone, and guided them to authorize malicious connected apps, often Salesforce Data Loader. Public reporting describes a data-extortion pattern across multiple organizations; it does not establish a full victim list or quantified record counts in the materials used here. Google Threat Intelligence had previously documented the same voice-phishing data-extortion pattern against Salesforce customers. This is not the UNC6395 Salesloft/Drift OAuth-token theft campaign.
If you want the prevention angle, read the related article on mfa2point0.com.
FAQ
How did UNC6040 get Salesforce access?
UNC6040 got Salesforce access by voice-phishing workforce users who shared login credentials and multifactor authentication codes live on IT-support-style calls, and by guiding those users to authorize malicious connected apps such as Salesforce Data Loader. According to the FBI/IC3 FLASH on 12 September 2025, both paths appear in the campaign. The credential and code handoff is classic transferable-factor social engineering. The connected-app step is a separate OAuth authorization grant after the caller already has the victim cooperating.
Did MFA stop UNC6040's vishing?
No. Legacy MFA did not stop UNC6040's vishing because the multifactor codes were treated as secrets the user could read aloud to a caller posing as IT or support. Passwords and OTP-style codes are transferable factors under social pressure. Public reporting on the UNC6040 Salesforce campaign centers on that verbal credential and MFA-code transfer, not on a spoofed login page or helpdesk TAP reset. A fix exists that removes shareable login factors from the identity path; the prevention write-up is on the companion site.
What did the malicious Data Loader consent do?
Malicious Salesforce Data Loader (or similar connected-app) consent gave UNC6040 standing OAuth access to org data after the victim approved the app. That step is authorization abuse, not another MFA check at login. Issued OAuth access, including residual refresh tokens noted in public intake on this campaign, is a post-authentication artifact. No login MFA redesign undoes consent that was already granted. Defenders still need connected-app allowlists, consent policy, and token revocation for that layer.
Is UNC6040 the same as Salesloft/Drift token theft?
No. UNC6040 is the Salesforce vishing campaign that steals workforce credentials and MFA codes and steers malicious connected-app consent. UNC6395 is the separate Salesloft/Drift OAuth-token theft pattern. Conflating them mis-scopes both the initial access and the control conversation. For UNC6040, the hero failure at the door is verbal transfer of passwords and MFA codes plus user-driven OAuth consent, not third-party integration token theft from Salesloft/Drift.
Would blocking only the password have been enough?
No. Blocking only the password would not have been enough against UNC6040 as reported, because callers also collected multifactor authentication codes and pushed malicious connected-app authorization. Closing shareable login factors stops the read-out-your-code path. OAuth connected-app consent and residual refresh-token use still need separate Salesforce authorization controls. Public reporting does not establish named enterprise victims or ransom figures for this FLASH beyond the multi-organization data-extortion pattern.
