Path & Payload

One Credential, Multiple Doors: Breaking Down the Klue OAuth Breach

A single dormant credential at one mid-market software vendor put the Salesforce data of dozens of organizations within reach, including at least four cybersecurity firms. None of those firms was breached through a flaw in its own systems. The door was opened via a competitive-intelligence platform they all used — that platform held the OAuth tokens connecting it to each of their environments. The Klue incident happened because of the standing, delegated access that every modern SaaS integration depends on.

This post draws on the ReliaQuest threat spotlight that first surfaced the activity, the Huntress incident report that reconstructed the actor and the entry point, the statement from Klue's CEO, and customer disclosures from Recorded Future and Gong. It walks the full chain from initial access through extortion, with the most detail on the token-harvest stage, where one compromise fanned out into many.

The Incident

Klue is a competitive- and market-intelligence platform. Its core function is to pull customer data out of systems like Salesforce, Gong, and HubSpot to build battlecards and win/loss analysis, which means it holds persistent, authorized connections into its customers' most sensitive go-to-market data. This is an ordinary arrangement, but it’s also what made Klue a high-value single point of failure.

The list of affected organizations grew quickly through the week of June 16. Huntress, Recorded Future, Jamf, and Tanium confirmed impact, as did Sprout Social, Gong, and Insurity. In every confirmed case the organization's own platform was untouched and the loss was confined to data held in connected systems.

Attribution points to a new extortion group calling itself Icarus, and while they claimed credit, there’s also methodological evidence. Huntress matched the Session Messenger ID in the extortion emails to the ID on the Icarus leak site, then watched the actor send a follow-up email correcting the key after a mistake, after which the leak-site page was edited to carry the corrected ID. That correlation, across infrastructure the actor controlled on both sides, is what moved the attribution to high confidence. Icarus appears to have been active only since late April 2026, with a short prior victim list.

ReliaQuest, which detected the activity independently and was not itself a Klue customer, declined to attribute. It noted a separate claim of responsibility posted to Telegram by ShinyHunters, and observed that the broad approach mirrors the ShinyHunters and UNC6395 campaigns against Salesforce throughout 2025 and 2026. The playbook resemblance is interesting, but there’s no actual evidence linking ShinyHunters. The tooling here doesn’t match the UNC6395 activity behind the Salesloft Drift compromise, which used python-requests, Salesforce-CLI, and Tor — this actor instead used a generic Python-urllib agent and commercial hosting.

The Attack Chain

Stage 1: Initial Access

ATT&CK: T1078 (Valid Accounts)

The entry point was a legacy credential tied to one of Klue's integration services. Klue's own statement describes it as a compromised legacy credential. Huntress reconstructs it more specifically as a credential Klue had created to prototype a third-party integration it later abandoned, and never deactivated. The credential outlived the project it was built for, and it still worked.

This is the least technically remarkable stage of the chain and the most consequential. There was no exploit. The attackers merely took advantage of an account that was forgotten about. Huntress places the start of anomalous activity on June 11. Klue identified it on June 12.

Stage 2: The Token Harvest

ATT&CK: T1528 (Steal Application Access Token)

With access to Klue's integration infrastructure, the attacker pushed a code update that collected the OAuth tokens Klue's customers used to connect the platform to their own systems. This is the center of the incident.

An OAuth token isn’t a password but a delegated grant, a standing key that lets one application act inside another on a customer's behalf without re-authenticating. The application holding it is a non-human identity, and unlike an employee account, it doesn’t log in from an endpoint, trigger location alerts, or get prompted for a second authentication factor. It simply has access, continuously, until the grant is revoked. Klue held one of these grants for every platform each customer had connected.

So when the attacker reached the token store, the blast radius was not just one system. Klue disabled nine integrations in response to the attack: Salesforce, HubSpot, SharePoint, Zoom, Gong, Chorus, Clari, Google Drive, and Slack. Each represented a class of standing access into customer environments that the stolen tokens could assume. Salesforce drew the most coverage because that’s where the bulk extraction landed, but the exposure was the full integration surface. Gong confirmed that a subset of its customers had licensed-user data reached through the same Klue connection, which is the clearest proof that this was a fan-out and not a Salesforce-specific event.

This attack couldn’t have been prevented with a password reset. A password reset does nothing to an active OAuth grant, because the grant exists independently of the credential that created it. Only revoking the refresh token cuts the access.

Stage 3: The Data Pull

ATT&CK: T1199 (Trusted Relationship), T1550.001 (Use Alternate Authentication Material: Application Access Token), T1526 (Cloud Service Discovery), T1213 (Data from Information Repositories), T1567 (Exfiltration Over Web Service)

Holding the tokens, the attacker authenticated as Klue into the connected environments and queried the CRM data directly. ReliaQuest reconstructed the pattern against Salesforce: the scripts first enumerated the org's object catalog through the sobjects endpoint, then looped queries against the REST query endpoint, paginating through results with the QueryMore cursor for roughly 24 hours. In at least one environment, the slow, blending pull gave way to a burst of nearly a thousand queries in fifteen minutes, a shift from stealth to speed that suggests either time pressure or a move to targeted records.

The traffic was difficult to flag for the same reason the access was difficult to see — it came from a trusted integration account, over the same authenticated API path that legitimate Klue syncs use. There was no malware to detect and no process to kill. The only tell was behavioral: query volume and pacing that did not match an integration's normal rhythm, from infrastructure the integration had never used before. Huntress and Klue both published the four source addresses, in the Netherlands, France, and Ukraine, and noted that only one had any prior reputation, tied to a March 2026 spam campaign. The user-agent strings were the primary signal, with Python-urllib accounting for the bulk of the malicious requests.

The data taken was business data. Across the disclosures it amounted to contact records, business titles and emails, pricing and quotes, sales communications, and free-form opportunity notes. Recorded Future and Gong both confirmed that core platform data, call recordings, telemetry, and payment information were not in scope. The value to the attacker was not the records themselves so much as the leverage they create.

Stage 4: The Extortion

ATT&CK: T1584 (Compromise Infrastructure), T1657 (Financial Theft)

Beginning June 16, employees at affected firms received extortion emails warning that their data had been taken and giving them a window to respond. The messages were sent from the mail servers of three Australian retail subsidiaries with valid SPF and DMARC, meaning the actor was relaying through genuinely compromised infrastructure rather than spoofing it. The sender went by "mr bean," and at one point followed a first email with a correction reading "wrong session lol" after providing the wrong contact key, the slip that later exposed the leak-site correlation.

Icarus framed its leak-site post in the now-standard register of the trade, describing the data as borrowed rather than stolen and inviting cooperation over consequence. But by June 22, it listed data for Huntress and several other impacted companies on its leak site.

Where Defenders Had a Window

There were four points where this chain was detectable, but only two of them belonged to the organizations whose data was taken.

1. The stale prototype credential. This was the root cause and the most preventable point, and it sat inside Klue. A credential created for an abandoned project and never deactivated is a standing inventory problem. Service accounts and integration credentials need the same lifecycle as employee accounts: an owner, an expiry, and a review that removes them when the work they were built for ends. The downstream victims could not see this, but every platform that holds other companies' tokens should read it as a warning about its own dormant accounts.

2. The code pushed into the integration layer. Unauthorized code reaching the system that stores and uses customer OAuth tokens should not be a quiet event. Change control and integrity monitoring on the token-handling path is the control here, and this window was also Klue's.

3. The anomalous API activity. This is the first window the downstream organizations actually owned. The stolen tokens were used from infrastructure the integration had never authenticated from before, at a query volume and pace that did not match a normal sync, including a burst of nearly a thousand queries in fifteen minutes. New source addresses for an established connected app, and query patterns that break from baseline, are visible in Salesforce event monitoring and to any SIEM ingesting those logs. Enforced login-IP ranges on the connected app would have rejected the attacker's traffic outright rather than merely flagging it.

4. The extortion contact. By the time the emails arrived on June 16, the data was already gone. The only value left in this window is the speed and scope of the response: revoking access, hunting the logs, and notifying the people whose data was exposed.

The first two windows sat inside a vendor the victims had no visibility into. That's the entire point of compromising an integration rather than a target directly. For a downstream organization, the realistic line of defense is windows three and four, which is why the work that matters most happens before an incident, in how narrowly the integration is scoped and bound in the first place. It's also an argument for taking supply chain security seriously.

The Pattern

This is the third widely reported instance in roughly a year of the same technique: steal the OAuth tokens of a trusted SaaS integration, then use them to drain the CRM behind it. Salesloft, Drift, and Gainsight preceded Klue, and the through-line is integrations. Non-human identities with broad, persistent, sanctioned access to the data an organization considers most sensitive are monitored far less closely than the humans who sit beside them.

The governance failure and the security failure are the same failure here. An OAuth grant that is not inventoried, scoped to least privilege, and watched for anomalous use has a standing key.

For organizations that connected Klue, the immediate actions are narrow and well understood: revoke and rotate the integration's tokens and secrets rather than only its password, hunt API logs for the query patterns and addresses below, and restrict integration access to known infrastructure. The broader lesson is the harder one. Every third-party application with a token into a core platform belongs on the same inventory, under the same scrutiny, and inside the same blast-radius math as any privileged account, because that is what it is.

Takeaway for Defenders

For organizations running third-party SaaS integrations, the goal is to make a stolen token worth as little as possible, and to notice when one is used.

Sources

#Attack Chain Breakdown