On 5 August 2025, Google disclosed that one of its corporate Salesforce instances had been affected by the same activity seen in a wider campaign of voice phishing and data theft. Across that campaign, the attackers did not break Salesforce. They called employees, posed as IT support and talked them through the steps needed to connect an application that the attackers controlled.

That distinction matters because we have spent years strengthening the front door with better passwords and multi-factor authentication. The campaign went after a different weakness: what an authenticated person was allowed to connect once inside.

The evidence available by 22 August showed what happened, what the reporting did and did not establish, and where I would focus a controls review.

A Phone Call + a Connected App = Data Exfiltration

Google Threat Intelligence Group tracked the campaign as UNC6040. Its operators impersonated IT support staff and persuaded employees to visit Salesforce's connected-app setup page. Victims were then guided to approve an attacker-controlled application, often a modified version of Salesforce's Data Loader.

Data Loader is a tool built to move large volumes of data. Give a hostile version of the tool sufficient access, and it becomes an efficient route for an attacker to exfiltrate data. Google said the attackers used connected apps to query and exfiltrate information directly from customer Salesforce environments.

This was social engineering, but describing it as merely a failure of user awareness misses the design problem. A caller could turn one convincing conversation into application access because the person on the phone had the authority to make a consequential delegation.

Google's own corporate Salesforce instance was affected in June. The company said the attacker retrieved basic and largely public business contact information during a small window before access was cut off. That is more precise and less dramatic than some of the breach reports circulating at the time, but it also clearly shows the attack path.

The names need similar care. Google used UNC6040 for the intrusion activity. It tracked the later extortion activity as UNC6240 and said those actors consistently claimed to be ShinyHunters. The public evidence therefore supports an intrusion campaign followed by extortion activity in which the actors claimed the ShinyHunters name. It does not verify that affiliation or establish that the same organisation performed each stage.

Authentication Was only One part of the Attack Path

The easy conclusion to draw is that multi-factor authentication failed. The evidence is more nuanced.

Google observed several routes. In some cases, callers sought credentials and MFA codes. In others, they persuaded a victim to authorise a malicious connected app. Salesforce's own security guidance described both patterns and recommended stronger access controls, careful management of connected applications and least privilege.

MFA definitely still has a job: it helps establish that the person attempting to sign in possesses the required factors. However, it shouldn't be seen as a silver bullet; it cannot decide whether a connected application deserves broad access to customer data. That is a separate control question, even when both decisions appear in the same session.

Telling people to be more careful is always important but never the full story. The organisation decides who can approve connected apps, how much data they can retrieve, which activity is visible and who can revoke access. Security awareness training affects the odds of a bad decision, but architecture affects its what the overall impact will be.

An Earlier Warning from Toyota

A Toyota disclosure from 31 May 2023 showed a different problem: some files managed in a cloud environment for overseas dealers had been potentially accessible from outside the company because of a misconfiguration.

Toyota blocked outside access after discovering the issue. It said it had found no evidence of secondary use or third-party copies remaining online, and had not confirmed secondary damage. This was a potential exposure, not a confirmed account of theft.

Its response included a system to check the settings of all its cloud environments and monitor them on an ongoing basis. The useful mechanism here is configuration monitoring. A policy can describe how a cloud service should be set up; ongoing checks can show whether its actual settings match that intention.

Final Perspective

What concerns me is an organisation treating this primarily as a security awareness failure. The critical permission was the ability to connect an application with enough reach to export data. Training may reduce the chance of a bad approval; it does not narrow what the approved application can do.

I'd want the application owner and the identity or security lead to show where that delegation is constrained, detected and revoked. If one convincing phone call can still result in broad application access, the control is too dependent on the fallibility of a busy human answering a call.