How a forgotten prototype credential let attackers harvest OAuth tokens from a SaaS vendor and loot 15 companies' CRM data

The Context

Klue is a competitive intelligence platform. Sales teams use it to track competitor moves, and it connects directly to the tools those teams live in: Salesforce, Gong, HubSpot, Slack, and others. To make those connections work, customers authorize Klue to read their data through OAuth, which issues a token (essentially a digital key) that Klue holds and uses to pull data on the customer's behalf.

This architecture is normal and widespread. The problem is that those tokens are long-lived, broadly scoped, and held by the vendor. When the vendor's backend is compromised, every token it holds becomes available to the attacker.

The Attack, Phase by Phase

Phase 1: The Forgotten Door

Klue once built a prototype integration with a third-party service. The project was abandoned. The service account credential created for that prototype was not decommissioned — no owner, no expiration date, no monitoring.

Icarus found this credential and used it to authenticate directly into Klue's integration infrastructure on June 11, 2026, at 12:56 UTC, according to Datadog Security Labs. No phishing. No exploit. No brute force. A valid credential opened the door.

Phase 2: Poisoning the Middleware

Once inside, the attackers pushed a malicious code update to Klue's integration middleware — the layer that manages connections between Klue and its customers' third-party platforms. This code silently collected the OAuth tokens Klue held for customers' Salesforce, Gong, HubSpot, SharePoint, Zoom, Chorus, Clari, Google Drive, and Slack environments.

The token-harvesting code ran undetected from June 11 until Klue staff removed it on June 13.

Phase 3: Automated CRM Exfiltration

With valid OAuth tokens, the attackers authenticated to customer Salesforce and Gong environments as the Klue Battlecards application — a trusted integration customers had explicitly approved. From Salesforce's perspective, this was normal traffic from a known source.

Automated Python scripts enumerated every available data object in each Salesforce instance, then bulk-extracted records through looped queries with automatic pagination. The loop ran for approximately 24 continuous hours, peaking at nearly 1,000 queries in 15 minutes. Because the traffic came from a trusted integration account, it did not trigger identity-based alerts. MFA was irrelevant: OAuth tokens do not require re-authentication.

Phase 4: Extortion Campaign

Beginning June 16, Icarus sent extortion emails with the subject line "top secret email" to staff at affected organizations, signed under the alias "mr bean." Recipients were given 48 hours to contact the group via Session Messenger or face public data release. Emails were routed through compromised infrastructure belonging to Global Retail Brands, an Australian retailer.

On June 19, Icarus listed Klue on its dark web leak site. On June 22, stolen data from Huntress and other victims was posted publicly.

What Made This Possible

1. A non-human identity with no lifecycle controls. The prototype service account had no owner, no expiration date, and no monitoring. Human employee accounts are offboarded when someone leaves. Service accounts created for abandoned projects are not. This is not a Klue-specific failure — it is the near-universal residue of how software is built and iterated.

2. OAuth tokens that outlive the trust that created them. When a customer authorizes Klue to access their Salesforce data, that authorization persists until explicitly revoked. The token remains valid regardless of what happens to the vendor holding it.

3. Integration traffic that looks identical to legitimate traffic. Once an attacker holds a valid OAuth token for a trusted integration, their queries are indistinguishable from normal operation. There is no second authentication layer and no perimeter alert for "too many queries from a known app."

The systemic lesson: a single credential hygiene failure at one integration vendor cascaded into simultaneous breaches across 15 downstream organizations, none of which had visibility into the attack until it was over.

What Should Have Stopped This

No single defense here depends on the vendor's security posture remaining intact. That is the unifying principle: customer-side controls applied before a vendor compromise are the only ones that survive it.

• OAuth scope minimization. Customers can limit what an integration is authorized to read. A Klue integration scoped only to competitive intelligence fields cannot exfiltrate full contact records and opportunity notes. Most organizations accept default broad scopes at setup and never revisit them.
• OAuth grant auditing. Salesforce and most major platforms allow administrators to review every active connected application and its permissions. A quarterly review surfaces integrations no longer in active use and allows revocation before a vendor compromise makes them dangerous.
• API query volume monitoring. Nearly 1,000 queries in 15 minutes from an integration account is not normal behavior. Salesforce's Event Monitoring feature logs API activity at this level of detail. Organizations that had it enabled could have detected the anomaly.
• Service account inventory and decommissioning. Klue's initial access came from a credential no one remembered. A mandatory decommissioning step in the development lifecycle — including credential revocation — would have closed this door.

The Takeaway

The Klue breach is the same class of failure as the Stryker Intune wipe: a trusted administrative tool weaponized against the organizations it was built to serve. In the Stryker case, attackers used a device management platform to destroy endpoints. Here, attackers used a sales intelligence platform to drain CRM data from 15 companies simultaneously. Once the attacker controls the trusted intermediary, every downstream organization inherits the breach.

This attack also mirrors the Axios supply chain incident: attackers injected malicious code into a widely used software package at build time. Here, they injected malicious code into a SaaS vendor's middleware at runtime. The delivery mechanism differs; the principle is identical. Compromise the supplier, inherit access to every customer.

ReliaQuest assessed in its June 17 threat spotlight that threat actors will continue targeting Salesforce-connected third-party integrations through the remainder of 2026. The Salesloft Drift and Gainsight compromises of 2025 used the same OAuth-abuse playbook. Klue is not an isolated incident; it is the third confirmed execution of a repeatable attack pattern against SaaS integration layers.

Pattern to remember: A vendor's credential hygiene failure becomes your data breach, because the OAuth tokens your vendor holds are indistinguishable from legitimate access once stolen.

What changed: The SaaS integration layer has become an attack surface where a single upstream credential compromise produces simultaneous, MFA-bypassing access to dozens of downstream organizations, with no signal visible to the victims until the data is already gone.

The Technical Mechanism

The attack chain has three distinct technical components: initial access via a dormant non-human identity (NHI), runtime code injection into integration middleware, and automated OAuth token abuse against downstream APIs.

Initial access. Klue maintained a service account credential originally provisioned for a prototype third-party integration. The credential was a long-lived static secret with no expiration policy, no owner assignment, and no behavioral monitoring. Icarus obtained this credential through means not publicly disclosed (likely credential exposure via a prior breach, dark web purchase, or reconnaissance of Klue's exposed infrastructure) and used it to authenticate directly to Klue's integration backend. Datadog Security Labs identified the earliest anomalous activity at 12:56 UTC on June 11, 2026.

Middleware code injection. Once authenticated, the attacker pushed a malicious code update to Klue's integration middleware, specifically the Klue Battlecards integration layer. This code intercepted and exfiltrated the OAuth tokens Klue held for customer integrations across Salesforce, Gong, HubSpot, SharePoint, Zoom, Chorus, Clari, Google Drive, and Slack. The tokens were long-lived OAuth 2.0 access tokens and refresh tokens. Datadog confirmed that in some instances the attacker used OAuth refresh tokens to maintain persistent API access beyond the initial access token's expiry window.

Automated API exfiltration. The attacker authenticated to customer Salesforce instances using stolen OAuth tokens, presenting as the Klue Battlecards connected application. The exfiltration scripts used Python-urllib user-agent strings and followed a two-step enumeration-then-extraction pattern:

1. GET /services/data/v59.0/sobjects to enumerate all available Salesforce object types in the target instance
2. Looped GET /services/data/v59.0/query/ requests with QueryMore cursor pagination to bulk-extract records across all enumerated object types

The loop ran for approximately 24 continuous hours. Peak query volume reached nearly 1,000 requests in a 15-minute window. Because all requests originated from a pre-authorized connected application identity rather than a user session, they did not trigger Salesforce's standard identity-based alerting. MFA controls were bypassed entirely: OAuth tokens authenticate the application, not the user, and do not require interactive re-authentication.

No CVE applies to this attack. There was no software vulnerability exploited in Salesforce or any downstream platform. The attack exploited a credential hygiene failure at Klue and the inherent trust model of OAuth delegation.

CVE and Advisories

No CVE has been assigned. This attack did not exploit a software vulnerability. Salesforce confirmed: "This issue is limited to Klue's app connection and does not arise from a vulnerability within the Salesforce platform."

No formal CISA advisory had been published as of the post date. Relevant vendor guidance:

• Huntress incident report, June 18, 2026
• ReliaQuest threat spotlight, June 17, 2026
• Datadog Security Labs detection guidance, June 22, 2026

MITRE ATT&CK Mapping

Indicators of Compromise

Detection is difficult because the attack traffic originated from a legitimate, pre-authorized connected application identity. Standard perimeter and identity-based controls do not flag this pattern. The following indicators were identified by Huntress, Datadog Security Labs, and ReliaQuest:

Network Indicators

• Attacker infrastructure: VPS nodes hosted by ISPs in the Netherlands, France, and Ukraine
• Only one of four known attacker IP addresses carried prior reputation history at time of attack
• Extortion emails routed through compromised mail infrastructure of Global Retail Brands (Australian retailer)

Behavioral Indicators in Salesforce

• Python-urllib user-agent string in API requests attributed to the Klue Battlecards connected application
• Anomalous query volume: sustained bulk requests to /services/data/v59.0/query/ with QueryMore pagination
• Initial enumeration request to /services/data/v59.0/sobjects followed immediately by high-volume record extraction
• Query bursts approaching 1,000 requests per 15-minute window from an integration account
• API activity outside normal business hours for the integration's expected usage pattern

Detection Recommendation

Salesforce Event Monitoring (a paid add-on) provides the API-level logging required to detect this pattern. Organizations without it enabled cannot retrospectively reconstruct whether this activity occurred in their instance. Datadog Security Labs published specific detection queries for identifying the attack pattern in Salesforce event logs.

Attribution

The attack is attributed with high confidence to Icarus, a financially motivated extortion group that became active on April 28, 2026. Attribution rests on two independent corroborating threads documented by Huntress:

1. Session Messenger IDs included in extortion emails sent to Huntress matched identifiers listed on the Icarus dark web leak site.
2. When Icarus corrected a Session ID in a follow-up email, the leak site updated to match simultaneously, providing a second independent confirmation that the email sender and the leak site operator are the same actor.

Icarus formally claimed the attack on June 19, 2026. The group used the alias "mr bean" in extortion communications and routed emails through compromised infrastructure belonging to Global Retail Brands subsidiaries. Huntress reported this infrastructure abuse to the Australian Cyber Security Centre.

A Telegram account purporting to be ShinyHunters claimed responsibility on June 21, 2026. ReliaQuest assessed it could not verify the account's authenticity and noted it may be an unrelated actor exploiting ShinyHunters' reputation to amplify extortion pressure. ReliaQuest and BleepingComputer both confirmed that ShinyHunters and UNC6395, the groups behind similar 2025 OAuth-abuse campaigns against Salesloft Drift and Gainsight, are not responsible for this attack. Icarus is assessed as a distinct criminal group. No nation-state link has been identified.

Primary Sources