On September 12, 2025, the FBI's Internet Crime Complaint Center released a FLASH advisory, coordinated with CISA, disclosing indicators of compromise tied to two distinct threat groups actively targeting Salesforce environments. The advisory publishes exhaustive lists of IP addresses, URLs, and user-agent strings tied to both UNC6040 and UNC6395 activities. This post breaks down how both groups operate, what the IOCs actually reveal, and the detection and hardening steps organizations should be implementing now.
Why This Advisory Matters for Salesforce-Dependent Organizations
Salesforce sits at the center of sales, support, and customer data operations for a huge share of enterprises, which makes it an extremely attractive target once an attacker finds a reliable way in. The attacks are linked to groups such as ShinyHunters and Scattered Spider and have already hit major firms across tech, aviation, and insurance. The scale and profile of the affected organizations is exactly why this advisory deserves direct attention rather than a quick skim.
What makes these campaigns particularly notable is that neither group relied on exploiting a platform vulnerability in Salesforce itself. Both exploited trust relationships: human trust in the case of one group, and application-level trust in the case of the other. Organizations assessing their own exposure to this kind of attack path often need a focused review of their SaaS integration security posture, not just their network perimeter. FoxRadar360 helps organizations evaluate exactly these trust boundaries across their SaaS and cloud application stack.
UNC6040: Voice Phishing Into Salesforce Access
How the Vishing Campaign Works
Since at least October 2024, the group tracked as UNC6040 has been using social engineering, particularly voice phishing, to gain initial access. The threat actors call an organization's help desk, posing as IT support staff, attempting to resolve a fabricated technical issue.
The attackers guide victims through closing a purported service ticket and coax them into sharing credentials or multifactor authentication codes. The calls are convincing precisely because they mimic legitimate internal IT workflows that employees are trained to comply with, not resist.
The Connected App Trick
A key tactic involves tricking employees into authorizing a malicious connected app within the Salesforce portal. This is the step that turns a successful phone call into persistent, credential-independent access, since a connected app grant does not require the attacker to know the victim's password going forward.
Threat intelligence researchers have publicly disclosed that UNC6040 attackers abused a modified version of Salesforce's Data Loader by tricking employees into installing it via voice phishing, which the group then used to bulk export data directly from the compromised org.
Testing Your Help Desk Against This Exact Pattern
A practical way to validate resilience against this specific technique is to run a controlled vishing simulation against your own support staff using the same pretext structure the advisory describes.
text
Simulated call script structure for internal vishing testing:
1. Caller identifies as internal IT, references a fabricated ticket number
2. Caller requests the employee navigate to Salesforce Setup > Connected Apps
3. Caller requests the employee approve a named "diagnostic" connected app
4. Caller requests an MFA code "to verify the fix was applied"Running this kind of simulation and measuring how many staff members comply, rather than assuming security awareness training alone has closed the gap, gives a much more honest picture of actual exposure.
UNC6395: OAuth Token Compromise Through a Third-Party Integration
How the Token Theft Occurred
The second group named in the advisory used a completely different entry point. In August 2025, these actors exploited compromised OAuth tokens associated with a third-party AI chatbot application that integrates with Salesforce. By using these compromised tokens, the group was able to access and exfiltrate data from the victim's Salesforce environment.
Investigation revealed the attackers had exfiltrated the tokens from the vendor's cloud infrastructure after gaining access to the vendor's source code repository months earlier, meaning the token compromise had a long dwell time before the actual data exfiltration campaign became visible.
The Response and Its Limitations
In response to this campaign, the affected vendor and Salesforce collaborated to revoke all active access and refresh tokens for the compromised application. That containment step closed the specific vector, but it does not undo any data already exfiltrated during the period the tokens were valid. The FBI warns that unauthorized access could have persisted for weeks before this revocation.
Why Third-Party Integrations Are the Real Lesson Here
This incident highlights the security risks posed by third-party application integrations, which is the structural takeaway that matters well beyond this specific incident. Any connected app, chatbot integration, or third-party OAuth grant sitting in a Salesforce environment represents a trust extension that most organizations do not audit with the same rigor as their own user accounts.
text
Salesforce connected app audit checklist:
1. List every connected app currently authorized against the org
2. Confirm each app is still actively used by a business function
3. Review the OAuth scope granted to each app, not just its name
4. Revoke any app with excessive scope beyond what its function requires
5. Rotate credentials for any app tied to a third-party vendor with its own
disclosed security incidentsKey IOCs From the FBI Advisory
Infrastructure Indicators
The advisory identifies more than one hundred IP addresses associated with UNC6040 infrastructure, spanning multiple hosting ranges used across the vishing and data exfiltration campaign.
URL and Domain Patterns
Key URLs used in vishing lures and exfiltration mimic legitimate Salesforce setup pages, embedding attacker-controlled parameters alongside decoy domains and PHP scripts hosted on attacker-controlled servers. This pattern is a strong signal worth building detection logic around rather than relying on domain blocklists alone, since decoy domains rotate quickly.
User-Agent and Technical Indicators
The advisory includes specific user agent strings, IP addresses, and URLs tied to both campaigns. These should be pulled directly from the official advisory and loaded into detection tooling rather than retyped from secondary summaries, since IOC lists are precise by nature and small transcription errors defeat their purpose.
python
def check_against_advisory_iocs(login_event, ioc_list):
flagged = []
if login_event["source_ip"] in ioc_list["malicious_ips"]:
flagged.append("known_malicious_ip")
if login_event["user_agent"] in ioc_list["known_user_agents"]:
flagged.append("known_malicious_user_agent")
if any(domain in login_event["referrer_url"] for domain in ioc_list["decoy_domains"]):
flagged.append("decoy_domain_referrer")
return flaggedDetection Strategies Beyond Static IOC Matching
Behavioral Detection for Connected App Abuse
Attackers adapt fast, so static IP and domain matching alone only catches infrastructure that has already been identified, meaning any new campaign infrastructure slips through entirely unless behavioral logic is also in place.
python
def detect_suspicious_connected_app_grant(event_log):
flagged_grants = []
for event in event_log:
if event["action"] == "connected_app_authorized":
if event["app_age_days"] < 7:
flagged_grants.append({"reason": "newly_created_app", "event": event})
if event["oauth_scope"] in ["full", "api", "refresh_token"]:
if event["authorizing_user_role"] not in ["admin", "integration_owner"]:
flagged_grants.append({"reason": "excessive_scope_non_admin", "event": event})
return flagged_grantsMonitoring Data Loader and Bulk Export Activity
Since UNC6040 relies on bulk data export tooling once access is established, monitoring for unusual export volume or frequency tied to a single user session is a strong detection layer independent of any specific IOC.
python
def detect_bulk_export_anomaly(export_log, baseline_profile):
flagged = []
for event in export_log:
user_baseline = baseline_profile.get(event["user"], {"avg_daily_records": 500})
if event["records_exported"] > user_baseline["avg_daily_records"] * 10:
flagged.append(event)
return flaggedAPI and Session Monitoring for Compromised Tokens
Since the UNC6395 campaign relied entirely on valid OAuth tokens rather than credential theft, traditional login anomaly detection would not have caught it. Monitoring API call volume and pattern per integration, rather than only per user, is necessary to catch this class of abuse.
python
def detect_integration_api_anomaly(api_log, integration_baseline):
flagged = []
for integration, calls in api_log.items():
baseline = integration_baseline.get(integration, {"avg_calls_per_hour": 100})
if calls["calls_per_hour"] > baseline["avg_calls_per_hour"] * 5:
flagged.append({"integration": integration, "calls": calls["calls_per_hour"]})
return flaggedHardening Recommendations From the Advisory
The FBI's recommendations include enforcing phishing-resistant MFA, restricting Salesforce access to approved IP ranges, closely monitoring API activity, and auditing all third-party integrations for unauthorized connected apps. Defenders are urged to review OAuth permissions, audit connected apps, rotate any potentially exposed credentials, and block the malicious infrastructure listed in the advisory.
Phishing-Resistant MFA as a Priority Control
Standard MFA codes shared over the phone during a vishing call are trivially defeated, since the victim reads the code directly to the attacker. Phishing-resistant methods such as hardware security keys or platform-bound passkeys remove this specific weakness entirely, since there is no code for an employee to inadvertently share.
Help Desk Process Hardening
The attackers pose as IT or connectivity support, referencing fabricated tickets, and request that staff perform steps that grant elevated access or credentials. Any help desk process that allows credential resets, MFA resets, or connected app approvals based solely on a phone call, without independent verification through a separate channel, remains vulnerable to this exact tactic regardless of how many IOCs are blocked at the network layer.
Third-Party Integration Governance
Given that the second campaign relied entirely on a compromised third-party integration rather than any direct Salesforce weakness, organizations should treat every connected app and OAuth-integrated tool as part of their attack surface, subject to the same review cadence as internally managed accounts.
Building an Ongoing Response Rather Than a One-Time Fix
Loading the published IOCs into a SIEM addresses the specific campaigns named in this advisory, but the underlying attack patterns, vishing against help desks and OAuth token abuse through third-party integrations, will continue to evolve and reappear under new group names and new infrastructure. Organizations that treat this advisory as a prompt to build lasting detection and process controls, rather than a one-time IOC import, will be better positioned against the next variant of the same technique.
Structured testing against these exact attack paths, including simulated vishing calls and connected app abuse scenarios, gives security teams concrete evidence of where their current controls hold up and where they do not. FoxRadar360 works with organizations to build this kind of testing directly into their security program, rather than leaving it as a reactive response to the next public advisory.
Key Takeaways
This advisory highlights two very different but equally effective paths into Salesforce environments: human-targeted social engineering against help desk staff, and OAuth token compromise through a trusted third-party integration. Neither required exploiting a Salesforce platform vulnerability, which is the core lesson defenders should take away. Loading the published IOCs into detection tooling is a necessary first step, but lasting protection depends on hardening help desk verification processes, tightening connected app governance, and building behavioral detection that does not rely solely on infrastructure that will inevitably change in the next campaign.
Organizations that have not yet audited their Salesforce connected apps or tested their help desk's resistance to this exact vishing pattern should treat this advisory as the trigger to do so now, rather than after their own name appears in a similar disclosure. Teams looking to assess their exposure to this attack path can work with FoxRadar360 to scope a review built around SaaS integration security and social engineering resilience.
