Officially, it’s a security problem. But the ShinyHunters campaign that moved through the Salesforce ecosystem this past week was, more precisely, an architecture issue wearing a security problem’s clothes.
Modern enterprise architecture is built on delegation. An organisation licenses Salesforce to manage customer relationships, Microsoft 365 to run communications, and Google Workspace to coordinate its operations. Each platform then becomes a hub: employees connect to scheduling tools, data enrichment services, AI assistants, PDF editors, and workflow automation agents, each of which requires a connection grant to the core system. The technical mechanism for most of those connections is OAuth, an open authorisation standard that allows a third-party application to act on a user’s behalf without ever seeing the user’s password.
The design logic is sound. OAuth was built to be safer than sharing credentials directly. But the problem is that governance rarely kept pace with the proliferation of connections. Most organisations today cannot produce an accurate count of which third-party applications hold active OAuth grants to their core platforms, what data scopes those grants cover, or when each grant was last reviewed. The resulting exposure of 2.55 million records from Google’s corporate Salesforce instance alone, with Allianz Life losing a further 1.1 million through the same mechanism, did not require a zero-day exploit or a breach of Salesforce’s own infrastructure. Instead, it required a phone call, a plausible story, and a permission button.
That gap between what leaders believe they govern and what they govern in practice is where the damage is often done.
OAuth consent phishing and how it works
The attack class now has a formal name: OAuth consent phishing, also known as an illicit consent-grant attack. Walking through its steps is important because it shows how an attacker can exploit a user’s trust and bypass controls that organisations have invested in.
The attacker begins with reconnaissance, sufficient to identify a plausible employee and an internal IT scenario. The approach is then made by voice rather than email. This is deliberate: the secure email gateway, the anti-phishing scanner, and the link detonation sandbox. None of these controls touches a telephone call. The attacker establishes a sense of urgency and authority (“Your Salesforce Data Loader sync is broken; I need you to re-authenticate it now”) and directs the employee to a URL.
The page the employee reaches is structurally identical to a legitimate OAuth authorisation screen. It may use a near-identical application name, a plausible developer account, and familiar Salesforce or Google branding. What it requests is not a password. It requests permission: “Read and modify all your Salesforce data,” “Manage users,” “Access via API.” The employee, conditioned by years of routine permission requests across dozens of platforms, clicks “Allow.”
At that point, Salesforce issues a cryptographic token to the attacker’s registered application. The token carries the authorisation granted by the employee. It is not a session cookie that expires when the browser closes. It is a persistent credential that survives password changes, MFA re-enrolment, and device wipes. The attacker’s application can now call the Salesforce API directly, exporting records, querying user data and adjusting configuration over encrypted HTTPS traffic addressed to legitimate Salesforce infrastructure.
The controls that theoretically could have caught this:
Endpoint detection found nothing to examine. The attack produced no malicious file on the employee’s device. The decision to grant permission was made in a browser, over HTTPS, to a page that may have been hosted on entirely legitimate infrastructure. Endpoint detection and response tools observe process execution and file system behaviour; they have no visibility into whether an OAuth grant is legitimate or coerced.
The firewall saw normal business traffic. Every byte of the authorisation exchange was encrypted and addressed to Salesforce-controlled domains. Network-layer controls cannot distinguish between a legitimate administrator exporting a report and an attacker’s application draining the database through an authorised connection.
Multi-factor authentication was made irrelevant. MFA defends the authentication step: proving that the person entering credentials is who they claim to be. However, in OAuth, consent phishing does not attack the authentication step. It attacks the authorisation step that follows it. The employee authenticated correctly. They then granted permission to an attacker. MFA had no role to play.
The control that would have prevented it was a default-deny posture for third-party application connections: IT approval before any OAuth grant is issued. That control was absent. That absence is by design, not accidental, and ultimately, this control was replaced by implicit trust in the process and the humans involved.
Nice, but not so fast!
It turns out that consent phishing now turns the permission layer into the attack surface. The mechanics are straightforward: an attacker registers a malicious OAuth application, crafts a legitimate-looking authorisation request, and waits for a user to click approve. No credential theft, no brute force. The identity provider does exactly what it was designed to do. What makes this hard to defend against is the environment it exploits. Organisations have spent years onboarding SaaS applications, each extending the permission graph further. The default posture is permissive because restrictive defaults create friction, and friction creates helpdesk tickets. Transitioning to an allowlist is achievable. The reason it moves slowly is that the costs are immediate and the risk is abstract until it isn’t.
AI tooling has sharpened the problem. AI assistants and workflow agents each add OAuth grants, often with broad scopes, often without IT visibility.
Shadow SaaS existed before AI, but AI copilots make it much harder to find.
The permission graph is now growing faster than the governance processes designed to review it. The attack does not require a sophisticated threat actor. It requires an environment where approval has become a habit.
The design shift needed: blacklist to allowlist
The practical change required is to reverse the default posture. Most enterprise identity platforms ship with a configuration that allows users to grant OAuth permissions to third-party applications unless those applications have been specifically blocked. This is a blacklist model. It assumes that most third-party applications are legitimate, with a manageable set of known bad actors to exclude.
The evidence from this and other attacks highlights a major issue with this assumption.
A default-block posture, where no third-party application can receive an OAuth grant until it has been reviewed and approved by IT, is needed. We need to invert the permission structure so that legitimacy must be established before access is granted, rather than revoked only after harm occurs.
The transition is not easy, though, as it reintroduces friction and help desk calls. Organisations with mature SaaS environments will have hundreds of existing OAuth grants, some of which are connected to live business processes. A responsible implementation begins with an audit:
- Pull the full list of active grants from each major platform
- Identify the data scopes covered
- Match applications against current business needs
- Revoke anything that is dormant, unrecognised, or holds more permissions than its function requires.
These simple steps alone often reveal grants from applications that have changed ownership, been abandoned by their developers, or were authorised by employees who have since left the organisation.
The second layer is behavioural API monitoring. A token that exports tens of thousands of records at three in the morning from an IP address outside the organisation’s known operating geography is behaving anomalously, regardless of whether it was legitimately granted.
API-layer monitoring, the SaaS equivalent of network detection and response, can identify usage patterns that fall outside the baseline established by legitimate application behaviour. This does not prevent the initial grant from being issued, but it narrows the window between compromise and detection from months to hours.
The ownership question is important and often avoided. OAuth governance touches identity and access management, IT operations, SaaS platform administration and business operations. A default-block posture has productivity implications, so ownership cannot sit with the security team alone. Assigning it to IT operations without security involvement results in a process lacking appropriate risk assessment. When ownership is unclear, the audit is completed once, the report filed, and the grant list quietly grows again to its previous size within eighteen months.
There is also a user-communication dimension that matters more than it might seem. Consent fatigue, a condition in which employees automatically approve permission requests because they are routine, is not a character flaw. It is a rational response to an environment that has issued hundreds of routine requests. Organisations that introduce an approval workflow for OAuth grants without explaining why will encounter resistance and workarounds. The alternative is for employees to use personal accounts to connect productivity tools IT has not approved. That creates a shadow integration problem worse than the one being solved.
The permission graph is the attack surface we need to focus on
Today, the attack surface is not primarily the device or the network. It is the permission graph. Most organisations can produce a reasonable account of their network topology. However, few can produce an accurate account of their permission graph.
The gap between those two maps is where this week’s damage was done. Closing it requires a different kind of investment than the one that produced the current security stack: less focused on detecting malicious behaviour after the fact, more focused on ensuring that the permissions granted in the first place are the right ones.
The attack surface now includes integrations, connections, and delegated authorisations, creating trust blind spots that conventional controls were not designed to see.
The required mindset shift is architectural, not operational. Organisations that address these questions now can remove the obvious entry points for such attacks. Those that keep relying on people to click the right buttons and avoid suspicious emails will find that model increasingly unsustainable.
