Attackers stopped stealing passwords — now they steal your tokens
In June 2026 a breach at a SaaS vendor most people had never heard of spilled Salesforce data from LastPass and a dozen security companies. No password was cracked. No MFA was beaten. The attackers used the OAuth tokens that quietly connect your apps to each other.
In June 2026 a company called Klue — a market-intelligence tool that plugs into Salesforce — was breached. Klue is not a household name, but its customers are: when the dust settled, LastPass, BeyondTrust, HackerOne, Huntress, Tanium, Snyk, and a striking number of other security firms had to tell their own customers that data had been taken. Here is the unsettling part. The attackers did not crack a single password. They did not beat multi-factor authentication. They stole the OAuth tokens Klue held — the digital keys that let one app talk to another — and used them to quietly vacuum data out of each customer's Salesforce. It is the clearest example yet of the supply-chain attack that has defined the last year.
What actually happened
Klue is a competitive-intelligence platform that go-to-market teams connect to their Salesforce. To do its job, it holds an integration into each customer's Salesforce account.
The attackers got in through a single compromised legacy credential tied to one of those integrations. From there, they took the OAuth tokens Klue stored for its customers and used them to call each customer's Salesforce directly, pulling out CRM data in bulk. LastPass confirmed on June 23 that the exposed data included business contact information, CRM records, and support-case data — while stressing that its actual product, its infrastructure, and customers' password vaults were never touched. Salesforce was clear that this was not a flaw in Salesforce itself; it disabled the Klue connection. But the damage was already done across a long list of Klue's customers.
Wait — what is an OAuth token?
Every time you click "connect this app" or "log in with Google," you are using OAuth. Instead of handing the new app your actual password, the service gives the app a token — a long-lived key that says "this app is allowed to access this data on the user's behalf."
Think of it like a valet key. You do not give the parking attendant the keys to your house; you give a limited key that starts the car and nothing more. OAuth tokens are the internet's valet keys, and they are what make modern software convenient: your CRM talks to your email tool talks to your support desk, all without anyone re-typing passwords. The catch is that these keys are powerful, they last a long time, and a typical company has thousands of them.
Why a token is more dangerous than a password
A stolen token beats a stolen password in three ways, and all three matter.
It is a bearer key — whoever holds it gets in, no password required. Multi-factor authentication does not help, because MFA is checked once, at the moment you first connect the app; after that, the token works silently with no login and no prompt. And it survives a password reset — changing your password does nothing to a token that was already issued. Only explicitly revoking the token kills it.
That last point is the trap. The reflexive response to a breach — "everyone reset your passwords" — does absolutely nothing against stolen tokens. They keep working until someone specifically hunts them down and revokes them.
The master-key problem
Here is why one vendor's breach becomes everyone's breach. When a SaaS tool connects to, say, five hundred customers' Salesforce accounts, that vendor is holding five hundred tokens — a vault full of master keys.
Steal that vault and you do not have to break into five hundred companies. You inherit working API access to all of them at once. The attacker breaches one vendor and walks through five hundred doors. That is the brutal efficiency of these attacks: the effort is constant, but the payoff scales with how many customers the breached vendor serves.
This keeps happening — and it is a pattern, not a fluke
Klue is the third act of the same play. In 2025, attackers stole OAuth tokens from a chat tool called Drift (made by Salesloft) and used them to pull Salesforce data from more than 700 organizations. A similar wave through a platform called Gainsight hit 200-plus more. Now Klue, same technique, different vendor.
A note on who did it, because accuracy matters here: researchers attribute the Klue intrusion to a newer extortion group tracked as "Icarus." Claims that it was the well-known ShinyHunters crew are unverified — likely reputation-borrowing. The honest takeaway is that the technique is what is repeating, not necessarily a single gang. The method has been proven to work, so everyone is copying it.
Why this is the new supply chain
Every company now runs on a sprawling web of SaaS-to-SaaS connections — your CRM linked to your marketing platform linked to your support desk linked to your data warehouse. Each link is a long-lived token and a vendor you are trusting with API access to your most sensitive systems.
Most organizations cannot even list all of their integrations. They accumulate over years, added by different teams, each one a standing grant of access that nobody revisits. That invisible mesh is now a core part of your attack surface — and unlike your own systems, you do not control most of it. You are only as secure as the least careful vendor you ever clicked "connect" on.
Why your existing defenses miss it
The security tools most companies rely on were built to catch password attacks: failed logins, impossible-travel alerts, MFA prompts, suspicious sign-in locations. Token abuse trips none of them.
There is no login event, because the app was already authorized. There is no MFA prompt, because that happened once, long ago. There are no failed attempts, because the key is valid. To your monitoring, it looks like a normal API call from an app you approved. Without controls specifically watching for token misuse, the first sign of trouble is often your data showing up for sale.
What to actually do
Start with an inventory: list every connected app and OAuth grant in your major platforms — Salesforce, Google Workspace, Microsoft 365. You will find "zombie" connections nobody remembers approving. Cut every integration's access down to the least it needs; a tool rarely requires full access to do its job.
When something goes wrong, revoke and rotate tokens — do not rely on password resets, which we have seen accomplish nothing here. Set token lifetimes and expirations so credentials do not live forever. Restrict access by IP address where the platform allows it. Monitor for the tells of token abuse: bulk data exports, high-volume automated queries, scripted access patterns, connections from new locations. Do not store secrets like API keys or passwords inside CRM records, because attackers grep exported data for exactly that. And treat your vendors' security as part of your own — if a vendor is breached, assume any token they held for you is already compromised.
The shift to internalize
For years the advice was "use a strong password and turn on MFA." That is still true and still worth doing. But the frontier has moved.
The keys that matter most now are not the ones you type. They are the ones your apps hold on your behalf — invisibly, for a long time, until someone thinks to revoke them. Identity security is no longer only about people logging in. It is about governing the machines, apps, and integrations that act in your name every day, which means knowing they exist, limiting what they can do, and being able to shut them off the moment one goes bad.