Follow : Add us as a preferred source
on Google.
Key takeaways
- The FBI warned about the alarming trend of compromised accounts.
- The success rate of threat actors could tarnish Salesforce's reputation.
- The most recent wave of attacks was likely preventable.
Since Salesforce's founding in 1999, the company's executive team has made trust the top priority for the organization and its employees. In a post titled "Trust is our #1 value," the company states that "our trust-first culture is based on ensuring that our customers know their data is safe, and theirs -- to be accessed when, where, and how they intend."
However, recent data thefts involving Salesforce's infrastructure suggest that the cloud company is encountering avoidable difficulties in delivering on that promise.
Also: Your passkeys could be vulnerable to attack, and everyone - including you - must act
's research reveals that Salesforce could be doing more to secure the parts of its platform that were exploited in recent attacks. In preparing this report, I interviewed Salesforce chief trust officer Brad Arkin as well as cybersecurity experts from AppOmni, Google Cloud Mandiant, and Okta. (Okta's brand was hijacked in some versions of the attacks in question, but Okta's platform itself was not a part of those attacks.)
A giant platform with a target on its back
For Salesforce customers, 2025 has been a particularly brutal year. A long (and growing) list of organizations -- many of which are household names -- have reported massive and malicious exfiltrations of sensitive customer data followed by demands for cryptocurrency ransoms.
While several companies have openly cited their instances of Salesforce as the targets of these attacks, others have coyly and generically referred to a third-party application in their disclosures. Various media reports have insinuated that Salesforce was the affected system in many of those cases. The FBI has issued a flash warning regarding the attacks on Salesforce accounts. And now, 14 of the company's customers have filed lawsuits in connection with the attacks.
Also: Employees learn close to nothing from phishing training, and this is why
Salesforce has acknowledged that customers' instances of its platform have been targeted during the recent wave of attacks. On Aug. 7, 2025, the company published an Informational Message stating that "Salesforce platform has not been compromised and this issue is not due to any known vulnerability in our technology." A March 2025 company blog post notes that threat actors "have been reported luring our customers' employees and third-party support workers to phishing pages designed to steal credentials and [multi-factor authentication] tokens or prompting users to navigate to the login.salesforce[.]com/setup/connect page in order to add a malicious connected app."
The list of victim organizations reads like a who's who of well-known brands -- Allianz Life, LVMH (parent to Louis Vuitton, Dior, and Tiffany & Co.), Quantus , Cisco , Chanel , Google , and Workday , just to name a few. And the list is growing. In recent weeks, Proofpoint, SpyCloud, Tanium, and Tenable added their names to the victim list, potentially bringing the total to over 700 companies .
In late August, TransUnion notified the Maine and Texas attorneys general of a July 28, 2025, breach that was sourced to a third-party application. What's so special about Maine and Texas? According to Joseph Rosenbaum, a New York-based attorney specializing in cybersecurity, privacy, and data protection at Rimon Law, "both states have specific (and time-sensitive) disclosure requirements when data breaches affect more than a certain number of their residents and require reporting to their Attorneys General."
Although the credit reporting bureau did not name Salesforce, Fox News was among several news outlets to make the connection. Fox News stated that the breach "appears to be part of a broader wave of Salesforce-related attacks that is hitting organizations across sectors, from tech and finance to retail and aviation."
Also: 5 ways to spot software supply chain attacks and stop worms - before it's too late
Cory Michal, chief security officer at SaaS security solution provider AppOmni , told me that "based on the tactics, techniques, and procedures (TTPs) observed, along with the timing of the attack and available threat intelligence, the TransUnion incident aligns closely with the ongoing [attacks] targeting Salesforce environments." The Fox News report mentioned Air France-KLM as yet another target.
In an interview for this story, Okta vice president of threat intelligence Brett Winterford told me that "the list of companies targeted in the most recent attacks, which involved theft of OAuth tokens, is longer than the people who have disclosed so far. It is a very long list." As this article was being written, new reports were emerging about ransomware attacks involving similar TTPs on Gucci, Balenciaga, and Alexander McQueen. Okta is painfully aware of the situation.
The first two waves of the attacks, having nothing to do with Okta's infrastructure or technology, involved different forms of phishing that directed users of Salesforce and other SaaS applications to convincing imposter replicas of Okta's single sign-on splash page that many users encounter when logging into their SaaS apps.
Also: 3 reasons VPN use is set to explode worldwide - and that might apply to you
The scale of success achieved by the threat actors begs the questions of how they've managed to penetrate the Salesforce-stored data of so many organizations -- many of which are experts in cybersecurity themselves -- and what Salesforce is doing (or not doing) to mount a lasting technical defense to better protect its customers.
Anatomy and evolution of the attacks
According to AppOmni's Michal, the TTPs used on Salesforce customers evolved from a series of phishing attacks first carried out against other targets in 2022. Since then, the threat actors or "clusters" -- groups known as The COM, ShinyHunters, and Scattered Spider -- have shifted, merged, or morphed in their efforts to evade the authorities. In recent days, British authorities arrested two teenagers in connection with Scattered Spider-related hacks, while another teenager turned himself in to the Las Vegas Police Department .
According to Michal, the attacks have come in four distinct waves, the last of which has yet to be officially linked to any particular cluster or threat actor. As such, the cybersecurity professionals at AppOmni, as well as other cybersecurity organizations, refer to the perpetrators of the fourth evolution as UNC6395 . This designation was originally created by Mandiant , the branch of Google Cloud that tracks, investigates, and consults on cyber breaches and defenses. Google itself was one of the victims of the attacks . (The prefix UNC stands for Uncategorized.) Another yet-to-be-identified cluster -- UNC6040 -- is said to have some involvement in the third phase.
First came the phishing
"The first variant of the attack is one they've been carrying out for literally over three years," said Michal as he described the standard operating procedure for a phishing attack. "They register a company name with '-okta.com' [i.e., itbit-okta.com], and then, at that domain, they put up a site that looks exactly like a legitimate Okta login, and then they send you a [phishing] email to get you to log into it."
Paxos' crypto trading platform itBit was one of the targets of the attack . Normally, if a platform like itBit relied on Okta to handle application authentication, the correct domain would have involved an Okta subdomain like itbit.okta.com (no hyphen). The addition of the hyphen and absence of a subdomain are subtle modifications that many unsuspecting end users might never notice.
Also: Traveling soon? 5 simple ways I thwart phone thieves - and you can too
In the case of Salesforce, once a user's Okta credentials were compromised, the threat actors would gain access to the Salesforce instance belonging to the user's employer (in some cases, the targeted user was a contractor to the Salesforce customer). From there, the employer's customer data would be exfiltrated, followed by the ransom demands.
Then came the vishing
But once the various stakeholders shored up their defenses against the email phishing threat, the hackers evolved the attack to rely on vishing, the voice version of phishing. The main social engineering levers of the attack remained essentially the same (going after the same types of users and the same credentials). But, in this evolutionary step, the threat actors placed phone calls to would-be victims, posing as legitimate IT personnel and directing users to the imposter domains.
Earlier this year, Brian Krebs published a YouTube video of an unrelated vishing attack in progress to demonstrate the artful and convincing nature of such calls. Of course, demands for ransom typically followed once the data was successfully exfiltrated.
Also: The fastest VPNs with the best networks, ranked
According to Michal, as the attacks evolved, the threat actors were running a full-blown DevOps workflow that, with the help of an Adversary-in-the-Middle (AitM) toolkit like EvilGinx2 , could quickly provision most of the necessary infrastructure to perpetrate an attack against a specific target. Then, once the treasure was acquired, the hackers would just as quickly deprovision that infrastructure to cover their tracks.
"In the breach of Mark and Spencer (M&S) , they registered the fake domain name and then they called two support engineers from TSC, a firm used by M&S for contract IT support," said Michal. "Then, they got them to go through a flow where they get the credential, the session, and they get the multifactor authentication token, and then it expands into this whole attack, which results in ransomware."
And then came the imposter-ware
As if Salesforce.com is more of an operating system than a web application, the cloud company has cultivated a thriving ecosystem of third-party developed applications that can be installed into a company's partition of Salesforce, otherwise known as a "Salesforce organization."
A "Salesforce organization" is essentially a private, customizable Salesforce portal dedicated to a specific customer. That customer could be an entire company or just a department within a company, and until very recently, it was not uncommon for non-administrative users within those groups to have the freedom to plug add-on applications into their Salesforce organizations. Salesforce encourages users to shop its AppExchange marketplace for over "9,000 pre-built and customizable apps to extend Salesforce."
As security teams closed off the vishing version of the attack, the nature of the threat evolved into a third phase that took the voice tactics of the previous evolutionary step to a new level. Instead of deceiving victims into divulging their credentials, the threat actors targeted Salesforce users with phone calls that tricked them into installing malicious applications into their Salesforce organizations. As Mandiant's post regarding UNC6040's TTPs explains, "A prevalent tactic in UNC6040's operations involves deceiving victims into authorizing a malicious connected app to their organization's Salesforce portal."
Also: Why no small business is too small for hackers - and 8 security best practices for SMBs
At least one of those malicious apps was a malware doppleganger to DataLoader.io -- one of the most popular plug-ins across the sprawling universe of Salesforce customers. As the application's home page states, DataLoader.io is "the most popular data loader for Salesforce to quickly and securely import, export, and delete unlimited amounts of data for your enterprise." Although Salesforce itself is the actual developer of DataLoader.io, that wasn't always the case. It was originally offered by MuleSoft, an API management solution provider that was acquired by Salesforce in 2018.
"During a vishing call, the actor guides the victim to visit Salesforce's connected app setup page to approve a version of the Data Loader app with a name or branding that differs from the legitimate version," says Mandiant's post about UNC6040's TTPs. "This step inadvertently grants UNC6040 significant capabilities to access, query, and exfiltrate sensitive information directly from the compromised Salesforce customer environments."
In other words, the Data Loader imposterware made good on the legitimate DataLoader.io 's promise to "quickly and securely import, export and delete unlimited amounts of data" -- just to the wrong people.
A hacker's version of 'tailgating'?
Slipping into a secured building without authorized access behind someone who does have it is known as tailgating. It's a physical security breach that relies on social engineering tactics, and it comes with major risks and potential legal consequences. Access cards to buildings are often categorized as security tokens. If there's such a thing as digital tailgating -- for example, surreptitiously skating past Salesforce's defenses on the coattails of someone else's security token -- then sneaking into one of Salesforce's alternative entry points behind a legitimate third-party application might be it.
When a server running one application seeks to access resources from another server running a different application (commonly referred to as a machine-to-machine connection), the two typically communicate over an application programming interface (API), and the latter server usually issues a special API access credential known as an OAuth token to the former. In the case of integrations involving Salesforce, if the former server is acting on behalf of multiple Salesforce organizations, that former server would likely be physically or logically divided into partitions for each organization, each requiring one or more OAuth tokens in order to securely integrate with its counterpart on the Salesforce side of things.
Also: How to safeguard your small business in the hybrid work era: 5 top cybersecurity solutions
Depending on the former application's popularity across the Salesforce ecosystem, the operator of that application might have to securely store, manage, and track hundreds or thousands of OAuth tokens on behalf of the customers that it and Salesforce mutually share. However, if the application operator's infrastructure is compromised in such a way that a threat actor gains access to some or all of the tokens, that threat actor might have all they need to gain access to the corresponding Salesforce resources.
That is exactly what happened in early August 2025, according to a post jointly authored by Mandiant and a separate Google-operated cybersecurity research organization known as Google Threat Intelligence Group (aka GTIG). A threat actor currently designated as UNC6395 "targeted Salesforce customer instances through compromised OAuth tokens associated with the Salesloft Drift third-party application."
According to AppOmni's Michal, the series of attacks on Salesforce customers bore a striking resemblance to an older attack on Microsoft 365 customers that started with Commvault, a company that, ironically, claims to provide "an unfair advantage to enable resilience in the face of ransomware and other advanced threats."
According to an AppOmni threat intelligence post , "attackers used Commvault to extract stored [OAuth] credentials used by the [Commvault's] Metallic platform to access customer Microsoft 365 environments. These tokens often [included] scopes that [granted] broad access to Exchange mailboxes, SharePoint sites, OneDrive files, and even Teams chats."
Commvault's public record of the incident stated that there was "no unauthorized access to customer backup data that Commvault stores and protects, and no material impact on our business operations or our ability to deliver products and services." But the post acknowledges that the "threat actor may have accessed a subset of app credentials that certain Commvault customers use to authenticate their [Microsoft 365] environments."
Also: Want AI to work for your business? Then privacy needs to come first
In the case of Salesloft and Salesforce, Mandiant and GTIG reported that the unknown threat actor -- UNC6395 -- used the OAuth credentials exfiltrated from Salesloft's Drift application to "systematically [export] large volumes of data from numerous corporate Salesforce instances" -- instances belonging to Salesforce's customers. According to BleepingComputer , "The ShinyHunters extortion group claims to have stolen over 1.5 billion Salesforce records from 760 companies using compromised Salesloft Drift OAuth tokens."
"Somehow, the Drift environment was compromised by the bad guys who used that access to slurp out Oauth tokens which allowed them to behave with the permission of the Drift app when they connect to other services," Salesforce's Arkin told me. The "somehow" part is answered by the same BleepingComputer article which noted how, "in March, one of the threat actors breached Salesloft's GitHub repository , which contained the private source code for the company."
Technological remedies available to Salesforce
The threat's ever-evolving nature and the extraordinary number of Salesforce customers (and the customers of those customers) that have so far been impacted now begs the question of whether Salesforce could be doing more to contain the attacks' growing blast radius and live up to its promise of trust.
In an effort to prevent the installation of malware (e.g., imposter-ware), Salesforce's Arkin explained to me how ordinary users within a Salesforce organization will no longer have the ability or permissions to install an "uninstalled" app. It sounds confusing if you're not familiar with how Salesforce works. Basically, this means that before an end-user can take advantage of a third-party application designed to work within the Salesforce organization, an administrator of that organization -- a person who (hopefully) has more experience, training, and permissions -- must install it first.
Also: The best VPN routers: Expert tested and reviewed
"If an attacker wanted to trick an employee to connect to an app, they would only be able to do it if it's an app that's been blessed and approved and installed by the admin of the org," Arkin told me. "So we shrunk the number of people who might get tricked into connecting an app." Provided that Salesforce administrators are themselves sufficiently resilient to social engineering attempts, this behind-the-scenes change to how Salesforce works should help to prevent the unauthorized end-user installation of malware (and subsequent exfiltration of data leading to ransomware).
Arkin told me that Salesforce is also disabling one of the three main application installation workflows for certain applications, like Data Loader, that, going forward, will no longer be auto-installed into every newly provisioned Salesforce organization.
"When you connect an app to Salesforce, there are three different authentication paths [to authorize the connection]; there's user ID password, there's the OAuth connection workflow, and then there's this thing called device connection," said Arkin. "This device connection workflow is something that's unfamiliar to the typical victim employee who makes the connection, and they may not realize what they're being tricked into doing. We have removed the device connection option from the way [previously auto-installed] apps work within the Salesforce platform."
Arkin said Salesforce is also urging its customers to take better advantage of the platform's IP Allow Listing capabilities. For example, all users should connect from known and allowed IP address ranges, a security posture made possible by VPN technologies like ZScaler when managing remote users.
However, while the cloud company appears to be modifying its platform to ward off earlier evolutions of the attacks involving end users, the response so far to the Drift machine-to-machine incident has been mostly administrative. Instead of applying industry-standard countermeasures to neutralize the value of stolen OAuth tokens before they are stolen, Salesforce's initial remedy was to cut off all of Salesloft's systems from connecting to Salesforce's infrastructure. This included Saleloft's namesake application as well as Drift, which the company acquired in February 2024 .
"We've terminated all connections from Salesloft to Salesforce," said Arkin, who suggested Salesforce may have to act accordingly when similar incursions arise involving other third-party developers. "In the future, should we just turn it off right away before we do the investigation, just based on things that look different?"
Surprisingly, even though I openly mused about technical options during our interview, Arkin didn't float any specific approaches that the company might be considering. For example, existing approaches designed to restrict the re-usability of stolen OAuth tokens. As authentication credentials go, an OAuth token is the rough equivalent of a user ID and password. Once malicious actors gain possession of OAuth tokens, they also gain unauthorized access to whatever resources can be unlocked by those tokens unless certain technical precautions are taken -- precautions which Salesforce doesn't appear to be taking.
What about IP address whitelisting?
Salesforce offers administrative users the ability to restrict end-user access to Salesforce organizations based on their IP addresses, which raises the question of why the same is not done by default for third-party server-based applications that are part of the Salesforce developer ecosystem.
For example, Salesforce has a record of all the OAuth tokens it issued to SalesLoft. Salesforce could theoretically deny access to those OAuth tokens if they come from IP addresses that are not associated with Salesloft. But Arkin disputed the idea, suggesting that many of the applications in the Salesforce ecosystem rely on dynamic rather than static IP addresses.
"It's very normal for our integration partners to have ephemeral infrastructure that is very often changing where it's hosted," said Arkin. "And so if you're spinning up and winding down Kubernetes clusters, you're getting different IP addresses all day long."
But Okta's Winterford sees things a bit differently and reminded me that Okta itself was on the receiving end of an attack. "We were a Drift customer," said Winterford. "We went through issues with attackers gaining access to our Salesforce support environment a couple of years ago, and among the many things we did was [to implement] an IP Allow listing. [Such listings] are difficult but not impossible. It requires vendors like Okta to publish a set of IP addresses that you can expect [API] requests from Okta to come from. So does Salesloft, for that matter. Salesloft has published a set of IP addresses."
During Okta's annual customer conference (Oktane) in Las Vegas, Okta chief security officer David Bradbury told me that Salesforce actually has a feature that allows customers to restrict such machine-to-machine OAuth authentications to specific IP addresses. "That is actually what saved Okta from being hacked in this exact instance" said Bradbury. But the feature is not activated by default nor...