Background and context
ShinyHunters, a threat group long associated with data theft, extortion, and the sale of stolen records, is reportedly claiming a fresh campaign affecting nearly 400 websites tied to Salesforce Experience Cloud environments, according to Infosecurity Magazine [1]. The scale alone makes the incident notable, but the deeper lesson is more important: this appears to fit a broader pattern of attackers abusing cloud identities, SaaS permissions, and customer portal configurations rather than exploiting a newly disclosed Salesforce software flaw.
Salesforce Experience Cloud is used to build customer, partner, and employee-facing portals. These sites often sit on branded domains and give external users access to support cases, account information, knowledge bases, or business workflows. That makes them valuable targets. If an attacker can gain access to the right account, connected app, or integration token, they may be able to pull large amounts of sensitive data while appearing to act like a legitimate user.
At the time of writing, public reporting has not tied this campaign to a specific CVE or confirmed a breach of Salesforce’s core platform itself [1]. That distinction matters. Many major SaaS intrusions over the past two years have involved valid credentials, infostealer-captured logins, consented OAuth applications, or social engineering of support staff rather than direct exploitation of a vendor bug. CISA and major incident response firms have repeatedly warned that identity and cloud control planes are now prime targets for threat actors [2][3][4].
ShinyHunters is not a new name in this space. The group has been linked in public reporting to multiple high-profile breaches and criminal marketplaces involving stolen data [5]. Its alleged involvement here is consistent with a criminal model centered on broad data acquisition, monetization, and pressure campaigns against victims.
What may be happening technically
Based on the reporting available, this campaign looks less like “Salesforce got hacked” and more like “Salesforce customer environments were accessed through weak points around identity and configuration.” That is an important difference for defenders.
Salesforce Experience Cloud deployments commonly rely on several moving parts: internal Salesforce users, external portal users, identity providers, connected apps, APIs, and third-party integrations. Any of those can become an entry point if they are over-permissioned or poorly monitored.
The most plausible attack paths include credential theft. Attackers frequently buy or harvest credentials from phishing kits and infostealer malware logs, then test them against SaaS services. If a user reused a password or if multifactor authentication was weak, bypassed, or reset through social engineering, the attacker may gain direct portal or admin access [3][4].
Another likely vector is OAuth or connected app abuse. In Salesforce, connected apps can authorize API access to tenant data. If a user or administrator approves a malicious or over-privileged app, the attacker can maintain access through tokens instead of repeated logins. Microsoft, Google, and CISA have all documented how consent phishing and token abuse can turn a one-time mistake into durable cloud access [2][6].
Misconfiguration is also a realistic factor. Salesforce has previously published guidance around securing guest user access, sharing rules, and Experience Cloud visibility because poorly scoped permissions can expose records to unintended audiences [7][8]. In some environments, external users may be able to view more customer records, case histories, or document content than intended. Even where records are not fully public, a compromised partner or customer account can still be enough to scrape valuable data at scale.
Integration credentials present another risk. Many organizations connect Salesforce to marketing tools, support systems, analytics platforms, and internal applications. If API keys, service accounts, or bearer tokens tied to those integrations are stolen, attackers may bypass the normal user interface entirely and exfiltrate data through APIs.
Defenders should also remember that SaaS-native intrusions often produce subtle indicators. Instead of malware alerts on endpoints, the warning signs may be impossible-travel logins, unusual API spikes, new connected apps, mass report exports, changes in sharing settings, or suspicious MFA reset events. Salesforce’s Event Monitoring, Login History, and Setup Audit Trail are therefore central to any investigation [9].
Why the “400 websites” claim matters
The reported figure of nearly 400 websites should be read carefully. It may refer to portal domains, community subdomains, or branded sites rather than 400 entirely separate companies [1]. Even so, that still points to broad targeting across a shared SaaS ecosystem.
That kind of scale matters because Experience Cloud sites often hold data that is immediately useful for fraud and follow-on attacks: names, email addresses, phone numbers, support interactions, account identifiers, and business relationship details. In some sectors, portals may also expose invoices, case notes, internal documentation, or regulated data.
If the claims are substantiated, the impact could reach several groups at once:
Organizations operating Experience Cloud portals: They may face incident response costs, legal review, customer notification duties, and reputational harm. Public companies may also need to assess securities disclosure obligations depending on materiality.
Customers and portal users: Stolen data can fuel phishing, account takeover attempts, social engineering, identity fraud, and targeted scams. Support case history can be especially useful to criminals because it gives them context to impersonate a trusted company convincingly.
Partners and contractors: Partner portals often expose relationship maps, contact lists, order details, and account notes. That information can be abused for business email compromise and supply-chain fraud.
Admins and support teams: These users are often the next target. Once attackers know which organization uses Salesforce and who manages access, they can mount tailored help-desk impersonation attempts.
Severity will vary by tenant. A well-segmented portal with limited data exposure may contain the damage. A loosely configured environment with broad sharing rules or over-privileged service accounts could suffer much deeper compromise.
The bigger security lesson
This incident fits a wider shift in enterprise attacks: adversaries increasingly prefer legitimate access paths over noisy exploitation. That means identity hygiene, cloud logging, and permission design now carry as much weight as patching. The lesson is not that Salesforce is uniquely insecure; it is that external-facing SaaS platforms concentrate valuable data and business workflows in one place.
Organizations often invest heavily in endpoint detection while giving less attention to SaaS telemetry and tenant hardening. That gap can be costly. If an attacker signs in with a real account or approved token, traditional security tools may see very little that looks malicious.
There is also a privacy angle. Customer portals frequently retain more data than users expect. Data minimization, field-level restrictions, and shorter retention periods can reduce the value of any single compromise. Where sensitive records must be stored, stronger access controls and encryption practices help limit exposure if data is intercepted or exfiltrated.
How to protect yourself
If your organization uses Salesforce Experience Cloud, the immediate priority is to validate whether your tenant shows signs of identity abuse or excessive data access.
Review Salesforce logs now. Check Login History, Event Monitoring, Setup Audit Trail, report exports, and API activity for unusual access, especially logins from unfamiliar locations, sudden spikes in record retrieval, or newly authorized connected apps [9].
Audit connected apps and OAuth grants. Remove apps that are unnecessary, unknown, or over-privileged. Revoke suspicious refresh tokens and rotate credentials tied to integrations.
Harden MFA and account recovery. Use phishing-resistant MFA where possible, and tighten help-desk verification for password or factor resets. Many cloud intrusions succeed because recovery workflows are easier to manipulate than the login itself [2][3].
Reassess Experience Cloud permissions. Review guest access, sharing rules, profiles, permission sets, and external user visibility. Confirm that portal users can only access the minimum records and fields needed for their role [7][8].
Rotate and secure integration secrets. Inventory service accounts, API tokens, and middleware credentials connected to Salesforce. Remove stale integrations and rotate secrets that may have been exposed.
Monitor for mass export behavior. Set alerts for unusual report downloads, bulk API extraction, and changes to data-sharing settings. SaaS attacks often reveal themselves through volume and timing rather than malware.
Prepare user-facing defenses. If customer data may have been accessed, warn users about phishing and impersonation attempts. Encourage unique passwords and the use of a trusted VPN service on untrusted networks for general privacy protection, though a VPN does not stop account takeover by itself.
Minimize exposed data. Remove unnecessary sensitive fields from external portals, shorten retention periods, and separate high-risk records from broadly accessible community content.
What comes next
The biggest unanswered questions are whether named victims will confirm intrusions, whether any common intrusion path emerges across cases, and whether the “nearly 400 websites” figure reflects successful compromises, attempted targeting, or a mix of both. Until more detail is available, the safest interpretation is that this is a large-scale campaign exploiting the weak seams around SaaS identity and portal governance.
For defenders, that means looking beyond CVE hunting. The most urgent controls here are visibility into cloud activity, tighter permissions, stronger identity verification, and faster detection of abnormal data access. If ShinyHunters’ claims are even partly accurate, the campaign is another reminder that one of the fastest ways into enterprise data is not through a firewall or endpoint at all, but through a trusted portal account that was never meant to be trusted this much.
Sources: [1] Infosecurity Magazine; [2] CISA Secure Cloud Business Applications guidance; [3] Google Cloud/Mandiant threat reporting; [4] Microsoft threat intelligence on identity attacks; [5] U.S. Department of Justice case materials on ShinyHunters-related activity; [6] Microsoft guidance on OAuth app consent risks; [7] Salesforce Experience Cloud security guidance; [8] Salesforce guest user access guidance; [9] Salesforce Event Monitoring documentation.
