Detecting Salesforce leaks after Salesloft Drift breach

Sebastien Tricaud

Summary

Salesloft was breached in August, resulting in Drift marketing token re-use in Salesforce based on the popular Salesforce integration.  Drift collects quite a bit of information from prospects and customers alike, making the cache of that data gathered from token abuse very useful today as well as down the road. Since August 8th 2025, the threat actor tracked as UNC6395, GRUB1 or misp-galaxy:uuid=”12503160-884d-40b8-b4cf-9a4d11a769cf” has used stored drift tokens to exploit Salesforce instances across a broad swath of companies.  The description given by Google, Cloudfare and Salesloft themselves are more than enough to have a pretty accurate detection capability. However, we haven’t seen many rules created in the public domain to detect this activity? For the rules that do exist, they do not really accurately represent the threat in their detection logic.  Let’s walk through the process someone trying to put detections in place for this emergent threat might use.

Hunting for public detection

Using the search capability in public detection repos, we found only a few public detections using the terms ‘Salesloft’, ‘Trufflehog’ which are dominant terms in the Salesloft Drift attack, ‘Salesforce’ as a search term finds a single detection in SigmaHQ repo detecting a user terminating an activity in Microsoft 365 Defender:

Inside this file, the detection is “Activity performed by terminated user” which doesn’t have any direct relationship to Salesforce, Salesloft or the attack behavior we would want to detect. 

 18 detection:                                                                                                                                                       
 19     selection:                                                                                                                                                   
 20         eventSource: SecurityComplianceCenter                                                                                                                    
 21         eventName: 'Activity performed by terminated user'                                                                                                       
 22         status: success                                                                                                                                          
 23     condition: selection

Looking in the Splunk Detection repo, we also do not find any detection examples based on the keyword search,  ‘Salesloft’, ‘Trufflehog’ or ‘Salesforce’:

Azure Sentinel has a few Salesforce detections which illustrate generic detection behaviors shared with this attack:

Emerging Threat rules for Snort and Suricata have three rules matching the Google blog, which is at least a starting point.  Here are those detections:

alert http $EXTERNAL_NET any -> $HOME_NET any (msg:"ET HUNTING Suspicious User-Agent String Observed Inbound (Salesforce-CLI/1.0)"; flow:established,to_server; http.user_agent; bsize:18; content:"Salesforce-CLI/1.0"; fast_pattern; reference:url,cloud.google.com/blog/topics/threat-intelligence/data-theft-salesforce-instances-via-salesloft-drift; classtype:trojan-activity; sid:2064295; rev:1; metadata:affected_product Web_Server_Applications, attack_target Web_Server, tls_state TLSDecrypt, created_at 2025_09_04, deployment Perimeter, performance_impact Low, confidence High, signature_severity Informational, tag Description_Generated_By_Proofpoint_Nexus, updated_at 2025_09_04, mitre_tactic_id TA0043, mitre_tactic_name Reconnaissance, mitre_technique_id T1590, mitre_technique_name Gather_Victim_Network_Information; target:dest_ip;)
alert http $EXTERNAL_NET any -> $HOME_NET any (msg:"ET HUNTING Suspicious User-Agent String Observed Inbound (Salesforce-Multi-Org-Fetcher/1.0)"; flow:established,to_server; http.user_agent; bsize:32; content:"Salesforce-Multi-Org-Fetcher/1.0"; fast_pattern; reference:url,cloud.google.com/blog/topics/threat-intelligence/data-theft-salesforce-instances-via-salesloft-drift; classtype:trojan-activity; sid:2064296; rev:1; metadata:affected_product Web_Server_Applications, attack_target Web_Server, tls_state TLSDecrypt, created_at 2025_09_04, deployment Perimeter, performance_impact Low, confidence High, signature_severity Major, tag Description_Generated_By_Proofpoint_Nexus, updated_at 2025_09_04;)
alert http $EXTERNAL_NET any -> $HOME_NET any (msg:"ET INFO Python aiohttp User-Agent Observed Inbound"; flow:established,to_server; http.user_agent; content:"python/"; startswith; nocase; content:"aiohttp/"; within:20; nocase; fast_pattern; reference:url,cloud.google.com/blog/topics/threat-intelligence/data-theft-salesforce-instances-via-salesloft-drift; classtype:trojan-activity; sid:2064326; rev:1; metadata:affected_product Web_Server_Applications, attack_target Web_Server, tls_state plaintext, created_at 2025_09_04, deployment Perimeter, performance_impact Low, confidence High, signature_severity Informational, tag Description_Generated_By_Proofpoint_Nexus, updated_at 2025_09_04; target:dest_ip;)

These rules have clearly been auto-generated and not tested.

These rules reflect the message ‘Observed Inbound’ for a flow that goes to_server. Normally this flow should be Outbound, though this doesn’t affect the detection efficacy.  The real problem is these Detections are solely based on three User-Agent strings:  

  • Salesforce-CLI/1.0
  • Salesforce-Multi-Org-Fetcher/1.0
  • python/ <whatever> aiohttp/ <whatever> which could match Python/3.13 aiohttp/3.12.15

So anytime one has a tool using the Python aiohttp library, there will be an alert “ET INFO Python aiohttp User-Agent Observed Inbound” referencing the Salesforce instance Salesloft Drift breach!

Testing Cloudfare token validity

Effective detection of this attack necessitates a behavioral approach. Although relying on a user agent string can be helpful, its efficacy is compromised when shared across multiple tools or libraries. In this particular incident, requests originated exclusively from Tor exit nodes. Specific and documented HTTP responses from the services employed provide further indicators: the Cloudflare API service, specifically the call to /client/v4/user/tokens/verify, generated a high volume of 404 errors with “invalid tokens” messages, as the attacker utilized Trufflehog to generate valid tokens for subsequent connection to the Salesforce instance.

It was observed the error returned when the token was invalid was 400. We are using our attack description language, Adel, to capture the attack.

Successful Salesforce Connection

Continuing on the timeline we observed the Salesforce connected user token being used:

Those request are also happening from a Tor exit node as well, from this pool of user agents:

Salesforce Eventlog 

Salesforce Eventlog allows to get the attack behavior, which in its reconnaissance phase got various information from salesforce: Account, Contact and User.

The last part of the attack uses the Salesforce Bulk API to exfiltrate but then remove created bulk jobs and DELETE data from the Case table:

Why Detecteam

While public detections of the recent breach appear limited, Detecteam’s REFLEX™ platform  specializes in developing, testing, validating and deploying robust detection mechanisms for various integrations, including Splunk, Elastic, Sekoia, and Devo, by leveraging attack behaviors.  Because we generate precise data reflecting adversary behaviors, Detecteam’s detections are accurate to the threat behavior.  Details matter when discussing speed, coverage, and quality.  Accuracy is the validation you are actually prepared for this behavior and have evidence from testing and provenance in the data used to tell the detection story.  Close the loop on your detection development lifecycle in minutes not months. 

For context-aware and rigorously tested quality detections, we are happy to support your requirements.

Search

Rozita Brandson

Sed ut perspiciatis unde omnis iste natus error sit voluptatem accusantium doloremque laudantium, totam rem aperiam, eaque ipsa quae ab illo inventore veritatis et quasi architecto beatae vitae.

Signup Newsletter

Sed ut perspiciatis unde omnis iste natus error sit voluptatem accusantium doloremque laudantium illo inventore.

[contact-form-7 id=”f245613″ title=”Newsletter”]

Latest Posts

Categories

Tag Cloud

T1003.001 – LSASS Memory T1005 – Data from Local Syste T1012 – Query Registry T1016 – System Network Configuration Discovery T1018 – Remote System Discovery T1021.001 – Remote Desktop Protocol T1021.002 – SMB/Windows Admin Shares T1021.004 – SSH T1027 – Obfuscated Files or Information T1033 – System Owner/User Discovery T1036.005 – Masquerading: Match Legitimate Name or Location T1041 – Exfiltration Over C2 Channel T1047 – Windows Management Instrumentation T1053.005 – Scheduled Task/Job: Scheduled Task T1055 – Process Injection T1057 – Process Discovery T1059 – Command Line Interface T1059.001 – Command and Scripting Interpreter: PowerShell T1059.003 – Windows Command Shell T1069 – Permission Groups Discovery T1069.001 – Local Groups T1069.002 – Domain Groups T1070.004 – File Deletion T1071 – Application Layer Protocol T1071.001 – Web Protocols T1078 – Valid Accounts T1082 – System Information Discovery T1083 – File and Directory Discovery T1087.002 – Domain Account T1105 – Ingress Tool Transfer T1110.001 – Brute Force: Password Guessing T1112 – Modify Registry T1140 – Deobfuscate/Decode Files or Information T1190 – Exploit Public-Facing Application T1204.002 – User Execution: Malicious File T1210 – Exploitation of Remote Services T1218.011 – System Binary Proxy Execution: Rundll32 T1219 – Remote Access Software T1482 – Domain Trust Discovery T1486 – Data Encrypted for Impact T1490 – Inhibit System Recovery T1518.001 – Security Software Discovery T1543.003 – Create or Modify System Process: Windows Service T1566.001 – Phishing: Spearphishing Attachment T1574.002 – DLL Side-Loading

Social Media