Technical Analysis of the Klue Attack: OAuth Abuse, Stale Integrations, and Salesforce Exfiltration

On June 17, 2026, Reliaquest reported that the Salesforce integration for competitive intelligence platform Klue had been used to steal data from a still-unknown number of victim organizations.

The attack follows an increasingly common SaaS supply chain pattern: compromise a trusted third-party integration, then use that access to exfiltrate data from crown-jewel SaaS applications such as Salesforce. While early speculation pointed to ShinyHunters, multiple sources, including Huntress, which was itself affected by the campaign, have attributed the activity to a newly formed criminal gang known as Icarus.

The incident is another reminder that supply chain attacks are becoming one of the fastest ways for threat actors to amplify impact. Instead of targeting one organization at a time, attackers are increasingly targeting the identities, integrations, and OAuth grants that connect vendors to their customers’ most sensitive SaaS environments. Prior Obsidian research has shown that attackers can multiply their impact through this method compared with targeting individual organizations directly.

This is the OAuth risk at the core of every third-party integration in your environment. OAuth tokens allow applications to maintain access to SaaS data without repeatedly asking users to re-authenticate. That makes integrations seamless for the business, but it also creates a powerful attack surface when tokens are over-permissioned, long-lived, poorly monitored, or compromised.

The result is a large, under-monitored attack surface that is highly attractive to attackers. The Klue breach is the latest example.

‍

How Klue Was Breached

While there was initially some mixed reporting on the exact initial access method leading to the theft of customer OAuth tokens, a statement from Klue’s CEO detailed how the incident occurred.

First, the attackers gained access to a compromised legacy credential associated with an integration. This is something Obsidian has observed frequently. The credential could have been obtained in several ways, including device compromise, CI/CD pipeline compromise, as observed in the Trivy breach, or a developer accidentally leaving a token in publicly accessible code. Based on our experience with similar activity, it’s also possible that a secret scanning tool, such as TruffleHog, was used to discover the initial credential or pivot from one credential to others.

After gaining access, the attacker inserted backdoor code, though the exact specifics have not been publicly disclosed. That code was then used to steal customer OAuth tokens.

While several root causes can be attributed to this incident, the primary issue was a stale integration token with highly privileged access, including the ability to change code. This underscores the importance of continuous auditing and management of third-party integrations.

Incident Breakdown

Obsidian Security analyzed the Klue incident using our own data across impacted organizations. We then compared the findings against prior ShinyHunters-linked SaaS incidents to understand how SaaS supply chain attacks are evolving across actors, methods, timing, and execution patterns.

Initial Access

Klue is an integration that has an incredibly stable baseline, as is common with integrations from vendors. Many vendors provide a list of IP addresses, or ranges, that they connect from, which can be used to proactively restrict an integration from connecting outside of its approved infrastructure.

‍

Caption: Legitimate access to Klue primarily came from Google Inc. and Google Cloud, making the deviations during the incident stand out.

‍

Caption: One of the detections Obsidian fired related to the incident.

Reconnaissance

Unlike the Salesloft Drift and Gainsight supply chain attacks, the initial reconnaissance activity in this incident was not uniform in timing or source IP across the impacted customers.

The first observed reconnaissance activity was a Salesforce schema query from 138[.]226[.]246[.]94. This activity was immediately followed by exfiltration.

Approximately 3.5 hours later, two additional impacted organizations saw reconnaissance activity from 94[.]154[.]32[.]160.

A fourth impacted organization saw reconnaissance activity from 138[.]226[.]246[.]94 approximately 11 hours after the first organization was probed.

This differs from prior incidents. In the Salesloft Drift campaign, for example, reconnaissance activity across impacted organizations came from the same IP address and occurred within two hours of the first observed activity.

The queried data was the Salesforce Global Describe object, which returns a comprehensive list of all standard and custom objects accessible to the authenticated user, along with metadata properties and organizational limits. This is highly unusual behavior for most integrations. There are few legitimate reasons for a non-developer integration to pull this level of schema detail.

‍

Caption: Another detection Obsidian fired in relation to this incident.

Exfiltration

The exfiltration that followed used the same core technical method across all affected organizations. However, as with reconnaissance, execution varied by source IP, timing, scope, and volume.

The first impacted organization experienced exfiltration immediately after reconnaissance from 138[.]226[.]246[.]94 and later 212[.]86[.]125[.]24. This was the highest-record-count theft across the impacted organizations, with approximately 13.9 million records exfiltrated. Activity began at the reconnaissance timestamp and continued into the following day.

Another impacted organization experienced exfiltration approximately 30 minutes after the reconnaissance probe, through a single session. The data harvest was broad, spanning core CRM objects such as Account, Contact, Opportunity, and Task, as well as Chatter Feed, field history, email message, user, and login objects.

A third impacted organization saw the largest theft by data volume, despite being the most narrowly scoped. Only ten objects were queried, all of them core CRM objects: Lead, Contact, Account, Opportunity, Task, Case, and Contract. Unlike the first two cases, reconnaissance and bulk exfiltration were separated by approximately 6.5 hours.

A fourth impacted organization experienced exfiltration immediately after reconnaissance, approximately 11 hours after the first organization’s reconnaissance activity. The exfiltration ran as a continuous overnight burst lasting roughly 12 hours. The source IP shifted mid-operation from 138[.]226[.]246[.]94 to 212[.]86[.]125[.]24. This organization also saw the broadest object harvest, with more than 100 standard and custom objects queried, including support cases, file attachments, contracts, quotes, and CPQ records.

This also differs from prior incidents. In Salesloft Drift, exfiltration was more uniform, with a consistent set of source IPs and activity concentrated in a tight time window. In the Klue incident, source IPs varied by organization and activity was spread across more than 24 hours.

In every case, the underlying technique was the same. After querying Global Describe, the actor issued SOQL queries against discovered objects using /services/data/v59.0/query, then used QueryMore pagination through /query/{locator} to extract full result sets batch by batch. QueryMore activity at the scale of tens to thousands of fetches is a strong indicator of automated bulk export, rather than the periodic, resource-bound queries expected from a legitimate integration.

Other Deviations

Beyond source IP, timing, and activity pattern deviations, Obsidian observed two additional signals tied to the incident.

User Agent

The user agent associated with Klue login activity in Salesforce was historically stable. Before the incident, the application was only observed connecting with the user agent python-httpx/[version].

During the incident, malicious logins used different user agents: python-urllib/3.12 and python-urllib/3.14.

‍

Caption: The user agent deviation is clearly visible in the integration’s activity breakdown.

‍

‍

User agent deviation is a strong signal when paired with IP deviation, especially for integrations that normally operate from a predictable infrastructure and software baseline.

API Version

Obsidian also observed a deviation in the Salesforce REST API version used for API calls. In the month before the incident, API calls used v64.0, such as /services/data/v64.0/queryAll/.

During the incident, malicious API calls used v59.0, such as /services/data/v59.0/sobjects/.

This type of version downgrade is not typical for a stable Salesforce integration and can be an indicator of malicious activity.

Conclusion

The Klue incident shows how quickly trusted third-party access can become an active attack path. Across the impacted customers Obsidian analyzed, the signal was visible: a normally stable integration began authenticating from unexpected infrastructure, using different user agents, calling a different Salesforce API version, performing schema reconnaissance, and extracting records at a scale inconsistent with normal integration behavior.

For vendors, the remediation path starts with reducing the risk of integration compromise: rotate credentials, remove stale tokens, enforce least privilege, scan continuously for exposed secrets, and monitor integration infrastructure for anomalous behavior.

For customers, the priority is visibility and control over the third-party integrations already connected to business-critical applications. Security teams need to know which OAuth apps have access to Salesforce, what scopes they hold, which users authorized them, and whether those integrations are behaving in line with their historical baseline. They also need a way to act quickly when trusted access becomes suspicious.

Obsidian helps teams do exactly that. Customers can use Obsidian to inventory OAuth apps connected to Salesforce, assess risky or excessive scopes, identify users and tenants tied to each integration, detect deviations in infrastructure and behavior, map potential blast radius, revoke OAuth tokens from one place, and investigate persistence activity such as newly created OAuth apps, admin accounts, or webhooks.

That’s the difference between manually reacting to a vendor advisory and continuously governing third-party integration access before, during, and after an incident.

The question for security teams is no longer just whether a trusted third-party integration could be abused. It’s whether they can see it happening, understand the blast radius, and remediate before the damage spreads.