Inside the ShinyHunters Campaign: OAuth at Scale, The Weak Link in SaaS Security

Executive Summary

A sophisticated cybercriminal confederation has weaponized social engineering against cloud platforms, fundamentally shifting the enterprise threat landscape from technical exploitation to human-centric attacks. The ongoing Salesforce ecosystem breach campaign, affecting dozens of organizations including Google, Pandora, Allianz Life, and major luxury brands, represents the emergence of "Extortion-as-a-Service" 2.0 - where technical sophistication takes a backseat to psychological manipulation.

Strategic Implications: This campaign signals the maturation of cloud-native threat actors who have solved the "access at scale" problem by targeting the weakest link in zero-trust architectures: authenticated users post-login. Organizations must move beyond technical controls to address the "trust seam" between identity verification and administrative actions.

Campaign Overview: The Sp1d3rHunters Convergence

The Unholy Alliance

The campaign represents an operational convergence between ShinyHunters (UNC6040/UNC6240) and Scattered Spider (UNC3944), now collectively branding as "Sp1d3rHunters." This partnership demonstrates a sophisticated service-oriented cybercrime model:

• Scattered Spider: Provides "Access-as-a-Service" through proven vishing capabilities

• ShinyHunters: Delivers "Extortion-as-a-Service" infrastructure and monetization

• Combined Operation: Creates an end-to-end breach-to-extortion pipeline

  
  

Confirmed Victim Ecosystem

The threat actors claim the campaign compromised data from nearly 90 organizations worldwide, with confirmed victims including Adidas, Cartier, Google, Louis Vuitton, Dior, Chanel, Tiffany & Co., Qantas Airways, Air France–KLM, Allianz Life, Pandora, and others.

Collective Impact: Estimated 15+ million customer records across all victims

Technical Architecture: Beyond Traditional Breach Vectors

The Social Engineering Kill Chain

The ShinyHunters Vishing Campaign 2025: Attack Flow

Phase 1: Reconnaissance & Infrastructure Preparation.

Investigators uncovered multiple malicious domains registered between June 20–30, 2025, following consistent naming patterns such as ticket-lvmh.com, ticket-dior.com, and ticket-louisvuitton.com.The attackers demonstrated disciplined infrastructure setup:

• Domain Infrastructure: Ticket-themed phishing domains closely aligned to companies’ brands

• Registration Patterns: Use of GMO Internet registrars with disposable emails and Cloudflare obfuscation

• Operational Prep: Staging of lure websites to support downstream vishing campaigns

Phase 2: Vishing Campaign Execution.

The attackers relied on extensive reconnaissance and the normalization of remote IT support to increase employee susceptibility. Victims were directly contacted by phone and socially engineered into authorizing access (vishing, also known as voice phishing).

Psychological Script Framework:

“Hi, this is [Name] from IT Security. We’re implementing new Salesforce security protocols and need you to authorize a security update. Can you navigate to your Connected Apps and approve the My Ticket Portal application?”

This pretext funneled users into the OAuth consent flow of Salesforce while disguising the malicious Connected App as a legitimate security update.

Phishing page hosted at ticket-dior[.]com in June 2025 . Source: Realiaquest

Phase 3: OAuth Exploitation.

Attackers weaponized Salesforce’s OAuth authorization process to bypass MFA and gain persistent API-level access.

• Connected App Masquerade: Rebranding of the legitimate Salesforce “Data Loader” tool as My Ticket Portal during vishing campaigns

• Scope Abuse: Request for high-risk permissions (api, refresh_token) enabled bulk CRM data access

• Persistence Mechanism: Tokens issued to the malicious app allowed long-term access without repeated user interaction

The victim needs to enter a code to connect the threat actor controlled Data Loader. Source: Google Threat Intelligence

Phase 4: Data Exfiltration & Evolution.

With OAuth tokens secured, attackers escalated to data extraction at scale.

• Initial Tools: Salesforce Data Loader was used to quietly siphon customer records

• Technical Innovation: Google analysis revealed a shift toward custom Python scripts, enabling faster and stealthier data theft

• Operational Security: VPN obfuscation (Mullvad, Tor) was leveraged during exfiltration to mask attacker infrastructure and blend with normal traffic

Operational Intelligence: The Extortion Economy

Monetization Strategy Evolution

The monetization strategy employed delayed extortion, with attackers waiting weeks or months after initial data theft before contacting victims with ransom demands ranging from 4 to 20 Bitcoin.

Extortion Tactics:

• Delayed Revelation: Creates forensic challenges and reduces incident response effectiveness

• Public Naming: Non-compliant victims were publicly named on Telegram channels where data samples were leaked, creating immense reputational pressure

• Tiered Pricing: Ransom amounts scaled to organization size and data sensitivity

  
  

Infrastructure Resilience & Law Enforcement Evasion

In June 2025, French authorities arrested a BreachForums administrator linked to ShinyHunters, coinciding with the forum's shutdown. Many expected this to disrupt the group, but the Salesforce campaign continued.

Organizational Resilience Indicators:

• Decentralized Operations: ShinyHunters functions as a decentralized, extortion-as-a-service collective rather than a single coordinated team

• Service Continuity: Operations continued despite high-profile arrests

• Affiliate Model: Enables multiple threat actors to operate under unified branding

 

Strategic Defense Priorities: Lessons from Sp1d3rHunters Campaign Failures

The success against some of the most sophisticated and cyber-mature organizations reveals a significant blind spot in enterprise security architecture. These organizations built comprehensive defenses against unauthorized access while leaving authorized access decisions completely ungoverned.

The Critical Gap: Modern security programs assume that authenticated users make trustworthy decisions about application permissions. The Sp1d3rHunters campaign exploited this assumption by convincing legitimate users to grant OAuth access through sophisticated vishing campaigns -bypassing all technical controls through psychological manipulation.

Root Cause: While organizations implemented robust user permission controls within SaaS applications, they failed to govern the OAuth Connected Apps authorization process as a security-critical workflow. OAuth grants were treated as IT convenience rather than potential privilege escalation vectors.

1. Risk-based consent model (not static allow-list)

Instead of “only 10 apps forever,” design a tiered consent policy:

• Tier 1 – Pre-approved apps:

  • Core enterprise apps (Okta, Power BI, DocuSign, etc.) → always allowed.

  • Company-owned custom apps

• Tier 2 – User-requested apps with review: Business units can request new connectors. Security/IT reviews app ID, scopes, publisher, hosting region. Decision SLA = 1–3 days.

• Tier 3 – High-risk scopes auto-blocked: Apps requesting risky permissions “read all mail,” “directory.read.all,” “bulk export” are auto-denied unless an admin overrides.

  
  

2. Publisher verification / marketplace filtering

• Require apps to be from verified publishers (Salesforce AppExchange, Microsoft-verified, Google-verified).

• Block “unverified” apps by default. This reduces the burden of manually white-listing everything.

This keeps agility but stops the most toxic scopes cold.

3. Conditional access tied to device/browser

Policy: “OAuth consent can only happen from managed enterprise browser / device.”

• That means even if a user clicks a phishing link from their phone/personal Chrome, the login won’t work.

• This kills up to 80-90% of lure-based attacks without reducing SaaS agility.

  
  

4. Time-bounded & contextual approval

• Tokens and consents expire unless re-approved. Example: auto-revoke after 90 days if app unused.

• Enforce step-up approval for sensitive scopes (e.g., admin approval if app asks for api refresh_token or files.read.all).

  
  

5. Continuous monitoring and kill switch

• Policy: every new app consent = logged + alerted. Security can review weekly and auto-revoke suspicious ones.

• Have a “kill switch” playbook: revoke all tokens from a malicious Connected App in <1 hour.

  
  

6. User policy & process

• Users can request new integrations, but:

  • Requests go via a self-service portal that logs business justification.

  • Security doesn’t have to pre-approve everything, only high-risk scopes.

• Awareness training is targeted: “If a consent screen asks for more than email/profile, don’t approve unless it’s an approved app.”

Security must evolve from protecting against unauthorized access to governing authorized access decisions. In cloud-first environments where attackers can manipulate legitimate users into granting system permissions, the primary security function becomes trust arbitration rather than access prevention.