FBI Warning on Salesforce Attacks: IOCs and Detections to Watch For

Federal advisories about a specific SaaS platform are unusual. Most alerts concern malware families, vulnerabilities, or nation-state activity against critical infrastructure. An alert naming a CRM product signals that something has shifted in where attackers are spending their effort.

On 12 September 2025 the FBI issued a FLASH alert through the Internet Crime Complaint Center concerning indicators of compromise associated with actors compromising Salesforce customer relationship management software. The alert covered two criminal groups, UNC6040 and UNC6395, described as responsible for a rising number of data theft and extortion intrusions, both observed targeting Salesforce platforms through different initial access mechanisms.

The two campaigns arrived at the same destination through opposite routes, which is what makes them useful to study together. One relied on social engineering a human. The other relied on a compromised third-party integration. Neither exploited a vulnerability in Salesforce itself, and neither would have been stopped by the identity controls most organizations consider their strongest.

This post covers what the alert describes, which indicators are worth ingesting, and, more importantly, the behavioral detections that remain valid long after any indicator list expires.

What the Two Campaigns Actually Did

The mechanics matter because they define what detection has to look for.

UNC6040: Vishing Into a Malicious Connected App

Since October 2024, UNC6040 has targeted Salesforce accounts using voice phishing and social engineering, with actors posing as IT support to trick call centre and support staff into sharing credentials or approving a malicious connected app, frequently a modified version of Salesforce's Data Loader.

The FBI noted that the actors directed victims to phishing panels during the social engineering calls, visiting from mobile phones or work computers, then used API queries to exfiltrate large volumes of data in bulk once access was obtained.

The OAuth tokens obtained through the approved app bypassed MFA and other defences, and the actors registered malicious applications through Salesforce trial accounts to avoid detection.

The critical property: the victim performed the authorization themselves. There is no credential theft to detect, no anomalous login, and no failed authentication. A user was persuaded to grant access, and the grant behaves like any other grant.

UNC6395: Stolen OAuth Tokens From a Trusted Integration

In August 2025, UNC6395 exploited compromised OAuth tokens for the Salesloft Drift application, an AI chatbot integrated with Salesforce, using those tokens and the third-party integration to reach victim instances and exfiltrate data.

The campaign ran between 8 and 18 August, focused on support case data, and the exfiltrated records were then combed for secrets including AWS keys, internal passwords, and Snowflake tokens, which enabled pivoting into other cloud environments and expanded the blast radius considerably.

Here the organizations affected did nothing wrong at the moment of compromise. They had authorized a legitimate integration at some earlier point, and that integration's provider was breached.

The Extortion Follow-On

The extortion phase has been attributed to a separate cluster, tracked as UNC6240, whose operators have consistently claimed to be ShinyHunters in emails and calls to employees of victim organizations. Groups claiming responsibility have associated themselves with ShinyHunters, Scattered Spider, and Lapsus$ branding.

For defenders the branding matters less than the sequence: access, bulk export, credential harvesting from the exported data, then extortion contact that may arrive weeks later.

What the Published IOCs Cover, and Their Limits

Indicators are worth ingesting. They are not a detection strategy.

What the Alert Contains

The FLASH includes technical indicators such as user agent strings, IP addresses, and URLs linked to the intrusions. The authoritative source is the advisory itself, published through IC3, and organizations should work from that document rather than from any secondary summary including this one.

Where Indicators Genuinely Help

Retrospective hunting. This is the highest-value use. Search historical Salesforce event logs, network telemetry, and identity logs for the published addresses and user agent strings across your full retention window. Campaigns are disclosed after the fact, so the value lies in determining whether you were already affected during the active period rather than in blocking future use.

Triage enrichment. Knowing that an observed source address appeared in this campaign accelerates a triage decision meaningfully.

Scoping confirmation. During an investigation, indicator matches help establish the exposure window.

Where They Fall Short

Infrastructure rotates. Addresses published in September were often already abandoned. User agent strings are trivially changed, and the actors were already using custom user-agent strings to appear legitimate, which means the string itself is an attacker-chosen value rather than a reliable fingerprint.

More fundamentally, the activity these campaigns generated is API access from an authorized application. No indicator distinguishes a malicious bulk export from a legitimate one. Only behaviour does.

The Behavioural Detections That Actually Matter

These remain valid regardless of what infrastructure the next campaign uses.

Connected App and OAuth Authorization Events

New connected app authorization. Any application newly granted access to your Salesforce org, particularly one requesting broad object access. In the UNC6040 case this was the pivotal event, and it was performed by a legitimate user under social engineering pressure.

Applications registered through trial or unfamiliar publishers. The registration path used to avoid scrutiny.

Scope expansion on existing grants. An application that previously held narrow access now holding broad access.

Authorization events outside change management. No planned integration work, but a new grant appeared.

These deserve alerting rather than periodic review, because the interval between a malicious grant and bulk extraction can be very short.

Bulk Data Access and Query Volume

Query volume far outside an established baseline for a given user or integration. This requires baselining, which is exactly the work most organizations have not done for SaaS platforms.

Bulk API and export operations from an application that normally performs incremental synchronization, or from a user account that has never performed an export.

Access to object types outside the normal pattern for that identity, particularly Users, Accounts, and Cases when the integration's function does not require them.

Report and list view exports at unusual volume or outside working patterns.

API Session Characteristics

Access from source infrastructure inconsistent with the integration's normal origin. A SaaS integration typically connects from a stable set of provider addresses. Access from hosting infrastructure elsewhere is meaningful.

Sessions with no corresponding user activity. Substantial data movement attributed to an application with no human session behind it, at a time when no scheduled sync should be running.

Login events using API-only paths for accounts that normally authenticate interactively, or the reverse.

Log Tampering

Attackers deleted Salesforce query job records after exporting data to obscure their activity. Deletion of query job history, changes to audit or event monitoring configuration, and gaps in expected log continuity all warrant immediate investigation, since degradation of your own visibility is rarely accidental.

Identity-Side Signals

Because the entry point for UNC6040 was social engineering aimed at support staff, watch the identity layer for the surrounding activity: authentication from unexpected geography or infrastructure, MFA method registration or reset activity, and help desk driven credential resets clustered in time.

Help desk recovery deserves specific scrutiny. It is a documented social engineering target and frequently the softest path into an otherwise well-defended environment.

Correlating Across Layers

None of these signals is conclusive alone. An unusual export, an authentication anomaly, and a new application grant occurring within the same window is a different story than any one of them in isolation.

That correlation across SaaS audit logs, identity telemetry, and cloud activity is what converts individually dismissible events into a detected intrusion, and it is where most organizations have a genuine gap because SaaS audit logs are frequently not collected at all. Bringing them into the same detection layer as endpoint and cloud telemetry is central to how FoxRadar360 approaches SaaS coverage rather than relying on platform-native alerting.

Hunting Guidance: What to Check Now

A practical sequence for organizations wanting to establish whether they were affected.

Enumerate every connected app. For each, record the scopes granted, who approved it, when, and whether it is still in use. Expect to find applications nobody recognizes and grants belonging to tools the organization stopped using.

Revoke what you do not recognize or no longer need. Unused grants retain full access indefinitely.

Review authorization history for the campaign windows and beyond. Any grant approved during a period when no integration work was planned deserves investigation, including a conversation with the approving user about how the request arrived.

Search event logs for bulk export activity across your retention window, per user and per integration, looking for volume outliers rather than known-bad values.

Check for the published indicators across Salesforce login history, event monitoring, and network telemetry.

Search exported support case data for secrets. If any exfiltration occurred, the follow-on risk is credentials that were sitting in case text. Cloud keys, internal passwords, and database tokens found in exported data were used to pivot into other environments.

Review cloud audit logs for the exposure window if any secrets may have been exposed, looking for use of those credentials from unfamiliar sources.

Confirm your retention actually covers the period. If Salesforce event monitoring was not enabled or retention is shorter than the campaign window, that is itself a finding worth escalating.

Hardening Recommendations

The FBI's guidance covered training support staff to recognise social engineering, enforcing MFA, applying least privilege, restricting IP-based access, monitoring API usage for unusual activity, reviewing third-party integrations, and rotating API keys, credentials, and tokens regularly.

Some practical detail on the ones that matter most.

Restrict Who Can Authorize Connected Apps

Salesforce and most SaaS platforms allow administrators to require approval before applications can be granted access. Enabling this converts an uncontrolled surface into a governed one and directly addresses the UNC6040 path.

The trade-off is friction, which needs a fast approval route so people do not seek workarounds. But an unrestricted consent model means any user who can be persuaded can grant a third party access to your CRM.

Train Support and Service Desk Staff Specifically

Generic phishing awareness does not prepare someone for a confident caller claiming to be internal IT, walking them through a legitimate-looking approval flow. Train for the specific scenario, establish a verification procedure for any request to approve an application or reset credentials, and make it acceptable to refuse and call back.

Apply IP Restrictions and Session Controls

Limiting API access to expected source ranges, where operationally feasible, removes a large share of opportunistic access. Session timeouts and continuous access evaluation reduce how long stolen access remains usable.

Tier Integrations by What They Can Reach

Assess third parties by data access rather than contract value. A small vendor with a persistent read grant across your CRM presents more risk than a large vendor providing an isolated service. Concentrate real diligence on the top tier.

Rotate Tokens and Bound Their Lifetime

Tokens that never expire are permanent credentials nobody tracks. Where lifetimes can be configured, configure them. Where they cannot, establish a periodic revocation and reauthorization cycle for high-privilege integrations.

Stop Secrets Accumulating in Support Cases

The credential harvesting objective only worked because plaintext secrets sat in case text. Establish a handling procedure for credentials shared during support interactions, scan proactively, and rotate anything found. This reduces impact rather than probability, and it is entirely within your control regardless of any vendor's security.

Enable and Retain Event Monitoring

Detection depends on logs that exist. Many organizations discover during an incident that platform event monitoring was never enabled or that retention is too short to establish scope. Assessing whether your current SaaS logging would support a ninety-day investigation is a useful exercise to run with FoxRadar360 before you need the answer under pressure.

Preparing a Response Runbook

When the next advisory names an integration you use, speed matters.

Document in advance who owns each integration, who can revoke tokens, how to disable a connected app, where the audit logs live and how far back they go, and what the notification obligations are if customer data was in the exported set.

Organizations with this written moved within hours during the Drift disclosure. Organizations without it spent the first day working out who owned the integration.

Key Takeaways

The FBI alert is notable less for the indicators it published than for what the two campaigns reveal about where attackers are now working. Neither exploited a platform vulnerability. One socially engineered a user into authorizing access, and the other rode a compromised integration's tokens. Both bypassed multi-factor authentication entirely, because OAuth tokens represent access already granted and there is no login left to protect.

That has three implications for defenders. Indicators are worth ingesting for retrospective hunting and triage enrichment, but they expire and the actors were already shaping the most visible ones to blend in, so behavioural detection has to carry the weight. Connected application authorization, scope expansion, bulk export volume relative to baseline, access to unusual objects, and log tampering are the signals that stay valid across campaigns.

And the detection only works if the telemetry is collected. SaaS audit logs are security telemetry, correlating them with identity and cloud activity is what turns weak signals into a clear narrative, and a substantial number of organizations affected by these campaigns had the evidence sitting in platform logs that nothing was reading.

The practical starting point is unglamorous: enumerate every connected app, revoke what you do not need, restrict who can authorize new ones, baseline what normal export volume looks like, and get your SaaS audit logs into the same place as everything else.

To review which third-party integrations currently hold access to your SaaS environments and whether unusual activity from one would be detected, start a conversation with the team at FoxRadar360.