{"id":5505,"date":"2025-10-22T07:30:00","date_gmt":"2025-10-22T07:30:00","guid":{"rendered":"https:\/\/cybersecurityinfocus.com\/?p=5505"},"modified":"2025-10-22T07:30:00","modified_gmt":"2025-10-22T07:30:00","slug":"salesforces-glaring-dreamforce-omission-vital-security-lessons-from-salesloft-drift","status":"publish","type":"post","link":"https:\/\/cybersecurityinfocus.com\/?p=5505","title":{"rendered":"Salesforce\u2019s glaring Dreamforce omission: Vital security lessons from Salesloft Drift"},"content":{"rendered":"
\n
\n
\n
\n
<\/div>\n

Salesforce\u2019s 2025 Dreamforce conference<\/a> 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<\/a>, one to handle security issues and an agent for addressing privacy and compliance.<\/p>\n

Overall, security as a shared responsibility was the theme: Salesforce is doing its part, and customers need to do theirs.<\/p>\n

But what the conference didn\u2019t 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.<\/p>\n

\u201cI was at the event, and I talked to all the leadership, and this was not one of the topics,\u201d says Chirag Mehta, a vice president at Constellation Research. \u201cThis didn\u2019t come up.\u201d<\/p>\n

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\u2019s agentic vision.<\/p>\n

Anatomy of a third-party cyber disaster<\/h2>\n

At issue is one of the largest SaaS supply-chain breaches in recent years. According to the Google Threat Intelligence Group<\/a>, over 700 organizations<\/a> were impacted by an August breach in which the \u201cactor systematically exported large volumes of data from numerous corporate Salesforce instances.\u201d<\/p>\n

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.<\/p>\n

\u201cYes, the breach happened in a Salesforce instance,\u201d he explains. \u201cBut it was not caused by something Salesforce did. The people who understand what\u2019s going on, they understand what Salesforce is supposed to do, and what the customers were supposed to do.\u201d<\/p>\n

Instead, the breach occurred when a threat actor obtained Salesforce OAuth tokens<\/a> from third-party AI chat tool Salesloft Drift and used the tokens to download large volumes of data from Salesforce instances.<\/p>\n

Salesforce, which has attempted to minimize the breach\u2019s severity by saying \u201ca small number of customers<\/a>\u201d were affected, noted that when it detected the activity, it \u201cinvalidated active Access and Refresh Tokens, and removed Drift from AppExchange. We then notified affected customers.\u201d<\/p>\n

But according to Salesforce customer Cloudflare, the CDN giant saw the first signs<\/a> of reconnaissance related to the breach on Aug. 9, with an attacker gaining access to Cloudflare\u2019s Salesforce tenant on Aug. 12. By Aug. 17, the attackers had analyzed Cloudflare\u2019s Salesforce case workflows, derived insights into how Cloudflare\u2019s team members handle various types of cases, and completed their exfiltration.<\/p>\n

Three days later, on Aug. 20, Salesforce revoked Salesloft Drift connections and published its notice on its website. \u201cAt that point, Cloudflare had not yet been notified, and we had no indication that this vendor action might relate to our environment,\u201d Cloudflare\u2019s security leaders stated.<\/p>\n

Cloudflare wasn\u2019t alone. Hundreds of companies were affected, including some of the biggest names in cybersecurity.<\/p>\n

Mitiga Security researcher Idan Cohen wrote<\/a>: \u201cIn the Drift case, customers weren\u2019t careless. The attackers didn\u2019t hack their way in. They logged in, pretending to be a trusted third-party service.\u201d<\/p>\n

This wasn\u2019t the only case involving breached Salesforce accounts. In June, a different group of attackers, known as ShinyHunters, pretended to be IT support personnel<\/a>, in order to trick users into approving a connection to a malicious version of Salesforce\u2019s Data Loader application that then exfiltrated data from Salesforce environments.<\/p>\n

Google, whose threat intelligence team described these attacks in a June report, itself fell victim to such an attack in August.<\/p>\n

By October, attackers claimed to have stolen more than 1.5 billion Salesforce records<\/a> from 760 companies. They also launched an extortion campaign against Salesforce and its compromised enterprise customers, including Toyota, FedEx, Hulu, and UPS.<\/p>\n

Multiple lawsuits have been filed against Salesforce, claiming the company didn\u2019t do enough to vet third-party applications connected to its systems, or to monitor for signs of data exfiltration and other malicious activity.<\/p>\n

\u201cSalesforce \u2026 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\u2019s industry regularly and routinely implement. But Salesforce did not,\u201d said one complaint in a class-action lawsuit<\/a> filed on Aug. 29 in California.<\/p>\n

The potential for OAuth exploitation \u201cwas a known risk\u201d 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<\/a> filed in September.<\/p>\n

According to San Diego law firm CaseyGerry, there are now more than 70 cases filed<\/a> across the country related to the Salesforce data breach.<\/p>\n

The biggest blind spot<\/h2>\n

When companies delegate access to third parties via OAuth integrations, it creates a systemic security blind spot that spans all industries.<\/p>\n

By stealing those tokens, attackers can gain access to all connected systems. \u201cAuthorizing 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\u2019s from a trusted integration,\u201d the FBI warned<\/a> in an alert released in September.<\/p>\n

The exploitation of such weaknesses is only going to get worse \u2014 especially as AI-related integrations increasingly become the norm.<\/p>\n

Whereas a traditional CRM integration might need contact data, \u201can AI sales assistant typically requires contacts, email histories, calendar information, deal pipeline data, conversation logs, and product catalogs,\u201d noted Trend Micro AI security expert Fernando Tucci in a report on why the breach of Salesloft Drift \u2014 an AI chatbot \u2014 hits differently<\/a>. \u201cThis broader access pattern means a single compromised AI integration can expose significantly more sensitive information than traditional point solutions.\u201d<\/p>\n

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.<\/p>\n

Understanding all these partnerships and connections requires close coordination with vendor management, says Steve Winterfeld, advisory CISO at Akamai. \u201cPlus, understanding where your data is takes both culture-driven policies and technical controls,\u201d he says.<\/p>\n

With white-labeled services, APIs, and now LLMs, these two goals are much more complex. \u201cIf you haven\u2019t conducted a supply chain breach exercise yet, now is the time,\u201d Winterfeld says. \u201cThese recent events underscore the importance of validating your program.\u201d<\/p>\n

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.<\/p>\n

One company who didn\u2019t fall victim<\/h2>\n

One company that wasn\u2019t scathed by the breaches was cloud-based IAM vendor Okta. Why? It allowed connections only from authorized IP addresses.<\/p>\n

According to Okta<\/a>, when the company learned of the compromise, it immediately reviewed its logs and found attempts to access resources with stolen tokens \u2014 but those attempts failed.<\/p>\n

\u201cThe single most important control that prevented this breach was our enforcement of inbound IP restrictions,\u201d the company said. \u201cThe 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.\u201d<\/p>\n

This whitelisting approach to security is a powerful tactic, but it\u2019s difficult to implement because it requires a great deal of discipline.<\/p>\n

Another challenge is that not all SaaS vendors support this capability. \u201cMany providers in the cloud-first world do not offer this foundational security feature, creating a significant challenge for protecting interconnected systems,\u201d Okta said.<\/p>\n

Foundational security benchmarks for SaaS providers are only now coming together, following the Cloud Security Alliance\u2019s recently launched SaaS Security Capability Framework (SSCF)<\/a>.<\/p>\n

Okta noted that Salesforce already offers this functionality, but added that using it requires \u201csignificant effort,\u201d given that restrictions have to be configured for APIs and users.<\/p>\n

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.<\/p>\n

In the financial sector, for example, some regulators mandate DPoP or mTLS; while it isn\u2019t mandated in healthcare, there\u2019s a use case there as well, according to Tyk Technologies<\/a>.<\/p>\n

More companies should be looking at upgrading this as their use of interconnected SaaS apps and AI tools increases.<\/p>\n

The Internet Engineering Task Force included<\/a> both DPoP and mTLS among its best practices for OAuth security.<\/p>\n

Compounding risk going forward<\/h2>\n

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\u2019s Mehta says.<\/p>\n

Even a control as straightforward and common as multi-factor authentication can be difficult to implement for all employees, he says.<\/p>\n

\u201cFrom a solution provider perspective, they provide a specific set of security controls and features and it\u2019s up to the customers to make sure they actually use them. In my view, it is a shared responsibility,\u201d Mehta says.<\/p>\n

Shared responsibility for security was an important part of the message of last week\u2019s Dreamforce, but discussion of the Salesloft incident was conspicuously missing \u2014\u00a0a loss for attendees.<\/p>\n

Because if anything can be taken away from the past few months of Salesforce-related cybersecurity, it\u2019s that software supply-chain security is more important than ever. And it will only increase in importance as more systems get connected \u2014 a key tenet of Salesforce\u2019s aim to power the agentic enterprise<\/a>.<\/p>\n

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.<\/p>\n

More Salesforce news<\/a>:<\/h4>\n

Salesforce updates its agentic AI pitch with Agentforce 360<\/a><\/p>\n

Lessons from the Salesforce breach<\/a><\/p>\n

Salesforce brings agentic AI to IT service management<\/a><\/p>\n

Salesforce AI Research unveils new tools for AI agents<\/a>\u00a0<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>","protected":false},"excerpt":{"rendered":"

Salesforce\u2019s 2025 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 […]<\/p>\n","protected":false},"author":0,"featured_media":5493,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-5505","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-education"],"_links":{"self":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/5505"}],"collection":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=5505"}],"version-history":[{"count":0,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/5505\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/media\/5493"}],"wp:attachment":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=5505"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=5505"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=5505"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}