Salesforce Experience Cloud Under Siege: Detecting and Blocking AuraInspector Mass Scans

The democratization of cybersecurity tools is a double-edged sword. While open-source utilities empower developers to build robust applications, they also provide threat actors with ready-made weapons for reconnaissance. This reality is currently playing out across the Salesforce ecosystem. Security researchers at Salesforce have identified a surge in mass-scanning activity targeting Experience Cloud sites. Attackers are leveraging a customized version of a legitimate developer tool, AuraInspector, to hunt for misconfigurations that expose sensitive data to unauthorized public access. This isn't a sophisticated zero-day exploit; it is a relentless, automated exploitation of "config-day" vulnerabilities—specifically, overly permissive guest user settings.

The Attack Vector: Weaponizing Developer Tools

To understand the threat, we must look at the Salesforce architecture. Experience Cloud (formerly known as Communities) allows organizations to build external-facing portals and websites. These sites often rely on "Guest Users"—unauthenticated profiles that allow public visitors to interact with the platform without a login. This functionality is critical for public support forums or lead generation forms, but it becomes a liability when permissions are left wide open.

The attack focuses on the Aura Component Framework, Salesforce's proprietary UI framework. AuraInspector is a standard open-source Chrome extension designed to help developers debug Aura components by visualizing the component tree and inspecting data passed between the client and server. In the hands of a threat actor, this tool has been modified to operate at scale.

The modified tool iterates through potential Apex classes and objects, sending requests to the Salesforce server via the /aura endpoint (specifically targeting the AuraDispatcher). The goal is to determine if the Guest User profile has "Read" or "Update" permissions on sensitive objects or fields. The tool checks for API access flags like isAccessible or isUpdateable. If the response returns true, the attacker has identified a data leak vector.

Tactics, Techniques, and Procedures (TTPs)

• Automated Reconnaissance: High-volume requests to /services/data/v59.0/aura (or similar versions) from varying IP addresses.
• Object Enumeration: Rapid querying of standard and custom object definitions to map the database structure.
• Data Exfiltration: If permissions allow, bulk downloading of PII or intellectual property accessible to the Guest User profile.

Detection and Threat Hunting

Detecting this activity requires analyzing Salesforce Event Monitoring logs, specifically Uri pathways and EventIdentifier logs looking for Aura-based interactions. Below are detection mechanisms for your SOC to identify active scanning or exploitation.

KQL Query (Microsoft Sentinel / Defender)

This query identifies suspicious high-frequency access to Aura endpoints, indicative of a scanning tool rather than normal user navigation.

SalesforceEventLog
| where TimeGenerated > ago(24h)
| where Uri contains "/aura"
| where OperationName == "AuraDispatcher"
| summarize count() by SourceIp, UserId
| where count_ > 50 // Threshold tuning required based on traffic volume
| join kind=inner (SalesforceEventLog
    | where TimeGenerated > ago(24h)
    | where Uri contains "/aura"
    | project TimeGenerated, SourceIp, UserId, RequestUri, UserAgent) on SourceIp, UserId
| project TimeGenerated, SourceIp, UserId, RequestUri, UserAgent, count_
| order by TimeGenerated desc

Python Log Analysis Script

If you are exporting logs locally or using a custom SIEM ingest, this Python script can flag potential AuraInspector mass scanning by analyzing the frequency of unique Aura endpoint calls from single IPs.

import 
from collections import defaultdict

def detect_aura_scanner(logs):
    ip_aura_count = defaultdict(int)
    suspicious_ips = set()
    
    for entry in logs:
        # Log format expected: {'timestamp': str, 'ip': str, 'uri': str, 'method': str}
        uri = entry.get("uri", "")
        ip = entry.get("ip", "")
        
        # Check for Aura dispatcher endpoint usage
        if "/aura" in uri and ("AuraDispatcher" in uri or "preload" in uri):
            ip_aura_count[ip] += 1
            if ip_aura_count[ip] > 100: # Threshold for potential scanning
                suspicious_ips.add(ip)
                
    return suspicious_ips

# Example usage:
# with open('salesforce_logs.', 'r') as f:
#     logs = .load(f)
#     print(f"Suspicious IPs: {detect_aura_scanner(logs)}")

Mitigation Strategies

Stopping these attacks requires a shift in mindset from "patching" to "configuring." Since the vulnerability is a permission setting rather than a code flaw, applying a security patch won't solve the problem. Immediate action is required.

1. Audit Guest User Access: Immediately review the "Guest User" profile for every Experience Cloud site. Ensure that Read and Edit access is removed for all objects that are not strictly required for public consumption. The principle of least privilege is paramount here.

2. Restrict Site Access (IP Whitelisting): If your Experience Cloud site is intended for a specific audience (e.g., partners or employees) rather than the general public, configure "Network Access" settings in Salesforce to whitelist only trusted IP ranges. This effectively neutralizes the mass-scan threat for external actors.

3. Disable Debug Mode in Production: Ensure that AuraInspector and debug tools are disabled in production environments. This prevents the tool from attaching to the component tree and enumerating server-side controllers.

4. Enable Event Monitoring: Ensure Salesforce Shield Event Monitoring (or standard EventLogFile) is enabled and forwarding to your SIEM. You cannot hunt what you cannot see.

Related Resources

Security Arsenal Alert Triage Automation AlertMonitor Platform Book a SOC Assessment platform Intel Hub