How a forgotten service account credential let attackers harvest OAuth tokens from hundreds of companies' Salesforce environments

The Context

Klue is a competitive intelligence platform used by sales and marketing teams to track competitor activity and share it internally through Battlecards. To do its job, Klue integrates directly with tools sales teams use every day: Salesforce, HubSpot, Gong, Slack, SharePoint, and others. Those integrations require Klue to hold OAuth tokens — the digital keys that authorize one software system to act on behalf of another. Klue serves more than 250,000 users worldwide and hundreds of enterprise customers, many in the technology and cybersecurity sectors.

The breach was detected on June 12, 2026, and Klue began containment the same day. By June 13, Klue had revoked credentials and disabled integrations platform-wide. The exfiltration had already occurred.

The Attack, Phase by Phase

Phase 1: Initial Access via Forgotten Credential

The attack began with a credential that had outlived its purpose. Klue had created a service account to prototype a third-party integration the company later decided not to build. The prototype was abandoned, but the credential was never decommissioned or rotated. It remained active, valid, and unmonitored.

Attackers obtained this dormant credential and used it to authenticate to Klue's backend integration infrastructure on June 11, 2026. There was no zero-day exploit, no phished employee, no brute-force attack. The credential worked because nobody had thought to revoke it.

Phase 2: Code Injection and Token Harvesting

With a foothold inside Klue's infrastructure, the attackers pushed a malicious code update into Klue's integration layer — positioned at the authentication handshake point, the moment where OAuth tokens are created and exchanged as customers' integrations authenticate to Salesforce and Gong.

As each customer's integration authenticated normally, the injected code intercepted and copied the token. The attackers did not need to compromise each customer individually. They turned Klue's own platform into a collection mechanism, harvesting tokens for dozens of downstream environments simultaneously between June 11 and 12.

Phase 3: Automated CRM Exfiltration via Salesforce REST API

Armed with valid OAuth tokens, the attackers authenticated to victim Salesforce environments as the legitimate Klue integration account. From Salesforce's perspective, the token was valid, the access was authorized, and the session looked like normal Klue activity.

Automated Python scripts queried the Salesforce REST API, executing nearly 1,000 queries in a single 15-minute burst and sustaining extraction windows of over six hours across an approximately 24-hour total window. The only anomaly visible in Salesforce logs was that the source infrastructure had no connection to Klue's known legitimate environment — detectable only with API-layer logging in place. Organizations without it would have seen nothing unusual.

The stolen data included business contacts, sales communications, price quotes, opportunity notes, account records, and in some cases contract information. Gong confirmed internal user data including names, titles, and email addresses was accessed. Recorded Future described its exposure as limited to client contact names, email addresses, and possibly some contract information.

Phase 4: Extortion Campaign and Public Disclosure

Beginning June 16, the Icarus extortion group sent emails to affected organizations with the subject line "top secret email," warning that Salesforce data had been downloaded and giving recipients 48 hours to respond. The emails were routed through compromised mail servers belonging to Global Retail Brands, an Australian retailer. Huntress traced Session Messenger identifiers in the emails to the Icarus dark web leak site and reported the activity to the Australian Cyber Security Centre.

Salesforce disabled the Klue Battlecards integration platform-wide on June 17. Klue CEO Jason Smith published a public statement on June 18. Icarus officially listed Klue as a victim on June 19. By June 22, the confirmed victim list included HackerOne, Huntress, Jamf, Recorded Future, Tanium, Snyk, OneTrust, Sprout Social, Gong, and Insurity.

What Made This Possible

1. Unmanaged service account credentials. The entry point was a credential created for a project that no longer existed. Organizations routinely create service accounts for integrations, proofs of concept, and vendor evaluations, and rarely audit whether those accounts are still needed. A credential that is never rotated and never reviewed is a permanent open door.

2. Trusted integration access with no behavioral monitoring. OAuth tokens grant broad, persistent access to enterprise data. Klue's integration had legitimate authorization to query Salesforce on behalf of its customers, but nothing in that authorization model required queries to look like normal integration traffic. Bulk extraction at 1,000 queries in 15 minutes was only distinguishable from routine activity if someone was watching API-layer logs for anomalous volume.

3. Single-vendor blast radius across hundreds of environments. Klue's position as a shared integration layer meant one compromised credential at one vendor produced authenticated access to hundreds of downstream customer environments simultaneously. No customer had done anything wrong. Their Salesforce security controls were intact. The problem was upstream, in a system they did not control and could not monitor.

What Should Have Stopped This

• Credential lifecycle management: Service accounts should be inventoried, reviewed on a schedule, and deactivated when the project they were created for ends. This is the control that would have prevented initial access entirely.
• OAuth token scoping and expiration: Tokens scoped to specific data objects and set to expire limit what an attacker can do even with a valid token. Broad, long-lived tokens amplify the damage of any compromise.
• API-layer logging and anomaly detection: Salesforce's Event Monitoring feature logs API activity including query volume, source IP, and user-agent strings. Organizations with this logging enabled would have seen nearly 1,000 queries in 15 minutes from an unfamiliar IP range. This is a configuration choice, not a platform limitation.
• Third-party integration audits: Organizations should periodically review which SaaS tools hold OAuth tokens to their Salesforce environment, what permissions those tokens carry, and whether the integration is still actively used. Tokens for inactive integrations should be revoked.

The Takeaway

This is the same class of failure as the Stryker Intune wipe: a trusted management tool weaponized against the organizations it was built to serve. The mechanism is identical — an attacker inherits the vendor's authorized access and uses it at scale. The meta-pattern: systems fail when they trust a boundary the attacker controls.

This is also the third major Salesforce ecosystem supply chain breach in under a year, following the Salesloft Drift and Gainsight compromises. ReliaQuest described the OAuth-abuse playbook as "repeatable, effective, and now widely adopted" and predicted repeat attacks for the remainder of 2026. The playbook works because it requires no vulnerability, no phishing, and no perimeter breach — only a forgotten credential and a trusted integration.

Pattern to remember: A SaaS vendor with OAuth access to your data is a security boundary you do not control, and a breach at that vendor is a breach of your data.

What changed: Attackers can now extract an entire CRM without touching the CRM provider's infrastructure, by compromising the integration vendor that holds the keys on your behalf.

The Technical Mechanism

The Klue breach is a SaaS supply chain attack executed in three technical stages: credential reuse for initial access, code injection at the OAuth token exchange point, and automated bulk exfiltration via the Salesforce REST API.

Initial access was achieved using a dormant service account credential. The credential was associated with a Klue prototype integration that had been abandoned but never decommissioned. No CVE applies to this stage. The credential was valid and the authentication succeeded through normal means.

Token harvesting was accomplished by pushing a malicious code update into Klue's integration layer. The code was positioned at the OAuth handshake, intercepting tokens as they were minted during customer integration authentication flows. This is consistent with a server-side code injection into a middleware component, though Klue has not publicly disclosed the specific mechanism by which the code update was pushed or the language or framework of the integration layer. The injected code harvested OAuth tokens for Salesforce and Gong integrations across Klue's customer base.

Exfiltration was executed using automated Python scripts identified by user-agent strings Python-urllib/3.12 and Python-urllib/3.14. The scripts queried the Salesforce REST API endpoint /services/data/v59.0/query/ using the harvested OAuth tokens. Query volume reached approximately 1,000 requests in a 15-minute window, with sustained extraction periods exceeding six hours across an approximately 24-hour total window. Login events were recorded in Salesforce audit logs but originated from infrastructure inconsistent with Klue's known legitimate environment, specifically data-center hosting with no connection to Klue's normal IP footprint.

No CVE has been assigned to this attack. The vulnerability class is credential management failure (ungoverned service account lifecycle) combined with insufficient OAuth token scoping and absent API behavioral monitoring.

CVE and Advisories

No CVE has been assigned to this incident. The attack did not exploit a software vulnerability in Salesforce, Klue's published application, or any third-party platform. The root cause is a credential management and access governance failure.

Salesforce issued a platform notice on June 17, 2026, when it disabled the Klue Battlecards integration, explicitly clarifying that the issue was limited to Klue's app connection and did not arise from a vulnerability in the Salesforce platform. No Salesforce advisory ID has been published.

MITRE ATT&CK Mapping

Indicators of Compromise

Detection of this attack at the victim layer required Salesforce API-layer logging to be enabled. Organizations without Salesforce Event Monitoring in place had no visibility into the exfiltration as it occurred.

Network Indicators

• User-agent strings Python-urllib/3.12 and Python-urllib/3.14 in Salesforce API logs
• Source IP infrastructure inconsistent with Klue's known legitimate environment
• Data leak file hosting IP from AS200593, registered under PROSPERO OOO (Russian Federation), flagged with a Censys BULLETPROOF designation per Huntress

Behavioral Indicators

• Anomalous query volume against /services/data/v59.0/query/ from integration service accounts: approximately 1,000 queries in 15 minutes is not consistent with routine integration traffic
• Sustained API sessions exceeding six hours from integration accounts
• Login events in Salesforce audit logs from IP ranges with no prior association to the named integration vendor

Detection Limitation

Organizations that did not have Salesforce Event Monitoring enabled would have no log evidence of the exfiltration. The OAuth tokens used were valid, the API calls were authorized, and the activity was indistinguishable from legitimate integration traffic without volume-based anomaly detection at the API layer.

Attribution

The attack is attributed with high confidence to Icarus, a relatively new extortion group that claims to have been active since April 28, 2026. Before the Klue campaign, Icarus had listed only two prior victims on its dark web leak site. Icarus officially claimed the attack on June 19, 2026.

Huntress independently linked Icarus to the extortion emails by matching Session Messenger identifiers in the ransom notes to identifiers on the Icarus leak site. The extortion emails were sent under the alias "mr bean" and routed through compromised mail servers belonging to Global Retail Brands, an Australian retailer. Huntress reported this activity to the Australian Cyber Security Centre.

On June 21, 2026, ShinyHunters published a Telegram post claiming responsibility for the Klue breach and including a Session Messenger ID attributed to Icarus. Both BleepingComputer and Huntress note there is no confirmed evidence linking Icarus to ShinyHunters. ReliaQuest noted the activity resembles the 2025-2026 third-party OAuth-abuse campaigns attributed to ShinyHunters and UNC6395 (Salesloft Drift, Gainsight), but the Klue attack used a generic Python-urllib user-agent and ordinary data-center hosting rather than the Tor-routed, custom-toolchain tradecraft associated with UNC6395. No nation-state link has been identified.

Attribution to Icarus: high confidence. Any link to ShinyHunters: unconfirmed.

Primary Sources