UNC6040 Salesforce vishing worked when workforce users read passwords and multifactor authentication codes aloud to callers posing as IT or support, and when those users authorized malicious connected apps such as Salesforce Data Loader. According to the FBI/IC3 FLASH dated 12 September 2025, that pattern supported a multi-organization data-extortion campaign. Phishing-proof MFA 2.0 removes shareable login factors so a caller cannot harvest a password or code. Malicious OAuth connected-app consent and residual refresh-token use still need separate Salesforce authorization controls.

For the full attack-chain write-up, see the companion on legacymfa.sucks.

FAQ

Would MFA 2.0 stop UNC6040 MFA code vishing?

Yes for the credential handoff. Phishing-proof MFA 2.0 would stop the UNC6040 path where victims dictate passwords and multifactor authentication codes on a voice call, because device-bound authentication has no transferable secret to read aloud or replay from a script. According to the FBI/IC3 FLASH on 12 September 2025, UNC6040 operators requested credentials and MFA codes while posing as IT or support. Legacy OTP, SMS, email codes, and push approvals fail that test under social pressure. Closing the phishable login stops this path. Public reporting does not establish a spoofed AiTM page or helpdesk TAP reset as the mechanism for this campaign.

Does device-bound MFA block Data Loader consent?

No. Phishing-proof device-bound MFA does not block malicious Salesforce Data Loader or other connected-app consent in the UNC6040 campaign. That step is an OAuth authorization grant after the user is already cooperating, not another login-factor check. MFA 2.0 does not govern connected-app allowlists, consent policy, or API authorization. Defenders still need those Salesforce-side controls, plus revoke for residual OAuth access and refresh tokens noted on this campaign. No login MFA redesign undoes consent that was already granted.

What does MFA 2.0 change for this vishing class?

MFA 2.0 changes the workforce login surface by replacing passwords and shareable MFA codes with device-bound, origin-bound signatures that never leave the enrolled hardware. A vishing caller cannot finish authentication by coaching a code read-out. The same transferable-factor problem shows up when helpdesks are talked into handing over recovery secrets; why legacy MFA was dropped is that any factor a human can recite or approve on demand remains coachable. Prevention, not detection, is the point: remove the shareable secret so the call fails at identity, rather than hoping users spot fake IT.

How should defenders split login vs OAuth controls for UNC6040?

Defenders should split UNC6040 controls by phase. Harden workforce authentication so credentials and MFA codes cannot be dictated on a call. Separately, restrict Salesforce connected-app consent, prefer allowlists, scrutinize Data Loader-class grants, and revoke OAuth access and refresh tokens after suspected compromise. Public reporting does not establish named enterprise victims or quantified record counts in the materials used here. Do not conflate UNC6040 with UNC6395 Salesloft/Drift OAuth-token theft; that is a different campaign with a different initial-access story.

Is token revoke enough after malicious consent?

No. Token revoke is necessary hygiene after malicious connected-app consent in UNC6040-style activity, but it is not a substitute for preventing the credential and MFA-code handoff. Once OAuth access exists, revoke and consent policy contain blast radius. They do not fix the root cause that a caller talked a user into sharing transferable login factors. Prevention at authentication and authorization policy at consent are different layers, and both matter for this campaign.