Disclosure: ReliaQuest disclosed findings to Klue prior to publication.

Editor's Note: This report was authored by Thassanai McCabe and Alexa Feminella

Key Points

• A compromised Klue Battlecards integration was used to exfiltrate Salesforce CRM data using OAuth tokens and automated REST API queries.

• The activity resembles the 2025 and 2026 third-party OAuth-abuse campaigns against Salesforce, but attribution is currently unknown.

• Defenders should revoke and rotate the credentials and OAuth tokens (refresh tokens included) for Salesforce-connected integrations, and restrict their API access, along with SIEM and SOAR API access, to known allowlisted infrastructure.

In June 2026, ReliaQuest observed a compromised integration for Klue, a competitive-intelligence platform that syncs battlecard and win/loss data with Salesforce, being used to exfiltrate customer relationship management (CRM) data from enterprise environments. The activity follows the same third-party OAuth-abuse playbook behind the Salesloft Drift and Gainsight compromises that rattled Salesforce ecosystems throughout 2025 and 2026, reinforcing that trusted software-as-a-service (SaaS) integrations remain a high-value yet little-monitored route to reach sensitive data.

The attacker authenticated to targets’ Klue integration service accounts, generated OAuth tokens, and ran what appear to be automated scripts to pull large volumes of CRM records through the Salesforce REST API over roughly 24 hours, including a concentrated burst of nearly a thousand queries in 15 minutes and sustained extraction windows lasting over 6 hours.

Prior attacks against Salesforce, Salesloft Drift, and Gainsight have been attributed to threat groups “ShinyHunters” and “UNC6395,” but at the time of writing there is no evidence to confirm or rule out their involvement here. The attacker used Klue’s integration as an entry point to reach the target’s Salesforce environment. The CRM data accessible through that integration, which could range from account records and contact details to deal outcomes and pricing, depends entirely on how the integration was scoped. And while the platform serves a widespread integration footprint, it remains comparatively niche.

Exfiltration is confirmed; the full scope, initial access vector, and intent of the incidents are still being established. Organizations using Klue or similar Salesforce-connected integrations should revoke and rotate the integration's credentials and OAuth tokens, hunt Salesforce API logs for unusual query volume, and restrict both integration and SIEM API access to known infrastructure. More broadly, any third-party app with OAuth access to a core platform like Salesforce is part of your attack surface and should be inventoried, monitored, and scoped to least privilege accordingly.

Read on for:

• A breakdown of our observations so far, including API calls and automated Python scripts.

• How the activity compares to the 2025 and 2026 Salesforce campaigns, and who might be behind it.

• What details are still unclear about the attacks and the three actions to take now.

A Compromised Integration and a Data Harvest

In the attacks we observed, the adversary first authenticated through a compromised Klue integration service account, generated OAuth tokens, and ran automated Python scripts (identifiable by Python-urllib user-agent strings). These scripts first enumerated the org's object catalog via GET /services/data/v59.0/sobjects, then looped REST API queries against the Salesforce query endpoint (/services/data/v59.0/query) and paginated results via the QueryMore cursor for almost 24 hours. The volume and pacing point to bulk data retrieval, not routine integration traffic—a legitimate integration’s own credentials were used to quietly siphon CRM records at scale through a door that was already open.

The attacker then hit the same endpoint, sending almost a thousand queries in a 15-minute window in at least one environment. Where the first stage was a slow, steady pull designed to blend in, this burst traded stealth for speed, suggesting either time pressure or a shift to targeted records. In another case, the exfiltration was observed over 6 hours.

How This Fits the Broader Salesforce OAuth-Abuse Wave

The data theft follows a pattern that defined Salesforce attacks throughout 2025 and 2026. In June 2025, ShinyHunters drove much of the activity relating to Salesforce; the group was observed using voice phishing to trick employees into authorizing a malicious connected app before bulk-extracting Salesforce data for extortion. In August 2025, the cluster tracked as UNC6395 stole OAuth refresh tokens from the Salesloft Drift integration and used them to query Salesforce and exfiltrate data across hundreds of organizations, the closest analog to the harvest observed here.

The common thread is the abuse of OAuth tokens or credentials from a trusted third-party vendor. These integrations are non-human identities with persistent, often broad access to sensitive data, yet they are typically monitored far less closely than employee accounts. That gap is why a 24-hour automated query loop could run from a "trusted" integration account without tripping the usual alarms.

Is This ShinyHunters, UNC6395, or Something Entirely Different?

The objective and overall approach, bulk theft of CRM data by abusing a trusted third-party integration's OAuth tokens, mirror ShinyHunters’ defining campaigns, and the use of scripted Python tooling and dispersed hosting fits the group’s general pattern.

However, there is currently not enough evidence to attribute this activity to ShinyHunters or to rule the group out. ShinyHunters has historically used a range of initial-access methods, from voice phishing to exploiting vulnerabilities, and is known to delegate initial access to other actors before handling the extortion phase itself.

The closest public analog, Salesloft Drift token abuse, is believed to be conducted by UNC6395, a separate cluster. The tooling also differs: UNC6395 activity used user-agents such as python-requests, Salesforce-CLI, and Salesforce-Multi-Org-Fetcher, frequently routed through Tor, while this activity used a generic Python-urllib user-agent and data-center hosting. No extortion demand or leak-site posting has been observed to date.

On balance, it is realistically possible this is ShinyHunters or an actor in the same ecosystem, but the evidence is equally consistent with a more targeted operator that has adopted the now-widespread Salesforce OAuth-abuse technique for a different purpose entirely.

Step Up Your Defenses Against SaaS Integration Abuse

ReliaQuest Approach

GreyMatter Agentic AI connects what would otherwise look like isolated, low-fidelity events into a single intrusion narrative, faster than any human analyst could. In this case, an OAuth token refresh from an integration service account, a sustained spike in Salesforce REST API queries, and a shift from slow extraction to a concentrated burst of nearly a thousand queries in 15 minutes all happened within a narrow window. Individually, each event might look like noisy integration traffic or a misconfigured API call. Together, they reveal the full attack chain. As attackers increasingly operate through legitimate SaaS credentials rather than malware, the ability to correlate API-layer activity at machine speed is what separates early detection from a post-breach notification.

GreyMatter Transit detects anomalous API activity in real time as it crosses the network, without relying on endpoint telemetry. In an intrusion like this, where the entire kill chain lives in OAuth tokens and REST API calls, Transit provides visibility at the layer where the attack actually happens.

ReliaQuest Detection Rules are continuously updated using the latest relevant threat intelligence, including rules targeting anomalous Salesforce API query patterns from integration service accounts and unauthorized access to SIEM and SOAR endpoints.

GreyMatter Automated Response Playbooks address the specific challenge this activity exposed: the attacker was using valid credentials through a trusted integration, so there was no malicious process to kill and no malware to quarantine. For organizations that have these playbooks deployed and configured to trigger on anomalous integration activity, automated containment at the identity and API layer removes the window attackers depend on.

• Terminate Sessions and Reset Passwords: Immediately revokes active OAuth tokens and forces credential resets on compromised integration service accounts. In this intrusion, revoking the Klue service account's tokens would have killed the attacker's API access mid-harvest.

• Disable User: Disables the compromised integration service account entirely, blocking all further API access. This matters when automated query patterns or SIEM probing are detected, because the attacker will otherwise continue to authenticate with valid credentials until the tokens expire.

For faster containment, these Playbooks can be configured to execute automatically upon detection, removing the manual approval step and reducing response time to seconds.

Your Action Plan

These steps directly address the gaps these incidents exploited.

• Revoke and rotate credentials and tokens. Reset and reissue everything tied to the Klue integration, including the service-account password, refresh tokens, client secrets, and active OAuth grants. Revoking the refresh token, not just resetting a password, is what severs persistent access.

• Review Salesforce API activity. Hunt for unusual REST API query volume, repeated pagination through large result sets, the Python-urllib user-agent, and access from unfamiliar IP addresses.

• Lock down API access to known infrastructure. Enforce IP allowlisting on third-party integration accounts and connected apps and apply the same restriction to SIEM and SOAR APIs so requests from outside approved sources are blocked and alerted.

Key Takeaways and What's Next

Trusted third-party integrations are among the least-watched paths to an organization's most sensitive data. In this case, a single set of stolen OAuth artifacts gave the attacker hours of bulk access to CRM records from an account that, because it was "trusted," drew little scrutiny. Organizations should treat connected-app identities, their tokens, and their egress with the same rigor they apply to privileged user accounts.

What We Still Don't Know

As the investigation is ongoing, several questions remain open:

• Exfiltration is confirmed, but the specific Salesforce objects and record counts are still being quantified.

• The initial access vector is unresolved: whether the Klue service account and OAuth tokens were stolen on the vendor side, exposed through the target environment, or obtained another way.

• The attacker's end goal remains unclear. No extortion demand or follow-on activity has surfaced, and whether the SIEM probing was a prelude to a return is unknown.

We are also still investigating reporting that the attacker queried one environment's own detection tooling. ReliaQuest has not independently verified this activity, though the source IP address belongs to the same virtual private server provider used in the confirmed Salesforce exfiltration, which suggests a possible connection. The query itself may reflect broad API enumeration rather than a deliberate attempt to evade detection, consistent with an attacker working quickly to discover and extract whatever is reachable.

Looking Ahead

We assess it is highly likely that threat actors will continue targeting third-party Salesforce-connected integrations through the rest of 2026. The OAuth-abuse playbook is repeatable, effective, and now widely adopted. For this case specifically, follow-on extortion or a return to the environment cannot be ruled out, and ReliaQuest will update this spotlight as the investigation develops.

IOCs