An Uninvited Guest

Internet-facing services can almost always be hacked by threat actors in one way or another.

But what if an attacker could simply bypass any authentication mechanisms, and just walk in the front door? Would they enter? And what could they do with that access?

In this blog, we’ll look at how a misconfiguration in Salesforce’s Guest User Profile settings can unintentionally expose sensitive data and access to unauthenticated users.

No Hacking Required

In this case, a publicly exposed Salesforce Experience site allows for a "Guest User Profile" in order to provide anonymous, unauthenticated visitors with access to data that’s intended to be public-facing. Its purpose is legitimate and is intended to provide a convenient way to grant the customers access to resources like the company's help center, a public knowledge base, a product catalog, etc.

Salesforce admins configure what the Guest User is allowed to access. If they grant access to internal CRM objects (a type of record stored in Salesforce that holds real business data like customer records, contacts, or financial data), then every anonymous visitor on the internet can access that internal data, including threat actors.
By abusing the way that guest access is configured, an unauthenticated attacker can interact with functionality that normally shouldn’t be exposed.

AuraInspector is an open-source auditing tool developed by Mandiant (Google) for legitimate administrative and debugging purposes of Aura components and endpoint (/s/sfsites/aura) in Salesforce environments.

ShinyHunters, a well-known cybercriminal group responsible for numerous high-profile data breaches, claimed to have modified AuraInspector.
If accurate, the same tool built to help defenders find exposure has just become an attack tool that can:

• Automate mass scanning across thousands of Salesforce sites
• Identify which sites have a misconfigured Guest User Profile with "interesting" permissions
• Automatically extract data from vulnerable endpoints at scale
  

ShinyHunters flipped AuraInspector’s original purpose and used the same visibility it provides to instead find and exploit the very problems it identifies.

Attack Flow Summary

We know that ShinyHunters has been targeting Salesforce for a while now (ShinyHunters and UNC6395: Inside the Salesforce and Salesloft Breaches and Scattered Lapsus$ Shiny Hunters Strikes Salesforce Again, for example), but when exactly did they begin targeting misconfigured Salesforce Experience Cloud sites? They told BleepingComputer of this in September 2025, but who can tell?

Either way, AuraInspector was released this January and the attack's first public disclosure was published on March 9.

Given the nature of the attack, it can't simply be patched. We can assume for a fact that it’s still ongoing and that it will remain that way, as long as misconfigured instances exist (which, given the scale, is likely to be quite a while).

Now that we understand the context and timeline, let’s walk trough the attack flow step by step:

1. Mass Scanning: Automating mass scanning across thousands of public Salesforce Experience Cloud sites.
2. Identifying the Target: Which sites have misconfigured Guest User Profile (excessive permissions)?
3. Targeting the Aura API Endpoint: ShinyHunters hit the /s/sfsites/aura endpoint, which is the backend API that powers Salesforce's Aura (Lightning) frontend framework.
4. Query CRM Data as a Guest: Since Guest User profiles are misconfigured with API access enabled, unauthenticated requests to /s/sfsites/aura endpoint, can query internal CRM records.
5. Bypass Record Limits: Salesforce limits API queries to 2,000 records at a time (a standard platform constraint documented in Salesforce's developer resources). ShinyHunters found a way to bypass this limit.
6. Automate Exfiltration at Scale: By using their modified version of AuraInspector, they automate the mass extraction of data.

When Complexity Becomes the Attack Surface

Even though it’s tempting to think the root cause for this attack is the misconfiguration in Salesforce’s Guest User Profile settings, it’s actually much more profound.

What makes this attack so effective is the combination of multiple conditions aligning, as opposed to just one mistake:

1. Misconfiguration is Easy to Make: Salesforce is an extremely complex platform. Setting up Experience Cloud correctly requires deep knowledge of its permission model.
   Many admins don't fully understand the implications of enabling API access on a guest profile.
2. The Attack Requires Zero Authentication: The attacker doesn't need to steal credentials, find a software vulnerability, bypass MFA, or any other authentication mechanism. Anyone on the internet can simply access it. This makes it quite easy to exploit at scale.
3. The Endpoint is Public by Design: /s/sfsites/aura is a legitimate endpoint that has to be publicly accessible for the Experience Cloud site to function.
4. Aura is a powerful API endpoint: Its components communicate with one another through events and attributes. Aura also has access to the Salesforce Apex server, which allows them to communicate with the server and retrieve or update data as needed.
5. Easy to Miss: Since Aura Endpoint is public by design, it blends in with normal traffic and doesn't raise immediate suspicion. Security teams also typically weren’t monitoring guest user query volumes, focusing instead on network perimeters and endpoints rather than Salesforce API logs.
6. Scale Through Automation: AuraInspector provided visibility and understanding that allowed ShinyHunters to modify it and automate the entire attack.
   

In short: a powerful public API + overly permissive anonymous access + lack of monitoring = a database exposed to anyone on the internet.

When the Breach Is Silent

For organizations that rely on Salesforce as a central hub, the prospect of data theft or extortion by a threat actor poses a serious business risk:

ShinyHunters claims to have breached 300 to 400 organizations, extracting full CRM records (customer names, phone numbers, financial data, and business relationships). The stolen data is just the beginning. Besides the extortion demands, the breached organizations also face regulatory violations (under privacy laws like GDPR) and reputational damage.

For the customers whose data was exposed without their knowledge, the risk doesn't end when the breach is discovered. Once that data is out, it doesn't just sit on a dark web forum. It circulates and gets resold. This attack didn't just expose data, it exposed the people behind it; this data can be resurfaced in future attacks for targeted phishing emails, vishing calls to unsuspecting customers, identity fraud, and so on. The most troubling part? Many of the 300+ affected companies still don't know they were targeted and breached.

Are You Exposed?

The attack is relatively easy to detect if an organization is actively logging its Aura endpoint traffic.
There are a few detection approaches to detect whether a Salesforce site is vulnerable:

1. Monitor the Aura Endpoint

Based on what’s currently known, the attack always hits /s/sfsites/aura.
Look for:

• High volume of requests to this endpoint
• Unusual query patterns of requests querying CRM objects (Contacts, Accounts, etc.) from unauthenticated sessions
• Large response payloads from guest/anonymous sessions. Legitimate public pages rarely return bulk CRM data

2. Check Your Guest User Profile Right Now

This is the fastest "are you vulnerable?" check:

• Go to Setup → Guest User profile of your Experience Cloud site
• Review which objects and fields it has Read access to
• If it has access to Contacts, Accounts, or any sensitive object - you're exposed

3. Check your Web Application Firewall (WAF)

If you have a WAF in front of your Salesforce Experience Cloud site, look for:

• Unauthenticated sessions making repeated high-volume requests to /s/sfsites/aura
• Sequential pagination patterns: repeated queries that appear to be stepping through CRM records in chunks
• AuraInspector-like query structures: identical query patterns targeting CRM objects in rapid succession
• IPs generating bulk unauthenticated API call volumes

4. Salesforce Event Monitoring (if licensed)

Salesforce's Event Monitoring add-on logs API activity including Guest User queries.
Look for:

• Guest user sessions querying sensitive objects
• Abnormally large record counts being returned
• Repeated almost identical queries in a "machine speed"

5. Salesforce Shield (if licensed)

If you have Salesforce Shield, use Field Audit Trail and Platform Encryption. Shield also enhances event visibility for detecting abnormal data access patterns.

This Attack is Persistent and Ongoing

As of this writing, the attack is still ongoing. With no platform-level patch and many organizations yet to audit their configurations, there’s no clear end in sight. ShinyHunters isn't finished, and the misconfigured Salesforce instances aren't going anywhere on their own. If your organization uses Salesforce Experience Cloud, it’s not a question of if, but a question of when you will be targeted. Audit your Guest User permissions. Turn on monitoring for your Aura and for any other internet-facing endpoint.

ShinyHunters didn't invent a new class of attack. They found something old and overlooked and scaled it. The real takeaway isn't about Salesforce, it's about the widening gap between the complexity of the platforms we rely on and our ability to secure them.
As enterprise software becomes more powerful and more customizable, the attack surface grows with it. We don't know what ShinyHunters will target next, but this attack reveals that they are locating and targeting misconfigured, public-facing APIs on trusted enterprise platforms.

In other words, it seems that attackers are targeting misconfigurations over vulnerabilities.‍

What other platforms in your stack have the same profile?