BeyondTrust and LastPass Got Breached Through a Vendor They Plugged Into Salesforce

BeyondTrust and LastPass are among more than a dozen organizations confirmed to have had data lifted from their Salesforce instances when attackers hit Klue, a competitive intelligence platform that plugs into customer CRM environments. The way in was a vendor they had connected to Salesforce, not anything in their own products or code. Two security companies whose entire business is protecting other people's secrets lost their own business data in the soft tissue between SaaS tools.

Klue is a third-party integration, a tool sales and product teams use to track competitors, and like most modern SaaS it earns its keep by reaching into the systems where the real data lives, which here meant Salesforce. To do its job it holds standing access into a customer's CRM. Compromise the vendor and you inherit that access.

That is the supply chain breach pattern. The victim companies did everything inside their own walls correctly and still lost data, because the trust boundary had already been extended outward to a partner they had no operational control over. Hardening your own Salesforce org does nothing about a connected app with a valid token that gets popped.

When people hear "Salesforce data" they often picture a list of leads. A CRM accumulates more than that: contact names, work emails, phone numbers, deal notes, support history, internal commentary about accounts, and sometimes details about a customer's own security posture written down by a sales engineer. For a security vendor that last category is radioactive, because it means notes on which controls a customer runs, who their champions are, when their renewal lands, and what they fear.

There are no passwords in any of that, and it still works as fuel. The same crews who run these data thefts pivot fast into targeted phishing and business email compromise, using the stolen context to impersonate a real account manager or reference a real open deal. A breach that yields no credentials at all can still produce a credible, well-researched social-engineering campaign against the victim's customers weeks later, and none of that second-order damage shows up in the initial disclosure.

LastPass has been through the long tail of this already. Stolen material from its prior incident kept generating downstream attacks well after the original event.

The mechanism that makes these integration breaches work is usually an OAuth token, the long-lived credential a SaaS app holds so it can talk to your systems without a human logging in each time. They sit in a vendor's infrastructure, they rarely get rotated, and they often carry broad read scopes because nobody trimmed the permissions when the integration was set up.

When a vendor like Klue is breached, the attacker does not need to defeat your multi-factor authentication. They inherit a token that already passed every check. From the perspective of your Salesforce logs the access can look perfectly legitimate: the right app, the right grant, normal-ish API calls.

These thefts run quietly until someone on the vendor side notices. So every connected app is an extension of your attack surface, and you should treat the inventory of OAuth grants as seriously as the inventory of employee accounts. Most organizations cannot name every third-party app holding a token into their CRM right now, while that connected-app list is one of the first things an attacker enumerates after landing in an environment.

Audit every connected app and integration touching your CRM, and ask whether each one needs the scope it has. A competitive-intelligence tool almost certainly does not need write access or visibility into every object. Cut read scopes to the minimum, and rotate tokens on a schedule rather than never.

Alert on anomalous API volume from integration accounts, because a vendor compromise usually shows up as a sudden bulk export, not a slow drip.

Then assume your vendors will be breached and plan the blast radius in advance. The Klue victims did not get to choose when Klue got hit. What they could control was how much data sat exposed behind a single integration token, and how quickly they could detect and revoke. Third-party risk reviews that end at a signed questionnaire are theater, because they never answer what an attacker gets the day after your vendor falls.

At TrustSig we build invisible bot and abuse detection on the same instinct: trust is something you verify continuously from behaviour rather than grant once. A valid token, like a valid-looking session, proves only that somebody holds it, and standing access is a liability you watch instead of a decision you make and forget. The companies caught in the Klue incident are about as security-mature as it gets, and they still got reached through a partner.