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

Two security companies whose entire business is protecting other people's secrets just had their own business data stolen. Not through their products. Not through a flaw in their code. Through a competitive-intelligence vendor they connected to Salesforce.

That is the uncomfortable shape of the Klue incident. 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 companies that sell trust got breached through the soft tissue between SaaS tools, and that is the part worth sitting with.

Nobody kicked down BeyondTrust's front door. 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. In this case, Salesforce. To do its job, an app like Klue holds standing access into a customer's CRM. When the vendor is compromised, that access becomes the attacker's access.

This is the supply chain breach pattern in its purest form. 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. You can harden your own Salesforce org all day. It does not matter if a connected app with a valid token gets popped.

When people hear "Salesforce data" they often picture a list of leads. The reality is messier and more valuable. A CRM accumulates 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. Notes about which controls a customer runs, who their champions are, what their renewal date is, what they fear.

None of that is a password. All of it is 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. That is the second-order damage that does not show up in the initial disclosure.

LastPass knows this story better than most. The company has lived through the long tail of a prior incident, where stolen material kept generating downstream attacks long after the original event. Data does not expire when the press cycle does.

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. These tokens are convenient by design and dangerous by neglect. 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. That is exactly why these thefts run quietly until someone on the vendor side notices.

The defensive lesson is blunt. Every connected app is an extension of your attack surface, and you should treat the inventory of OAuth grants as seriously as you treat the inventory of employee accounts. Most organizations cannot name every third-party app holding a token into their CRM right now. Attackers can, because that connected-app list is one of the first things they enumerate after landing in an environment.

Start with the boring, effective work. 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. 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 do the part most teams skip: 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. The real question is what an attacker gets the day after your vendor falls.

The way we see it at TrustSig, this is the same instinct that drives invisible bot and abuse detection: trust is not a one-time grant, it is a thing you verify continuously based on behaviour. A valid token, like a valid-looking session, is not proof of a legitimate actor. Standing access is a liability you have to actively watch, not a decision you make once 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. That should reset anyone's assumptions about where their real perimeter ends.