The cybersecurity world is abuzz with the recent data breaches affecting major brands like Chanel, Pandora, and Google. While Salesforce is at the center of these incidents as the compromised platform, a deeper dive into the attack vector reveals that the core vulnerability isn't in Salesforce's code—it's in the human element.
The recent wave of attacks, attributed to the financially motivated threat group ShinyHunters (also tracked by Google as UNC6040), serves as a powerful case study in the effectiveness of sophisticated social engineering.
According to Google Threat Intelligence Group, the attackers employed a sophisticated voice phishing (vishing) scheme to trick employees at victim organizations. By impersonating IT support, the hackers persuaded individuals to take actions that compromised their company's Salesforce instance.
The attackers' playbook evolved, but the core tactic remained the same:
-
Vishing: Hackers call an employee, often referencing a non-existent support ticket, and convince them to install a malicious application.
-
Malicious app: The employee is duped into installing a rogue version of a legitimate Salesforce tool, like the Data Loader app. This malicious app, once granted access, allows the threat actor to exfiltrate vast amounts of data from the company's Salesforce environment.
-
OAuth abuse: The attacks exploit the Salesforce "Connected App" feature, where an employee unwittingly enters a code to authorize a malicious app, granting the attackers broad privileges and persistent access.
As a spokesperson for Salesforce told Salesforce Ben: "Salesforce has not been compromised, and this issue is not due to any known vulnerability in our platform.... Attacks like voice phishing are targeted social-engineering scams designed to exploit gaps in individual users' cybersecurity awareness and best practices."
The list of victims is extensive and growing, highlighting that this is a widespread and coordinated campaign:
-
Chanel and Pandora: Both luxury brands have confirmed breaches. Chanel's breach, discovered on July 25th, involved names, email and home addresses, and phone numbers of a "subset of individuals who contacted our client care center in the U.S.," as a spokesperson told WWD. Pandora's breach, discovered on August 5th, impacted customers' names, birthdates, and email addresses.
-
Google: In a blog update, Google's Threat Intelligence Group confirmed that one of its own Salesforce instances was breached for a "small window of time" in June. The stolen data was described as "confined to basic and largely publicly available business information, such as business names and contact details."
-
Other suspected victims: News reports suggest other companies, including Adidas, Allianz Life, Qantas, and several LVMH brands (Louis Vuitton, Dior, Tiffany & Co.), have also been victimized in similar attacks.
"The breach is tied back to their Salesforce customer management system and is linked to a broader wave of attacks targeting Salesforce instances—extending the string of incidents already impacting other fashion and luxury brands. But interestingly, even though Chanel had robust security operations supported by probably sophisticated tools, the attackers succeeded in lateral movement," said Agnidipta Sarkar, Chief Evangelist at ColorTokens. "They attempted to attack other systems, but were exposed in one instance. The attack was limited to personal contact details of U.S. customers who had contacted customer support. The attack pattern of using vishing to impersonate IT support staff and trick employees into authorizing a malicious Salesforce app could be ShinyHunters or even be Scattered Spider."
Sarkar added, "It is now evident that every company with a Salesforce/CRM presence is a potential target, and threat actors use highly convincing phone and email lures, and do not rely on technical exploits—making staff the primary attack vector. In my opinion, apart from building awareness of outsourced helpdesks and support staff, cybersecurity leaders should immediately invest in technologies to reduce lateral movement, heavily restrict which employees can install or approve new Salesforce apps, use strict RBAC controls and microsegment cloud instances, enforce digital certificate-based passwordless authentication and continuously monitor the critical digital assets for anomalous and malicious behavior."
The stolen data, while not including financial information or passwords in all cases, is a goldmine for attackers. As a Pandora customer notice stated, the breach exposed contact information, which is a "strong starting point for more serious attacks," such as phishing and credential stuffing. The ShinyHunters group is also reportedly engaging in private extortion, threatening to leak the data if ransom demands are not met.
The recent wave of breaches is a clear reminder that technology-based defenses are only as strong as the human factor. For cybersecurity professionals, the broken record of key takeaways are:
-
Elevate social engineering training: The attacks didn't rely on technical exploits; they relied on human trust and error. Regular, realistic training on vishing and impersonation tactics is non-negotiable for all employees.
-
Rethink MFA: While crucial, multi-factor authentication is not a silver bullet. Attackers in this campaign were able to bypass MFA by convincing employees to hand over their tokens or authorize malicious apps. Reviewing and tightening authentication policies for third-party apps is essential.
-
Strengthen third-party app governance: Organizations must have strict controls and visibility over which third-party apps and integrations are allowed to connect to their Salesforce instances. A robust approval process and the principle of least privilege should be enforced.
-
Implement a zero trust model: The attacks highlight the risk of implicit trust. Limiting lateral movement within the network and enforcing least privilege access to systems and data can help contain the damage of a compromised account.
More vendor experts reacted to the Salesforce-related hacking news.
"Salesforce is a treasure trove of regulated and privacy-sensitive business processes and data across domains like customer service and beyond," said Piyush Pandey, CEO at Pathlock. "This requires a high level of scrutiny into how access controls, monitoring, and third-party integrations are configured and audited. Organizations need to rethink their approaches to access governance in these environments, given these factors—compounded by the sophistication of modern threats."
"We don't have additional inside info on this particular attack. What’s playing out here is a classic example of attackers using clever tricks—not just through email, but also phone calls, browser pop-ups, SMS, and even fake apps—to steal login info and sneak into big databases," said J Stephen Kowski, Field CTO at SlashNext Email Security+. "Once inside, they grab valuable customer data and try to make money off it through scams or threats. Phishing isn't just an email problem anymore, and platforms loaded with customer info, like Salesforce, are prime targets. Teams can protect themselves by constantly training people to spot these new kinds of scams and using smarter security tools that catch phishing and sketchy access attempts in real time."
Elad Luz, Head of Research at Oasis Security, offered this commentary:
-
"At this time, there aren't many publicly available, technical details about the recent Salesforce-related breach. What follows includes some informed speculation based on what we know about OAuth and desktop application behavior."
-
"At a high level, Delegated OAuth is an authorization mechanism where a user explicitly grants an application access to their account without sharing credentials. The process begins when the application initiates an OAuth flow by directing the user to the identity provider’s login page. Importantly, this request includes a client ID—a public identifier representing the application—which is used to determine branding, scopes, and the redirect URI where tokens will be delivered."
-
"Once the user authenticates, the authorization server sends the tokens to a preconfigured redirect URI associated with that client ID (the application). This redirect URI is critical, as it defines where the tokens are sent after login and must match what's been registered with the platform."
-
"For web applications, this URI is typically hosted on a domain owned by the vendor. This ensures that only the legitimate backend running on that domain can receive the tokens."
-
"A malicious actor could register their own OAuth-connected web app with the same scopes, trick a user into logging in, and receive valid tokens via their own domain; but doing so leaves a high-profile trail. It requires domain registration, TLS setup, and potentially approval of a new app by the target organization, all of which increase the friction and traceability of the attack."
-
"However, according to Google's report, the malicious app in this case was impersonating Salesforce's Data Loader, which changes the equation. That detail affects my speculation significantly, because Data Loader is a desktop application."
-
"For desktop apps, which cannot host public URLs, the redirect URI is usually a local host with an arbitrary port number. These apps run a temporary local server during login to receive the token response via the loopback interface. This pattern is common and widely accepted for desktop OAuth flows."
-
"Now, turning to the Salesforce incident: the Salesforce Data Loader is a trusted utility that administrators use to bulk import/export CRM data. It supports OAuth, and likely uses the loopback redirect model described above."
-
"Here’s the key point: desktop apps are public clients, meaning they cannot store secrets securely. For this reason, nothing prevents another app from mimicking the OAuth flow by using the same client ID and the same localhost redirect URI. If the impersonating app tricks the user into authenticating, it can capture the same tokens that the legitimate app would receive."
-
"Even more concerning is that if the real Data Loader app is already pre-approved in the Salesforce environment, reusing its client ID bypasses the user consent screen entirely. The OAuth flow would appear seamless to the victim, presenting only a login prompt with no warnings or scope approval steps. This makes the phishing app far less suspicious and also gives it a lower profile in audit logs since it appears as an existing, trusted application rather than a newly connected third-party integration."
