Between mid-2025 and mid-2026, Microsoft tracked attacks against Salesforce customers linked to ShinyHunters, a black-hat criminal group. In several of the attacks, the group utilized voice phishing (vishing)1 and convinced employees to approve a fraudulent connected app dl, allowing it to inherit employee permissions and extract data undetected. Microsoft also found compromised Salesloft Drift and Gainsight credentials, which exposed customer environments through traffic resembling an already-trusted integration. Moreover, overly broad guest-user permissions created a third opening, permitting unauthenticated traffic to reach objects and fields through Salesforce's public Aura framework.2
None of these 3 access paths required a flaw in Salesforce. When an employee approves a connected app, that app inherits the employee's own access rights and keeps them until an administrator revokes it; a password change or added multifactor authentication (MFA) does not shut it off. Public-facing pages run under a single guest profile, so whatever that profile can see, an anonymous visitor can retrieve.
The Federal Bureau of Investigation (FBI) in the United States provided similar insights in a September 2025 notice, identifying UNC6040 and UNC6395, two cyberthreat groups, in a wave of Salesforce data theft and extortion.3 In East Asia, South Korea’s Personal Information Protection Commission (PIPC) imposed fines totalling US$25 million against Louis Vuitton, Dior, and Tiffany after a Salesforce-related data compromise.4 The lesson from these investigations and breaches is clear: A secure Salesforce platform can still be exposed by weak identity and access governance.
How the Attack Chain Unfolds
In each of the mentioned examples, one of 3 access paths, none requiring a zero-day vulnerability, converged on 1 result (figure 1).
Figure 1—Three Main Attack Paths and Their Shared Impact5
A Common Pattern Emerges
Across reviews of Salesforce environments, one pattern appeared repeatedly: the control environment was designed for Salesforce's original role as a sales or marketing tool and was never formally reassessed once the platform expanded into billing, commissions, or revenue-adjacent workflows.
Access reviews, where they existed, tended to focus on named human users, and overlooked the machine-facing layer: connected apps and their OAuth scopes, guest profiles, named credentials for external callouts, and permission set groups that quietly aggregate access across roles. This layer is self-service by design. Authorizing a connected app or callout takes one click, not a formal IT or security request, allowing new production access to be introduced with little visibility.6
Governance programs built for enterprise resource planning (ERP) systems, such as System Applications and Products in Data Processing (SAP), rarely apply the same rigor to Salesforce, largely because organizations often fail to clearly define when Salesforce becomes financially relevant. In practice, this gap shows up in predictable ways: a connected app that was authorized during a proof-of-concept that remains in place long after the project ends, or a guest profile copied from a template that was never properly restricted.
Individually, these issues may not stand out as significant findings. Collectively, however, they form a blind spot that periodic access certifications, especially those catered around named users, are unlikely to detect.
Defining the Scope Trigger
For public enterprises, the Sarbanes-Oxley (SOX) Act of 2002 forces a specific question: At what point does Salesforce become financially relevant? Whether a system supports a significant account or a relevant financial statement assertion is what determines internal control over financial reporting (ICFR) scope, not the software category it was purchased under.7 ERP systems such as SAP are financially relevant from the start, since they house the general ledger and core transaction processing, with control environments that mature through repeated testing.
Salesforce, however, usually relates to that scope differently, beginning as a sales or marketing tool where early scoping excludes pipeline and campaign functions. The risk changes once the platform expands into configure-price-quote (CPQ), billing, commissions, or general ledger interfaces while its classification stays unchanged.
Materiality here is assessed at the account level, not the transaction level. It is essential to know whether Salesforce feeds a significant account, such as revenue or receivables, at a volume material to the organization’s financial statements. Once transactions feeding one of those accounts move or receive approval without a second set of eyes, someone must assess whether that account's activity is still immaterial in aggregate, rather than assuming the answer from its original scoping.
There are 4 conditions that force that reassessment:
- A workflow that originates, calculates, or approves a transaction through CPQ, billing, or commission functionality, putting revenue recognition inside the platform. A subscription renewal that calculates recognized revenue and posts it forward without passing through the actual accounting system is common.
- An integration or automation that writes to a general ledger, accounts receivable, or revenue-recognition object, extending reach even when Salesforce is not the system of record. An order captured, priced, and approved in Salesforce and then synchronised to the ERP for invoicing and revenue recognition is a common version of this event. The ERP finalizes the transaction, but Salesforce already made the decisions that determine what gets recorded.
- An automation that can approve or modify a transaction without independent review and close the segregation-of-duties gap that once required a person. A flow that once routed CPQ discounts above 15% to a manager, later edited to auto-approve discounts up to 40%, illustrates this gap in practice. The approval step still fires, but no person ever sees it. This is the most common CPQ gap. Automation is added for speed, and the independent review it replaced is rarely reinstated once workarounds become routine.
- Guest or unauthenticated access reaching any of the above conditions, which may lead to exposure beyond the organization's own users, e.g., a self-service portal exposing a billing object to unauthenticated visitors.
None of these conditions makes Salesforce material on its own, but each one signals that a significant account runs through the platform, shifting the burden onto the control owner to show that the account's Salesforce-driven activity remains immaterial in aggregate. This reframes SOX scoping from a one-time judgment into a recurring materiality test.
A Recurring Monitoring Cycle
Spotting the trigger is only half the job. The other half involves continuous monitoring at the speed that each risk demands.
Some systems can be abused in minutes—a stolen token or a newly approved connected app can start pulling data before anyone notices. Risk requires continuous monitoring, not a quarterly glance. There are several practical steps practitioners can take to facilitate a recurring monitoring cycle:
- Create alerts for new connected-app authorizations from the OAuth Usage page.
- Monitor bulk and metadata application programming interface (API) traffic for volume spikes.
- Preauthorize IT security to revoke tokens and end sessions without a change ticket.
However, other areas may drift more slowly, e.g., a guest profile with too much access, or an employee who left 6 months ago but still has an active login. These instances may not be exploited immediately and will likely sit unnoticed for weeks or months. In cases such as these a quarterly check catch will suffice, along with several additional actions, including:
- Strip unneeded object and field access from each public site's guest profile.
- Recertify administrative rights in Salesforce, such as “Modify All Data”, “Manage Users”, and “View All Data holders”, by name.
- Compare the differences in sharing rules and permission set groups against last quarter.
Then there is the slowest-moving question of all: does Salesforce even belong in the ICFR scope right now? The answer depends on what the enterprise has built into the platform over time, not on how it was originally scoped. A full reassessment against the 4 conditions mentioned previously, once each audit cycle, is what answers that question.8
For audit, risk, and governance professionals, the core lesson is not a new philosophy of security. It is treating Salesforce like the ERP system it has become.A once-a-year control will always be too slow for risk that moves in minutes. Therefore, the cadence must match the risk, or monitoring is just paperwork on a schedule.
Mapping the Gaps to COBIT
COBIT® Objectives that have already been applied to SAP can help close this gap without requiring a new framework. Applying those objectives to Salesforce with a named owner, a defined cadence, and concrete evidence attached to each objective, rather than a policy reference nobody owns, will close that gap.9
Figure 2—Salesforce Control Areas Mapped to COBIT Objectives, Owners, and Cadence
| Control Area | COBIT Objective | Owner | Cadence |
|---|---|---|---|
|
Connected apps, OAuth scopes, and named credentials for external integrations |
APO13 Managed Security |
Requesting business unit |
New approvals monitored continuously; existing grants recertified each quarter |
|
Identity and access:
|
DSS05 Managed Security Services |
IT security |
Token revocation and session anomalies monitored continuously; the rest reviewed each quarter |
|
Production changes to permission sets, flows, connected apps, and system-context batch jobs that bypass user-level sharing |
BAI06 Managed IT Changes |
Independent change function |
Reviewed at every deployment |
|
Configuration and log review |
MEA01 Managed Performance and Conformance Monitoring |
Audit or governance teams |
Reviewed monthly so drift surfaces before an auditor finds it |
What turns figure 2 from a reference chart into an operating control is the evidence behind each objective: a change ticket, a log export, a signed attestation, or a rescoring memo. Without this evidence, an auditor can test the control's design but not whether it actually ran. It also provides auditors and business leaders a shared vocabulary that the board already recognizes.
Conclusion
The attacks tracked by Microsoft did not rely on advanced exploitation. They succeeded because identity governance, integration oversight, and configuration management had not kept pace with Salesforce's growing role in financial and operational workflows. Salesforce governance gaps and ICFR risk do not always overlap. Guest-access exposure may create confidentiality risk without influencing financial reporting, and where those records hold personal data, the EU General Data Protection Regulation and similar laws also apply, as the PIPC fines show. Poorly controlled billing configuration, by contrast, may create ICFR risk with no external attack. When a gap affects financially significant data or processing, the 2 threats converge, and consequences range from a routine deficiency to a material weakness or breach.
For audit, risk, and governance professionals, the core lesson is not a new philosophy of security. It is treating Salesforce like the ERP system it has become. This involves defining when Salesforce turns financially relevant, monitoring it on a fixed cadence, not a calendar reminder, and assigning clear ownership so that the control model is continuously operated, evaluated, and evidenced, not mapped once, and shelved.
Endnotes
1 CISCO, “What is Vishing?”
2 Microsoft, "Defending SaaS-based Applications Against ShinyHunters OAuth Abuse," Microsoft Security Blog, 13 July 2026
3 Federal Bureau of Investigation (FBI); "Cyber Criminal Groups UNC6040 and UNC6395 Compromising Salesforce Instances for Data Theft and Extortion," FBI FLASH Advisory, 12 September 2025
4 Kovacs, E.; "Dior, Louis Vuitton, Tiffany Fined $25 Million in South Korea After Data Breaches," SecurityWeek, 16 February 2026
5 Microsoft, "Defending SaaS-based Applications”
6 Wagenseil, P.; "Misconfigurations at Scale: Why Salesforce Drift Is the New Shadow IT," SC Media, 17 November 2025
7 Public Company Accounting Oversight Board (PCAOB); AS 2110, Identifying and Assessing Risks of Material Misstatement, 28 August 2025
8 Staz, P.; "SOX Compliance in Salesforce: What’s in Scope and How to Make it Simple," Netwrix, 4 May 2025; PCAOB; AS 2201, An Audit of Internal Control Over Financial Reporting That Is Integrated With An Audit of Financial Statements, 28, August 2025
9 ISACA, COBIT®, USA, 2018
Allan Dabre
Is a technology compliance and AI risk leader who designs the governance and control frameworks behind enterprise SaaS and AI products at Fortune 500 companies.