Salesforce has been in the news lately because of an unfortunate trend: social engineering attacks against companies using Salesforce 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.
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.
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.
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:
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.
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.
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.
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.
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:
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.
Data Protection
Data Security
Data Archiving
Data Compliance
Data Platform
