Somewhere in Klue’s infrastructure sits a credential nobody remembered to delete. It was created years ago for a prototype integration that never shipped, the kind of leftover access every SaaS company accumulates and nobody audits until it’s too late. On June 11, 2026, a threat actor calling itself Icarus found that credential, walked in through it, and within days had pulled CRM data out of the Salesforce instances of at least seven named cybersecurity vendors, including Huntress and Recorded Future, two companies whose entire business is telling other people how not to get breached.
I’ve covered three of these OAuth-token supply chain attacks now since Salesloft Drift blew up in August 2025. Each one follows the same blueprint with small variations in tradecraft, and each one proves the same point that nobody in the industry seems willing to act on: a connected app with a stale credential sitting behind your CRM is a bigger attack surface than most of your employee accounts, and almost nobody monitors it like one.
Here’s everything I’ve been able to piece together about how this one actually worked, who’s behind it, and what the API logs show.
What Klue is and why it had this much access
Klue is a competitive intelligence platform. Sales and marketing teams use it to build battlecards, win-loss reports, and competitor tracking dashboards, which means it needs deep read access into a company’s CRM to function. The Klue Battlecards app integrates with Salesforce, HubSpot, SharePoint, Zoom, Gong, Chorus, Clari, Google Drive, and Slack, syncing account records, deal data, contact information, and call transcripts back and forth.
That breadth is exactly why compromising Klue was worth the attacker’s time. One integration vendor, one set of stolen OAuth tokens, and you’ve got a pivot point into dozens of organizations’ CRM environments simultaneously. This is the supply chain math that keeps showing up: attackers don’t need to breach the target, they need to breach something the target trusts and gave a connected-app grant to.
The timeline, with the technical detail filled in
June 11. The attacker authenticated using a long-dormant credential tied to an abandoned Klue prototype integration. Huntress later confirmed this detail directly: the credential was originally created for a third-party integration project Klue started and never finished, then never revoked. This is initial access via a forgotten service account, not a zero-day, not a phishing email, not a vulnerability in Salesforce itself. The attacker used that access to connect remotely to Klue’s backend servers and execute commands, then pushed a malicious code update into production. That update was built specifically to intercept and harvest OAuth tokens as customers’ Klue integrations authenticated, meaning the attacker didn’t need to steal each token individually. They positioned themselves at the point where tokens are minted and let the platform hand them over.
June 12. Klue’s team noticed anomalous network connections tied to the IP addresses the attacker was using and began investigating. Klue says there’s currently no evidence that data stored natively inside the Klue platform itself was touched. The compromise was scoped to the integration layer.
June 13. Klue revoked OAuth credentials platform-wide and disabled the Salesforce, HubSpot, SharePoint, Zoom, Gong, Chorus, Clari, Google Drive, and Slack integrations while they investigated. Customers got a general notice that didn’t specify who was affected.
June 16. Extortion emails landed in inboxes at Huntress with the subject line “top secret email,” warning recipients their data had been downloaded and giving them 48 hours to make contact. Thirty-eight minutes later, the same recipients got a follow-up from the same sender: “wrong session lol,” with a corrected Session Messenger ID. Both messages were signed by someone calling themselves “mr bean.”
June 17. Salesforce suspended the Klue Battlecards connected app entirely, stating it had detected unusual activity that may have resulted in unauthorized access to customer data through the app’s Salesforce connection.
June 18. Huntress and Recorded Future went public with confirmation that their own Salesforce environments were affected. Tanium, Jamf, Sprout Social, Gong, and Insurity followed with their own disclosures. Klue’s CEO, Jason Smith, published a statement attributing initial access to “a compromised legacy credential associated with an integration service” and confirming the company had engaged CrowdStrike for incident response and notified law enforcement.
June 19, 9:45 AM ET. Icarus formally added Klue to its leak site as a named victim, rather than just referencing the breach in extortion emails. No download link was attached, and the listed data size was a placeholder value of “-1GB.” The post pressured Klue directly to negotiate and invited any of the downstream companies whose Salesforce data was caught up in the breach to reach out over Session independently if Klue didn’t cooperate, with a verification step requiring a contact to supply a specific field value pulled from a row in their own Salesforce instance, presumably to prove they actually had standing access to the stolen dataset and weren’t just a researcher fishing for confirmation.
June 19, 4:10 PM ET. Huntress published a follow-up update narrowing down exactly which data fields were exposed in its own environment, working alongside its DFIR team. The company also reiterated, for a second time, that no Huntress product, infrastructure, telemetry, password, or payment card data was touched.
June 19, evening. The Icarus group publicly claimed the attack on its leak site in broader terms, beyond the Klue-specific listing, and Recorded Future, Tanium, and Jamf each confirmed their own impact in official statements.
How the data left the building: the API layer
This is the part most coverage glossed over, and it’s the part that matters most if you’re trying to hunt for this in your own logs.
Once the attacker had valid OAuth tokens for a given customer’s Klue-Salesforce connection, they didn’t need malware, they didn’t need to touch an endpoint, and they didn’t need to bypass MFA, because the token itself already represented an authenticated, authorized session. ReliaQuest’s technical writeup lays out the query pattern in detail. The attacker’s scripts first hit GET /services/data/v59.0/sobjects to enumerate the target org’s full object catalog, essentially asking Salesforce “what data structures exist here and what can I read.” From there they looped requests against /services/data/v59.0/query, paginating through large result sets using Salesforce’s QueryMore cursor mechanism, which lets an API client walk through a result set in batches rather than pulling everything in one call.
The pacing tells you something about intent. In most environments, ReliaQuest observed a slow, sustained pull running for roughly 24 hours, the kind of low-and-slow query volume designed to look like ordinary integration traffic rather than a smash-and-grab. But in at least one environment, the same endpoint took nearly a thousand queries in a 15-minute window. That’s not a sync job. That’s either a deadline the attacker was working against or a pivot to a specific, high-value set of records once they’d mapped the org structure. A separate exfiltration window ran for over six hours straight.
On the fingerprinting side, Huntress’s own log review found that almost all of the malicious requests to Salesforce hit /services/data/v59.0/query/<STRING> and carried a numeric user-agent value of “5238” or no user-agent at all, with one notable exception: nearly 900 of the queries carried Python HTTP library signatures, specifically Python-urllib/3.12 for 811 of them and Python-urllib/3.14 for 58. That’s automated tooling, almost certainly a Python script wrapping urllib to hit the REST API on a loop, not a person clicking through Salesforce’s UI.
ReliaQuest’s IOC list for the IP infrastructure behind the queries:
- 138.226.246[.]94
- 212.86.125[.]24
- 213.111.148[.]90
- 94.154.32[.]160
Huntress traced these to ISPs in the Netherlands, France, and Ukraine, all consistent with rented VPS infrastructure rather than residential proxies or Tor exit nodes. Only one of the four, 138.226.246[.]94, had any prior reputation hit, tied to a spam campaign back in March 2026. The other three were clean before this. That’s a meaningful operational security choice: burner infrastructure with no prior footprint is harder to flag on reputation alone, which is exactly why log-based detection (query volume, pagination patterns, user-agent strings) matters more here than IOC blocklists.
Why attribution is messier than the headlines suggest
A lot of outlets jumped straight to calling this a ShinyHunters or UNC6395 operation because the playbook, OAuth token theft from a trusted SaaS integration followed by bulk CRM extraction and extortion, matches what those groups have run against Salesforce, Salesloft Drift, and Gainsight throughout 2025 and into 2026. The instinct is reasonable. The forensics don’t fully support it.
UNC6395, the cluster behind the Salesloft Drift token theft, used a distinct toolchain: user-agent strings including python-requests, Salesforce-CLI, and a custom Salesforce-Multi-Org-Fetcher string, with traffic frequently routed through Tor. The Klue activity used a generic Python-urllib signature and ordinary data-center hosting instead of anonymizing infrastructure. ShinyHunters’ defining move has historically been voice phishing employees into authorizing a malicious connected app, which isn’t what happened here at all. This compromise started with a stolen legacy service credential on the vendor side, not social engineering against a customer’s employee.
What actually nails this to a specific actor is the extortion correlation Huntress ran down. The initial “top secret email” pointed recipients to a Session Messenger ID. That ID matched one listed on the leak site of a group calling itself Icarus, active since April 28, 2026, which at the time had two victim entries: one from early May with data already (briefly) hosted on the file-sharing site gofile[.]io, since taken down, and a second “pending” entry posted June 16 whose description specifically referenced stolen Salesforce data. When that second entry first went live, it displayed the same Session ID from the initial extortion email. After the “wrong session lol” correction email went out, the leak site’s listed ID changed to match it. That’s two independent threads, internal Huntress email logs and Icarus’s own public leak site, converging on the same identifiers at the same time. That’s about as solid as attribution gets without a confession.
One more detail worth flagging because it’s genuinely unusual: the extortion emails were sent from infrastructure belonging to three Australian retail subsidiaries, house.com.au, robinskitchen.com.au, and baccarat.com.au, all under the same parent company. Huntress confirmed the message headers had valid SPF and DMARC alignment, meaning these weren’t spoofed sender addresses, the mail genuinely originated from those companies’ real mail servers. Icarus appears to have compromised that retailer’s email infrastructure and is using it as a relay for extortion campaigns against unrelated victims, which is its own small supply chain story sitting inside this bigger one.
Icarus’s leak site rhetoric is worth a mention too, mostly because it tells you what kind of operation this is. The May victim got a follow-up note reading “shawty sorry for leaking ur data. dm to resolve,” and the most recent post on their site, dated June 12, reads “get ready; big corps getting listed. be ready.” This isn’t a state-sponsored intrusion team. It’s a young, casual, English-fluent extortion crew that emerged within the last two months and picked up a proven OAuth-abuse technique that’s been circulating in the cybercrime ecosystem since at least mid-2025.
Klue goes up on the leak site, and the extortion framing shifts
On the morning of June 19, Icarus moved past private extortion emails and formally listed Klue on its dark web leak site as a named casualty. There’s no download link attached to the entry, and the data volume field reads “-1GB,” a placeholder that’s either a deliberate troll or just sloppy site tooling, it’s hard to tell which with a group this new.
The framing in the listing is worth paying attention to, because it tells you where the pressure is actually aimed. Icarus describes the stolen records as “data borrowed, not stolen,” language clearly built to soften the extortion ask and nudge Klue toward a quiet resolution rather than a public fight. The post pushes Klue specifically to negotiate “for a swift resolution,” and separately invites any of the downstream companies whose Salesforce data got swept up in the breach to contact Icarus directly over Session if Klue doesn’t cooperate. That’s a pressure tactic aimed at two targets at once: squeeze the vendor, and dangle a side channel to its customers as leverage if the vendor doesn’t pay.
There’s also a verification gate built into the offer. Anyone claiming to represent an affected company has to supply a specific field value pulled from a row in their own Salesforce data before Icarus will engage, which functions as rough proof that the requester actually holds (or had) access to the stolen dataset, not just someone fishing for confirmation that their org was hit. It’s a small operational detail, but it’s the kind of thing that separates an opportunistic script-kiddie operation from a crew that’s thought through how its extortion funnel needs to work at scale across potentially dozens of downstream victims simultaneously.
As of this writing, Klue is the only named entry tied to this specific incident on the leak site. Huntress has noted it remains unclear whether the individual downstream companies, Huntress included, will get their own separate listings later if negotiations with Klue don’t go the way Icarus wants.
Who’s confirmed affected, and what was actually taken
The publicly disclosed victim list as of this writing includes Huntress, Recorded Future, Tanium, Jamf, Sprout Social, Gong, and Insurity. Huntress has explicitly noted that several other cybersecurity firms use Klue and have not disclosed impact, so this list is almost certainly a floor, not a ceiling.
Huntress’s June 19 update gave the most granular breakdown of exposed fields published by any victim so far, and it’s a useful reference point for what “CRM data” actually means in practice during one of these incidents. For Huntress specifically, the exposed data spans business names, the products a given account had trialed or was actively using, subscription details including unit counts and pricing, business contact information (full names, work email addresses, job titles, phone numbers, and business addresses), marketing and sales communication threads, and opportunity notes, which are the free-text fields sales reps use internally to track deal context and next steps. None of that is data Huntress’s security product collects or generates; it’s all standard CRM and sales-ops content that happens to live in the same Salesforce org as everything else.
Across the other disclosures, the pattern holds: business contact records, sales communications, price quotes, deal and pipeline data, and in some cases competitive intelligence reports generated by Klue itself. Every company that’s spoken publicly so far has been explicit that no threat intelligence, no customer credentials, no payment card data, and no telemetry from their actual security products was exposed, because none of that lives in Salesforce. That distinction matters a lot for risk assessment. A CRM breach at a security vendor is embarrassing and creates real phishing risk for the contacts exposed, but it’s a categorically different incident than a breach of the vendor’s actual detection or response infrastructure.
The detection-and-response playbook, if you ran Klue integrations
If your org connected Klue to Salesforce, HubSpot, or any of the other affected platforms, here’s the technically grounded response sequence based on what both ReliaQuest and Huntress recommend, with the reasoning behind each step.
Revoke refresh tokens, not just passwords. OAuth access tokens are short-lived, but refresh tokens are what let an integration silently mint new access tokens indefinitely. Resetting a service account password does nothing if the attacker still holds a valid refresh token, because the refresh flow doesn’t require the password at all. You need to explicitly revoke the OAuth grant and refresh tokens tied to the Klue connected app in your Salesforce setup under Connected Apps OAuth Usage, and do the same for any other affected integration.
Hunt your Salesforce Event Monitoring and API logs directly. Look specifically for: requests to /services/data/vXX.X/sobjects followed by sustained query loops against /services/data/vXX.X/query; pagination via QueryMore cursors pulling unusually large result sets; user-agent strings matching Python-urllib or anomalous numeric values; and query volume spikes, especially anything resembling hundreds of calls inside a 15-minute window. Cross-reference any hits against the four IOC IPs above, keeping in mind the attacker’s infrastructure had a low prior reputation footprint, so IP reputation alone will miss this. Pull Salesforce LoginHistory and API Total Usage reports for the relevant window and look for sessions tied to the Klue integration user that don’t match its normal sync cadence.
Treat this as a non-human identity incident, not just a vendor breach notice. The structural problem here is that connected-app service accounts and integration users routinely hold broad, persistent CRM access and get almost none of the monitoring rigor applied to human employee accounts. No MFA prompt, no anomaly detection tuned to their behavior, no access review cadence. If you’re auditing this incident, also audit every other third-party connected app with standing OAuth access to your CRM, because the lesson of Salesloft Drift, Gainsight, and now Klue is that this exact technique is now a standard, repeatable cybercrime playbook, not a one-off.
Enforce IP allowlisting on integration accounts going forward. Both ReliaQuest and Klue’s own postmortem point to this as the most effective structural fix. If a connected app’s service account can only authenticate from known infrastructure, a stolen token from anywhere else simply fails at the network layer regardless of whether it’s cryptographically valid.
Check your inbox and spam folder for the Icarus extortion pattern. Subject lines referencing “top secret,” urgency framing around a 48-hour countdown, and a pivot to Session Messenger for “negotiation.” Don’t engage. Preserve the message for forensic purposes and route it to your incident response team.
Mapped to MITRE ATT&CK, this incident sits cleanly across T1199 (Trusted Relationship) for the initial vendor compromise, T1528 (Steal Application Access Token) for the OAuth harvesting itself, T1078.004 (Valid Accounts: Cloud Accounts) for the subsequent Salesforce access, and T1567 (Exfiltration Over Web Service) for the bulk REST API pulls. None of these techniques are exotic. What’s notable is how reliably they’re working against an entire category of trusted SaaS integrations that most security teams still don’t treat as part of their actual attack surface.
The open questions
Klue still hasn’t said publicly how that dormant prototype credential ended up in attacker hands in the first place, whether it was exposed through a code leak, found through credential stuffing against an old, weakly protected account, or sold by an initial access broker who’d had it sitting in inventory. ReliaQuest also flagged that they’re still chasing down a report that the attacker queried at least one victim’s own security detection tooling during the intrusion, which would suggest either broad opportunistic API enumeration or a more deliberate attempt to check what was watching them. Neither firm has confirmed extortion payment activity yet, and with the Klue entry on Icarus’s leak site still carrying no working download link and a placeholder “-1GB” size field, it’s genuinely unclear whether Icarus is sitting on a fully packaged dataset ready to publish or is still bluffing its way through negotiation while assembling one. Whether the individual downstream victims get their own separate leak-site entries if Klue doesn’t pay is also still an open question.
What’s not in question is the pattern. Three major OAuth-token supply chain incidents against Salesforce-connected platforms in under a year, three different threat actor clusters, the same underlying weakness every time: a third-party integration holding standing, lightly monitored access to your most sensitive customer data. Klue won’t be the last vendor this happens to. It’s just the most recent one to get caught.
