The Architecture of Borrowed Trust
Executive Summary
- OAuth consent phishing has become an industrialised attack vector, bypassing MFA and persisting through password changes—this is a structural failure, not a training problem
- Knowledge-Based Authentication is dead: the NPD breach exposed SSNs for nearly every US adult, collapsing the fiction that “secrets” can authenticate identity
- Nation-state actors are targeting executive personal email as a backdoor to corporate influence, not just corporate assets
- Ransomware has consolidated: RansomHub now operates the “All-Stars” of displaced affiliates from busted groups, raising operational sophistication
- AI liability is hardening: California’s SB 1047 introduces supply chain risk for any system dependent on models that may face mandatory shutdown
The Week’s Signals
The Salesforce Siege
ShinyHunters coordinated an assault on Salesforce CRM instances across major corporations, exposing over 4.5 million records. Google confirmed its corporate Salesforce instance was compromised in June 2025, affecting 2.55 million business contact records. Allianz Life followed with 1.1 million customer records exposed through an identical vector.
What happened:
Attackers used voice phishing, calling employees while posing as internal IT support. They did not ask for passwords or MFA codes. They asked employees to install a “fix”—a malicious OAuth application disguised as Salesforce’s legitimate Data Loader tool. Once the employee clicked “Allow,” attackers had a persistent, authorised token to scrape databases via API.
The mechanism:
This is OAuth Consent Phishing. The user authenticates normally, completes MFA, and grants permissions to what appears to be a legitimate application. The resulting token works independently of user credentials. Password changes do not revoke it. MFA does not protect against it—MFA protected the authentication that generated the token, not the token itself.
Why controls failed:
- Endpoint Detection and Response (EDR) sees nothing—the “malware” is a cloud-to-cloud permission grant
- Firewalls see encrypted HTTPS traffic to
salesforce.com—indistinguishable from legitimate business - Security Awareness Training asked users to protect passwords, not permissions
Three actions:
- Audit OAuth grants in Salesforce, Microsoft 365, and Google Workspace this week—revoke any with high-impact scopes not actively in use
- Configure identity providers to block all unverified third-party applications by default
- Establish out-of-band verification for any IT request involving application installation or permission grants
The Death of the SSN
National Public Data suffered a breach exposing 2.7 billion records. This includes Social Security Numbers for nearly every adult in the United States, alongside personal data for citizens of the US, Canada, and the UK.
What happened:
A data broker with no direct consumer relationship aggregated personal information and failed to protect it. The data is now searchable, tradeable, and cheap.
The mechanism:
For decades, the US financial system treated the SSN as a shared secret—a password you are born with. Knowledge of this number, combined with basic biographical facts, was accepted as proof of identity. The NPD breach does not just expose data; it collapses this entire authentication model.
Why controls failed:
The SSN was never designed as an authenticator. Using it as one was a convenience that became an assumption that became a vulnerability. Controls fail because the control assumption was false from the start.
Three actions:
- Eliminate Knowledge-Based Authentication from all customer-facing verification processes
- Mandate FIDO2 hardware keys for high-privilege access and sensitive transactions
- Audit vendor authentication practices—if they still use KBA, they inherit and propagate this risk
Geopolitics in the Inbox
Google’s Threat Analysis Group reported that APT42, an Iranian state-sponsored threat actor, has actively targeted US presidential campaigns. Sixty percent of their geographic targeting focuses on Israel and the US.
What happened:
APT42 conducts persistence campaigns, not smash-and-grab operations. They research targets, understand communication patterns, build rapport, and insert themselves into trusted relationships before attempting credential theft or malware deployment.
The mechanism:
Nation-state actors target executives not primarily for financial access but for influence. Compromise of a personal email account provides material for future social engineering, access to private communications, and potential for reputation damage or coercion.
Why controls failed:
Corporate security programmes protect corporate assets. Personal email accounts of executives sit outside this perimeter despite being connected to the same individual, the same device, and often the same password manager.
Three actions:
- Extend security monitoring to executive personal email accounts with their informed consent
- Mandate hardware security keys for executive personal accounts (Google Advanced Protection, Apple Security Keys)
- Include executive personal digital hygiene in threat briefings and tabletop exercises
Focus on: The Shadow SaaS Kill Chain
Definition
Shadow SaaS is not Shadow IT. Shadow IT was about unapproved infrastructure—servers under desks, rogue cloud instances. Shadow SaaS is about unapproved connections to approved infrastructure. Every time a user clicks “Log in with Google” or “Connect to Salesforce” on a third-party tool, they punch a hole in the perimeter.
The term “kill chain” matters here because OAuth consent phishing is not a single exploit—it is a sequence:
- Reconnaissance (identify high-value targets with SaaS access)
- Initial access (social engineering via telephone)
- Persistence (OAuth token generation)
- Collection (API-based data exfiltration)
Why Now
Three trends converged:
- Identity consolidation: Single Sign-On reduced friction but concentrated risk—one identity compromise now unlocks everything
- API proliferation: SaaS platforms compete on integrations, making third-party app connections a feature, not a bug
- MFA confidence: Organisations assumed MFA solved authentication security, failing to recognise that tokens are post-authentication artefacts
ShinyHunters did not invent this vulnerability. They industrialised it.
Failure Modes
Mode 1: The Allowlist Gap
Most organisations block known-bad applications. But the default for unknown applications is permissive. Attackers register new applications constantly, staying ahead of blocklists.
Mode 2: Consent Fatigue
Users click “Allow” or “I Agree” fifty times a day. We have trained them to be compliant button-pushers. When an attacker presents one more consent dialogue, users comply not from ignorance but from conditioning.
Mode 3: Token Blindness
Security teams monitor logins. They do not monitor API calls made via OAuth tokens. An attacker with a token can exfiltrate data at 3 AM from a foreign IP, and unless API-level monitoring exists, no alert fires.
Control Model
Tier 1: Restrictive Default
Configure identity providers (Entra ID, Google Workspace, Okta) to block all third-party application connections by default. Users requesting new connections submit a ticket. IT approves after security review.
Tier 2: Continuous Audit
Schedule quarterly reviews of all active OAuth grants. Revoke any with high-impact scopes (Read Mail, Read Files, Full Control) that have not been actively used in 90 days.
Tier 3: Behavioural API Monitoring
Deploy SaaS Security Posture Management (SSPM) or Cloud Access Security Broker (CASB) tools capable of monitoring API activity. Alert on anomalous patterns: bulk data exports, off-hours access, geographic anomalies.
30-Day Move
Audit OAuth grants across your top three SaaS platforms (likely Salesforce, Microsoft 365, Google Workspace). Generate a report of all applications with “high impact” scopes. Revoke any that have not been used in 90 days. Document exceptions.
90-Day Move
Implement restrictive defaults: all third-party applications blocked unless explicitly approved. Build an approval workflow that routes requests through security review. Communicate the change to the business with clear rationale—this is friction by design.
Operating Model Translation
Who owns this?
OAuth governance sits uneasily between IT, Security, and business units that own the SaaS platforms. Clarity is required. Recommendation: Security sets policy (restrictive default, quarterly audit cadence), IT implements technical controls, platform owners manage exception requests for their domains.
What changes?
The relationship between users and SaaS platforms shifts. Users can no longer self-service integrations. This creates friction—and that friction is intentional. The business case for any new integration must now include security review, which slows adoption but reduces attack surface.
How would this fail in reality?
- Shadow workarounds: Users find alternative tools that do not require integration, exporting data manually to unsanctioned platforms
- Approval bottlenecks: Security review becomes a backlog, business units escalate, executives grant exceptions that create risk
- Incomplete coverage: Some SaaS platforms lack native controls, requiring third-party tooling that may have its own gaps
The control model succeeds only if combined with clear escalation paths, reasonable SLAs on security reviews, and executive sponsorship that prioritises security over speed.
Threat Signals
RansomHub: Consolidation of Talent
Following law enforcement disruption of LockBit and ALPHV (BlackCat), RansomHub has emerged as the dominant ransomware operation by recruiting displaced affiliates.
The mechanism:
RansomHub operates a high-payout affiliate model, attracting experienced operators. This consolidation means defenders now face the combined expertise of multiple previously distinct threat groups.
Why controls fail:
Incident response playbooks tuned to LockBit TTPs may not apply. RansomHub inherits diverse tradecraft from its affiliates. Pattern-based detection becomes less reliable.
Quarterly action:
Update threat intelligence feeds and incident response playbooks. Conduct a tabletop exercise simulating a RansomHub intrusion to identify gaps.
Qilin: Credential Harvesting at Scale
Qilin ransomware now prioritises stealing saved passwords and session cookies from Chrome browsers before deploying encryption.
The mechanism:
Compromised credentials enable lateral movement into cloud infrastructure (AWS, Azure, SaaS platforms) even if the original endpoint is isolated. The ransomware event becomes a cloud breach.
Why controls fail:
Browser credential storage is convenient but unmanaged. Enterprise password managers exist but are not universally enforced. Session cookies can be replayed even if passwords change.
Quarterly action:
Enforce policies disabling password storage in enterprise browsers. Mandate enterprise password manager usage. Evaluate session token lifetime policies across critical SaaS platforms.
MacStealer: The Apple Blind Spot
MacStealer malware targets iCloud Keychain and browser cookies, spreading via fake job offers and pirated software.
The mechanism:
Developer endpoints are high-value targets due to access to source code repositories, cloud infrastructure credentials, and CI/CD pipelines. Compromised developer credentials can lead to supply chain attacks.
Why controls fail:
Mac endpoints are often treated as inherently more secure, receiving less monitoring and fewer restrictions than Windows. Developers often have elevated privileges and exemptions from security policies.
Quarterly action:
Extend endpoint detection and response coverage to all Mac endpoints. Review developer security exemptions. Implement Data Loss Prevention controls on code repositories.
Controls in Practice
The “Application Allow-List”
Where it breaks:
Users need new tools. Business units have deadlines. The approval process becomes a bottleneck, and exceptions proliferate until the allowlist is meaningless.
Implementation:
- Staff the security review function adequately—SLA of 48 hours on new application requests
- Create pre-approved categories (e.g., specific PDF editors, scheduling tools) that pass automatic review
- Log all exceptions with expiration dates; review and renew or revoke quarterly
30-day version: Audit existing grants, identify top 10 highest-risk applications, revoke or re-approve explicitly.
90-day version: Implement restrictive default with exception workflow. Communicate to business with clear rationale.
Out-of-Band Verification
Where it breaks:
Users do not remember the protocol. Attackers adapt, claiming to be from a third party that would not follow internal verification procedures.
Implementation:
- Publish a simple rule: “IT will never call you and ask you to install software. If someone does, hang up and call the helpdesk.”
- For high-sensitivity actions, require callback to a published number before proceeding
- Train helpdesk staff to recognise social engineering attempts
30-day version: Publish the policy. Include in all-hands communication.
90-day version: Conduct simulated vishing exercises targeting departments with SaaS access.
Board Questions
These questions are designed to surface gaps in current visibility and governance. They are copy/paste ready for board materials or executive briefings.
- How would we detect if an employee granted API access to a malicious OAuth application today?
- Which third-party applications currently have access to our Salesforce, Microsoft 365, and Google Workspace data, and when were they last reviewed?
- What is our current policy for verifying IT support requests received via telephone?
- If Knowledge-Based Authentication is no longer reliable, what alternative verification methods have we implemented?
- Which executive personal email accounts are currently protected with hardware security keys?
- Do we have visibility into API activity within our SaaS platforms, or only login events?
- If California’s SB 1047 mandated shutdown of a model we depend on, which business processes would be affected?
- How many OAuth grants exist in our environment with “Full Control” or equivalent permissions?
Close
The Salesforce siege is not an isolated incident. It is a demonstration of where adversary attention has moved. We outsourced infrastructure to the cloud and gained operational efficiency. But we shifted risk from servers to identities without shifting controls at the same pace.
Trust is borrowed. When we connect to a SaaS platform, we borrow their uptime, their patching discipline, their physical security. When we allow OAuth integrations, we lend that borrowed trust to third parties we may never have evaluated.
The architecture of borrowed trust requires active governance—continuous audit, restrictive defaults, and the willingness to accept friction in exchange for safety.
The friction is the safety.
Curated Assets
- OAuth Governance Checklist — When to use: quarterly SaaS audit. Minimum version: audit and revoke. Maturity version: restrictive default with exception workflow.
- executive-briefing-kba-death|Executive Briefing: The Death of Knowledge-Based Authentication — What changed, what it means for customer verification, and immediate actions.
- deep-dive-shadow-saas|Deep Dive: Shadow SaaS as Control Failure — Extended analysis of why visibility collapsed and how to rebuild it.
