A legacy GitHub Personal Access Token (PAT), shared with a vendor and never revoked, gave an attacker standing access to Klue's infrastructure. From there, they harvested OAuth tokens belonging to hundreds of Klue customers and queried those customers' Salesforce and Gong environments directly for up to 24 hours. There was no exploit, no phishing, and no vulnerability in any downstream platform. Every step of the attack was executed using valid credentials through legitimate APIs. Google's Threat Intelligence Group confirmed the initial access vector, Huntress traced the exfiltration, and ReliaQuest documented the API pattern. The attacker is Icarus, an extortion group active since April 2026 that has sent ransom demands to at least a dozen organizations.

This is not a story about Klue getting hacked. It is a story about what the non-human identity attack surface looks like when nobody is governing it.

The credential that outlived its purpose

Klue created a GitHub Personal Access Token to share with a vendor for a technical integration. The integration was never deployed, the relationship eventually ended, and the token was never revoked. A GitHub PAT is a non-human identity. Its scope is fixed at the point of issuance;; no multi-factor check is required for authentication; and it remains valid indefinitely unless someone deliberately expires or deletes it. This one sat in Klue's environment with standing access, no owner, no expiry, and no monitoring. That is the full description of an orphaned identity: a credential that has outlived its purpose but not its permissions.

The attacker found it and used it to access Klue's environment, then pushed a code update that harvested the OAuth tokens that Klue's customers had issued to connect the product to their Salesforce instances, Gong environments, HubSpot accounts, Google Drive, SharePoint, Zoom, Chorus, Clari, and Slack. One orphaned token became access to every OAuth grant across Klue's entire customer base, which is what an ungoverned blast radius looks like in practice.

An OAuth grant is access, not a setting

Every OAuth token a customer issues to a SaaS integration is a non-human identity in its own right. It authenticates on its own, independent of the person who authorized it, and the access it carries persists even when the integration sits idle for long stretches. It will not appear in an IAM dashboard when something else presents it, and it rarely surfaces in a quarterly access review unless someone specifically audits connected applications.

Klue does not publicly disclose the OAuth scopes it requests from Salesforce or any other integrated platform. Its integrations page describes what the product does, such as pulling battlecards from Salesforce objects and capturing win-loss data, but publishes no scope list, and its security page covers Klue's own compliance posture rather than the permissions it requests from customers. This is common practice among SaaS vendors, and it means that customers who authorized the integration had no published reference for what they were actually granting. The only public evidence of what the integration could reach is the confirmed exfiltration itself, which Huntress documented as including contacts, price quotes, sales communications, and competitive intelligence reports. When the attacker inherited those OAuth tokens, they inherited exactly that access. The scope had been set once at provisioning and had never changed since.

How the data left, in two stages

ReliaQuest's analysis of Salesforce API logs documented the extraction pattern in two distinct phases. In the first, the attacker enumerated the full object catalog of each customer org and then ran sustained queries against it through pagination cursors, in one environment continuing for more than six hours and pacing the requests to blend in with normal integration traffic. In the second phase, once the high-value objects had been mapped, the attacker traded stealth for speed, running close to a thousand queries within a fifteen-minute window. Across the affected environments, the full exfiltration ran for up to 24 hours each.

The requests included user-agent strings tied to Klue's own integration tooling, making them indistinguishable from legitimate Klue activity at the API layer. The exfiltration went undetected, not because the activity was hidden, but because no system was monitoring how this identity behaved relative to a normal baseline.

Why the standard stack caught nothing

The logs existed the whole time. Huntress confirmed that a post-incident review of Salesforce API logs clearly showed the extraction. The failure was not a lack of logging but a lack of behavioral monitoring at the identity layer.

Each layer of the conventional control stack was structurally unable to see this activity:

• SIEM rules built around impossible travel and unusual login geography do not fire when authentication comes from an IP address the system already recognizes as a known integration.
• Endpoint agents do not instrument REST API calls made from a vendor's infrastructure to a customer's Salesforce tenant.
• Data loss prevention does not inspect data leaving through an OAuth-authenticated session where the grant was legitimate to begin with.
• Privileged access management governs privileged human accounts rather than OAuth tokens held by a third-party vendor on a customer's behalf.

The detection that would have caught this depended on knowing the normal API call volume for the Klue integration and alerting when an order of magnitude suddenly exceeded that volume. A fifteen-minute burst of roughly a thousand queries from an integration that normally generates a small fraction of that is anomalous and detectable, but only if non-human identities are governed with the same rigor applied to privileged user accounts, including behavioral baselines.

This was the third confirmed Salesforce integration breach to follow the same structural logic, after the Salesloft Drift breach in August 2025 and the Gainsight breach earlier in 2026. The playbook keeps working because the underlying condition keeps recurring: SaaS integrations are granted broad OAuth access; that access is never scope-reviewed or behaviorally monitored; and the credential is held by a vendor whose own hygiene is invisible to the customer.

What to do if you are affected

If your organization used the Klue integration, the following steps should be treated as immediate priorities:

• Revoke and rotate first. Reset the Klue service account password, revoke all active OAuth grants across every connected platform, and rotate refresh tokens and client secrets. A password reset on its own does not invalidate existing OAuth sessions, so the refresh token has to be revoked explicitly.
• Enumerate connected applications. In Salesforce, go to Setup, then Connected Apps, then Manage Connected Apps, and review every active OAuth grant, removing anything that cannot be justified. In Google Workspace, the equivalent path is Security> API controls> App access control, where any active Klue grant can be revoked.
• Hunt the logs. Search Salesforce Event Monitoring for queries from the attacker IP addresses 138.226.246.94, 212.86.125.24, 213.111.148.90, and 94.154.32.160, and look for calls to the object enumeration endpoint that preceded extraction. The user-agent strings associated with this activity were Python-urllib/3.12, Python-urllib/3.14, and 5238. Unusual pagination across large result sets is another signal worth flagging.
• Restrict integration traffic. Limit integration service accounts to traffic from Klue's published egress IP ranges, which appear in Klue's customer advisory.
• Check inboxes for the extortion attempt. Icarus emails used the alias "Mr Bean" and a Session Messenger ID and originated from the compromised Global Retail Brands infrastructure, with valid SPF and DMARC. In one case, a correction email followed 38 minutes later from the same sender, a sign that the attacker was juggling multiple victim threads. Preserve any such messages before removing them.

Mapping the failure to a solution

Both classes of credentials that made this attack possible, the orphaned GitHub token inside Klue and the customer OAuth grants spread across Salesforce, Gong, Google Drive, and the rest, are non-human identities. Neither appears in standard IAM tooling nor a privileged access dashboard, and neither gets reviewed in a quarterly audit unless a process is built specifically to find it.

Unosecur discovers and inventories non-human identities across cloud and SaaS environments, maps the blast radius of each credential, and monitors for behavioral deviation against an established access baseline. In the context of this incident, that means continuous visibility into which OAuth grants exist, what each one can access, when each last generated activity occurred, and whether current query volume has drifted from the integration's normal pattern. That last point is the difference that matters. It is what separates detecting a six-hour slow extraction while it is happening from discovering it in a post-incident log review after the ransom note has already arrived.

If you cannot say which non-human identities exist in your environment, what they can reach, and what normal behavior looks like for each, you are operating with the same blind spots that this incident exposed.

‍Assess your non-human identity exposure risk with Unosecur.