top of page

Systemic Incident Analysis: Case #1 - Salesforce

  • Neil Hare-Brown
  • Sep 1
  • 4 min read

Updated: Sep 3

Systemic Incident Type Analysis

In our attempts to take a practical approach to the potential for systemic cyber incidents, this is the first article of several documenting our analysis of incidents affecting widely used technologies. We have taken a global view of incidents over the last three years, emphasising 2025 with a focus on:

  • whether there was a spike;

  • whether attackers have deliberately focused on the technology;

  • whether the technology’s complexity and defaults contributed;

  • consistency of the technology vendors advice; and

  • practical recommendations.


Cyber Incidents Involving Salesforce Technologies (2023–2025)


Executive summary


  • A spike in incidents in 2025. A clear escalation in Salesforce-centred data breach/theft/extortion campaigns in 2025, driven by vishing + OAuth abuse (UNC6040/ShinyHunters). Multiple high-profile victims (e.g., Google, Air France–KLM, Workday CRM, Allianz Life, Salesloft).

  • Deliberate targeting. Reporting and threat intel show purposeful focus on Salesforce: attackers social-engineered users to authorise malicious Connected Apps (often masquerading as Data Loader) to extract data via legitimate APIs.

  • Design & defaults matter (2023). Large-scale Experience Cloud (Communities) leaks in 2023 were not a Salesforce code bug, however the access-control design and permissive/complex defaults made risky states easy to reach, leading to widespread guest-user data exposure.

  • Vendor posture. Salesforce issued guidance (notably Mar-2025) stressing shared responsibility and best practices. However, key gaps remained (OAuth approvals post-MFA; app spoofing). There is no public evidence Salesforce proactively surveyed its specialist workforce/partner ecosystem to reveal these misconfigurations before the 2023 disclosures. This is a pattern mirrored across vendors such as Oracle, CrowdStrike, etc., who typically react 'post-incident'.


Incident timeline & attack patterns


2023: Public data exposures via Salesforce Communities


  • What happened A shocking number of organisations exposed private data through guest-user access misconfigurations on public Salesforce sites.


  • Design critique Although labelled “not a vulnerability,” the guest access model and permissive defaults made insecure deployments easy, especially under time pressure. Secure-by-default was not achieved.


2024: Customisation risks & SaaS targeting


  • Researchers highlighted risks from Apex/custom app misconfigurations and noted threat actors pivoting to SaaS data stores.


2025: Coordinated Salesforce data-theft/extortion


  • TTPs. Vishing + OAuth device flow abuse Attackers phoned employees, impersonated IT, and tricked them into authorising malicious Connected Apps (often fake “Data Loader”). Tokens granted API access; data exfiltration followed.


  • Victims: Confirmed reports Organisations including Google, Cisco, Qantas, Workday, Allianz Life (1.1M impacted), luxury brands under LVMH. Campaigns claimed up to ~91 orgs breached.

    Conclusion: Compared with 2023–24, 2025 marks a pronounced spike in Salesforce-specific attacks.


Are attackers focused on Salesforce?

Yes. The repeatable technique (OAuth + vishing), applied across dozens of organisations, shows attackers have deliberately selected Salesforce because it centralises valuable data and offers scalable API-based exfiltration once access is obtained.


Did Salesforce’s complexity and defaults contribute?


  • 2023 Communities. Guest access design and defaults made insecure states common.

  • 2025 OAuth. App authorisation occurred after MFA, lacked re-auth prompts, and allowed spoofing of known apps. Many orgs left Connected App policies permissive.

  • Apex/custom apps. Elevated default privileges created opportunities for data leaks if developers omitted “with sharing”.


Bottom line: Platform power + complex config + permissive defaults increased risk.


Salesforce’s official guidance and response


  • Acknowledgement Salesforce emphasised no platform vulnerability and blamed misconfigurations or social engineering.

  • Advisories March-2025 blog advised IP restrictions, least privilege, Connected App controls, Shield monitoring, user education.

  • Gaps Attack path exploited post-login OAuth authorisation, which Salesforce guidance did not neutralise with product-level safeguards.

  • Proactivity No evidence Salesforce proactively surveyed its consultant/partner base to surface systemic flaws ahead of disclosure; typical vendor pattern of reactive advisories.


Common attack vectors & weaknesses

Vector

Abused via

Result

Guest access misconfig (2023)

Overly broad guest profiles/fields

Public data exposure

Vishing + OAuth (2025)

Malicious Connected App approvals

Bulk data exfiltration

Over-permissive roles

Excessive admin/export rights

Greater blast radius

Weak app allow-listing

Users free to authorise impostors

App spoofing succeeded

Monitoring gaps

Limited event/transaction logs

Late detection

Recommendations


  1. People & process

    1. Anti-vishing training. Teach users never to approve Connected Apps on caller instruction. Run vishing drills.

    2. Change control for integrations. Require admin approval for any new Connected App/OAuth authorisation.

  2. Identity & access

    1. IP restrictions. Enforce login IP ranges, at least for privileged accounts.

    2. Step-up auth for setup. Add re-auth/MFA for app authorisation and export settings.

    3. Least privilege. Limit “Modify All Data,” restrict Data Loader use, minimise export rights.

  3. Platform hardening

    1. Connected App control. Allow-list known apps; alert on any new authorisations; disable device flow unless needed.

    2. Communities audit. Use Guest User Access Report; remove unnecessary object/field exposure.

    3. Monitoring. Enable Event Monitoring/Transaction Security or export to SIEM; alert on abnormal data pulls or new apps.

    4. Secure custom code. Review Apex for “with sharing,” validate input, run static code scans.

    5. IR readiness. Maintain backups; pre-planned runbooks for revoking OAuth tokens and breached data discovery and classification.

  4. Vendor accountability & ecosystem

    1. Contractual requirements. Customers should compel or contractually require Salesforce and other critical SaaS vendors to operate programmes designed to reveal design flaws and common risky misconfigurations before exploitation. These programmes should include systematic surveys of vendor field engineers, partner networks, and customer deployments.

    2. Government / CERT / insurer oversight. This obligation should also concern governments, CERTs and cyber insurers. Vendors failing to proactively address systemic flaws should be recognised as contributing to systemic cyber risk. Regulators and underwriters should incentivise 'secure-by-default' configurations and continuous design-level assurance.


Adequacy of Salesforce’s advice


  • Strengths. Provided timely 2025 advisory, detailed defensive measures, reinforced MFA/IP/least-privilege.


  • Shortcomings. Did not introduce product-level friction against OAuth spoofing; reliance on customer vigilance. Lack of evidence of proactive ecosystem-wide surveying prior to 2023 exposures.


Sources & recent coverage


  • KrebsOnSecurity (Apr-2023): Experience Cloud misconfigs.

  • Google Threat Intelligence (Jun-2025): UNC6040 vishing/OAuth campaign.

  • Reuters (Jun-2025): ~20 orgs impacted.

  • Salesforce (Mar-2025): Protect Your Salesforce Environment from Social Engineering Threats.

  • BleepingComputer / TechCrunch (Aug-2025): Workday, Google, Allianz Life cases.

  • SOCRadar (Aug-2025): ~91 organisations claim.

 
 

Recent Posts

See All

Speak with a cybersecurity specialist

Contact the team at STORM Guidance:

UK/Europe: +44-203-693-7480

Africa: +230-434-1277

India: +91-80010-04277

USA: +1-703-232-9015

Your contact details will only be used in connection with this enquiry.

Please read our Privacy Policy.

I'm enquiring as
bottom of page