Exfiltration via Malicious Versions of Trusted Tools

‍

In the course of just one week, multiple organizations have gone public regarding a breach in their SaaS CRM application. Mitiga’s Threat Hunting & Incident Response team, part of Mitiga Labs, investigated one such case and discovered that a compromised Salesforce account was used in conjunction with a “Salesforce Data Loader” application, a legitimate bulk data tool, to facilitate large-scale data exfiltration of sensitive customer data.

The threat actors began with social engineering: they tricked an employee into approving a malicious connected app during a voice phishing (vishing) call. The approval gave the threat actors API access to the organization’s Salesforce data without exploiting any software vulnerabilities. From there, they could use automated queries to silently export customer data for extortion and resale of PII on the dark web, although attribution of the actors remains under investigation.

This report breaks down the attacks, including:

• The threat group behind this campaign
• What this fake Salesforce Data Loader is 
• The New method of exfiltration
• Recommendations: How organizations can detect and mitigate such threats

‍

This investigation uncovered a lesser-known but highly effective exfiltration method: threat actors used a trojanized version of Salesforce Data Loader, approved through social engineering, to perform high-volume, authenticated API queries. By chaining legitimate tooling with OAuth access, they extracted millions of records without touching a single credential or triggering traditional perimeter controls.

‍

Attack Methodology: From Vishing to Salesforce API Exfiltration

‍

The breach combined social engineering and abuse of OAuth (connected app authorization) in a multi-step operation. Here’s how the attack unfolded based on our investigation and similar tactics by UNC6040.

‍

Step 1: Initial Social Engineering (Vishing)

The threat actor called an employee pretending to be internal IT support and claimed that there was an open Salesforce issue that required action. The fake IT support caller guided the victim to Salesforce’s webpage for connected apps (e.g., login.salesforce.com/setup/connect) under some pretext.

‍

Step 2: Unknown Connected App Authorization 

Normally, installing a new connected OAuth app in Salesforce requires a user to confirm a code. On the call made by the threat actor, the employee was asked for an 8-digit code on the to authorize an app. Threat actors will also modify the application name – like “My Ticket Portal,” for example – to avoid raising suspicion. In this case, because the user had sufficient permissions, the approval granted the threat actor persistent API access to the Salesforce environment – operating with the compromised user permissions.

‍

‍

Step 3: Stealthy Data Extraction via API

Once authorized, the threat actors leveraged the Data Loader API access to run bulk queries and extract data. The Mitiga team’s threat hunting detected unusual patterns in the Salesforce Event Monitoring logs (specifically, RestAPI logs) revealing how the data was being exfiltrated. The logs showed the compromised user account (let’s call it “User X”) performing numerous API GET requests to the /services/data/v62.0/query endpoint (Salesforce REST API for SOQL queries). Each request was for the Customers_PII object and returned approximately 2.3 MB of data (roughly 1,000 records with 400 fields each) per request.

‍

‍

Step 4: Burst-Based Exfiltration

The attacker ran queries in a methodical, batch-like sequence.

• Initial Access Test: First, a single GET request was sent from a new IP address, likely used to validate the connected app’s access and confirm API functionality.
• Burst Execution: Moments later, the same IP would initiate a rapid burst of approximately 170 to 230 GET requests, each retrieving ~2.25–2.3 MB of contact data. This flood of API calls typically lasted about 9 to 11 minutes, then stopped.
• IP Rotation Strategy: Immediately after, a different IP address (a Tor IP Address) would take over and perform the next batch of ~200 GET requests in the same manner.
• Volume & Speed: This pattern repeated with about 8 distinct IP addresses, one after the other, over the course of roughly 1 hour and 20 minutes. In total, about 3.9 GB of data (nearly 4 million records) were exfiltrated from the Customers_PII object in that short time frame.

All of the involved IP addresses were traced to anonymization networks (Tor exit nodes or VPN services) rather than known corporate or trusted IP ranges. This aligns with known UNC6040 behavior of using services like Mullvad VPN to carry out intrusions and data theft while masking their location. By cycling through IP addresses, and presumably different exit nodes or proxies, the threat actors also attempted to bypass any single-IP rate limits or detections and make their traffic blend in with normal API usage patterns.

‍

Step 5: Detection and Interruption

With Salesforce event monitoring and Mitiga’s detection logic, the activity was flagged before the operation fully completed – in fact, when only about 10% of the data had been exfiltrated, ensuring breach impact was minimized. In this case, alerts were triggered by anomalous query volumes (e.g. 30**+ API queries returning sizable data**) within a short period. An alert described “221 mid-sized GET requests fromContactobject by user X in 10 min – potential data exfiltration.”

Security teams were able to notify the relevant parties about the connected app’s access and reset the compromised user’s credentials, cutting off the threat actor midstream. However, in at least one other incident, the threat actor managed to extract multiple objects (several gigabytes of data) before being noticed, due to the speed and stealth of the operation.

‍

Evidence from the Salesforce Logs

‍

Salesforce Event Monitoring logs were critical to piecing together the incident. Here’s what stood out in the data:

‍

Anomalous Connected App ID

Event Monitoring logs showed the suspicious activity tied to a Salesforce Connected App ID 889Kb100000KFJc. This ID did not match any known legitimate and vetted application in the organization and appeared for the first time on the day of the attack. It corresponds to the malicious Data Loader app that was added by the threat actor. During normal operations, Salesforce’s connected apps are usually known and vetted, so an unknown app ID performing large data queries was a red flag.

‍

REST API Query Spike 

In Salesforce’s Event Monitoring RestApi logs, Mitiga observed an extreme outlier in data query behavior. Over a short period, the compromised user 005Kd000006mU2MIAU performed hundreds of GET requests to the REST API endpoint /services/data/v62.0/query (Salesforce API version 62, SOQL query resource). Each request targeted the Contact object, visible in the log as ENTITY_NAME:CONTACTS, and succeeded with a 200 OK status. The response sizes for these queries were consistently around 2,380,000 bytes (~2.3 MB) —each multiple thousands of requests—indicating a large volume of data.

‍

Burst Patterns and Multiple IPs

The timeline in the logs showed the queries came in bursts of approximately 200 calls in ~10 minutes from one source IP, then a new burst from a different source IP address, atypical to the victim’s network (e.g., AS27284 Fourplex Telecom LLC, AS214503 QuxLabs AB, AS53667 PONYNET). These ASN’s and IP addresses are known for Tor exit nodes or VPN egress points. In total, at least eight distinct IP addresses were seen, matching the pattern of the threat actor rotating through anonymization services.

‍

“User Agent” and Tool Fingerprint

Interestingly, the logs had a field for USER_AGENT which in this case was set to a numeric or blank value ("USER_AGENT":"9999" was observed). This is basically an unknown UA (classified by Salesforce). Combined with the CONNECTED_APP_ID, it painted a picture of a potentially automated data extraction at work rather than any standard user activity.

‍

Event-Derived Alerts

Mitiga’s detection platform raised an alert after observing: 

‍

"221 mid-sized GET requests from 'Contact' by user '005Kd000006mU2MIAU' 
in 10 min indicate a potential data exfiltration." 

‍

This triggered based on an Indicator of Attack (IOA) pattern we’d developed for high-volume API queries from single users. By defining a threshold (e.g., more than 30 API queries returning small packets of data), we can catch the behavior of bulk data theft. Salesforce Shield’s Threat Detection events and Transaction Security Policies can similarly be configured to flag or block anomalous data downloads (for example, unusually large report exports or API calls) from salesforce.com.

‍

Detection and Mitigation Strategies

‍

This breach did not rely on malware or brute-force tactics. The threat actor used trusted Salesforce functionality: a connected app authorized by a user and authenticated API queries that operated within standard platform limits.

After authorization, they extracted nearly four million records through automated queries that resembled typical administrative activity. This method exposes a gap in many SaaS security models, where actions appear legitimate unless viewed in a broader behavioral context.

Here are several steps that could help detect and prevent similar attacks in the future:

• Restrict and Monitor Connected Apps

• Review which users can authorize new connected apps. 
• Limit “Manage Connected Apps” or “Customize Application” permissions to a small number of admins. 
• Use App Allowlisting in Salesforce to whitelist known good applications and block unapproved ones.

• Employee Security Training (Social Engineering) 
  
  • Since the initial entry vector was a vishing phone call, reinforce security awareness training for all staff. 
  • Train staff to verify any unsolicited IT support calls – for instance, by independently contacting their real IT department. 
  • Emphasize that they should never be asked to install software or provide authentication codes via a phone call without validation. 
  • Conduct periodic simulated phishing/vishing exercises to keep awareness high. In this case, the attacker’s ask, entering an 8-digit code on a Salesforce page – should have raised suspicions. Encouraging a culture of “trust but verify” can prevent that crucial lapse.
• Threat Hunting and Anomaly Detection
  
  • Even with preventive measures, assume a breach can happen. Proactively hunt for signs of data exfiltration. 
  • For example, look at your Salesforce logs for patterns, including but not limited to:
    
    • A single user performing a high volume of queries, especially if from atypical IPs or at odd hours
    • Large report exports or CSV downloads
    • Multiple login attempts from new locations
  • Leverage tools that analyze cloud logs using machine learning, which can flag anomalies that deviate from normal user behavior. 

‍

Conclusion

‍

The Salesforce Data Loader abuse case highlights a troubling trend: threat actors are directly targeting high-value data in cloud services by exploiting human trust and built-in tools. By masquerading as IT support and getting a malicious app authorized, the threat actors bypassed traditional perimeter defenses and operated with the permissions of a legitimate user – essentially hiding in plain sight.

Mitiga’s Threat Hunting/IR team was able to identify and stop this breach by correlating subtle indicators, like unusual API calls and Tor/VPN IP usage, and by tracking emerging threats such as UNC6040. Salesforce has since issued guidance to customers on protecting against these social engineering tactics and emphasizing the shared responsibility model for cloud security.

With the right controls in place, organizations can significantly reduce the risk of falling victim to such well-known attacks. The case of the fake Data Loader and slow exfiltration reminds us that even trusted tools can be weaponized when threat actors find a way in – but with preparedness and quick response, the damage can be contained.

‍

Hunting Leads

Network IOCs:

‍

AS27284 (FOURPLEX-ASN)
AS214503 (QuxLabs AB)
AS210558, (1337 Services GmbH)
AS53667 (PONYNET)
AS58087 (Florian Kolb)
AS51852 (Private Layer INC)
AS200195 (Verasel, Inc.)
AS60729 (Stiftung Erneuerbare Freiheit)

‍

User and Entity Behavior (UEBA)
‍

• Fragment data exfil e.g. 2,300,000 bytes + each packets
• Unrecognized User Agent as Categorized by SalesForce: 9999

Sigma Rule:

‍

title: Salesforce Mid-Sized Chunk Exfiltration via GET Requests 
status: experimental 
description: Detects potential data exfiltration in Salesforce by identifying multiple mid-sized successful GET requests to the query API endpoint within a short time window. 
logsource:
 product: salesforce 
 service: restapi 
 category: application 
detection: 
 selection: 
   EVENT_TYPE: "RestApi" 
   METHOD: "GET" 
   STATUS_CODE: "200" 
   URI|re: '^/services/data/v\d+.\d+/query$' 
 size_filter: 
   RESPONSE_SIZE|gte: 1200000 
   RESPONSE_SIZE|lte: 6400000 
  timeframe: 10m 
  condition: selection and size_filter | count(USER_ID_DERIVED) >= 30 
fields:
 -USER_ID_DERIVED
 -ENTITY_NAME
 -RESPONSE_SIZE
 -URI
 -ORGANIZATION_ID
 -TIMESTAMP_DERIVED
 -STATUS_CODE
 -METHOD 
falsepositives:
 -Large volume legitimate downloads by integration or sync apps
 -Bulk exports triggered by scheduled jobs 
level: medium 
tags:
 -attack.exfiltration
 -detection.salesforce
 -technique.T1030