---
title: "Detecting the Klue supply chain attack in Salesforce instances"
description: "We summarize the Klue supply chain attack and provide detection guidance for Salesforce environments monitored by Datadog Cloud SIEM."
author: "Julie Agnes Sparks"
date: 2026-06-22
category: "emerging threats and vulnerabilities"
tags: ["threat detection", "salesforce"]
url: "https://securitylabs.datadoghq.com/articles/detecting-the-klue-supply-chain-attack-in-salesforce/"
---

## Overview

On June 11, 2026, a threat actor compromised backend systems at Klue, a market intelligence platform that hundreds of enterprise organizations use to sync competitive battlecard data with their CRM environments. By the time Klue alerted customers on June 13, the threat actor had already harvested OAuth tokens for Salesforce and Gong, and had begun querying those environments through automated API calls.

The group behind the attack, which self-identifies as "Icarus" and has been active since at least April 28, 2026, has since run an extortion campaign against multiple victims. One victim, Huntress, published a [detailed incident report](https://www.huntress.com/blog/klue-breach-investigation) confirming the compromise of CRM data: business contacts, price quotes, and sales communications.

This post summarizes what is known about the attack chain, then provides detection guidance for Salesforce environments monitored by Datadog Cloud SIEM. If you are working through a broader Salesforce threat hunt, our recently published [threat hunter's guide to Salesforce](https://securitylabs.datadoghq.com/articles/mapping-out-your-unknown-threat-hunters-guide-to-salesforce.md) covers the many of the threat actor's behaviors and log sources to consider.

![The Klue attack chain: a single compromised integration gave the threat actor OAuth access to fan out across multiple customer Salesforce orgs and exfiltrate CRM data (click to enlarge).](https://securitylabs.dd-static.net/img/detecting-the-klue-supply-chain-attack-in-salesforce/attack-chain.png?auto=format)
*The Klue attack chain: a single compromised integration gave the threat actor OAuth access to fan out across multiple customer Salesforce orgs and exfiltrate CRM data (click to enlarge).*

## What happened

According to Huntress, the compromise followed a pattern common in third-party OAuth abuse campaigns. The threat actor gained initial access through a dormant credential rather than a phishing campaign or a vulnerability exploit. Klue had created the credential for a prototype integration and never decommissioned it.

We reconstructed the following timeline from our investigation, Huntress's report, and Klue's disclosures:

- **June 11**: Anomalous behavior begins in Klue's integration infrastructure. Datadog observes the earliest activity at 12:56 UTC.
- **June 12**: Klue identifies unusual network connections from external IP addresses and removes Salesforce access to stop further exfiltration.
- **June 13**: Klue revokes OAuth credentials for all customers, disables integrations, and issues a general customer alert.
- **June 16**: Extortion emails begin arriving at affected organizations, with the subject line "top secret email" and a 48-hour deadline to contact the actor through Session Messenger.

![Timeline of the Klue supply chain attack, from the first anomalous activity on June 11 to Klue's listing on the Icarus leak site on June 19 (click to enlarge).](https://securitylabs.dd-static.net/img/detecting-the-klue-supply-chain-attack-in-salesforce/timeline.png?auto=format)
*Timeline of the Klue supply chain attack, from the first anomalous activity on June 11 to Klue's listing on the Icarus leak site on June 19 (click to enlarge).*

The threat actor ran scripts to issue REST API queries against connected Salesforce instances. The observed user-agent strings suggest the scripts were written in Python. Huntress observed three primary user-agent strings across logs, which align with Datadog's findings.

```
Python-urllib/3.12
Python-urllib/3.14
5238
```

These user agents made malicious requests against the `/services/data/v59.0/query/*` endpoint to exfiltrate data quickly.

## What we found

Our analysis of Salesforce event logs surfaced additional detection opportunities for teams responding to this incident or hunting for evidence of Klue-related activity.

### Identifying the compromised connected application

The Klue Battlecards integration will appear in Salesforce logs under different field names depending on the event type.

In **LoginEvent** logs, look for:

```yaml
application:"Klue Battlecards"
```

In **API events** and other event types, the application may surface in the connected app name field:

```yaml
connected_app_name:"Klue Battlecards"
```

### Detecting OAuth refresh token usage

In some instances, the threat actor used **OAuth refresh tokens** to maintain API access if needed. This behavior appeared in only a _subset_ of affected environments, so treat it as a supplementary indicator rather than a primary detection signal. Where it appears, Salesforce surfaces it differently depending on which event log you have access to.

In the **Login** object this is reflected through:

```yaml
login_sub_type:oauthrefreshtoken
```

And in the **LoginEvent** object:

```yaml
login_sub_type:"OAuth Refresh Token"
```

### Threat actor API data access activity

Once authenticated, the threat actor queried standard Salesforce objects through the API. The following entities were the most heavily targeted:

```
Opportunity
Case
Task
Lead
Contact
Account
User
Contract
Event
Campaign
```

Scope API event volume by entity type using the `entity_name` or `queried_entities` field in your Salesforce audit log data.

Datadog's Security Research team observed another pattern: spikes in failed API requests alongside successful ones. The threat actor scoped these requests broadly to return as much data as possible.

Failed requests came from querying a table that was too large, querying a table that requires a filter on a reified column, or accessing a table that the account lacked permission to read.

The following example shows the threat actor attempting to query all fields in a table:

```sql
$ SELECT FIELDS(STANDARD) FROM Event

exception_message: fault=-1;
common.exception.ApiException: exceeded 100000 distinct who/what's
```

These `ApiException` messages in the RestApi logs deviate from the expected behavior of a connected application.

As Huntress noted, we also observed the use of QueryMore. To exfiltrate large amounts of data, a threat actor must use QueryMore because Salesforce [limits](https://developer.salesforce.com/docs/atlas.en-us.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_platform_soslsoql.htm) each API request to 2,000 records.

The following queries match REST API events to the v59.0 query endpoint from a connected application account.

Within Event Log File, this behavior is tracked under the [ApiTotalUsage](https://developer.salesforce.com/docs/atlas.en-us.object_reference.meta/object_reference/sforce_api_objects_apitotalusageeventlog.htm) or [RestApi](https://developer.salesforce.com/docs/atlas.en-us.object_reference.meta/object_reference/sforce_api_objects_eventlogfile_restapi.htm) event.

```yaml
event_name:ApiTotalUsage connected_app_name:* api_family:REST api_client_category:EXTERNAL_APPLICATION api_resource:*v59.0/query/*
```

The ApiTotalUsage event includes a `client_ip` field but does not include a user agent.

```yaml
event_name:RestApi connected_app_id:* method:GET uri:/services/data/v59.0/query* message:Query*
```

The RestApi event includes a `client_ip`, `user_agent`, and `message` to filter within your search. The `message` field will include QueryMore when it occurs.

Within Real Time Monitoring Events, this behavior is tracked in the [ApiEvent](https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/sforce_api_objects_apievent.htm) event.

```yaml
event_name:ApiEvent api_type:"REST" operation:Query* connected_app_id:*
```

The ApiEvent includes the `operation` field to view Query or QueryMore activity. It also includes `application`, `message`, `user_agent`, and `source_ip` for further filtering.

A spike in read-heavy API queries across many objects, especially alongside the known indicators, is a strong behavioral signal of automated data exfiltration.

## How Datadog can help

You can identify anomalous Salesforce activity using the following out-of-the-box Cloud SIEM detection rules, enabled by default for customers who ingest Salesforce logs:

- [Anomalous amount of Salesforce query results](https://docs.datadoghq.com/security/default_rules/cz6-1ud-98v/)
- [Salesforce anomalous amount of queried tables](https://docs.datadoghq.com/security/default_rules/def-000-x75/)
- [Salesforce previously unseen network for application OAuth token login](https://docs.datadoghq.com/security/default_rules/def-000-yf3/)

Datadog Cloud SIEM customers who ingest Salesforce logs can start hunting with the queries above. Scope your investigation to activity from June 11 to June 12, and cross-reference any sessions tied to the Klue Battlecards application against the IP address and user-agent indicators.

For a full walkthrough of Salesforce log sources, event types, and threat actor tactics, techniques, and procedures (TTPs) to hunt for, including privilege escalation, API abuse, and data access patterns, see our guide: [**Mapping out your unknown: A threat hunter's guide to Salesforce**](https://securitylabs.datadoghq.com/articles/mapping-out-your-unknown-threat-hunters-guide-to-salesforce.md).

## Indicators of compromise

Klue confirmed the following IP addresses as threat actor infrastructure. Cross-reference them against Salesforce login and API event logs, as well as any other services integrated with Klue. The user agents are a lower-confidence indicator, but you can correlate them with the IP addresses.

| 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 |
| Python-urllib/3.12 | User agent |
| Python-urllib/3.14 | User agent |
| 5238               | User agent |

## References

- [Klue: An update on the recent Klue security incident](https://klue.com/blog/an-update-on-recent-klue-security-incident)
- [Salesforce: official statement](https://status.salesforce.com/generalmessages/20000257)
- [Huntress: Klue breach investigation](https://www.huntress.com/blog/klue-breach-investigation)