Salesforce attack exposed Google Ads customer data


Google has revealed more details about an attack on one of its corporate Salesforce instances. The company now says that the attack exposed user data of Google Ads customers.
The security issue was spotted by Google Threat Intelligence Group (GTIG) back in June. Activity by UNC6040 – described as a financially motivated threat cluster that specializes in voice phishing (vishing) – hit Salesforce and subsequent investigations have revealed the extent and impact of the attacks.
Google has now contacted affected customers via email after the company analyzed what happened and took mitigating action. As reported by Bleeping Computer, the email says:
We're writing to let you know about an event that affected a limited set of data in one of Google's corporate Salesforce instances used to communicate with prospective Ads customers. Our records indicate basic business contact information and related notes were impacted by this event.
This will be of great concern to Google Ads customers, and anyone thinking of becoming one. For such a large corporation to fall victim to such an attack is somewhat unusual, but particularly a global technology company with a vested interest in security.
Targeting Google Ads customers
In a blog post about data extortion, Google explains how the attack works and goes on to say:
In June, one of Google’s corporate Salesforce instances was impacted by similar UNC6040 activity described in this post. Google responded to the activity, performed an impact analysis and began mitigations. The instance was used to store contact information and related notes for small and medium businesses. Analysis revealed that data was retrieved by the threat actor during a small window of time before the access was cut off. The data retrieved by the threat actor was confined to basic and largely publicly available business information, such as business names and contact details.
Although Google seems to be attempting to downplay the impact of the attack by describing the data that was accessed as being “largely public”, it does not provide any detail about the type of quantity of exposed data that was neither basic nor public. This is the data that will be a cause for concern.
Google says that it has now completed the process of contacting anyone whose data has been involved in this attack – so if you’ve not heard anything yet, you should have nothing to worry about.
The perpetrators of the attacks are known to be ShinyHunters, threat actors who have been targeting Salesforce customers for some time.
Communicating with Bleeping Computer, the attackers said that they had been able to steal around 2.55 million data records, but it is not clear how many customers these relate to.
DataBreaches.net reports that the group sent an extortion demand to Google. It was seeking millions of dollars not to leak the data; neither Google nor the attackers have said whether any ransom was paid, or if payment was even considered.
Google has a number of tips for organizations to help strengthen their security:
- Adhere to the Principle of Least Privilege, Especially for Data Access Tools: Grant users only the permissions essential for their roles—no more, no less. Specifically for tools like Data Loader, which often require the "API Enabled" permission for full functionality, limit its assignment strictly. This permission allows broad data export capabilities; therefore, its assignment must be carefully controlled. Per Salesforce's guidance, review and configure Data Loader access to restrict the number of users who can perform mass data operations, and regularly audit profiles and permission sets to ensure appropriate access levels.
- Manage Access to Connected Applications Rigorously: Control how external applications, including Data Loader, interact with your Salesforce environment. Diligently manage access to your connected apps, specifying which users, profiles, or permission sets can use them and from where. Critically, restrict powerful permissions such as "Customize Application" and "Manage Connected Apps"—which allow users to authorize or install new connected applications—only to essential and trusted administrative personnel. Consider developing a process to review and approve connected apps, potentially allowlisting known safe applications to prevent the unauthorized introduction of malicious ones, such as modified Data Loader instances.
- Enforce IP-Based Access Restrictions: To counter unauthorized access attempts, including those from threat actors using commercial VPNs, implement IP address restrictions. Set login ranges and trusted IPs, thereby restricting access to your defined enterprise and VPN networks. Define permitted IP ranges for user profiles and, where applicable, for connected app policies to ensure that logins and app authorizations from unexpected or non-trusted IP addresses are denied or appropriately challenged.
- Leverage Advanced Security Monitoring and Policy Enforcement with Salesforce Shield: For enhanced alerting, visibility, and automated response capabilities, utilize tools within Salesforce Shield. Transaction Security Policies allow you to monitor activities like large data downloads (a common sign of Data Loader abuse) and automatically trigger alerts or block these actions. Complement this with "Event Monitoring" to gain deep visibility into user behavior, data access patterns (e.g., who viewed what data and when), API usage, and other critical activities, helping to detect anomalies indicative of compromise. These logs can also be ingested into your internal security tools for broader analysis.
- Enforce Multi-Factor Authentication (MFA) Universally: While the social engineering tactics described may involve tricking users into satisfying an MFA prompt (e.g., for authorizing a malicious connected app), MFA remains a foundational security control. Salesforce states that "MFA is an essential, effective tool to enhance protection against unauthorized account access" and requires it for direct logins. Ensure MFA is robustly implemented across your organization and that users are educated on MFA fatigue tactics and social engineering attempts designed to circumvent this critical protection.