The Credential Nobody Was Watching
It wasn't a zero-day. It wasn't even clever.
Klue, the competitor intelligence platform that syncs battlecards and win-loss data with Salesforce, discovered anomalous behavior in its integration infrastructure on June 12, 2026. The compromise had actually begun the day before. The root cause? A legacy credential tied to an integration service account that nobody remembered existed.
Here's what makes this incident worth your attention, beyond the usual breach-fatigue: Klue didn't store customer data themselves. Their platform was untouched. The breach happened entirely in the integration layer — through OAuth tokens harvested from a forgotten service account, then used to systematically drain CRM data from dozens of enterprise Salesforce environments.
The attackers didn't need to be geniuses. They just needed to be patient. And in 2026, patience is the most dangerous weapon in an attacker's arsenal.
This is what happens when we treat service accounts like ghosts. We forget they exist. We don't rotate their keys. We don't audit their access. And then we're shocked when they're exploited.
It's like leaving your house keys under the mat and blaming the burglar.
How the Attack Actually Unfolded
ReliaQuest researchers observed a two-phase exfiltration pattern that's worth understanding, because this methodology is going to repeat.
Phase one was slow. Methodical. The attackers authenticated through the compromised Klue integration service accounts, generated OAuth tokens, then deployed automated Python scripts — identifiable by Python-urllib user-agent strings — to systematically drain CRM records via Salesforce's REST API.
For nearly 24 hours, they enumerated the organization's object catalog via GET /services/data/v59.0/sobjects, then ran sustained looped REST API queries, paginating results through the QueryMore cursor in a pattern designed to mimic legitimate integration traffic. Stealth over speed.
Phase two was different. In at least one environment, the attackers sent nearly 1,000 queries within a 15-minute window. A separate incident saw sustained extraction lasting over six hours. Either time pressure or a targeted pivot to high-value records.
The data they took? Account records, contact details — names, emails, phone numbers, job titles — deal outcomes, pricing data, sales communications. No core platform data. No product telemetry. No passwords or payment card info.
But that's still enough for extortion. And that's exactly what happened.
The Victims Who Knew Better
The affected organizations read like a who's-who of cybersecurity firms:
Huntress, HackerOne, Jamf, Recorded Future, Tanium, Gong (internal licensed user data only — no call recordings), OneTrust, Snyk, Sprout Social, Insurity.
Ten companies. All security vendors. All confident in their defenses.
None of them could stop an attack that started outside their perimeter. The attackers didn't infiltrate Huntress. They infiltrated Klue. And Klue? They didn't even know they were a target until it was too late.
Huntress confirmed the attackers sent extortion emails using an Australian company's email server — valid SPF, valid DMARC. They didn't spoof. They hijacked. That's next-level operational security.
And then, because cybercrime has its own ecosystem of predators: on June 24, a second crew hacked the Icarus infrastructure and grabbed the stolen Salesforce data. They launched their own parallel extortion campaign.
Think about that. If you're one of the victims, you're now getting demands from two separate extortionists for the exact same database. You can't trust them to delete the data. Once it leaves your control, it's gone.
Why This Is the New Supply Chain Attack Vector
ReliaQuest noted the attack methodology closely mirrors campaigns attributed to ShinyHunters (June 2025 — voice phishing for malicious connected app auth) and UNC6395 (August 2025 — stole OAuth refresh tokens from Salesloft Drift integration, queried Salesforce across hundreds of orgs).
Key differences matter here. UNC6395 used python-requests, Salesforce-CLI, and Tor infrastructure. This campaign used generic Python-urllib and data-center hosting. No extortion demands or leak-site postings observed from UNC6395 in this case — Icarus did demand ransom.
But the pattern is clear: OAuth-abuse is repeatable, effective, and now widely adopted. ReliaQuest assesses it's highly likely that threat actors will continue targeting Salesforce-connected third-party integrations through the remainder of 2026.
This isn't an anomaly. It's a playbook. And the playbook is getting better.
The Non-Human Identity Problem Nobody's Solving
Here's the structural vulnerability that makes this incident so dangerous: third-party SaaS integrations function as non-human identities with persistent, often broadly scoped API access.
Because they authenticate with valid credentials, they rarely trigger the behavioral alerts associated with user account compromise. A 24-hour automated query loop can run undetected from a "trusted" account.
This is the defining cybersecurity vulnerability of 2026, and it's getting worse as AI agents increasingly rely on OAuth-connected APIs. Every integration you build? Treat it like a human account. Rotate the credentials every 90 days. Monitor the API calls. Require MFA — even for service accounts.
And when you retire a tool? Revoke the key. Not just delete the code.
Because in 2026, the most dangerous thing in your stack isn't the zero-day. It's the credential you forgot about. And someone else didn't.
What Salesforce and Klue Actually Did
Salesforce disabled the Klue Battlecards app connection pending investigation. They confirmed the issue is not a vulnerability within their own platform, but rather a compromise of Klue's integration service account credentials.
Klue revoked affected credentials and tokens, removed unauthorized code, disabled integrations with Salesforce, HubSpot, SharePoint, Zoom, Gong, Chorus, Clari, Google Drive, and Slack App. They engaged CrowdStrike for incident response and notified law enforcement.
CEO Jason Smith called it "a deliberate criminal act." Fair enough. But the response came after the damage was done.
The IOCs ReliaQuest identified — 138.226.246[.]94, 212.86.125[.]24, 213.111.148[.]90, 94.154.32[.]160 — are all IP addresses. No Tor. No proxies. Just clean, direct, public-facing servers.
Why? Because they didn't need to hide. The API calls looked legitimate. The OAuth token was valid. The user-agent was standard.
Until it wasn't.
Hardening Your Integration Posture
ReliaQuest's recommendations are straightforward, even if implementing them requires discipline:
Revoke and rotate all credentials. Including service-account passwords, OAuth refresh tokens, client secrets, and active OAuth grants. Revoking the refresh token, not just the password, is what terminates persistent access.
Audit Salesforce REST API logs. Hunt for unusual query volumes, repeated pagination, Python-urllib user-agents, and access from unknown IP ranges.
Enforce IP allowlisting. Restrict connected app and SIEM/SOAR API access to approved infrastructure only, blocking and alerting on all out-of-scope requests.
The exfiltrated sales communications make the perfect base for hyper-targeted phishing campaigns. Attackers can draft emails referencing actual historical conversations, making them look highly legitimate to your sales staff.
Keep your teams warned. Check your secrets. Automate credential lifecycle monitoring.
We cannot let legacy credentials sit around in our cloud infrastructure. Not anymore.