The FBI has seized a domain used by the ShinyHunters hacking group said to be behind a wave of Salesforce data theft incidents.
Several big-name Salesforce customers have in recent months been targeted by social engineering attacks, with attackers claiming affiliation with the well-known hacking group ShinyHunters, aka UNC6240.
A trend has emerged in reports of the incidents, which often see English-speaking branches of multi-national corporations that use Salesforce voice phished over phone calls to compromise data by downloading an attacker-controlled replica of the Data Loader app.
Once downloaded, the app grants hackers extensive access, enabling them to query and exfiltrate sensitive data from compromised Salesforce customer accounts. Follow-up extortion attacks have also been reported.
On October 10, the FBI took down a BreachForums domain used by ShinyHunters as a data leak extortion site, according to BleepingComputer. The threat actor reportedly said that law enforcement stole database backups for the notorious hacking forum.
Many companies do not name Salesforce directly when they reveal the incidents, instead opting for phrasing like “third-party CRM”. With that caveat in mind, here is a roundup of all the incidents we know of so far.
SF Ben note: The potential for compromised connected apps in Salesforce orgs is ongoing. We at Salesforce Ben strongly recommend that all admins and org owners prioritize auditing the connected apps currently in use in their orgs. This includes identifying the origin of all connected apps, removing any unused or unknown apps, setting permissions for access to remaining apps, and removing the ability for any user to add connected apps without approval. We’ve published an article to help.
Timeline of 2025 Salesforce Customer Hacks
May 23: Adidas publishes a statement revealing that an “unauthorized external party” had obtained “certain consumer data through a third-party customer service provider”, with subsequent reports linking this incident to the Salesforce customer social engineering attacks.
June 5: Salesforce Ben reports that hackers had stolen large amounts of data by tricking employees at companies into installing a modified version of a Salesforce-related app.
June 16: Salesforce Ben publishes an article outlining how admins can audit connected apps and keep their orgs secure.
June 30: Australian airline Qantas “detected unusual activity on a third-party platform used by a Qantas airline contact centre”. Later reporting links this to the ShinyHunters campaign.
July 26: Reports say Allianz Life had been subjected to a hack. The company’s statement did not name Salesforce, but BleepingComputer wrote that they had learned the attack is “believed to have been conducted by the ShinyHunters extortion group”.
August 6: We report that fashion giant Chanel had announced that the company had fallen prey to a Salesforce data security breach; and Pandora is also reported to be among those targeted in a “security attack”.
August 7: Salesforce posts an advisory message, warning customers of social engineering and phishing threats. They stress that the Salesforce platform has not been compromised, and the issue is “not due to any known vulnerability in our technology”.
August 11: Salesforce Ben reports that Google is among the victims of the Salesforce-related data breaches.
August 18: We report that Workday has been targeted in a social engineering campaign. They did not name Salesforce in their blog post, but it came amid a wave of data theft attacks against the cloud giant’s customers.
August 19: Salesforce notifies its user base of a hardening of the exploited connected apps functionality.
August 20: Salesforce Ben publishes an article about the importance of security and steps you can take to secure your org against human error.
August 26: We report that Farmers Insurance had disclosed a data breach that impacted 1.1M customers.
August 27: Salesforce customers are revealed to have been targeted in yet another data theft campaign – this time carried out through Salesloft Drift. Salesforce removes the Drift application from the Salesforce AppExchange.
August 29: Salesforce disables all integrations with Salesloft as GTIG reveals that the scope of the Drift application hack is worse than previously thought.
September 3: TransUnion says that more than 4.4M people’s data has been exposed in a hack by an unknown threat actor. The third-party application was not disclosed.
September 4: We report on the news that British automobile manufacturer Jaguar Land Rover (JLR) had been severely impacted by a cyberattack; and that Salesloft Drift was being taken offline “temporarily”.
September 7: Salesforce said that they had re-enabled integrations with Salesloft technologies, “with the exception of any Drift app”.
September 10: JLR revealed that they now believe “some data has been affected” in the incident.
September 12: The FBI issues a FLASH alert warning that two threat groups – identified as UNC6040 and UNC6395 – are compromising Salesforce environments.
September 16: Salesforce Ben reports that JLR production will remain halted until September 24.
September 18: We report that ShinyHunters may have stolen the private information of millions of Balenciaga, Gucci, and Alexander McQueen customers.
September 24: Salesforce Ben reports that automotive manufacturing giant Stellantis confirmed they fell victim to a data attack on their Salesforce instance.
September 25: News emerges that Salesforce has been hit with 14 lawsuits amid the data theft campaign.
October 6: Voice phishing hackers claim to have stolen nearly 1B Salesforce records.
October 8: Reports say Salesforce is refusing to pay a ransom demand following the Salesloft Drift attack.
October 10: The FBI seizes a BreachForums domain which was used by ShinyHunters as a data leak extortion site.
October 11: Google confirmed that Oracle’s E-Business Suite (EBS) was compromised due to a vulnerability in the system.
October 13: Reports say that a hacking group released millions of records allegedly stolen from Salesforce customers after a failed ransom bid.
What To Do With Your Org
The hacking campaign often involves victims downloading a malicious replica of the Data Loader app.
Even if you do not believe your data has been breached, now is always a good time to make sure – and audit your connected apps.
Here’s how Salesforce administrators should audit connected apps:
Step 1: Review Your Connected Apps
From Salesforce Setup, you can get a good understanding of which Connected Apps are in use, by whom, and take action. You can use either Connected Apps OAuth usage in the Setup menu or SOQL to pull together a list of what Connected Applications exist in your organization.
Once you’ve created a list of items, you will have a sense of what is installed and what’s in use.
Step 2: Review Connected Apps
Use the list from the previous step to ensure things are in order. If a connected app is installed, you’ll see Manage App Policies. From this screen, you can adjust permitted users, set a session timeout, and force the app to use a high assurance session before it can be accessed.
If an app isn’t installed, you can block it or install it to have more granular control as to who is or isn’t allowed access.
The following steps are based on a standard configuration. If your Salesforce org includes customizations, the steps might not provide complete coverage or protection. Always review and adapt guidance to your organization’s unique setup before making changes and ensuring you are fully protected. If you choose to block an app, this could impact users – so think twice about it!
First, start by reviewing Connected Apps. Do they look familiar to you or your users? If not, block them by using that action next to each item in the list.
Once you’ve filtered out Connected Apps you do not recognize from the remaining list, you will have to determine what’s genuine. Connected Apps supplied by Salesforce can be found with a blue arrow next to the name under ‘Manage Connected Apps’ in Setup.
They are automatically installed and usually have a namespace of sf_com_apps or sf_chttr_apps. As namespaces are unique, you can trust that these items come from Salesforce. If you can’t verify the source for other items, then you can block these. This disconnects sessions and stops users from accessing the app until you unblock access.
Only keep apps connected that have been used recently. If a Connected App hasn’t been used for some time, block it. You can unblock it later should a user need access again.
You can only adjust the settings of Connected Apps that are installed, so for the remaining items, install them to get control over Permitted Users, Session Timeouts, and more.
If a Connected App already exists, then you won’t be able to install another with the same name. This is something to investigate further, as it could suggest you have a ‘malicious’ version of the Connected App installed rather than the genuine version.
For each installed Connected App, make sure the Permitted Users are set to ‘Admin Approved Users’ and assign access to others via Permissions Sets. This follows the principle of least privilege and ensures users will only be granted access if they have permission.
Step 3: Enable API Access Control (Optional)
Once you’ve reviewed Connected Apps and are left with only known genuine Connected Apps that follow the principle of less privilege, you have a decision to make.
You can enable ‘API Access Control’ by reaching out to Salesforce Support. This provides an allowlist of Connected Apps and blocks users from accessing a Connected App outside this list. Unlike other steps, this is a proactive action and can prevent the org from using unauthorized apps in the future, as it blocks connected apps.
Once enabled, any new connected app will be blocked, which will first have to be installed and unblocked before an admin can then assign access via Permission Sets (or Profiles).
This feature blocks any API Access that is not via a Connected App. Export Login History and review any login via APIs, including SOAP. Before you enable this feature, switch these logins to use OAuth Flows instead, which are considered more secure.
As always, test this feature in your sandboxes first and consider that not all installed packages are compatible with ‘API Access Control’, so regression testing is important.
‘Use Any API Client’ permission overrides API Access Control. Only assign this for a limited time via a Permission Set with an expiry date and never grant this to Business Users.
API Access Control could break Visualforce Pages that access APIs. If this is the case, then enable ‘Allow Visualforce Pages to access APIs’ to allow access.
Other Options
Connected Apps have been around for a while and have been superseded by External Client Apps, which provide more security options by default. You can migrate any ‘local’ Connected App to an External Client App. The migration option, however, does not stop third parties from using Connected Apps, so for full assurance, use API Access Control.
If you have access to Security Centre or Event Monitoring, which require special licenses, you can dive further into Connected App usage.
More Resources
It’s worth bearing in mind that this hacking campaign focuses on “social engineering” – meaning the threat arguably comes from human error.
Adding a new connected app requires elevated permissions, which are typically assigned to a Salesforce administrator.
One can easily imagine how Salesforce Admins, advertising their abilities on LinkedIn, might have been collected and systematically targeted as part of this social engineering campaign.
We have written an article outlining how best to mitigate this type of risk too:
Salesforce Help also offers a number of resources on managing connected apps:
This is an ongoing campaign, and this article will be updated to reflect the latest news.
Have you been affected by the hack? Email us at tips@salesforceben.com
