Contribution
Microsoft, Salesforce, FINRA and Coalition describe the campaign and the configuration fix. The contribution here is narrower: a two-plane hunt that joins public Aura endpoint traffic to Salesforce object access, then separates expected portal activity from unauthenticated CRM scraping and its downstream social-engineering risk.
The pattern
Microsoft groups misconfigured Salesforce guest access with OAuth consent abuse and SaaS supply-chain compromise as three trusted-access paths into SaaS data. The detection gap is more specific. Web defenders see requests to a public Aura endpoint, while Salesforce defenders see object queries. Neither view proves the full chain unless the two are joined. The attacker does not need malware on an endpoint if a public portal already grants the wrong object and field permissions.
Salesforce's own guidance describes the exposed surface clearly. Experience Cloud sites can allow anonymous visitors through a shared guest user profile. That profile is meant to expose only data needed for a public site. When object access, record access, field-level security or masking are too broad, anonymous users can query Salesforce CRM objects without logging in. Salesforce says its security team observed a campaign using a modified version of Aura Inspector against the /s/sfsites/aura endpoint. The original public tool probes exposed API endpoints; the actor-modified form went further and extracted data from over-permissioned guest profiles. Microsoft adds the request mechanics: the actors chained unauthenticated Aura requests with GraphQL queries to retrieve more data than a guest user would normally be able to access.
FINRA's alert makes the operational risk less abstract for regulated firms. It says ShinyHunters was actively exploiting misconfigured Experience Cloud instances to bypass authentication requirements and access sensitive customer data, then using that data for fraud, phishing, vishing and extortion. Coalition's security alert reaches the same conclusion from a risk-monitoring lane: threat actors were scanning public Experience Cloud sites, abusing the Aura API endpoint, and scraping CRM records such as contact records and lead lists where guest profiles were too permissive.
This is a configuration-driven incident, not a Salesforce platform vulnerability. That distinction changes the response. A vulnerability patch will not close the case. The exposed condition lives in site settings, guest profiles, object permissions, field-level security, external sharing defaults, API permissions and public endpoint activity. Detection focused only on CVEs, endpoint alerts or authenticated access will not capture the initial public-portal activity.
The observed sequence starts when the actor finds a public Experience Cloud site, probes /s/sfsites/aura, tests what the guest profile can query, then extracts objects or fields that should not be public. Salesforce and FINRA report that harvested names and phone numbers have supported follow-on voice phishing, fraud and extortion. Case history, account relationships and support details would also make helpdesk impersonation more credible, but that is a defensive inference rather than a uniformly observed step in this campaign. A confirmed portal scrape is therefore both a data-exposure incident and potential reconnaissance for a human attack that follows.
Why it matters to cloud defenders
Salesforce administration, public-site operations and security monitoring often sit in different teams. Experience Cloud joins all three: it is a public-facing SaaS surface connected to CRM data. The exposed records are not low-value web content. They can include customer identity details, leads, support cases, business relationships and custom objects that explain who to call, what to ask for and which internal process to impersonate.
The misleading part is that the first observable action may be unauthenticated web traffic. There is no compromised employee account, no stolen OAuth token and no suspicious MFA change at the start. The caller or extortion email may arrive later, after the scrape. That reverses the usual identity-led ShinyHunters story. In the vishing and OAuth lane, a social-engineering event leads to SaaS data access. In the Experience Cloud lane, SaaS data access can create the target list for later social engineering.
This also crosses team boundaries. Salesforce administrators own the guest profile and sharing model. Web teams own the public portal. Security operations owns suspicious endpoint and IP behaviour. Fraud or customer-support teams may see the follow-on calls. If those groups look at their own evidence only, the incident looks like normal public-site traffic until it is already an extortion problem.
Cloud defenders should treat public CRM portals like cloud storage buckets with a business workflow attached. The question is not only whether the site is reachable. The question is what an unauthenticated principal can query, at what volume, from which networks, and whether the requested objects match public-site functionality. A partner portal may need to show a knowledge article or form metadata. It should not allow broad reads of Contacts, Leads, Cases, Accounts or custom objects that hold personal or commercial data.
The timing makes this worth review now. Salesforce updated its guidance in March after observing additional configuration scenarios, FINRA warned firms about active exploitation, Coalition reported a widespread campaign, and Microsoft re-raised the guest-access path in July as part of current ShinyHunters-linked SaaS abuse. That is enough independent signal to justify a specific detector rather than another broad SaaS-vishing recap.
ATT&CK mapping
T1190, Exploit Public-Facing Application, is the entry point for the Experience Cloud lane. This is not exploitation of a Salesforce software flaw, but it is abuse of a public-facing application boundary. The actor interacts with a public portal and its Aura endpoint, then benefits from a misconfigured access model behind that surface. In ATT&CK terms, the externally reachable application is the route into data access. The important constraint is to describe it as configuration abuse, not as a vendor vulnerability.
T1213.004, Data from Information Repositories: Customer Relationship Management Software, is the precise collection mapping beneath T1213. The target is CRM data held in Salesforce objects and fields. The sources name customer data, sensitive business data, contact records, lead lists and customer records. Those are repository reads, not endpoint file theft. T1567, Exfiltration Over Web Service, should be added to a case only when telemetry proves the transfer path rather than merely the repository query.
The follow-on social-engineering phase can touch voice phishing, OAuth consent abuse, cloud account use and application access tokens. Those techniques belong in the case narrative when the data is later used to compromise users or integrations. They should not be forced onto the portal scrape itself. The clean chain for this incident is public portal access, CRM object query, data extraction, then possible vishing or extortion built from the exposed records.
Detection guidance
Start by checking whether the required telemetry exists. Salesforce recommends Aura Event Monitoring for queries targeting objects not meant to be public, spikes from unfamiliar IP addresses and activity outside normal business hours. For Microsoft Defender for Cloud Apps connector capabilities other than SaaS security posture management, Microsoft lists Salesforce Shield as a prerequisite and recommends enabling stored data for API Event and Guest User Anomaly Event, among other events. Public sites always receive anonymous traffic, so endpoint volume alone is not enough. The detector needs object and field intent.
Microsoft provides a concrete object-level pivot in Defender for Cloud Apps. In CloudAppEvents, filter Salesforce events to ActionType == "UniqueQuery", read the full query from RawEventData.QUERY_IDENTIFIER, derive the object named after the SOQL FROM clause, and retain RawEventData.USER_ID as the Salesforce user identifier. This does not by itself prove theft. It supplies the Salesforce side of the join and shows which repository the request targeted.
Build a watchlist of Experience Cloud sites and the guest user profile behind each one. For every site, record the objects and fields the public workflow genuinely needs. Then alert when anonymous or guest-profile activity queries outside that allowlist. The highest-risk objects are Contacts, Leads, Accounts, Cases, user fields and custom objects that store personal data, credentials, entitlement data, support history, order history or commercial relationships. A single unexpected object may be a configuration mistake; repeated reads across several sensitive objects are a likely scrape.
Watch the /s/sfsites/aura endpoint as a separate public surface. Useful network signals include repeated POSTs to Aura from the same source, high request volume across many public sites, user agents that differ from normal browsers, unusual referrer patterns, requests that enumerate actions or descriptors, and requests that keep returning data while no visible public-page journey explains the access. Coalition specifically calls out unusual request volume against /s/sfsites/aura; Salesforce names the same endpoint in the campaign.
Join the web and Salesforce views as a decision path. An Aura endpoint hit with no unexpected object access is a hunt lead, not proof of compromise. A guest query outside the site's object or field allowlist is a configuration incident. Repeated or chained queries across sensitive objects from the same source network are evidence of likely scraping. Raise severity again when returned data includes phone numbers, email addresses, account ownership, case notes, security-contact details or fields that could support impersonation. This ordering keeps ordinary public traffic below the incident threshold while escalating the behaviour the sources describe.
Add a second-stage watch after any suspected scrape. Look for new calls, tickets or email lures that reference recently exposed Salesforce data. Monitor helpdesk resets, MFA enrolment requests, new connected apps, OAuth consent events, unusual Salesforce Data Loader clients and CRM exports involving the affected accounts. This is where the Experience Cloud lane can converge with the OAuth and vishing lanes Microsoft describes. The public portal event may be the first half of the same intrusion chain, not a separate low-severity web issue.
False positives come from legitimate public-site traffic, search indexing, QA tests, partner integrations and marketing forms. Tune by site, object and workflow, not by suppressing Aura traffic as a category. A customer-facing form can explain reads of a small public object. It does not explain unauthenticated access to lead lists, case descriptions, internal user fields or broad custom objects.
Response should be configuration-first. Disable guest API access where it is not required, remove API Enabled from guest profiles, set external organisation-wide defaults to Private, remove object and field access that public users do not need, review field-level security on Contact, Lead, Case and custom objects, and disable self-registration where it is not required. Preserve available Aura, API, web and WAF evidence as containment begins, without delaying the permission change, because the same records will be needed for exposure assessment and any notification decision.
What to do now
Treat the audit as a data-exposure exercise, not as a patch ticket. List every Experience Cloud site, identify its guest user profile, and write down the exact objects and fields a public visitor needs. Start from zero access and add back only what the site function requires. Salesforce calls disabling public API access the highest-impact single change because it closes the Aura endpoint to unauthenticated API queries used in the campaign.
Next, make the detection join explicit. Send Salesforce Event Monitoring, web access logs, WAF logs and helpdesk or fraud reports into one investigation view. The useful joins are site ID, source IP, user agent, endpoint path, guest profile, object, field, record count and event time. If a suspected scrape touches customer contact data, tell the teams that handle inbound support calls and account recovery before the actor uses that data against them.
Finally, do not let the configuration fix erase the incident. If logs confirm guest access to sensitive records, treat those records as potentially disclosed unless evidence bounds the returned data more narrowly. Review who was exposed, what fields were returned, whether the source networks match known scanning or actor infrastructure, and whether later OAuth, helpdesk or voice-phishing events touched the same population. That is the practical defence: close the public portal gap, then hunt the human attack it may have enabled.