How to Prevent Salesforce Social Engineering Attacks

[Update, September 8, 2025: A new attack method has emerged, involving attackers gaining access to Salesforce authentication tokens (OAuth tokens) stored by Salesloft, an AI vendor that was storing these tokens to be able to connect to their customers’ Salesforce Orgs. Using the stolen OAuth tokens, the attackers could connect directly to the victim’s Salesforce instance and steal data there, without relying on social engineering methods to access Salesforce. Odaseva protects our customers against this threat too, using the same technology described in the post below. While the threats are different – social engineering and gaining access to OAuth tokens – the solution to protect our customers’ Salesforce data against them is the same. Odaseva’s Zero Trust suite of products enables customers to force their third-party vendors (for example, Salesloft) to only connect to their Salesforce instance through Odaseva Zero Trust Connect. This ensures that Odaseva customers’ sensitive data is encrypted in transit, processing, and at rest.]

Salesforce has been in the news lately because of an unfortunate trend: social engineering attacks targeting enterprise organizations are resulting in data breaches, and the hacking ring promises more to come. The problem has hit enough high-profile companies that Salesforce issued an advisory statement titled “Security Advisory: Protect Your Salesforce Environment from Social Engineering Threats” which links to a more in-depth blog post.

Salesforce itself is not a vulnerability, the platform hasn’t faced a security breach related to this new wave of attacks. The problem is that employees of companies using Salesforce are being tricked into allowing attackers to access Salesforce data, highlighting how social engineering can circumvent traditional security protocols.

In this wave of attacks, the threat group UNC6040/ShinyHunters impersonated IT support in convincing phone calls (vishing) to trick employees into granting access to Salesforce data. A common tactic was deceiving a user into authorizing a malicious “Data Loader” connected app, thereby hijacking an OAuth token/session and giving the attackers API access to export large amounts of data from the Salesforce Org. This support impersonation and token hijacking approach did not exploit a technical vulnerability in Salesforce, but rather abused misplaced trust – both in the fraudulent support caller and in the malicious application. These attacks typically compromise organizations in under 4 hours but remain undetected for weeks—giving attackers ample time to exfiltrate hundreds of thousands of records.

The incident raises the question: How can leaders at other companies protect their Salesforce data against such an attack?

If you’re concerned that your company may fall victim to this threat, then you’re already on the right track by proactively seeking to protect against it. And by reading this blog post, you’re in the right place – Odaseva can help protect companies against social engineering attacks that infiltrate Salesforce data with our Zero Trust Vault product.

What are social engineering attacks on Salesforce?

Social engineering attacks manipulate human psychology rather than exploiting technical vulnerabilities. Instead of hacking through firewalls or cracking passwords, attackers deceive employees into voluntarily granting access to sensitive systems.

The UNC6040/ShinyHunters technique involves vishing (voice phishing) where attackers impersonate IT support to convince Salesforce admins to authorize fake connected apps. This grants attackers OAuth tokens with admin privileges—allowing them to export massive amounts of data while appearing as legitimate activity in audit logs.

That’s because with Odaseva Zero Trust Vault, if the attacker gains credentials that allow them to impersonate a company’s Salesforce Admin and access the Salesforce Org data, they can only see redacted and tokenized data. The most sensitive information remains securely encrypted in the external Odaseva Zero Trust Vault, completely out of attackers’ reach.

Let’s explain in more detail.

Why don't traditional Salesforce security measures prevent social engineering attacks?

The UNC6040/ShinyHunters attacks on Salesforce data highlight the limitations of conventional security controls when an attacker is already inside the system. Let’s look at why these conventional measures fall short in this specific social engineering scenario:

• Multi-Factor Authentication (MFA): MFA is crucial, but it can be bypassed. In these social engineering attacks on Salesforce data, the perpetrator gains a long-term access token and refresh token by impersonating a highly privileged Salesforce user, rendering the initial MFA challenge irrelevant for ongoing access.
• Least Privileges and Granular Access Controls: The attackers specialize in identifying and targeting Salesforce System Administrators—users who, by the nature of their role, require broad Salesforce access. Even with granular controls in place for standard users, a compromised Admin account can bypass them all.
• Salesforce Shield Platform Encryption: Salesforce Shield provides server-side encryption, which protects data at rest within the Salesforce database. However, it decrypts the data for any Salesforce user or API with access to the field. An attacker with a hijacked Salesforce Admin token can simply access the clear text data as if they were a legitimate user. Salesforce Shield is a protection against Salesforce itself, not a rogue, authenticated user.
• Event Monitoring: While Salesforce Event Monitoring is a powerful tool, it is primarily an alerting mechanism. However, it is possible to configure automated preventative measures that can be triggered by specific events. That said, detecting this type of social engineering attack is incredibly difficult. An attacker with a legitimate-looking token will perform activities that appear normal for a Salesforce System Admin. This makes it challenging to set up effective blocking conditions because the malicious behavior can be disguised as routine operations, allowing the attacker to remain under the radar.

At the end of the day, when a bad actor is already inside your Salesforce Org with the “Keys to the Kingdom,” the only approach that can truly protect your most sensitive data is storing it somewhere else entirely. That’s where Odaseva Zero Trust Vault comes in.

How can you protect Salesforce data from social engineering attacks?

Odaseva’s Salesforce data security platform is built on Zero Trust architecture, meaning no user, network, or component is inherently trusted – every access is continuously verified. Odaseva’s approach assumes that social engineering attacks will occur and designs safeguards such that even if an intruder obtains Salesforce credentials or tokens, they cannot freely access sensitive data or persist undetected.

The Odaseva product that solves this challenge is Zero Trust Vault, which ensures that if an attacker gains Salesforce credentials that enable them to impersonate a company’s Admin and access Salesforce data, they can only see redacted, tokenized data. The clear text data remains encrypted in the external Odaseva Zero Trust Vault.

The Zero Trust Vault: the ultimate solution against Salesforce social engineering attacks

Odaseva Zero Trust Vault involves decoupling sensitive data elements from Salesforce and storing them in a secure Vault that’s completely and only under the customer’s control. The Salesforce records only retain tokenized or masked placeholders for the Vaulted fields. Authorized users can still retrieve or view the real values via secure connectors or a managed package, but the clear text never actually resides in Salesforce.

This means that if a threat actor uses a stolen session or a malicious app to export data from Salesforce, the most sensitive fields would be unreadable tokens – the actual data remains protected in the Odaseva Zero Trust Vault.

Odaseva Zero Trust Vault ensures that an attacker who fooled a Salesforce Admin still cannot access the company’s most sensitive data without breaching the Vault’s additional layers of security (which would require separate credentials, keys, and approvals). The Vault maintains fine-grained access logs and geolocation-based controls as well, so every access event to sensitive data is monitored and can be restricted by policy (e.g. only accessible from certain networks or regions). In short, Odaseva Zero Trust Vault deeply minimizes the damage of a Salesforce breach: even a successful social engineering attack yields little of value, since critical data is stored and encrypted outside the attacker’s reach.

Odaseva Zero Trust Vault core features:

Client-side encryption: When a user inputs ultra-sensitive data (e.g., personal information, payment details) into Salesforce, it is encrypted in their browser using a customer-owned encryption key. Only this encrypted, unreadable data is sent to the Odaseva Zero Trust Vault.

Zero-knowledge server: The Odaseva Zero Trust Vault acts as a secure, external storage system. It stores only the encrypted data and never has access to the unencrypted data or the keys to decrypt it. It operates on a “zero-knowledge” principle—it knows nothing about the content it’s handling. In the Salesforce Org, the original sensitive fields are replaced with redacted or tokenized placeholders, so even if the Salesforce database is compromised, it contains no clear text (unencrypted) sensitive data.

Client-side decryption: When an authorized user needs to view the sensitive data, it is retrieved from the Odaseva Zero Trust Vault and decrypted in their browser, and only in their browser. The clear text data is never stored in or passed through Salesforce.

In summary, with Odaseva Zero Trust Vault, if the attacker gains credentials that allow them to impersonate a company’s Salesforce Admin and access the Salesforce Org data, they can only see the redacted and tokenized data. The most sensitive information remains securely encrypted in the external Odaseva Zero Trust Vault, completely out of attackers’ reach.

Odaseva Backup and Restore can help recover corrupted data

For companies that unfortunately become the victim of a successful social engineering attack on their Salesforce data which results in data corruption, or are concerned about data integrity, restoring data from a backup can minimize the effects of such a disaster and get companies back to business-as-usual faster.

We have much more information about Salesforce backup and restore, and encourage you to view the following resources if you’d like to learn more:

• Backup & Restore for Enterprise Salesforce Data 5 Common Questions Answered
• The Complete Guide to Salesforce Backup & Restore
• Checklist: Salesforce Backup and Restore Vendor Capabilities
• The Odaseva Blog

FAQs About Salesforce Social Engineering Attacks

How do social engineering attacks bypass Salesforce security?

Social engineering attacks target people, not technology. Attackers impersonate IT support or Salesforce teams to trick admins into authorizing malicious connected apps. Once authorized, these apps provide OAuth tokens with admin-level API access that remain valid for days or weeks—bypassing MFA and appearing as legitimate activity in audit logs. Traditional Salesforce security measures can't prevent attacks that exploit human trust rather than technical vulnerabilities.

What should I do immediately if I suspect a Salesforce social engineering attack?

First, don't panic or confront the suspected attacker. Document everything (caller ID, time, requests made), then immediately alert your IT security team. Audit recent connected app authorizations in Salesforce Setup → Apps → Connected Apps, looking for unfamiliar apps authorized in the past 24-48 hours. Revoke any suspicious OAuth tokens immediately—even if it causes temporary business disruption. Check Event Monitoring logs for unusual data export activity (large volumes, unfamiliar IP addresses). Speed matters: the faster you revoke compromised tokens, the less data attackers can steal.

Can traditional Salesforce backup solutions protect against social engineering attacks?

Backup solutions help with recovery after an attack but don't prevent data exfiltration. If attackers gain admin OAuth tokens through social engineering, they can export your entire Salesforce database before you detect the breach. The only effective prevention is Zero Trust architecture that stores sensitive data encrypted outside Salesforce. With solutions like Odaseva Zero Trust Vault, even if attackers successfully compromise admin credentials, they can only access tokenized placeholders—the actual sensitive data remains encrypted in an external vault they cannot access.

Why does Salesforce Shield Platform Encryption not protect me against these attacks?

Data encrypted by Salesforce Shield Platform encryption are automatically decrypted by the Salesforce platform when accessed over the Salesforce API. To make sure data remains protected, solutions such as Odaseva Zero Trust Connect can be implemented to offer end to end encryption and prevent your most sensitive data from being exfiltrated after a successful social engineering attack.

Conclusion: Why Zero Trust is Essential for Salesforce Data Security

The recent wave of social engineering attacks against Salesforce users has exposed a critical gap in traditional security measures. While tools like MFA and granular access controls are essential, they are not foolproof against sophisticated attacks that compromise high-level Salesforce Administrator accounts. These incidents demonstrate that when a bad actor is already inside your Salesforce Org with “the keys to the kingdom,” conventional security is simply not enough. The only truly effective strategy is to assume a breach will happen and build a defense that protects your most sensitive data even after a successful intrusion. By storing your most critical information in a secure, external vault, you can ensure that even a successful social engineering attack yields nothing of value, leaving your sensitive data safe and sound.

The Odaseva Zero Trust Vault is a security solution that assumes no user, device, or network can be trusted by default. Instead of relying on perimeter defenses, it verifies every access request, even from inside the network. This approach is essential in today’s security landscape, where social engineering and other internal threats are on the rise.

If you’d like to take the next steps in protecting your company’s Salesforce data against social engineering attacks, contact us today for a personalized demo.