SaaS Supply Chain Attack: What the Klue Breach Teaches You to Monitor
By ScruteX Published
LastPass, Huntress, Recorded Future, Tanium, Snyk and HackerOne all defend other companies for a living. In June 2026 they became victims of the same breach, and not one of them was the target. The attacker went after a competitive intelligence vendor called Klue, stole the OAuth tokens Klue held for its customers, and walked into their Salesforce data through the side door.
A SaaS supply chain attack is an intrusion where the attacker breaks into a trusted third-party service, then uses that service's existing access to reach the data of every customer connected to it. In the Klue case, the attacker never touched a password, an MFA prompt or a phished employee at the victim companies. They held a valid token, and to Salesforce that token was Klue. Access was granted and records were pulled at scale.
This post breaks the Klue attack into its separate vectors and, for each one, states the exact signal a defender should have been watching. The lesson is not "Klue was careless". The lesson is that every SaaS integration you approve inherits your data, and most of that access sits unmonitored after the day it is switched on.
What happened in the Klue breach?
Klue is a market intelligence platform. Sales and marketing teams use its Battlecards app to sync competitor and win/loss data into CRM systems like Salesforce. To do that, Klue holds an OAuth token for each customer, a standing key that lets it read and write data in that customer's environment.
On June 11, 2026, anomalous activity appeared in the backend system that runs those integrations. Salesforce notified Klue of the suspected activity on June 12, and the same morning Klue disabled the affected GKE pods, disabled the compromised GitHub tokens, and rotated OAuth credentials. By June 13 the company had removed the malicious code and sent a general alert (which did not name affected customers). Klue engaged CrowdStrike for a full investigation and notified law enforcement. Salesforce disabled the Klue Battlecards connection on June 17 and stated the problem sat in the app connection, not in the Salesforce platform itself.
CrowdStrike completed its investigation on June 30 and Klue published a summary on July 1. It confirmed the entry point was a previously compromised GitHub personal access token (PAT) used to inject unauthorised code into Klue's integration service, which then collected the Salesforce OAuth access and refresh tokens. CrowdStrike found no evidence the attacker reached Klue systems outside the integration service, no activity after June 12, and could not determine how the PAT was first compromised. Google's Threat Intelligence Group confirmed the initial-access vector.
A new extortion group calling itself Icarus claimed the attack and listed Klue on its leak site on June 19. Huntress attributed the original intrusion to Icarus by matching the Session Messenger ID in the extortion emails to the identifier on the group's leak site. Icarus has been active only since April 28, 2026. The attribution is not entirely settled, though. The techniques match the OAuth-abuse playbook behind the 2025 and 2026 Salesloft Drift and Gainsight attacks on Salesforce, which were tied to ShinyHunters and UNC6395, and on June 21 a Telegram account claiming to be ShinyHunters also claimed the Klue breach. That account carried Icarus's Session ID and could not be verified; ReliaQuest noted an unrelated actor may be borrowing the ShinyHunters name, and Huntress found no evidence linking Icarus to ShinyHunters. Then on June 24 a separate party claimed to hold the stolen data, referencing nearly 200 companies and threatening daily releases. The practical read: treat the original intrusion as Icarus, and expect copycat or second-party extortion referencing the same data.
The data taken was CRM data, not product data. Across the affected companies that included names, work emails, job titles, phone numbers, business addresses, account records, price quotes, subscription details and free-text sales notes. LastPass confirmed customer vaults were never in scope, and other victims confirmed their core products, networks and payment data were untouched. That distinction matters, and we return to it below.
How did attackers get in without a password?
The entry point was a credential that should not have existed anymore. Klue had created a GitHub personal access token (PAT) to share with a vendor for an integration prototype. The integration was never deployed, the relationship ended, and the token was never revoked. A PAT is a non-human identity: its scope is fixed when it is issued, it needs no second factor, and it stays valid until someone deliberately expires or deletes it. This one sat in Klue's environment with standing access, no owner and no monitoring. An attacker got hold of it, used it to reach Klue's integration service, and pushed a code update that harvested the customer OAuth tokens. CrowdStrike's July 1 summary named the PAT as the confirmed entry point but could not establish how it was first compromised.
From there the chain ran in four moves:
- Initial access. The attacker used the compromised GitHub PAT to reach Klue's integration service.
- Token theft. They pushed a malicious code update to Klue's servers designed to collect the OAuth tokens that Klue's customers use to connect the Battlecards app to their own systems.
- Direct query. Holding those tokens, the attacker queried customer Salesforce environments directly. ReliaQuest traced automated Python scripts (identifiable by Python-urllib user-agent strings) hitting the Salesforce REST API for roughly 24 hours. Datadog observed the requests aimed at the
/services/data/v59.0/query/*endpoint, consistent with bulk data pulls rather than routine sync traffic. - Exfiltration and extortion. The attacker collected the CRM records, then emailed victims with a 48-hour deadline and a Session Messenger contact, and posted claims on the Icarus leak site.
The important detail for defenders: a token is a bearer credential. Whoever holds it is treated as the app that owns it. There is no second factor on a token in flight, and no password prompt. That is why "we have MFA everywhere" did not stop this.
Why did security companies get breached too?
Because they did the same thing every other enterprise does. They connected a useful SaaS tool to their CRM and trusted it to behave. The strength of a company's own defences was irrelevant, because the attacker never attacked those defences. They attacked the shared vendor and inherited its access to everyone downstream.
This is the part worth sitting with. Huntress, LastPass, Recorded Future and Tanium run mature security programmes. Their internal controls held. What failed was the assumption that a validated, widely used vendor could be treated as safe once it was integrated. Obsidian Security described the shift plainly: attackers have moved from hitting individual organisations to hitting the SaaS vendors those organisations trust, because one vendor compromise means access to hundreds of environments at once.
There is a fair reading here that protects Klue's customers from hindsight bias. Before June 11, the Klue integration was a normal, trusted connection with a stable baseline, the kind most teams would never flag. Blaming a customer for approving a common tool misses the point. The gap was not approval. The gap was the absence of continuous monitoring on the integration after approval, and the absence of a token inventory that would have made the abuse visible.
Reporting put the number of organisations confirming Salesforce compromise through Klue at around 20 by late June, and the list kept growing. The named companies below published what they confirmed. The pattern repeats: Salesforce CRM data was reached through the Klue integration, while core products, infrastructure and credentials were not.
| Company | Confirmed impact |
|---|---|
| Huntress | CRM data copied (business contacts, price quotes, sales communications). Products, telemetry, passwords and card data not affected. |
| LastPass | Attacker used Klue's OAuth tokens to reach LastPass Salesforce data. Products, infrastructure and customer vaults not impacted. |
| Recorded Future | Salesforce account affected via a compromised Klue OAuth token. Intelligence Graph, internal databases and customer platform data not affected. |
| Tanium | Listed among affected Klue customers; said no impact on its ability to serve customers. |
| Jamf | Salesforce instance data accessed through Klue's integration. Products and service delivery not affected. |
| Sprout Social | Salesforce CRM data exposed (business contacts, organisational data, CRM records). Product, credentials, API keys and scheduled content not affected. |
| Gong | Klue integration impact: internal licensed user names, business titles and emails. Call recordings and transcripts not directly affected. |
| HackerOne | CRM data accessed and copied via Klue's OAuth integration. Products and infrastructure remained secure. |
| OneTrust | Unauthorised activity in Salesforce linked to the Klue integration; CRM data accessible through it was involved. |
| Snyk | Salesforce data accessed via Klue: mainly business data fields and limited support case titles and descriptions. Products, services and infrastructure not involved. |
| Insurity | Salesforce flagged suspicious Klue-app activity on June 16. A limited set of active credentials found in CRM data was rotated or reset. |
What each attack vector tells you to monitor
Every step in this attack maps to a specific thing a defender can watch. Treat the table as a checklist, then read the notes below it.
| Attack vector in the Klue breach | What it tells you to monitor | Where to watch |
|---|---|---|
| Compromised GitHub PAT (dormant, never revoked) injecting code into the integration service | Source-control tokens and other non-human identities: PAT inventory, age, scope and expiry; secret scanning; unauthorised changes to CI/CD pipelines | Source-control (GitHub) audit logs, secret scanning, CI/CD pipeline logs, identity provider, cloud IAM |
| OAuth tokens stolen and reused | Token inventory: which apps hold tokens, what scopes they have, when each token last logged in | SaaS app connection settings, OAuth grant logs |
| Token-based logins from attacker infrastructure | Deviation from an integration's normal source IPs; a trusted app appearing from unexpected infrastructure | SaaS authentication and login-event logs |
| Automated bulk API reads over ~24 hours | API query volume and pattern: spikes in record retrieval, unusual user-agent strings, off-hours activity | SaaS API/event logs (for example Salesforce event monitoring) |
| CRM data exfiltration | Large outbound reads and export events tied to a single integration identity | Data access and export logs |
| Downstream extortion and phishing | Leaked contact data on leak sites; spoofed sender domains; impersonation of your brand or staff | Dark web monitoring, brand and domain monitoring, email security |
Four points sharpen this.
Non-human identities are the cheapest thing to fix and the most commonly ignored. The whole breach started with a GitHub PAT that had no business still being active. A PAT, service account or OAuth grant does not log in like a person, so it rarely gets reviewed. Inventory every non-human identity by scope, owner and last-used date, prefer short-lived and automatically expiring credentials over long-lived tokens, and run secret scanning across your repositories. Klue's own remediation went the same way: it blocked PATs organisation-wide, moved to GitHub Apps and short-lived credentials, added secret scanning, and put an allowlist on approved GitHub Actions. Those are the controls worth copying before an incident, not after.
A trusted integration has a baseline, and the baseline is the detection. Obsidian noted that legitimate Klue access came almost entirely from Google and Google Cloud infrastructure. The malicious activity came from unrelated IP addresses. If you record what "normal" looks like for each vendor connection, the deviation stands out immediately. Many vendors publish their connecting IP ranges precisely so you can allowlist them and alert on anything outside.
API-layer logging is not optional for SaaS. ReliaQuest's own analysis noted the bulk retrieval would not have been visible without API-layer logging. Login logs alone would have shown a valid token doing valid things. The tell was the volume and the endpoint, which live in the API event stream. If your CRM's API event monitoring is off or unshipped to your SIEM, you are blind to exactly this class of attack.
The breach does not end at exfiltration. Stolen CRM data feeds targeted phishing and extortion. The Icarus emails reached Huntress staff from three mail domains belonging to an Australian retailer, Global Retail Brands, whose infrastructure the group appears to have abused for the campaign. Watch for your own contact data surfacing on leak sites and for lookalike domains and spoofed senders in the weeks after any vendor breach, because that is when the follow-on social engineering arrives.
MITRE ATT&CK mapping and indicators of compromise
The attack maps cleanly to known techniques, which makes it straightforward to build detections and threat-hunt queries.
| Technique | ID | How it appeared here |
|---|---|---|
| Supply Chain Compromise | T1195 | Compromise of Klue as a trusted vendor to reach its customers |
| Valid Accounts | T1078 | Use of a compromised, never-revoked GitHub PAT to reach the integration service |
| Steal Application Access Token | T1528 | Malicious code update that harvested customer OAuth tokens |
| Data from Cloud Storage | T1530 | Direct queries against Salesforce and Gong data |
| Exfiltration Over Web Service | T1567 | Bulk retrieval through the Salesforce REST API |
Published indicators of compromise. These come from the vendor advisories on this incident. Defang applied for safety.
| Type | Value | Context |
|---|---|---|
| IP address | 138.226.246[.]94 | Threat actor infrastructure (ReliaQuest, Huntress) |
| IP address | 94.154.32[.]160 | Threat actor infrastructure (ReliaQuest, Huntress) |
| IP address | 212.86.125[.]24 | Threat actor infrastructure (ReliaQuest, Huntress) |
| IP address | 213.111.148[.]90 | Threat actor infrastructure (ReliaQuest, Huntress) |
| IP address | 159.183.215[.]61 | Threat actor infrastructure (LastPass advisory) |
| IP address | 159.183.181[.]239 | Threat actor infrastructure (LastPass advisory) |
| Session ID | 05e37988d80adfedf4504c39a1943cad3c082d9ce932c5820ccd98842bbee02f3f | Actor Session Messenger ID (attribution indicator) |
| Session ID | 05117e1c4110e0edc5ca1c539784c6a03eb34206e8ef25a8b7a729b4bb0e1a4251 | Actor Session Messenger ID (attribution indicator) |
| Sender domain | baccarat.com[.]au | Extortion email origin (abused third-party mail) |
| Sender domain | robinskitchen.com[.]au | Extortion email origin (abused third-party mail) |
| Sender domain | house.com[.]au | Extortion email origin (abused third-party mail) |
Cross-reference the IP addresses against Salesforce login and API event logs, and against any other service that was integrated through Klue. IP sets vary slightly by source, so treat the full list as your hunt scope. The Session Messenger IDs are attribution indicators, not a contact route: Huntress matched the ID in the extortion emails to the ID on Icarus's leak site, which is how it tied the two together. The user-agent indicator (Python-urllib strings) is lower confidence on its own but useful when correlated with the IPs and with unusual query volume. Scope any hunt to the June 11 to June 13 window first, then widen.
What defenders should do now
If you use Klue, treat the integration as compromised until proven otherwise, and act on these steps.
- Revoke and rotate everything tied to the Klue integration. That means the service-account password, refresh tokens, client secrets and active OAuth grants, not just the visible connection. ReliaQuest was explicit that disabling the integration alone may be insufficient.
- Terminate active sessions for known-affected services, since revoking an integration does not always kill a session already established with a stolen token.
- Pull and review API logs from Salesforce and any other connected platform (Gong, HubSpot, SharePoint, Zoom, Chorus, Clari, Google Drive, Slack were all disabled by Klue during response). Look for bulk query activity from the IOC IPs.
- Request missing logs from vendors where API or access logs are not available to you directly, and state that it is part of an active investigation.
- Check spam and quarantine folders for the extortion emails, which used subject lines like "top secret email" and a 48-hour deadline.
Beyond this specific incident, the durable fixes are structural.
- Build and maintain a token and integration inventory. Know every third-party app that holds a token into your environment, its scopes, and its last-used date. This is the single control that would have shortened this breach for every victim.
- Baseline each vendor integration and alert on deviation. Record normal source IPs and normal query volume per connection, allowlist published vendor ranges where offered, and treat anything outside the baseline as an incident until cleared.
Who is behind the Klue breach?
The breach was claimed by Icarus, an extortion group that first appeared in April 2026. Huntress tied the intrusion to Icarus by matching a Session Messenger ID in the extortion emails to the same ID on the group's leak site. Attribution is not fully settled, because the tradecraft copies older ShinyHunters campaigns and, in a strange turn, other parties tried to claim or seize the same data.
Here is how the picture came together, and why it stayed murky.
A new group: Icarus
When the first reports landed, the obvious suspect was ShinyHunters. That group had spent 2025 and 2026 stealing Salesforce data through trusted integrations, and the Klue attack looked identical. Then the extortion emails arrived. They came from an alias, "mr bean", carried the subject line "top secret email", and gave victims 48 hours to reply over Session Messenger. Huntress spotted that the Session ID in those emails matched the ID on a leak site run by a group calling itself Icarus. On June 19, Icarus listed Klue itself. Huntress said that listing appeared to confirm who was behind the original attack.
Icarus was new. Its leak site showed a start date of April 28, 2026, and only a couple of earlier victims, none tied to the older Salesforce campaigns. The working answer became a fresh crew using a proven method.
The ShinyHunters question
The method was the problem. It matched the ShinyHunters and UNC6395 playbook so closely that researchers could not rule out a link. Then on June 21, a Telegram account claiming to be ShinyHunters also claimed the Klue breach. It echoed Icarus's wording and even pointed to a Session contact tied to Icarus. ReliaQuest could not verify the account and said an unrelated actor might be borrowing the ShinyHunters name to add pressure. Huntress found no evidence connecting Icarus to ShinyHunters. Two names, one breach, and no clean line between them.
The twist: hackers robbing hackers
Then it got stranger. On June 24, a separate party claimed it had obtained the stolen data and threatened to publish the names of nearly 200 companies unless it was paid. Icarus reportedly warned Klue about this other party and told the company not to pay them. By June 25, Klue was said to be negotiating and believed the data was being deleted. Whether the second party stole the data from Icarus, bought it, or invented the claim was never established.
What this means for defenders
The label matters less than the behaviour. Whoever ran it, the attack used the same route every time: a trusted integration, stolen OAuth tokens, and bulk Salesforce queries. So the safe position is to treat the original intrusion as Icarus, keep the ShinyHunters overlap as an open question, and expect copycat extortion. If a message lands claiming to hold your data, check it against your own logs before you believe it or reply. In an incident this tangled, the loudest claim is not always the real one.
The pattern: Salesloft Drift, Gainsight, now Klue
Klue is not a one-off. It is the latest in a run of attacks that hit a middleware vendor to reach many downstream Salesforce environments at once. ReliaQuest and Obsidian both linked the Klue tradecraft to the OAuth-abuse playbook seen in the Salesloft Drift and Gainsight compromises during 2025, which were themselves associated with the ShinyHunters and UNC6395 activity clusters. Icarus appears to be a separate, newer group, but the method is the same one that keeps working.
The through-line is simple. Attackers have learned that the fastest way to reach hundreds of enterprises is to compromise a single vendor those enterprises trust and connect to their crown-jewel SaaS. Each new integration you approve widens that shared attack surface. The defensive answer is not to stop using SaaS integrations, which is not realistic. It is to treat third-party access as a monitored, inventoried, expiring thing rather than a one-time approval you never look at again.
The Klue breach was a monitoring gap on third-party access. The lessons above split into two halves: the internal half (token inventory, API-layer logging, IdP hygiene) that lives in your SIEM and identity provider, and the external half (vendor posture, leaked data, active campaigns, brand abuse) that most teams have no continuous eyes on. That external half is where Scrutex works.
Where Scrutex fits
Two things worth saying plainly first. Scrutex is an external and third-party risk platform. It does not sit inside your Salesforce reading API logs, and it will not replace your SIEM or your identity provider. That internal telemetry is yours to own. What Scrutex covers is the part of this attack that happened outside your walls: the vendor you trusted, the credentials that leaked, the campaign that targeted your sector, and the phishing that followed. Here is how the lessons in this post map to the platform.
| Lesson from the Klue breach | Scrutex module | What it does about it |
|---|---|---|
| Third-party access is a standing risk after approval | Vendor Insights | Continuous vendor posture scoring and questionnaire automation, so a vendor's risk is tracked after the day you onboard it, not just at procurement. Keeps an audit-ready evidence trail if a vendor is breached. |
| Dormant and leaked credentials feed initial access | Data Exposure Insights | Monitors the dark web, paste sites, stealer logs and breach corpora for exposed credentials tied to your domains. Also catches your own contact data and quotes appearing on a leak site, so you learn it from monitoring rather than from an extortion email. |
| Active OAuth-abuse campaigns hit one sector at a time | Threat Insights | Curated CTI that maps actors like Icarus and campaigns like the Salesloft Drift and Gainsight pattern to your region and sector, so you know to hunt before you are on the list. Not a raw feed. |
| Stolen contact data fuels follow-on phishing and spoofing | Brand Insights | Watches for lookalike domains, spoofed senders and impersonation (the kind of abused-mail-domain activity seen in the Klue extortion emails) across DNS, social and app stores, with takedown support. |
| The whole external surface needs continuous eyes, not a quarterly scan | Vulnerability Insights | Continuous external scanning for open ports, expired certificates, dangling subdomains and outdated technology, prioritised by real-world exploitability. |
The reason these sit together rather than as five separate tools is the CTEM lifecycle: scope your external and third-party exposure, discover new assets and leaks within hours, prioritise by what attackers are actually exploiting, validate with continuous automated red teaming and automated pen testing, then mobilise findings into your ticketing and takedown workflows through webhook and API integrations. Applied to third-party access, that loop is what turns a Klue-style integration from a one-time approval into a monitored, expiring thing. An Application Security module (in beta) extends the same approach to your own apps and SDLC.
CTEM is a framework developed by Gartner, Inc. GARTNER is a registered trademark and service mark of Gartner, Inc. and/or its affiliates.
If you want to see your own external and third-party exposure, Scrutex runs agentless. You add a domain and a few brand keywords and discovery starts in minutes, and the free tier covers the core modules on your primary domains with no credit card. Book a demo and the team will run a live scan of your external attack surface during the call. Start free at scrutex.ai.
Key takeaways
- A SaaS supply chain attack reaches your data through a trusted vendor's existing access, so your own MFA and network controls never come into play.
- The Klue breach started with a compromised GitHub personal access token, created for a vendor integration prototype and never revoked. Non-human identities like PATs, service accounts and OAuth grants are the cheapest risk to remove and the most often ignored.
- OAuth tokens are bearer credentials. Whoever holds a token is treated as the app that owns it, with no password or second factor in the way.
- The detection lived in the API logs and the source-IP baseline, not the login logs. A valid token doing high-volume reads from unfamiliar infrastructure was the tell.
- Even mature security companies were affected because the attacker hit their shared vendor, not them. Third-party access needs continuous monitoring, a token inventory, and expiry.
FAQ
Q: What is a SaaS supply chain attack?
A: It is an attack where a threat actor compromises a trusted third-party SaaS vendor, then uses that vendor's existing access to reach the data of every customer connected to it. The victim organisations are breached without their own systems being attacked directly.
Q: Was LastPass hacked in the Klue breach?
A: LastPass customer data in its Salesforce CRM was accessed, including names, emails, phone numbers, physical addresses and support-case data. LastPass confirmed its products, infrastructure and customer password vaults were not affected, and the exposed OAuth tokens were rotated.
Q: How did attackers steal the OAuth tokens?
A: The attacker used a compromised GitHub personal access token (created for a vendor integration prototype and never revoked) to reach Klue's integration service, then pushed a code update that harvested the OAuth tokens Klue's customers use to connect its app to their systems. Those tokens were then used to query customer Salesforce environments directly. CrowdStrike confirmed the PAT as the entry point but could not determine how it was first compromised.
Q: Who is the Icarus threat group?
A: Icarus is an extortion group that publicly claimed the Klue breach and listed the company on its leak site on June 19, 2026. Huntress attributed the original intrusion to Icarus by matching Session Messenger IDs. The group has been active only since April 28, 2026. Attribution is not fully settled: the tradecraft matches earlier ShinyHunters and UNC6395 Salesforce campaigns, a Telegram account claiming to be ShinyHunters also claimed the breach on June 21 (unverified), and a separate party later claimed to hold the data. The safest position is to treat the original intrusion as Icarus while expecting copycat extortion.
Q: What should I monitor to catch this kind of attack?
A: Watch five things: non-human identities such as GitHub PATs, service accounts and OAuth grants (scope, owner, expiry, last-used date), your inventory of the OAuth tokens vendors hold, the source IPs and query volume of each vendor integration against a known baseline, unauthorised changes to your CI/CD pipelines, and your contact data surfacing on leak sites afterward. API-layer logging on your CRM is essential, because login logs alone will not show bulk token abuse.