Attackers linked by Microsoft to ShinyHunters-style data-extortion activity have shown a practical lesson for every SaaS-heavy organization: a cloud platform can be breached without a software vulnerability in the platform itself. In the Salesforce campaigns reported this week, the weak point was not Salesforce code. It was previously granted trust — OAuth consent, third-party integrations, and guest access that exposed more than intended.

Microsoft says the activity stretched from mid-2025 into mid-2026 and clustered around three paths into Salesforce environments. The common theme is that the attackers found ways to make their activity look like ordinary business use. That is exactly why security teams should treat this as a governance and detection problem, not only as an incident-response story.

What Microsoft says happened

The first path involved voice phishing. Attackers posing as IT support reportedly convinced employees to approve an attacker-controlled OAuth connected app that resembled Salesforce Data Loader. Once a user granted consent, the application could call Salesforce APIs as that user, enumerate data, and maintain access to CRM records without needing malware or repeated password theft.

The second path targeted vendors and integrations. If a third-party application already has OAuth access into customer Salesforce tenants, a compromise of that vendor can become a many-to-many incident. Microsoft pointed to cases involving Salesloft Drift, Gainsight, and Klue, where stolen tokens, integration secrets, or legacy credentials were reportedly used to reach downstream Salesforce environments and extract data. This is the hard part for defenders: traffic from a sanctioned integration may not resemble a suspicious sign-in at all.

The third path involved Salesforce Experience Cloud and Aura endpoints. Where guest-user permissions were too broad, attackers could query data without normal authentication. Microsoft described suspicious activity against Aura functionality, including GraphQL-style access patterns and pagination used to retrieve more records than defenders may have expected a guest role to expose.

None of these paths requires a traditional exploit chain. They exploit business trust, configuration drift, and the fact that SaaS integrations often remain powerful long after anyone has reviewed whether they still need that power.

Why normal login monitoring is not enough

Many security programs still treat identity monitoring as a question of whether the user authenticated correctly. That is necessary, but it is incomplete for OAuth and connected-app abuse. If a real employee consents to a malicious app, or if a legitimate vendor token is stolen, the resulting API activity may not trigger the same signals as a password spray, impossible travel event, or unfamiliar browser login.

The better question is behavioral: which application made the API call, what scopes did it have, how much data did it query, and is that pattern normal for that app and tenant? A support-chat integration suddenly running broad SOQL searches across cases for secrets should not be treated the same as routine chat synchronization. A dormant integration becoming active after months of silence deserves immediate scrutiny.

This is also why third-party SaaS risk cannot stop at vendor questionnaires. A vendor with long-lived OAuth tokens into sensitive CRM data is part of the production identity perimeter. Its source-code repositories, cloud accounts, CI/CD process, and credential handling can become your exposure.

Immediate defensive actions

Security teams using Salesforce should start with an inventory of connected apps and OAuth grants. Identify applications with broad scopes, administrator-level access, refresh tokens, or access to high-value objects such as contacts, cases, opportunities, attachments, and custom objects containing customer data. Remove grants that are no longer needed, and place owners on every remaining integration.

Next, review inactive apps. An integration that has not been used for 90 days but still holds powerful permissions is unnecessary attack surface. Disable or revoke it unless a business owner can justify keeping it active.

Teams should also tighten consent workflows. Users should not be able to approve high-risk OAuth applications without administrative review. Where possible, restrict app installation to approved publishers and known application IDs. Train help desks and employees on OAuth-consent phishing: if someone calls and walks a user through approving an app, the correct action is to stop and verify through a known internal channel.

For vendor integrations, ask more specific questions. Does the vendor store customer OAuth tokens? Are refresh tokens encrypted and access-limited? How are GitHub, cloud, and production secrets protected? Can tokens be rotated quickly? Will the vendor notify customers if suspicious API activity occurs even before a breach is fully confirmed?

Detection priorities for Salesforce environments

Defenders should build detections around API behavior, not only login events. Useful signals include newly authorized connected apps, apps requesting unusually broad scopes, high-volume object enumeration, large exports, unusual SOQL queries, access from unexpected networks, deletion of query jobs or logs, and dormant apps suddenly becoming active.

For Experience Cloud sites, review guest-user permissions with a least-privilege mindset. Guest roles should not expose sensitive records, and public endpoints should be tested as an unauthenticated user. Monitor Aura and GraphQL-related activity for unusual pagination, object access, and scraping patterns.

Microsoft also highlighted new Salesforce-related capabilities in Defender for Cloud Apps, including connected-app attribution, visibility into OAuth scopes, risk scoring, and support for Salesforce Shield Event Monitoring telemetry. Organizations using those tools should validate that the connector is configured, ingesting the right events, and producing actionable alerts.

The larger lesson

The Salesforce incidents underline a broader SaaS security reality: attackers increasingly prefer legitimate access paths because they are quieter than exploits. OAuth, integrations, and guest portals are powerful because they make business processes work. They are dangerous for the same reason.

The practical answer is not to abandon integrations. It is to govern them like privileged identities: inventory them, limit their scopes, monitor their behavior, rotate and revoke access, and verify that every trust relationship still has a business reason to exist.

Source: The Hacker News source