The attack was hiding in plain sight

In July, Microsoft published its analysis of a year-long campaign associated with ShinyHunters that targeted Salesforce environments across multiple industries. The activity began in mid-2025 and continued into 2026, using several different paths to reach customer data.

The campaign is notable because the attackers did not need to exploit a vulnerability in Salesforce itself. Instead, they took advantage of mechanisms organizations deliberately use to connect applications, employees and outside vendors.

Microsoft identified three primary techniques:

• Voice phishing: Attackers called employees pretending to be IT support and persuaded them to authorize a malicious OAuth application. In some cases, the application was disguised as Salesforce's legitimate Data Loader tool.

• Compromised third-party integrations: Attackers obtained OAuth tokens from software vendors that already had legitimate connections to Salesforce. Those tokens could then provide access to customer environments without requiring another login.

• Misconfigured guest access: Attackers found Salesforce environments where guest permissions allowed access to information through Salesforce's Aura framework without requiring normal user authentication.

The third-party integration attacks are particularly revealing.The campaign followed compromises involving applications and vendors including Salesloft's Drift integration, Gainsight and, more recently, the competitive-intelligence platform Klue. In the Salesloft incident, stolen OAuth tokens potentially exposed more than 700 organizations. The Gainsight campaign reached more than 200 Salesforce instances, while the Klue compromise involved OAuth tokens associated with 195 organizations, according to research from the Cloud Security Alliance.

The common thread was trust.

The Salesforce environments were already configured to trust these applications. Once an attacker obtained a legitimate token, activity could look much more like normal application traffic than an intrusion.

That creates an uncomfortable problem for traditional security monitoring. Authentication systems are very good at asking, “Who just logged in?” They are less effective at answering, “What is this already-authorized application doing with its access?”

Microsoft and Salesforce have subsequently added capabilities intended to improve that visibility, including connected-app attribution, OAuth scope information, risk scoring and identification of unused applications with active permissions.

The security stack is becoming more interconnected

This incident illustrates a broader change in enterprise security. A typical organization may have hundreds of SaaS applications connected through identity providers, APIs, OAuth permissions and third-party integrations. Security teams may have excellent controls protecting individual applications while having limited visibility into the relationships between them.

Consider a simplified chain: Each individual component may be properly secured. The risk can emerge from the connection between them.

Employee → Identity Provider → Salesforce → Marketing Platform → Customer Data

An application that was approved two years ago may still have broad permissions today. A vendor that was considered low risk may now hold access to sensitive systems. A test integration may remain active long after the project has ended. A legitimate application can become an attacker's pathway into several organizations simultaneously.

The Cloud Security Alliance's review of the campaign found that overlooked, persistent OAuth relationships were a recurring factor across the supply-chain compromises. That makes the security portfolio itself worth examining.

What should security leaders ask?

The lesson from the Salesforce campaign isn't that organizations should stop using SaaS integrations. Those integrations are fundamental to how modern businesses operate.

The better questions are about necessity, exposure and visibility:

• How many applications currently have access to critical systems?

• Which applications have elevated OAuth permissions?

• How many integrations are no longer actively used?

• Can security teams see what connected applications are actually doing?

• How quickly can an organization revoke access when a vendor is compromised?

• Are multiple security products providing overlapping protection while an important SaaS exposure remains poorly monitored?

• Does the security budget reflect the risks created by the organization's actual technology architecture?

These are portfolio questions as much as they are technical questions.

Security teams have become accustomed to evaluating products individually: endpoint protection, identity, SIEM, vulnerability management, cloud security, SaaS security and so forth. But risk increasingly exists in the spaces between those categories.

That creates a challenge for security investment decisions. Adding another product may improve visibility, but it may also add another layer to an already complicated environment. Sometimes the better answer is configuration. Sometimes it is removing an unused integration. Sometimes it is reducing permissions. And sometimes a new capability really is warranted.

The important thing is being able to distinguish between those choices.

A broader warning for the security industry

The ShinyHunters campaign is another example of why security effectiveness cannot be measured simply by counting tools or checking whether individual controls are deployed.

An organization can have MFA, endpoint protection, identity controls and extensive monitoring and still have a significant exposure through an authorized application. The security question increasingly becomes one of relationships and accumulated risk.

• What has been connected?

• What has been granted access?

• What is still necessary?

• What can actually be seen?

• And where are security investments producing diminishing returns while other

• parts of the environment remain exposed?

For Balance Theory, that is perhaps the most important takeaway.

A security program is a portfolio of technologies, vendors, permissions and decisions. Understanding how those pieces work together is becoming just as important as evaluating how well each individual product works. The strongest security stack may ultimately be the one an organization understands well enough to know what it can safely remove, what it needs to strengthen, and where the connections themselves have become the risk.