Microsoft Maps Three Salesforce Attack Paths Tied to a Year of ShinyHunters Activity

Microsoft's threat intelligence team has published a detailed breakdown of three distinct attack paths used by actors whose techniques align with the ShinyHunters data-extortion group to compromise corporate Salesforce environments. The research covers approximately a full year of activity, and notably, not a single intrusion required exploiting a flaw in Salesforce's platform. Instead, attackers walked in through legitimate front doors — using stolen credentials, abused OAuth tokens, and misconfigured integrations to gain persistent access.

ShinyHunters: Background

ShinyHunters emerged as a significant threat actor around 2020, initially known for data theft and sale on cybercrime forums. Over time, the group — or actors using overlapping tradecraft — evolved toward direct extortion, threatening to publish stolen data unless victims pay. High-profile incidents linked to the group's methods have affected technology companies, healthcare organizations, and retailers across multiple countries.

The group's trademark is not technical sophistication but operational patience: spending extended periods inside compromised environments, exfiltrating data quietly before making contact with victims. Salesforce CRM systems are a prime target because they contain customer contact records, deal pipelines, support histories, and often deeply sensitive business intelligence.

Attack Path 1: Credential-Based Access via Phishing and Infostealer Logs

The first and most common path documented by Microsoft involves compromised Salesforce credentials obtained through:

• Phishing campaigns specifically crafted to harvest Salesforce login pages, often using reverse-proxy phishing toolkits like Evilginx2 that capture session tokens alongside credentials — bypassing SMS-based MFA.
• Infostealer malware logs — a growing underground market where credentials from infected endpoints are sold in bulk. Attackers search these logs specifically for *.salesforce.com or *.my.salesforce.com entries.
• Credential stuffing against organizations that reuse passwords across services.

Once inside, attackers used Salesforce's built-in data export features — legitimate admin tools — to extract contact records, accounts, opportunities, and custom object data in bulk, generating minimal security alerts since the tools are designed for normal business use.

Key observation: Organizations that rely solely on MFA through SMS or TOTP are not protected against the phishing-plus-session-token approach. Phishing-resistant MFA (FIDO2/WebAuthn) is the recommended countermeasure.

Attack Path 2: OAuth Application Abuse

The second path exploited Salesforce's Connected Apps (OAuth 2.0) integration framework. The attack sequence:

1. Attacker gains initial access to a target employee's email account or cloud identity.
2. A malicious or compromised OAuth application is authorized to access the victim's Salesforce data — either by convincing the user to authorize it directly, or by exploiting an already-authorized third-party integration that the attacker has separately compromised.
3. The attacker uses the OAuth access token to query Salesforce APIs (REST, Bulk, or Tooling API) from their own infrastructure, exfiltrating data without ever appearing to log into Salesforce interactively.

This path is particularly difficult to detect because:

• OAuth token usage can look identical to legitimate integration traffic.
• Many organizations have dozens of authorized Connected Apps and rarely audit which ones are still active or necessary.
• The actual data access occurs via API rather than the Salesforce UI, potentially evading session monitoring focused on browser-based logins.

Microsoft notes that several victims had long-forgotten integrations — apps authorized years prior that remained active — which were leveraged by attackers after compromising the third-party vendor that originally built the integration.

Attack Path 3: Salesforce Community and Experience Cloud Misconfigurations

The third path exploited Salesforce Experience Cloud (formerly Community Cloud) portals — externally accessible sites that organizations build for customer self-service, partner collaboration, or public-facing content. The attack leveraged:

• Guest user permissions set too broadly, exposing records beyond what external visitors should see.
• Sharing rules and org-wide defaults misconfigured to allow the Guest profile to read internal Account, Contact, or Case records.
• Salesforce API access left enabled on Guest profiles, allowing bulk data retrieval without authentication.

In these cases, no credentials were needed at all. Attackers identified misconfigured Experience Cloud sites (often through public footprinting), then used the Salesforce REST API with the Guest user context to query and export data at scale.

This type of misconfiguration is well-known in the Salesforce security community and has been documented since at least 2021, yet Microsoft's research indicates it remains prevalent and actively exploited.

Common Post-Compromise Behaviors

Across all three paths, Microsoft observed consistent post-access behaviors:

• Bulk data export via Salesforce's Data Export service or API — prioritizing contact records, account lists, and deal data.
• Creation of new admin accounts or Connected App credentials to maintain persistent access after the initial entry point is remediated.
• Reconnaissance within the org using SOQL queries to enumerate available objects and identify the highest-value data stores.
• Low-and-slow exfiltration spread across weeks or months to avoid triggering data volume anomaly alerts.

Defensive Recommendations

Microsoft's report includes a set of hardening recommendations directly applicable to Salesforce administrators:

Identity and Access

• Enforce FIDO2-based MFA across all Salesforce users — not SMS or TOTP where phishing-resistant alternatives exist.
• Enable Salesforce's Enhanced Security Policies to restrict login from untrusted IPs and devices.
• Conduct a Connected Apps audit — revoke any OAuth applications that are no longer needed, and review the permissions granted to remaining integrations.

API and Data Access Controls

• Restrict API access to known trusted IP ranges where operationally feasible.
• Enable Salesforce Shield or equivalent monitoring for API-based data access anomalies, particularly bulk exports.
• Review Data Export settings and restrict the ability to generate full org exports to a small number of verified admins.

Experience Cloud / Community Hardening

• Run Salesforce's Health Check tool to identify Guest User permission issues.
• Audit org-wide sharing defaults for all objects exposed in Experience Cloud portals.
• Disable API access on Guest profiles unless explicitly required.

Monitoring and Detection

• Integrate Salesforce Event Monitoring logs into your SIEM, focusing on ApiTotalUsage, BulkApiResult, and LoginEvent log types.
• Alert on new Connected App authorizations and new admin account creations.
• Monitor for SOQL queries accessing sensitive objects from unfamiliar IP addresses or user agents.

Broader Implications

The ShinyHunters-aligned activity documented by Microsoft highlights a strategic reality: CRM platforms are increasingly a primary target for data extortion groups, and the attack paths do not require sophisticated exploitation. They require patience, access to credential marketplaces, and an understanding of how Salesforce's legitimate features can be turned against organizations.

For security teams, this means CRM security can no longer be treated as the responsibility of the sales ops team alone. Salesforce environments need the same rigorous access review, monitoring, and hardening processes applied to cloud infrastructure and identity systems.