Maliciously impersonating a Salesforce App

Preface: When OAuth Trust is Abused

In early June 2025, Google Cloud's Threat Intelligence team (GTIG) published a detailed report outlining a voice phishing (vishing) campaign targeting Salesforce administrators. According to GTIG, the threat actor (tracked as UNC6040) used social engineering to convince employees to install a malicious impersonation of Salesforce’s Data Loader desktop app. The attackers then exfiltrated sensitive CRM data directly from the organizations' Salesforce environments.

But by early August, the scope of the attack became clearer. High-profile companies, including fashion brand Chanel, publicly confirmed data breaches stemming from unauthorized access to their Salesforce instances,all traced back to this same attack chain involving a fake Data Loader application and a deceptively trusted OAuth flow.

The common thread: these organizations were tricked into authorizing access to their Salesforce data via an app that appeared legitimate, but was actually controlled by the attackers. This blog post unpacks how that kind of impersonation is even possible, particularly with Salesforce’s Data Loader and the nuances of OAuth for desktop apps.

‍

OAuth 2.0: Delegated Access and the Role of the Client ID

At a high level, Delegated OAuth allows a user to grant a third-party application access to their account - without ever revealing their password. The process works like this:

1. The application directs the user to the identity provider’s login page (in this case, Salesforce).
2. The client ID is passed along - this public identifier tells Salesforce which app is requesting access.
   
   
3. After a successful login, Salesforce returns access tokens to a preconfigured redirect URI associated with the client ID.

For more in-depth on How OAuth works, read our blogpost about OAuth.

For web applications, the redirect URI is usually a vendor-controlled domain like:

https://app.vendor.com/oauth/callback

This ensures only the legitimate backend of the application can receive the tokens. An attacker could, in theory, create a malicious web app that initiates an OAuth flow - but they'd need to register their own domain, host a backend to receive tokens, and possibly get app approval inside the target org. This setup is traceable and has higher friction.

‍

Desktop Apps Change the Security Posture

Things look different for desktop applications.

Because desktop apps can’t host public URLs, they typically use a redirect URI like:

http://localhost:port

The app spins up a temporary local web server during the OAuth flow, and the browser redirects the tokens back to that local listener.

This pattern - known as the loopback redirect - is common and officially supported in the OAuth 2.0 standard, but it has some serious caveats:

• Desktop apps are public clients - they can’t securely store secrets or prove their identity.
• The client ID alone is the app’s identity, and it’s not tied to a particular binary or hash.
• Any app running on the user’s machine can claim to be any other app, as long as it knows the client ID and redirect URI.

‍

The Salesforce Data Loader Attack: What Likely Happened

The legitimate Salesforce Data Loader is a desktop application used by admins to bulk import/export Salesforce data. It supports OAuth and likely uses a localhost redirect during login.

Here’s what the attackers probably did:

1. Impersonated the Data Loader interface - likely a lookalike desktop app with the same UX.
2. Used the same client ID and redirect URI as the real Data Loader.
3. Socially engineered users (via voice calls) into initiating the OAuth flow and logging into Salesforce.
4. Because the client ID matched an already approved application in the org, the consent screen was skipped.
5. The attacker-controlled app received valid OAuth tokens, giving it access to Salesforce data - invisibly and silently.
   

From an audit/logging perspective, this access would appear to come from an already-approved application. There’s no new connected app, no scary permission prompt, and no abnormal IP address if the app is run from the user’s machine. That’s why this technique is so effective - it abuses the implicit trust of existing apps and the limitations of OAuth enforcement for desktop clients.

‍

Lessons and Mitigation

If this attack indeed involved a malicious desktop app impersonating Salesforce’s Data Loader by reusing its legitimate client ID, then traditional app-level restrictions (such as blocking untrusted connected apps) would not have prevented it - because the app appeared to be already approved and trusted.

However, organizations can still limit the blast radius through user-level authorization controls. By explicitly defining which users are permitted to authorize specific apps, particularly powerful tools like Data Loader, companies can significantly reduce the number of employees who could be tricked into granting sensitive access. In most environments, only a small, vetted group of administrators or data managers truly need access to such tools - tightening access here directly reduces the attack surface.

Additionally, training Salesforce administrators to recognize and question unusual OAuth authorization prompts - even for apps they’re familiar with - is critical. In this case, familiarity with the Data Loader brand may have created a false sense of security. Security awareness should include the idea that even trusted tools can be mimicked, especially in phishing or vishing scenarios.