The Third Salesforce OAuth Breach in Twelve Months: Icarus Hit Klue, Stole Tokens for Everything, and 'Mr Bean' Sent the Extortion Email
- Patrick Duggan
- 8 minutes ago
- 5 min read
We have written about this attack three times now. September 2025 we named it OAuth's Blind Spot and walked through the Salesloft/Drift breach. June 2 we covered how ShinyHunters used TruffleHog to extract OAuth tokens from source code and exfiltrated 1.5 billion records from 760 organizations. June 5 we wrote about the federal takedown of the leak site and noted that closing the site doesn't close the attack class. On June 11, a threat actor called Icarus — operator signs as "mr bean" — demonstrated the point by doing it again, to Klue, and this time Huntress is in the victim list.
The physics of the attack has not changed. The integration hub is the target. OAuth tokens are the key. CRM data is the payload.
The attack chain
Seven steps, five days, three named victims.
1 — Stale credential / A prototype integration credential at Klue was created and never deprovisioned. It still worked on June 11, 2026.
2 — Backend access / The attacker authenticated with the stale credential and gained access to Klue's backend systems.
3 — Token harvester deployed / Malicious code was pushed as a backend update. It collected OAuth tokens for every customer integration Klue had wired: Salesforce, HubSpot, Gong, SharePoint, Zoom, Chorus, Clari, Google Drive, and Slack.
4 — Integration sweep / Every token collected gave the attacker application-scoped access to the connected customer systems — inherited from the original authorization the customer granted Klue.
5 — Data exfiltration / Salesforce data was pulled via the API at version 59.0 using Python-urllib/3.12 and 3.14 user agents. Exfiltrated to Gofile.io as a dead-drop.
6 — Extortion / June 16: Huntress staff received an email with subject "top secret email." Session Messenger ID. Operator signed as "mr bean." This is Icarus announcing a third victim.
7 — Leak site / Three confirmed victims listed. Huntress publicly named. Data on offer.
The entry point was not a zero-day. It was not a phishing campaign. It was a credential that had been created for a prototype integration — a credential that Klue had apparently never deprovisioned when the prototype was abandoned. The attacker authenticated with it on June 11. Klue detected anomalous behavior and unusual network connections the next day. On June 13, Klue disabled integrations across all connected platforms.
Between authentication and detection: 24 hours. In that window, malicious code was pushed to Klue's backend systems. The code collected OAuth tokens — the tokens Klue's customers use to connect the Battlecards product to their own systems. Not one integration. All of them. Salesforce, HubSpot, Gong, SharePoint, Zoom, Chorus, Clari, Google Drive, and Slack were all in scope.
OAuth tokens don't require a password. They don't trigger MFA. They are long-lived credentials that grant application-scoped access to a third party's data on behalf of a user who consented to the integration at setup time. When you authorized Klue to read your Salesforce, you gave Klue a token. When someone stole that token from Klue, they inherited your authorization.
Who Icarus is and what they did next
Icarus self-identifies as active since April 28, 2026 — a new group, not a rebranded prior crew as far as current reporting shows. The operator who handles communications signs as "mr bean." The extortion mechanism is a leak site with victims listed; Huntress was announced as a third victim on June 16 via an email with the subject line "top secret email," which is either an operational security failure or a deliberate provocation.
The infrastructure used for the attack sourced from Netherlands, French, and Ukrainian ISPs across four IP addresses. The exfiltration destination was Gofile.io, an anonymous file sharing service that functions as a dead-drop for stolen data. The attacker queried Salesforce's API directly at version 59.0 using Python-urllib user agents — 3.12 and 3.14 — against the query endpoint.
Icarus has at least two prior victims on their site before Huntress. The data stolen from Huntress specifically was described as business contacts, price quotes, and sales-related data and messaging from their Salesforce and Gong instances — the kind of data that gives a competitor or a targeted attacker a complete picture of pipeline, pricing floors, and deal strategy.
The IOCs
We indexed all four Icarus infrastructure IPs this morning — none were in our corpus before today. They are now at confidence 85 and flowing into the edge shield:
[138.226.246.94](https://analytics.dugganusa.com/stix/register?ref=ioc-click&q=138.226.246.94) — Netherlands, primary attack infrastructure
[212.86.125.24](https://analytics.dugganusa.com/stix/register?ref=ioc-click&q=212.86.125.24) — France, exfiltration
[213.111.148.90](https://analytics.dugganusa.com/stix/register?ref=ioc-click&q=213.111.148.90) — Ukraine ISP, attack infrastructure
[94.154.32.160](https://analytics.dugganusa.com/stix/register?ref=ioc-click&q=94.154.32.160) — attack infrastructure, June 11
If you run a SOC and you see Python-urllib/3.12 or Python-urllib/3.14 user agents hitting your Salesforce API at /services/data/v59.0/query/, that is the hunting string. Normal Salesforce integrations do not present Python-urllib as a user agent. Production OAuth clients present their own application identifiers.
The third time and what it means
The Salesloft breach used TruffleHog to pull tokens from source code. The Klue breach used a stale credential to deploy a token harvester server-side. The attack surface is different; the outcome is identical — OAuth tokens in the hands of an actor who can use them to move through every integration as if they were the authorized user.
The pattern across all three incidents is the same two failures. First: credentials and tokens accumulate without lifecycle management. The prototype integration credential that gave Icarus entry to Klue existed because nobody turned it off when the prototype was abandoned. The tokens Salesloft issued existed in source code because nobody rotated them out of that repository. Long-lived credentials in forgotten places are the attack surface. Second: integrations are trusted by virtue of having been authorized once, without ongoing verification that the authorization is still appropriate.
The defensive posture that addresses both failures is token lifecycle management that treats OAuth grants as expiring resources rather than permanent entitlements. Audit which integrations have access to your Salesforce. Revoke the ones you do not use. Set short expiry on the ones you do. Run queries against your API access logs for unusual user agents and unusual query patterns. The Salesforce API logs who is asking; the question is whether you are reading them.
Salesforce has disabled the Klue Battlecards integration while the investigation continues. If you were a Klue customer who had authorized that integration, assume your token was collected and assume any data accessible through your Salesforce OAuth grant was exfiltrated. Rotate accordingly and review your Salesforce audit logs for the June 11 through June 13 window.
We are at 95 percent certainty on the above — one breach, specific actor, specific mechanism, named victims including a named security company. The 5 percent is the extent of the victim list, which is almost certainly larger than three.
The threat feed this post is built on
1.14M+ IOCs, STIX 2.1, precursor signals, supply-chain detection. Free API key in 30 seconds.