In early June 2024, Google Threat Intelligence (GTI) published an article which exposed details of a sophisticated attack campaign primarily targeting the Salesforce platform. This threat, tracked as UNC6040 (Mandiant's designation for an uncategorized threat cluster), begins with a familiar but highly effective tactic: voice phishing (vishing).

Attackers call victims directly, impersonating internal IT support personnel. They typically fabricate urgent pretexts—such as unresolved service tickets requiring immediate attention or mandatory security updates—to establish credibility and create time pressure. After gaining initial trust, attackers deploy one of two primary techniques: they either request login credentials directly over the phone, or redirect victims to convincing phishing sites designed to harvest both authentication credentials and multi-factor authentication (MFA) codes in real-time.

From Stolen Credentials to Broad Cloud Compromise

Once valid user credentials are in hand, the attackers leverage these stolen credentials to log into other cloud services such as Okta or Microsoft 365. This allows them to expand their access across different cloud platforms, systematically searching for more sensitive data or high-value targets – a classic example of lateral movement within a cloud environment.

The Malicious Use of Legitimate Tools

To add another layer to their deception, UNC6040 attempts to manipulate victims into authorizing a malicious Salesforce Connected Application. By design, a Connected Application is a framework that integrates with third-party applications in the Salesforce platform via APIs and standard protocols like OAuth 2.0. However, UNC6040 exploits this integration feature, turning it into a primary attack vector. The malicious application is typically a modified version of a legitimate tool - often an unauthorized and modified build of the Salesforce Data Loader, which is intended for bulk data operations. Once a user grants authorization to this seemingly benign application, the attackers gain access which allows them to programmatically query and exfiltrate high-value data from the compromised organization.

The exfiltrated data can, months later, be used for additional extortion attempts. The entire attack path can be visualized as shown in the diagram below.

It's important to note a key characteristic of this campaign: UNC6040 does not exploit any platform vulnerabilities. Instead, this entire attack relies on the abuse of trusted access permissions, skillfully leveraging Salesforce's legitimate integration framework. Furthermore, the attackers actively seek out misconfigurations within cloud services, such as overly permissive access rights, to further broaden their reach and deepen their compromise.

SSPM : defense against SaaS targeted attacks

SaaS Security Posture Management (SSPM) is a security discipline designed to safeguard cloud-based applications such as Microsoft 365, Salesforce, Google Workspace, and other SaaS platforms. SSPM solutions continuously monitor and assess these environments to identify security risks, including misconfigurations, excessive permissions or weak authentication policies. By ensuring adherence to security best practices and compliance standards, SSPM helps organizations maintain a robust security posture in their SaaS ecosystems.

Given UNC6040's reliance on legitimate access channels and permission abuse rather than technical vulnerabilities, SSPM becomes a particularly effective tool for defense. The attack campaign exploits multiple types of security gaps that SSPM is designed to identify.

Principle of least privilege

First is the Principle of least privilege. Every user and every application should only be granted the absolute minimum set of permissions required for their function. This is an important consideration for data access tools. The tool used in this attack was a modified Data Loader in this attack, a tool that often requires the API Enabled permission to function. Administrators should review who needs this permission, why they need it and ensure people with elevated permissions are trained appropriately to use their privileges responsibly.   

The attack succeeds by tricking a user into authorizing a modified application. However, that application cannot do anything the user themselves cannot do. It inherits the user's permissions. If the compromised user has limited access—if they can't export mass data or access sensitive records—then the app is significantly limited in its impact. A successful social engineering attempt might compromise an account, but it won't lead to a large-scale data breach.

SSPM can automate the enforcement of this principle. It can scan Profiles and Permissionsets, automatically flagging any user who has been assigned the API Enabled, System Administrator or View All Data permission inappropriately. However, to implement this effectively, we must first perform a detailed knowledge base on roles and responsibilities to define what least privilege actually means for each job function. Once that baseline is established, the SSPM can ensure we never deviate from it.

Connected App authorization restrictions

Managing the authorization of connected applications is another control point that directly addresses the attacker's entry vector. A recommended approach is to establish a formal process where no new connected application is allowed to interact with the Salesforce environment until it has been explicitly approved by both IT and security stakeholders. This means creating and maintaining an allowlist of applications, and any app not on this list is untrusted by default.

The entire attack depends on tricking an employee into authorizing a malicious application disguised as a legitimate tool. If we have a clear, pre-approved inventory, any request to authorize an unknown app immediately becomes a red flag. This process mitigates the risk of a compromised employee inadvertently granting access to corporate data. An unauthorized application would be prevented from being installed or executed from the outset.

Netskope SSPM can identify this misconfiguration by applying targeted security detections. For example, it can enforce detections such as “Only administrator allowed connected apps should be able to access the Salesforce API” or “External users should only be able to access Salesforce API via whitelisted apps”. The latter detection, for instance, configures Salesforce to block any application from accessing data via its API unless an administrator has explicitly installed or approved it.

Enforce Multi-Factor Authentication Universally

A useful protection against any phishing attack is still to make Multi-Factor Authentication (MFA) mandatory. MFA adds an important layer of security by requiring verification beyond just a password, significantly reducing the risk of attackers exploiting stolen credentials. However, in a modern enterprise, simply enabling MFA is not always sufficient due to the prevalence of Single Sign-On (SSO).

For the majority of users, authentication is handled by a central Identity Provider (IdP) like Okta. Forcing another MFA challenge for these SSO users is not a practical security enhancement. This creates a blind spot: the high-risk accounts that exist outside of your SSO governance. 

This is where our SSPM platform can be particularly effective. Using template rules, the platform continuously monitors the user base, distinguishing between SSO accounts and high-risk, direct-login accounts.

Verify connected apps information

The next strategy is to verify connected app information. This matters because the attacker's entire strategy is built in deception. They utilize a legitimate tool, the Data Loader, by wrapping it in a seemingly harmless application, giving it a plausible name like "My Ticket Portal" to fit their social engineering script. To a user under pressure, this can look like a routine IT procedure.   

However, legitimate applications, particularly those from the Salesforce AppExchange, undergo a verification process. Therefore by having a clear process to cross-reference any new app against a list of known, approved applications, organizations can identify these malicious apps.

SSPM potentially can automate this defense, but cannot distinguish a legitimate custom app from a malicious one by itself. To make this feasible, we must first establish and maintain an allowlist - a source of truth for all sanctioned applications within our organization. This list should contain specific identifiers, such as the official App ID or name for the legitimate Data Loader. Once this allowlist is established, an SSPM detection rule can be configured to generate an alert if a connected app is installed or authorized whose App ID is not on the allowlist.

IP based Restrictions

One of the most effective security controls is IP-based access restriction. This feature is designed to explicitly define and enforce which network locations are permitted to access your organization. By configuring Trusted IP Ranges, you can create an allowlist of IP addresses from which users can log in. This serves as an effective control against access attempts from unauthorized or unexpected geographical locations.

IP-address restrictions help neutralize the value of stolen credentials or sessions when the attacker is outside the trusted network. Even if the vishing call is successful and the attacker tricks an employee into giving up their password and MFA code, this IP-based restriction would block their login attempt from their own infrastructure. It creates a barrier that is independent of user behavior. A layered strategy can be used here.

The first layer is to harden the perimeter, strictly define the IP ranges for your corporate offices and company-managed VPN services at Profile level. Any login attempt using a profile with these settings will be immediately denied if the source IP address is not on this allowlist. The block occurs before any MFA prompt is even initiated, preventing the attacker from proceeding.

Next is to ensure that no Connected App can be used as a mechanism to bypass the perimeter. Setting IP Relaxation value to Enforce IP restrictions in each Connected App helps ensure that all OAuth authentication flows for the Connected App must still adhere to the user's Profile-level Login IP Ranges. There are some exceptions that we need to take into consideration, such as legitimate third-party cloud applications that require Relax IP restrictions instead of Enforce IP restrictions to function, as their servers are outside your network. This can be found in the rule “Connected App IP Relaxation and Continuous IP Enforcement”

The last layer is an internal safety setting designed to limit the damage if, under exceptional circumstances, an attacker manages to establish a session. You can enable SSPM rule “Lock user sessions to the login IP address”, in case an attacker steals a valid session cookie but tries to use it from their own IP address, the session will be immediately invalidated.

While IP-based access restriction was once a key component of enterprise security, its effectiveness as a primary defense mechanism in today's SaaS ecosystem has become more complex. The core issue lies in the shared infrastructure of the cloud. Both legitimate and malicious services now operate from the same hyperscale cloud providers (like AWS, Azure, GCP) and utilize the same global load balancing and CDN networks. These platforms rely on vast and dynamic IP address pools. This means the IP address of a malicious botnet can originate from the same subnet as one of legitimate business applications. However, this does not render the control obsolete. You should still use IP-based access restrictions where possible and mandate that your plugin vendors provide static IP-address ranges for you to whitelist as an added security measure.

Platform Monitoring

Finally, there is platform monitoring. Building strong defenses is important, but actively watching for threats also allows us to respond before a minor incident becomes a major breach.

The action here is to leverage the advanced capabilities within Salesforce by enabling Salesforce Shield. Salesforce Shield enhances the standard security features of the Salesforce platform, allowing users to better protect sensitive data. While Salesforce Shield has several handy features, two are particularly effective for countering a threat like this: Event Monitoring and Transaction Security Policies.

Event Monitoring provides deep visibility into user and application activity. Think of it as a detailed security camera system for your Salesforce org, logging nearly every event, from API calls, report exports to login attempts.

Transaction Security Policies allow us to act on that data in real-time. We can create automated rules that trigger when specific events occur. For example, we can automatically block a user from exporting a massive number of records if a suspicious action is detected.

This defense is valuable because the attack pattern has distinct, detectable behaviors. We know that the attackers often start with small queries before attempting a large-scale data exfiltration. Without granular monitoring, these initial probes would go unnoticed. With effective monitoring, we can flag when a user who rarely exports data suddenly attempts to download entire tables. This visibility allows us to move from a reactive posture to a proactive one, potentially stopping an attack before significant damage occurs.

Conclusion: 

The vishing attack we described previously relies on sophisticated social engineering skills and the exploitation of stolen credentials and SaaS misconfigurations. While these threats are effective, SSPM offers a strong defense, mitigating the potential for damage. By continuously monitoring, detecting, and helping remediate misconfigurations and identity-related risks across the SaaS ecosystem, SSPM acts as a key layer of defense against such credential-based attacks and data exfiltration attempts.

There's no single silver bullet that can entirely prevent threats like this. Resilience against modern cyber attack requires a multi-layered defense strategy. This approach must seamlessly integrate people, processes, and also technology. Holistic technical protection must be complemented by continuous employee security awareness training to identify and prevent social engineering, and well-defined incident response processes to quickly contain and recover from any breach. By weaving these elements together can organizations build a truly effective defense against the evolving landscape of cloud threats.