Battered by cyberattacks, is Salesforce facing a trust problem?

Erik McGregor/Contributor/LightRocket via Getty Images Follow ZDNET: Add us as a preferred source on Google. ZDNET's 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 ZDNET'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. A variety of media reports have insinuated that Salesforce was the affected system in many of those cases, and the FBI has issued a flash warning regarding the attacks on Salesforce accounts. 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 ""=""> 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 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 UNC6345 "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 -- UNC6345 -- 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 does Salesforce play an active role in curating or managing IP whitelists from machine-to-machine application developers like Salesloft. That burden is on Salesforce's customers. When asked if it the burden should be on Salesforce instead, Bradbury responded "That's the right question to ask." Over on Salesloft's Help site, a post offers a list of Salesloft "Drift Public IP addresses [that] can be used to provide whitelist rules for access to internal or third-party services." More specifically, the post (see screenshot below) lists 34 individual IP addresses specific to Drift's integration with Salesforce. With the idea of whitelisting in mind, Salesloft publishes a list of IP addresses that it uses for its integrations with Salesforce on its website. Screenshot by David Berlind/ZDNET It's not 100% clear when the post was actually published. It appears to have been most recently updated on Aug. 24, 2025, but also notes that the list was last "updated as of April 1, 2025," which predates the first known theft of Salesloft's OAuth tokens. Emails to Salesloft regarding the exact date of the post's publication were not returned. In fairness to Arkin's concern about IP address ephemerality, the post also notes that Salesloft will do its "best to keep this page up to date, but it is possible that changes will be made to the Public IP addresses Drift uses without advanced notice." Even so, if given the option for Salesforce to whitelist IPs from Salesloft and other server-based applications, the potential damage to Salesforce's customers could be limited to dysfunction of the server-based application (e.g., Drift) rather than the widespread, expensive, and brand-damaging compromise of customer data -- not to mention the ransoms. Salesforce should be asking itself which is the lesser of two evils. Also: The best password managers: Expert tested Minimally, the Salesloft post suggests that the company has (or is now) publishing a list of IP addresses for the specific purpose of connection whitelisting, which also means that minimally, other server-based applications in the Salesforce ecosystem might be able to publish similar lists. In turn, Salesforce can (and probably should) give its customers the choice of rejecting OAuth connections to their data if the sources of those connections aren't whitelisted by Salesforce itself. Additionally, Salesforce could adjust its security posture to require developers to publish those whitelists, and if they cannot -- due to the ephemerality of their infrastructures -- there should be a clear disclosure (wherever the app is advertised) of the potential risks. "At scale, where an adversary like this had hundreds of targets to execute on in a matter of minutes, the [IP Allow lists] made all the difference for us," says Winterford. "I know that [Okta] says identity is the new perimeter, and that's our catch cry. But the network still matters, and so it's just a matter of whether organizations like Salesloft agree to publish their IP addresses, preferably through an API that can be programmatically updated all the time without human intervention. And then it's about constraining the use of an OAuth token to [those IP addresses]." Given its history of innovation, Salesforce could easily develop and provide such an API and then require third-party developers within its ecosystem to rely on it for timely whitelist updates. Securing OAuth with DPoP, Mutual TLS, or FAPI As techniques go, whitelisting might present a barrier to certain exploits. But whitelisting, like many individual layers of security, is no silver bullet. When I consider how the technology industry came together to produce a theft-proof credential -- the passkey -- with the help of public key cryptography (see my 6-part series on exactly how passkeys work), I can't help but wonder if there aren't similar technologies for preventing the misappropriation of OAuth tokens. According to Okta's Winterford, there are. He should know. Automated provisioning, managing, and securing OAuth tokens is one of the main features of Okta's turnkey Auth0 solution. One solution that immediately came to Winterford's mind is a specification called OAuth 2.0 DPoP (Demonstrating Proof of Possession). As the spec's name suggests, an application like Salesloft's Drift would need to prove to Salesforce that it has the right to possession of an OAuth token before the application is allowed to engage with a Salesforce resource. With DPoP, "you could create an environment where you can cryptographically tie a token to the client that first requested it," Winterford told me. Another alternative that merits attention, according to Winterford, is OAuth 2.0 Mutual TLS (MTLS) -- an OAuth extension that involves mutual authentication on both the client and server sides. According to the IETF RFC for MTLS, "Mutual-TLS certificate-bound access tokens ensure that only the party in possession of the private key corresponding to the certificate can utilize the token to access the associated resources. Binding an access token to the client's certificate prevents the use of stolen access tokens or replay of access tokens by unauthorized parties." Also: Crowdstrike and Meta just made evaluating AI security tools easier "MTLS can be a little bit clunky to set up, certainly more difficult than DPoP," according to Winterford. But in his opinion, it's more robust. Winterford also noted that FAPI is another OAuth extension worth a look. According to OAuth.net, "FAPI 2.0 is an API security profile based on the OAuth 2.0 framework suitable for protecting APIs in high-value scenarios." Given the compliance-driven Fort Knox-like security requirements in the financial and healthcare industries, OAuth covers the basic authentication fundamentals but isn't secure enough in its base form. Winterford again: "A bunch of organizations said, 'If we were to use OAuth in a financial services or healthcare setting, can we be more opinionated about the use of OAuth?' There are certain grant types that would be ruled out, and all token use must be constrained to the client, and for that, you've got to use either [the MTLS or DPoP extensions to OAuth]." Unfortunately, neither MTLS nor DPoP are getting the attention they apparently deserve. "But [these recent] events might help change people's minds," says Winterford. According to him, within Okta's Auth0 solution, an administrator only needs to check a checkbox to toggle on DPoP support. So far, however, Salesforce seems to be focused on administrative remedies as opposed to aggressively pursuing any technical countermeasures. Citing nothing specific like DPoP, MTLS, FAPI or token-binding (another option that my research uncovered), Arkin said "There are probably new and clever ideas waiting to be discovered and invented and so we're working together not just internally but with our partners in the ecosystem to figure out what more we do as an industry to better manage these types of risks." Also: Salesforce unveils AI agents for sales teams - here's how they help Although Salesforce integration was restored to Salesloft's namesake application on Sept 7, 2025, Salesloft's Drift application was still disconnected from the Salesforce infrastructure at the time this story was published. Even so, given the demonstrable tenacity of the hackers and the current absence of a technical solution to the OAuth compromise, it's safe to assume that threat actors are looking for the next Salesloft-like application to exploit. Meanwhile, barely a day seems to go by that another company doesn't reveal the breach of a third-party customer-related system. Just this week, Reuters reported that Stellantis -- parent company to Chrysler, Jeep, and Peugeot -- "detected unauthorized access to a third-party service provider's platform that supports its North American customer service operations." Although Salesforce is not identified in the report, Stellantis announced in 2023 that it would be relying on Salesforce's Automotive Cloud to offer the car company's customers a more connected, AI-driven vehicle experience. Disclosure: From 2013 to 2018, David Berlind was the editor-in-chief of ProgrammableWeb.com, the journal of the API economy. ProgrammableWeb was owned by MuleSoft during that period. David became an employee of Salesforce as a part of its 2018 acquisition of MuleSoft and left the company in 2022.