Salesforce’s flagship Dreamforce conference last week offered attendees a range of sessions on best practices for securing their Salesforce environments and AI agents, and about what Salesforce itself is doing with AI to improve security. The company even released two new agents aimed at CISOs ahead of the event, one to handle security issues and an agent for addressing privacy and compliance.
Overall, security as a shared responsibility was the theme: Salesforce is doing its part, and customers need to do theirs.
But what the conference didn’t address were weaknesses exposed by the recent spate of Salesforce-related breaches that affected more than 700 companies and nearly 1.5 billion records, inspiring 70-plus lawsuits.
“I was at the event, and I talked to all the leadership, and this was not one of the topics,” says Chirag Mehta, a vice president at Constellation Research. “This didn’t come up.”
The omission was a likely missed opportunity, given that the lessons of what has gone down in the Salesforce ecosystem over the past few months are significant for the increasingly connected and AI-infused future that is central to Salesforce’s agentic vision.
Anatomy of a third-party cyber disaster
At issue is one of the largest SaaS supply-chain breaches in recent years. According to the Google Threat Intelligence Group, over 700 organizations were impacted by an August breach in which the “actor systematically exported large volumes of data from numerous corporate Salesforce instances.”
Seeing as the data had been stored by Salesforce, non-cyber professionals might assume this was a Salesforce breach, but that was not the case, Mehta says.
“Yes, the breach happened in a Salesforce instance,” he explains. “But it was not caused by something Salesforce did. The people who understand what’s going on, they understand what Salesforce is supposed to do, and what the customers were supposed to do.”
Instead, the breach occurred when a threat actor obtained Salesforce OAuth tokens from third-party AI chat tool Salesloft Drift and used the tokens to download large volumes of data from Salesforce instances.
Salesforce, which has attempted to minimize the breach’s severity by saying “a small number of customers” were affected, noted that when it detected the activity, it “invalidated active Access and Refresh Tokens, and removed Drift from AppExchange. We then notified affected customers.”
But according to Salesforce customer Cloudflare, the CDN giant saw the first signs of reconnaissance related to the breach on Aug. 9, with an attacker gaining access to Cloudflare’s Salesforce tenant on Aug. 12. By Aug. 17, the attackers had analyzed Cloudflare’s Salesforce case workflows, derived insights into how Cloudflare’s team members handle various types of cases, and completed their exfiltration.
Three days later, on Aug. 20, Salesforce revoked Salesloft Drift connections and published its notice on its website. “At that point, Cloudflare had not yet been notified, and we had no indication that this vendor action might relate to our environment,” Cloudflare’s security leaders stated.
Cloudflare wasn’t alone. Hundreds of companies were affected, including some of the biggest names in cybersecurity.
Mitiga Security researcher Idan Cohen wrote: “In the Drift case, customers weren’t careless. The attackers didn’t hack their way in. They logged in, pretending to be a trusted third-party service.”
This wasn’t the only case involving breached Salesforce accounts. In June, a different group of attackers, known as ShinyHunters, pretended to be IT support personnel, in order to trick users into approving a connection to a malicious version of Salesforce’s Data Loader application that then exfiltrated data from Salesforce environments.
Google, whose threat intelligence team described these attacks in a June report, itself fell victim to such an attack in August.
By October, attackers claimed to have stolen more than 1.5 billion Salesforce records from 760 companies. They also launched an extortion campaign against Salesforce and its compromised enterprise customers, including Toyota, FedEx, Hulu, and UPS.
Multiple lawsuits have been filed against Salesforce, claiming the company didn’t do enough to vet third-party applications connected to its systems, or to monitor for signs of data exfiltration and other malicious activity.
“Salesforce … had the duty and ability to control its software environment and prevent these attacks from succeeding through implementation of security protocols that other companies in Salesforce’s industry regularly and routinely implement. But Salesforce did not,” said one complaint in a class-action lawsuit filed on Aug. 29 in California.
The potential for OAuth exploitation “was a known risk” and Salesforce failed to vet third-party connections, build protections, or monitor its networks against this kind of malicious activity, another group of class-action claimants said in a complaint filed in September.
According to San Diego law firm CaseyGerry, there are now more than 70 cases filed across the country related to the Salesforce data breach.
The biggest blind spot
When companies delegate access to third parties via OAuth integrations, it creates a systemic security blind spot that spans all industries.
By stealing those tokens, attackers can gain access to all connected systems. “Authorizing a malicious connected app bypasses many traditional defenses such as MFA, password resets and login monitoring, and because OAuth tokens are issued by Salesforce itself, activity coming from the malicious app can look like it’s from a trusted integration,” the FBI warned in an alert released in September.
The exploitation of such weaknesses is only going to get worse — especially as AI-related integrations increasingly become the norm.
Whereas a traditional CRM integration might need contact data, “an AI sales assistant typically requires contacts, email histories, calendar information, deal pipeline data, conversation logs, and product catalogs,” noted Trend Micro AI security expert Fernando Tucci in a report on why the breach of Salesloft Drift — an AI chatbot — hits differently. “This broader access pattern means a single compromised AI integration can expose significantly more sensitive information than traditional point solutions.”
Worse, because AI chatbots are specifically designed to access large data sets, when a malicious actor piggybacks on the same connection to steal data, the traffic pattern can look legitimate.
Understanding all these partnerships and connections requires close coordination with vendor management, says Steve Winterfeld, advisory CISO at Akamai. “Plus, understanding where your data is takes both culture-driven policies and technical controls,” he says.
With white-labeled services, APIs, and now LLMs, these two goals are much more complex. “If you haven’t conducted a supply chain breach exercise yet, now is the time,” Winterfeld says. “These recent events underscore the importance of validating your program.”
Ironically, many security firms were among the victims, including Zscaler, Cloudflare, Palo Alto Networks, Pager Duty, SpyCloud, Tenable, Proofpoint, Rubrik, BeyondTrust, Bugcrowd, JFrog, CyberArk, and Black Duck.
One company who didn’t fall victim
One company that wasn’t scathed by the breaches was cloud-based IAM vendor Okta. Why? It allowed connections only from authorized IP addresses.
According to Okta, when the company learned of the compromise, it immediately reviewed its logs and found attempts to access resources with stolen tokens — but those attempts failed.
“The single most important control that prevented this breach was our enforcement of inbound IP restrictions,” the company said. “The threat actor attempted to use a compromised token to access our Salesforce instance, but the attack failed because the connection originated from an unauthorized IP address. This security layer proved essential, blocking the unauthorized attempt at the front door before any access could be gained.”
This whitelisting approach to security is a powerful tactic, but it’s difficult to implement because it requires a great deal of discipline.
Another challenge is that not all SaaS vendors support this capability. “Many providers in the cloud-first world do not offer this foundational security feature, creating a significant challenge for protecting interconnected systems,” Okta said.
Foundational security benchmarks for SaaS providers are only now coming together, following the Cloud Security Alliance’s recently launched SaaS Security Capability Framework (SSCF).
Okta noted that Salesforce already offers this functionality, but added that using it requires “significant effort,” given that restrictions have to be configured for APIs and users.
Another way to protect connections is to limit them to a specific client, using demonstrating proof of possession (DPoP), which prevents the reuse of stolen tokens, but this is even more difficult in practice because it requires changes to the authentication flow and adds new requirements for clients and servers. Another option is mutual TLS, which offers even stronger security, but at an even higher cost of complexity.
In the financial sector, for example, some regulators mandate DPoP or mTLS; while it isn’t mandated in healthcare, there’s a use case there as well, according to Tyk Technologies.
More companies should be looking at upgrading this as their use of interconnected SaaS apps and AI tools increases.
The Internet Engineering Task Force included both DPoP and mTLS among its best practices for OAuth security.
Compounding risk going forward
When companies allow connections to systems outside their perimeter, they need to understand the risks they are assuming and the security controls available to them, Constellation’s Mehta says.
Even a control as straightforward and common as multi-factor authentication can be difficult to implement for all employees, he says.
“From a solution provider perspective, they provide a specific set of security controls and features and it’s up to the customers to make sure they actually use them. In my view, it is a shared responsibility,” Mehta says.
Shared responsibility for security was an important part of the message of last week’s Dreamforce, but discussion of the Salesloft incident was conspicuously missing — a loss for attendees.
Because if anything can be taken away from the past few months of Salesforce-related cybersecurity, it’s that software supply-chain security is more important than ever. And it will only increase in importance as more systems get connected — a key tenet of Salesforce’s aim to power the agentic enterprise.
Software supply-chain security is already not so easy to achieve, and, even as Salesforce promises to make this easier with the help of AI, it is AI itself that will make the problem that much harder to solve.
No Responses