Klue breach exposes Salesforce CRM data through stolen OAuth tokens

Attackers used a compromised Klue integration to access Salesforce CRM data from multiple organizations, turning a trusted SaaS connection into a data theft channel. The incident prompted Salesforce to disable the Klue Battlecards app connection while the investigation continues.

The issue did not stem from a Salesforce platform vulnerability. Instead, researchers at ReliaQuest said attackers abused Klue-related integration access, generated OAuth tokens, and used automated REST API queries to extract CRM records.

Klue Battlecards is a competitive intelligence tool that connects with Salesforce to surface battlecards, win-loss notes, and sales context inside CRM workflows. That trusted connection gave attackers a path into data that could include accounts, contacts, deal records, pricing details, and competitive notes, depending on how each customer scoped permissions.

What happened in the Klue Salesforce incident?

Huntress, one of the affected Klue customers, said the incident began after attackers gained access to Klue backend systems through a long-disused credential tied to an abandoned integration prototype. The attackers then pushed code designed to collect OAuth tokens used by Klue customers to connect with third-party platforms.

Those tokens gave the attackers access to connected services, including Salesforce. BleepingComputer reported that multiple organizations had Salesforce data stolen and linked the activity to an extortion group known as Icarus.

Salesforce responded by cutting off the Klue Battlecards connection. The company said the unusual activity may have allowed unauthorized access to a subset of customer data through the app’s connection to Salesforce.

Item	Confirmed detail
Initial access	Klue-side integration infrastructure was compromised
Access method	OAuth tokens and connected app access
Data target	Salesforce CRM records from connected customer environments
Salesforce status	Klue Battlecards connection disabled while the incident is investigated
Attribution	ReliaQuest remains cautious; Huntress links the activity to Icarus

How attackers pulled Salesforce data

ReliaQuest observed attackers using automated Python scripts with Python-urllib user-agent strings. The activity started with Salesforce object enumeration through the REST API before moving into repeated query activity.

The attack followed a pattern familiar to cloud and SaaS defenders. First, the attackers mapped available Salesforce objects. Then they used query endpoints and pagination to pull data over long periods, which can look like normal integration traffic unless API activity is closely monitored.

In at least one environment, the attackers sent nearly 1,000 queries in 15 minutes. Another case involved extraction over more than six hours. ReliaQuest said the activity showed both slow collection and faster burst extraction.

Why OAuth tokens make this dangerous

OAuth tokens are designed to let apps connect without repeatedly asking users for passwords. That makes SaaS platforms easier to integrate, but it also means a stolen token can act like a standing key to sensitive business data.

In this case, attackers did not need to break into Salesforce directly. They abused an already trusted connection. That distinction matters because many security teams monitor employee logins more closely than non-human identities, service accounts, and connected apps.

Salesforce connected apps can support OAuth policies, IP restrictions, token controls, and permission scoping. Organizations that use many SaaS integrations need to review those settings regularly, especially for tools with access to CRM records.

• OAuth tokens can remain useful even after a password reset if refresh tokens are not revoked.
• Connected apps often have broad access because teams configure them for convenience.
• Service accounts may not trigger the same alerts as normal user accounts.
• High-volume API calls can blend into expected integration behavior.

Huntress says its Salesforce data was stolen

Huntress said copied data from its Salesforce account included business contacts, price quotes, sales-related data, and messaging. It said threat data, passwords, payment card information, engineering data, agent telemetry, and product infrastructure were not affected.

The company also said attackers sent extortion emails to current and former staff. Huntress later updated its post to say Klue had appeared on the Icarus leak site, although no download link was available at that time.

This update changes the risk picture. Early technical analysis treated attribution as unresolved and said no extortion had been observed. Later victim reporting points to extortion activity and stronger evidence connecting Icarus to the campaign.

How this compares with earlier Salesforce OAuth abuse

The Klue incident fits a wider pattern of attacks against Salesforce-connected SaaS integrations. Rather than exploiting Salesforce itself, attackers target trusted apps and tokens that already have permission to read customer data.

BleepingComputer compared the incident with earlier Salesforce data theft campaigns involving third-party integrations. ReliaQuest also said the method resembles earlier OAuth-abuse activity, but it did not confirm ShinyHunters or UNC6395 attribution.

The lesson for defenders is clear. A CRM can be secure as a platform while still leaking data through a trusted app connection if that app, its service accounts, or its tokens become compromised.

Risk area	Why it matters	What to check
OAuth refresh tokens	They can preserve access after passwords change	Revoke and reissue tokens for affected integrations
Connected app permissions	Broad scopes increase data exposure	Apply least privilege and remove unused scopes
API query volume	Bulk theft can look like integration activity	Hunt for spikes, pagination, and unfamiliar user agents
Service accounts	They often receive less scrutiny than employees	Monitor them as privileged identities

What affected organizations should do now

Organizations that use Klue, or any Salesforce-connected integration, should start with token revocation. Resetting a password alone may not stop access if refresh tokens or active OAuth grants remain valid.

Security teams should also review Salesforce API logs for unusual query patterns. Useful signals include Python-urllib user agents, unfamiliar IP addresses, repeated pagination, sudden query spikes, and access from data-center networks that do not match normal vendor infrastructure.

Administrators should also inspect connected app settings and confirm whether each integration still needs its assigned permissions.

• Revoke OAuth grants for affected or unnecessary Klue connections.
• Rotate service-account passwords, client secrets, and API credentials.
• Invalidate active sessions for affected services where possible.
• Audit Salesforce REST API logs for abnormal query volume.
• Review user agents, source IPs, and repeated QueryMore-style pagination.
• Restrict connected app access to approved IP ranges.
• Remove stale integrations and long-unused service credentials.
• Check inboxes and spam folders for extortion messages related to the incident.

Known indicators tied to the Klue compromise

Huntress said Klue’s notification included a non-exhaustive list of IP addresses linked to attacker access. These should be treated as leads for investigation, not as the full scope of activity.

Indicator	Type
138.226.246[.]94	IP address
212.86.125[.]24	IP address
213.111.148[.]90	IP address
94.154.32[.]160	IP address

Teams should search for these indicators across Salesforce, Klue, SIEM, SOAR, identity provider, proxy, and email logs. They should also look for nearby activity from the same hosting providers, because attackers may rotate infrastructure after public reporting.

Why Salesforce customers should review all integrations

The immediate incident centers on Klue, but the broader issue applies to any SaaS tool with access to sensitive CRM data. Sales, marketing, support, analytics, and AI tools can all become downstream paths into Salesforce if they hold durable OAuth access.

The Salesforce status notice makes clear that the company disabled the app connection to protect customers while it works with Klue and affected organizations. That action limits the specific connection, but it does not remove similar risks in other integrations.

Klue’s own Salesforce integration page shows how deeply competitive intelligence workflows can connect with CRM data, including battlecards, win-loss notes, competitor insights, and revenue impact reporting. Those business benefits also explain why attackers value these integrations.

The bottom line

The Klue incident shows that attackers no longer need to compromise the main CRM platform to steal CRM data. A trusted integration can offer the same practical access if its tokens, service accounts, or backend systems become exposed.

For security teams, OAuth governance now needs the same urgency as password security and MFA. Every connected app should have an owner, a reason to exist, limited permissions, monitored API behavior, and a clean removal path when no longer needed.

Klue’s Salesforce integration was built to help sales teams work faster. The breach shows why speed and integration need stronger guardrails when customer data, pricing, and deal intelligence move across cloud platforms.

FAQ