Salesforce attacks are increasing, as the platform has become a prime target for cybercriminals. Salesforce is an attractive target due to its high level of connectivity and the volume of sensitive personal and commercial information it contains.

Between Q1 2023 and Q1 2025, malicious activity aimed at Salesforce environments has seen 96% rise in volume in WithSecure’s telemetry. It reflects a deliberate shift in attacker priorities.

Salesforce environments now sit directly in the path of cyberattacks.

“The targeting of organisations’ SaaS services that hold and process sensitive data has become an extremely popular TTP of ransomware actors. It has become apparent that actors no longer need to spend a lot of time and money seeking to fully compromise a network, when extortion demands based on sensitive data theft can be just as successful. It enables an effective and scalable way of targeting organisations at scale,” explains Tim West, Director of Threat Intelligence at WithSecure. “The business value of Salesforce and the level of sensitive data held within Salesforce makes it an exceptionally attractive target for financially motivated Threat Actors.”

Salesforce attacks have resulted in major breaches

Threat actors adapt faster than the defenses. They aren’t focusing on technical exploits. They’re exploiting access, trust, and human behavior. Salesforce is a perfect environment for this. Salesforce doesn’t have a built-in antivirus. It doesn’t scan incoming data for cyber threats. Securing the data and users of the platform is the customer’s responsibility. Attackers are aware of this gap.

The UNC6040 campaign: from vishing to connected apps

In 2025, Google’s Threat Intelligence Group reported on a campaign by UNC6040 – a financially motivated group targeting Salesforce with a blend of social engineering and OAuth abuse.

Credential harvesting was the first step. Attackers gained access through reused or phished credentials tied to single sign-on (SSO) systems. Once authenticated, they moved laterally within environments using the victim’s privileges, often unnoticed. OAuth abuse worsened the situation, allowing attackers to generate long-lived access tokens that bypassed MFA and evaded traditional security alerts.

These Salesforce attacks didn’t rely on technical exploits. Just an 8-digit authorization code – which is the default for installing a connected app in Salesforce – was enough. Once installed, malicious apps weren’t inspected by native tools, leaving the door wide open.

Attackers impersonated IT support and persuaded employees to install a fake version of the Salesforce Data Loader – often called “My Ticket Portal” – through the Connected Apps interface. This provided persistent access, enabling attackers to extract data directly from Salesforce, pivot into Microsoft 365 and Okta, and return weeks later with extortion demands.

The methods used by UNC6040 are nearly identical to those of UNC3944, better known as Scattered Spider.

“Attribution is hard, particularly to Scattered Spider,” West notes. “They’re often described as a loosely organised ‘collective,’ revolving around forums and social channels known as ‘The Com’. Groups like UNC6040 – sometimes observed directly targeting Salesforce through modified apps – share overlapping behaviors with UNC3944. It’s even possible there’s a direct connection.”

While these two groups are technically tracked separately, their tactics, infrastructure, and behavioral patterns suggest they could be the same actors or closely affiliated.

UNC3944 (Scattered Spider): silent exfiltration at scale

UNC3944, or Scattered Spider, is known for precision-targeted attacks that exploit trust and identity. Like UNC6040, they frequently begin with compromised credentials – often phished or purchased – and escalate access via manipulated IT support processes.

Once inside, they authorize third-party tools such as Airbyte and Fivetran to silently exfiltrate cloud data. Their techniques include:

• Persuading help desks to escalate permissions
• Exploiting identity provider (IdP) integrations
• Establishing virtual machines for persistence and staging

“Scattered Spider deploy social engineering to gain access to SaaS environments. Their attacks may look technically simple, but that doesn’t make them any less dangerous,” West adds. “They’ve been linked to the MGM and M&S breaches, and even tenuously connected to the Snowflake mass compromise. If your organisation runs Salesforce in the cloud, it’s highly likely actors like these are already looking at you.”

Their goal isn’t disruption – it’s long-term data theft, often invisible until it’s too late.

From help desk to breach: The same tactics behind the UK’s retail cyberattacks

In May 2025, major UK retailers including M&S, Co-op, and Harrods were forced offline by a wave of ransomware and data theft attacks. Investigators believe the same group, Scattered Spider (UNC3944), is behind these incidents.

What happens next is where the real damage begins: lateral movement, data exfiltration, and extortion. All from inside a trusted, integrated system.

Coca-Cola: Middle East employee data leak

In May 2025, the Everest ransomware group attacked Coca-Cola’s operations in the Middle East. The group accessed and leaked over 1,100 HR files, including:

• Personal identification documents
• Salary and banking details
• Internal org charts and account structures

The breach affected nearly 1,000 employees across the UAE, Oman, and Bahrain. Reports indicate that Salesforce file access was part of the attack chain.

Coca-Cola Europacific Partners: 23 million records exposed via Salesforce

In a separate incident, the Gehenna group breached Coca-Cola Europacific Partners (CCEP) Salesforce dashboards and exfiltrated over 23 million records. This included:

• 7.5 million account records
• 9.5 million customer service cases
• 6 million contact entries
• 400,000 product records

Sample data was published on public breach forums. The attackers also contacted employees, signaling intent to sell or release more data unless paid.

Why this matters, and what comes next

Salesforce is central to how many organizations operate. It holds loads of sensitive customer records, sales data, intellectual property, and internal support content. Files and links flow through it every day. It’s deeply integrated with other cloud services.

This level of access and automation makes it highly attractive to attackers. And yet, Salesforce environments often operate without the same level of inspection or control applied to other enterprise systems.

When observing Salesforce attacks, we’ve seen phishing links embedded in business documents. Data exfiltrated directly from support systems. Malicious files distributed via workflow automation. Each case shows how attackers use Salesforce’s built-in functionality to move laterally or extract high-value data.

This isn’t hypothetical. Threat actors are already targeting Salesforce directly – using impersonation, stolen credentials, and OAuth abuse to establish long-term access. The UK retail breaches show just how public and damaging these tactics have become.

If that’s already happening, the next question is clear: what happens when even more threat actors start treating Salesforce as the new and effective entry point?

Identity-based attacks are the common thread

Many of these Salesforce attacks don’t rely on technical exploits but succeed through access. And that access often begins with compromised credentials.

The compromise might come from a phishing link. Or from login details exposed in a third-party breach. Credentials dumped on the dark web are frequently reused across systems, giving attackers an easy way in.

This isn’t just a backend hygiene issue anymore — it’s a front-line security gap. As attackers increasingly exploit legitimate access methods and IT support workflows, even one reused password or stolen credential can open the door to Salesforce… and everything it connects to.

An evolving risk surface

Threat actors are shifting focus to systems where trust is built in. They don’t need to break through technical barriers when users are already opening the door, whether by approving a connected app, using single sign-on without MFA enforcement, or responding to a convincing IT support call.

The Salesforce threat surface is expanding:

• Users are uploading and sharing more files
• Portals and agents interact with customers at scale
• Connected apps have broad privileges, often without visibility
• Credentials are being reused or phished, giving attackers direct entry into CRM environments

In many cases, once a credential is compromised, attackers can quietly authenticate, pivot across cloud services, and extract data without triggering alarms. Access can be maintained long after the initial compromise.

Without inspection and control, these access pathways become vulnerabilities. And the cost of exposure – operational, legal, reputational, strategic – can be difficult to contain.

What you can do next in light of Salesforce attacks

You can’t prevent every phishing email. You can’t control which credentials show up on the dark web. And no help desk workflow is completely immune to social engineering.

But you can still take control over what happens next. And as these recent Salesforce attacks underline, proactive security strategies are key.

These practical recommendations help reduce risk across identity, access, and content:

Audit and visibility
Audit connected apps and user activity in Salesforce. Regularly review and revoke unused or high-privilege accesses. Monitor for suspicious login behavior.

Identity and access controls
Enforce MFA across all user roles and integrations. Apply least privilege principles and limit admin access. Harden IT support processes against impersonation tactics. Include Salesforce in access governance reviews.

Credential compromise monitoring
Ensure you can detect credential compromise, rapidly revoke access, and restore clean Salesforce configurations and data when needed.

Real-time content protection
Use natively integrated threat protection to inspect files and links directly in Salesforce. Minimize human error by preventing phishing links and malware from spreading through cases, chats, and portals – not just email.

Phishing and user awareness
Educate users about social engineering methods, voice phishing, and fake app installs targeting Salesforce. Include Salesforce-specific tactics in security awareness programs.

Third-party and integration risk
Review and vet all connected apps. Prioritize tools with native integration over custom ones. Limit the permissions of external apps and monitor usage.

Incident response preparation
Include Salesforce in incident response and recovery plans.

Real-time protection against cyber attacks targeting Salesforce

WithSecure Cloud Protection for Salesforce delivers the security visibility and control that traditional tools miss, directly inside Salesforce.

It stops malicious files and phishing links before they reach users.
It inspects content shared via email, portals, cases, and automation in real time.
And soon it monitors compromised credentials used to access your Salesforce environment.

While attackers are adapting fast, your defenses can too.

WithSecure Cloud Protection for Salesforce closes the Salesforce security gap across your workflows, and is set-up with a only few clicks.

By mitigating threats such as credential compromises, credential phishing and malware delivery, our Salesforce native security layer stops the breach before it spreads.

Prevention is always cheaper than recovery.

In May 2025, Coinbase, one of the world’s largest cryptocurrency exchanges, disclosed a data breach that involved the theft of sensitive customer information, and a $20 million extortion attempt by cybercriminals. While no funds or passwords were stolen, the breach highlights a growing and under-protected threat surface in cloud-based environments: customer support platforms and insider risk. 

This attack wasn’t sophisticated in a technical sense. It wasn’t a zero-day exploit or a brute-force intrusion. It was a breach of trust—leveraging phishing, social engineering, and human compromise at the edges of Coinbase’s trusted support environment. 

A coordinated attack: From phishing to insider breach 

According to Coinbase’s official disclosure, the attack began when cybercriminals targeted third-party customer support contractors employed outside the United States. These individuals had legitimate access to Coinbase’s support tools. The attackers used phishing and social engineering tactics to steal credentials, or in some cases, allegedly bribed support agents directly. 

While Coinbase has not disclosed every technical detail, reports suggest that stolen credentials (whether phished or willingly handed over) allowed attackers to log in to the support system using legitimate sessions. In some cases, attackers may have bypassed or exploited weak multi-factor authentication (MFA) protections. Once inside, they used standard access privileges to search and extract customer data, without triggering traditional intrusion alerts.

Once access was gained, the threat actors exfiltrated customer data, including: 

• Full names 
• Email addresses 
• Phone numbers 
• Masked Social Security Numbers (SSNs) 
• Partial bank account details 
• Account activity logs 

Coinbase confirmed that no passwords, private keys, or actual cryptocurrency funds were accessed or stolen. However, the data collected was still extremely sensitive and could easily be used for downstream fraud or phishing. 

As reported by Cointelegraph, the attackers demanded a $20 million ransom to prevent the public release of the data. Coinbase refused to negotiate and instead offered a $20 million bounty for information that led to the perpetrators’ arrest. 

Customer support: The cybersecurity front line 

Customer support environments have become attractive and exposed entry points for attackers. 

In the Coinbase case, human vulnerability enabled the breach. Rogue support agents with valid credentials and system access were either deceived or willingly participated in data theft. This is a pattern of insider threats: trusted humans inside trusted systems acting maliciously or negligently. 

It is worth mentioning that Coinbase’s support environment did not show signs of excessive permissions or privilege sprawl. The data accessed during the breach, although sensitive, was aligned with what support agents would reasonably need to perform identity verification and basic troubleshooting. In many organizations, such an incident would have exposed far more due to poorly enforced least privilege models.

The rise of the rogue support agent 

Support agents often have broad visibility into customer data, including PII, account history, financial data, and documents, to do their jobs efficiently. 

Outsourcing adds complexity: many support functions are handled by external vendors in low-cost geographies, where direct governance, training, and behavioural monitoring are more complex to enforce. 

Insider collusion is hard to detect: an attacker using a real user account with approved access can fly under the radar of traditional security tools. 

This is part of a broader trend. We’ve seen similar tactics in previous high-profile breaches, including Uber’s 2022 compromise via a support contractor, and other incidents in the healthcare and fintech sectors. 

Support systems are increasingly hybrid spaces, where external users (customers, contractors, third parties) interact with internal systems through shared channels, file uploads, and messaging. Without proper controls, these trusted gateways become perfect attack paths. 

How does the Coinbase breach compare? 

Coinbase’s breach is part of a broader pattern of high-profile attacks targeting cryptocurrency and financial firms: 

• Crypto.com (2022) – Hackers bypassed 2FA to steal over $34M from 483 users.  
• Ledger (2020) – A phishing attack on a support agent led to the leak of 1 M+ customer records.  
• FTX (2022) – Insider misuse of access contributed to catastrophic losses during the collapse investigations. 

The trend is clear: support platforms and privileged access remain critical attack surfaces, especially in fast-moving, cloud-dependent operational environments.

What Coinbase is doing now 

In response to the breach, Coinbase implemented a series of reforms and security upgrades: 

• Launching a U.S.-based support hub to reduce reliance on third-party vendors 
• Introducing scam-awareness prompts and extra ID verification for flagged accounts 
• Implementing enhanced threat detection 
• Partnering with law enforcement to investigate and recover exfiltrated data 

Coinbase’s response has been widely recognized as a standout example of transparent, decisive incident handling. Within days, the company filed an 8-K with the SEC, released a video message from the CEO, and published a detailed public blog post. All synchronized and consistent. This level of coordination reflects not only mature processes but a security-first culture, where teams across the globe took initiative and acted with clarity under pressure. Their ability to act swiftly, terminate involved parties, engage law enforcement, and flip a $20 million extortion attempt into a public bounty campaign reflects an organization with a security-first mindset.

It is good to keep in mind that Coinbase did not suffer from outages in this breach. An organization with critical systems compromised might have made different choices with the ransom.

Still, Coinbase has estimated costs of the breach between $180 million and $400 million. This is a result of remediation costs and customer reimbursements.

In the bigger picture, the breach raises a broader concern for any organization that handles sensitive data in the cloud: Are your support workflows adequately protected? 

What does it mean for Salesforce security? 

Many organizations use Salesforce as the backbone of their customer support operations. Support agents, community users, and customers routinely upload documents, share links, and communicate sensitive details inside the platform. 

While Salesforce is secure by design, it doesn’t natively scan uploaded files for malware or links for phishing, nor does it detect unusual behavioural patterns from compromised or rogue user accounts. This means: 

• Files uploaded via support cases or Experience Cloud portals can deliver malware or ransomware
• Phishing links can circulate within case comments or shared messages undetected  
• Compromised support agent and contractor accounts can perform malevolent actions without triggering alerts 

This creates a blind spot, a vulnerability window that attackers increasingly know how to exploit. These attacks don’t just target large fintechs. You may already be exposed if you rely on Salesforce for support, especially with outsourced or partner-based teams. Do you have the controls to detect and stop a trusted identity from doing untrusted things? 

Detecting & responding to support platform threats 

• Monitor file activities in support cases 
• Set user behavioural alerts
• Enforce multi-factor authentication for all support users (including contractors) 
• Regularly audit contractor access levels 
• Use real-time scanning for uploaded files and shared links 

How WithSecure Cloud Protection for Salesforce can help 

WithSecure Cloud Protection for Salesforce is built to secure the exact kind of environment compromised in the Coinbase breach, where files, links, and sensitive data move between internal teams and external users.  

• Real-time file and URL scanning: This feature automatically analyzes all file uploads and shared links within Salesforce for malware and phishing threats. 
• Sandboxing and AI detection: Suspicious files are detonated in a secure sandbox to detect zero-day or evasive threats that bypass reputational checks. 
• Compliance and visibility: You get full audit trails and data residency options, which are essential for regulated industries and outsourced operations. 

The solution runs natively inside Salesforce, ensuring low latency, high compliance, and seamless protection without moving data outside the platform. 

Why it matters 

The Coinbase breach is a wake-up call for organizations relying on cloud-based customer support and CRM systems. It was not caused by a zero-day exploit, but by trusted humans doing untrustworthy things. It was enabled by weak security visibility and inadequate defences. 

Coinbase’s breach was enabled by precisely the kind of blind spot Salesforce users often face: a trusted interface (support), a trusted identity (contractor), and a lack of real-time threat defence. WithSecure Cloud Protection closes this gap. 

Prevention is the cheapest treatment. If you’re using Salesforce to support customers, primarily through partners or contractors, don’t wait for a breach to expose your security gaps.

There’s one tactic that cyber defenders easily let slip through the cracks: the password-protected archive. A ZIP file encrypted “just in case”…. and suddenly, your scanners and gateways go blind. It’s a clever exploitation of trust: end users expect a password prompt, not a hidden payload.

How file encryption becomes an exploit

Attackers weaponize file encryption – which seemingly is there for privacy reasons. When a threat protection solution like a malware scanner encounters an encrypted attachment, it often defers inspection, tagging it as “unscannable” and forwarding it without deeper analysis. Meanwhile, the attacker conveniently shares the password in the message body or an accompanying chat, ensuring only a human user can unpack it. By the time the malicious payload emerges, it’s already doing damage.

No sophisticated zero-day exploit is needed when a basic ZIP file can evade detection simply because security tools aren’t configured to look that deep.

Last-line defenses are limited against encrypted threats

Relying solely on endpoint protection is a high-stakes gamble. Consider password-protected archives containing decompression bombs: a small encrypted file that expands into terabytes of junk, overwhelming sandbox environments and crashing AV engines.

Even if the sandbox survives, analysis is delayed as it desperately unpacks nested layers. And all the while, an end user eager to collaborate may decrypt and execute the payload before any alarm rings.

Defensive tools like antivirus with sandboxing and EDR are crucial, but they operate under the assumption that they can see what they’re scanning. Encryption breaks that assumption.

Shifting control upstream

What if we simply treated encrypted archives as policy violations? By enforcing controls at entry points like Salesforce, organizations can neutralize threats before they ever reach downstream tools or employees. With straightforward attachment policies you could quarantine or block any file flagged as encrypted. No password, no pass.

Salesforce native solution in WithSecure Cloud Protection for Salesforce

Security and Salesforce teams have a built‑in shield against encrypted archive threats. WithSecure™ Cloud Protection for Salesforce automatically detects and blocks password-protected archives on upload and download. Here’s how it works:

• File Protection: password-protected archives are identified in real time as they transit Salesforce.
• Automatic removal: based on feature settings, any detected archive is removed and replaced with a placeholder text file, ensuring no hidden payload reaches users.
• Visibility and alerts: every blocked archive generates alerts and events, giving investigating security teams immediate insight into attempted threats.
• Comprehensive format coverage: supports all popular archive formats (ZIP, RAR, 7z, ISO).

A hands‑off approach like this lets you enforce policy without complex custom triggers or workflows, while providing clear visibility and audit trails for compliance.

Prevention is the best policy

Password-protected archives grant attackers a head start. By moving our defenses upstream and treating encrypted archives as policy considerations, we cut off threats at the source. The mindset against threats like these needs to be: security begins at the gate, not at the endpoint.