14 Mega-Breaches, Three Playbooks: How ShinyHunters Dominated H1 2026

The Scale

ShinyHunters is the top threat actor of H1 2026. According to the CRN Mega-Breach Tracker, fourteen of the largest confirmed mega-breaches in the first half of 2026 have been linked to this single group — reported by CRN as 14 of 37 total, or roughly 38%. That concentration of damage attributed to one actor has no parallel in the modern breach landscape.

The victim list reads like a cross-section of enterprise America and beyond: Salesforce, Charter Communications, Carnival Corporation, Telus Digital, and the Council of Europe. The industries span cloud SaaS, telecommunications, hospitality, digital services, and international governance. On paper, these organizations share almost nothing in common. In practice, they share one thing: every one of them generated alerts during the intrusion that were never investigated in time.

What makes ShinyHunters exceptional is not any single technique but their operational breadth. Google Cloud Threat Intelligence tracks the group’s vishing operators as UNC6040 and documents over 1,000 organizations targeted through voice phishing alone. But vishing was only one of three distinct playbooks the group ran in H1 2026 — each designed to exploit a different weakness in enterprise security operations.

Three Playbooks, One Outcome

ShinyHunters did not rely on a single attack vector. The group operated three distinct playbooks, often in parallel, each targeting a different layer of the enterprise stack.

Playbook 1: Voice Phishing for SSO/OAuth Credentials (Primary Method)

The dominant attack vector — and the one most organizations are least prepared to detect — was voice phishing (vishing) targeting help desks. Tracked by Google Cloud Threat Intelligence as UNC6040, ShinyHunters operators called enterprise help desks impersonating employees, social-engineered credential resets for SSO and OAuth accounts, and then used the compromised credentials to access cloud environments. Once inside, they abused tools like Salesforce Data Loader to exfiltrate data at scale.

This was not a niche technique. Google Cloud documented over 1,000 organizations targeted through this vishing campaign. The operators were methodical: they researched employee names and internal processes, called help desks with convincing pretexts, obtained credential resets, and then moved quickly to extract data before the compromised accounts were flagged. Varonis documented similar patterns, noting that ShinyHunters operators demonstrated detailed knowledge of enterprise IT workflows — enough to navigate help desk verification procedures that would stop less prepared attackers.

The key insight is that vishing-based credential theft generates alerts across multiple systems — password reset logs, unusual login geolocations, anomalous data access patterns — but those alerts land in different queues managed by different teams.

Playbook 2: Salesforce Experience Cloud Guest-Access Misconfigurations

Salesforce Experience Cloud — formerly Community Cloud — allows organizations to create customer-facing portals, partner sites, and self-service applications on top of their Salesforce data. When misconfigured, these sites grant guest or unauthenticated users access to Salesforce objects containing sensitive data, making the data queryable through the site’s public-facing APIs.

ShinyHunters systematically scanned for these patterns across thousands of Salesforce instances, using publicly available tools and techniques to identify Experience Cloud sites with overly permissive guest access. The reconnaissance was methodical: enumerate Experience Cloud sites, test guest API access against standard Salesforce objects, identify which instances returned data that should have been internal. This required patience, automation, and the knowledge that most organizations never audit their Experience Cloud access controls after initial deployment.

This was a real and significant attack vector — but it was one of three playbooks, not the only one.

Playbook 3: OAuth Supply-Chain Attacks

The third vector exploited OAuth integrations between SaaS platforms. In the most notable case, ShinyHunters compromised the Salesloft Drift integration, abusing OAuth tokens to gain access to connected services and their underlying data. This supply-chain approach allowed the group to pivot from a compromised third-party application into the target organization’s environment without ever directly attacking the target’s own infrastructure.

OAuth supply-chain attacks are particularly difficult to detect because the access pattern looks legitimate — the tokens are valid, the API calls use authorized integrations, and the data flows through expected channels. The anomaly is in the volume and scope of access, not in the mechanism itself.

The Canvas/Instructure Breach

The single largest breach linked to ShinyHunters — 275 million user records from the Canvas learning management platform owned by Instructure — illustrates the complexity of attributing a precise technical vector.

ShinyHunters attributed the breach to a Free-For-Teacher account misconfiguration on shared production infrastructure, though the precise mechanism remains disputed. Salesforce has maintained that the breach did not result from a platform vulnerability. Whether the initial access came through a misconfigured guest profile, a compromised credential, or some combination of both has not been conclusively established in public reporting.

What is not disputed is the outcome: a quarter of a billion records — names, email addresses, and institutional affiliations for students and educators across thousands of school districts and universities — were exfiltrated and appeared on breach forums. The extraction of 275 million records does not happen in a single query. It happens over sustained, high-volume API calls that generate telemetry across multiple monitoring systems. That telemetry existed. The investigation that should have connected it did not happen in time.

The Victim List

Each major ShinyHunters victim tells a version of the same structural story: alerts fired across multiple systems, and no one connected them before the data was gone.

• Salesforce: Customer data exposed through a combination of vectors. The platform vendor itself was victimized — internal customer records, account metadata, and support case data were compromised. ShinyHunters targeted Salesforce through both credential-based access and misconfigured portals.
• Charter Communications: Subscriber data including names, addresses, and account numbers exfiltrated. Charter’s subscriber base spans millions of households across the United States, and the exposed data set included the core identifiers that enable downstream identity fraud.
• Carnival Corporation: Guest and employee data from loyalty program databases. The cruise line’s customer loyalty platform exposed passenger records, loyalty tier information, and employee operational data.
• Telus Digital: Customer records and internal operational data. The breach exposed both customer-facing information and internal business data, indicating access spanning multiple business functions.
• Council of Europe: Personal data of delegates and staff. An international governance body with members from 46 countries had delegate contact information, staff records, and institutional data exposed.

Across these victims, ShinyHunters deployed whichever playbook matched the target’s weakest point — vishing a help desk for credentials at one organization, scanning for a misconfigured Experience Cloud portal at another, pivoting through a compromised OAuth integration at a third. The common thread was not a single vulnerability class. It was the fact that the resulting alerts, regardless of which playbook triggered them, sat uninvestigated in separate queues.

The Alerts Were There

Every ShinyHunters playbook generates alerts. This is not a detection gap problem. The signals exist across all three attack vectors, and in most reasonably instrumented environments, they are already being collected:

• Help desk credential resets are logged in identity providers and ticketing systems. A password reset for an SSO account followed by an immediate login from an unfamiliar location generates signals in both the IAM platform and the endpoint detection stack.
• Unusual Salesforce Data Loader activity appears in Salesforce audit logs. When a freshly reset account begins bulk exports through Data Loader within hours of the credential change, the EventLogFile and Login History surface the anomaly.
• Unauthorized API access patterns from misconfigured Experience Cloud sites generate SOQL monitoring alerts. Queries that enumerate object schemas, iterate across record sets, or access objects unrelated to a portal’s stated purpose are visible in Salesforce’s own monitoring telemetry.
• Anomalous data export volumes get flagged by DLP rules. A quarter-billion record extraction happens over sustained, high-volume API calls that exceed any reasonable baseline.
• OAuth token abuse from compromised integrations shows up in connected app logs. When a legitimate integration begins accessing data outside its normal scope or at abnormal volumes, the connected app telemetry records the anomaly.
• Authentication from unexpected geolocations triggers identity alerts. ShinyHunters operates from infrastructure that does not geolocate to the expected user base.

All of these signals sit in SIEM logs across four or five different telemetry sources. The data exists. The detections exist. The alerts fire. What does not happen — in the time that matters — is the investigation that connects them into a coherent narrative.

Why the Exfiltration Narrative Never Forms

Here is what a vishing-initiated breach looks like from the inside of a SOC, as it is happening:

• A password reset request in the help desk ticketing system → triaged by the IT service desk as a routine request.
• An SSO login from an unexpected geography → triaged by the IAM team as potential contractor access.
• A Salesforce Data Loader session with elevated export volume → triaged by the cloud security team as a data migration or reporting job.
• A DLP alert on outbound data volume → triaged by the data protection team as an approved business process.

Each alert is triaged independently. Each falls within normal parameters for its category when viewed in isolation. The IT service desk has no visibility into the subsequent login anomaly. The IAM team does not know about the Data Loader activity. The cloud security team sees the export volume but has no context on how the session was established. The data protection team flags the volume but lacks the upstream context to distinguish exfiltration from a legitimate bulk operation.

The same pattern plays out for the misconfiguration vector: an unusual guest API pattern in Salesforce audit logs, a data volume spike in DLP, an unfamiliar API consumer in identity logs — each alert triaged by a different team, each appearing benign in isolation. And for the OAuth supply-chain vector: an integration accessing data outside its normal scope, an unexpected token refresh pattern, elevated API call volumes — all explicable individually, devastating collectively.

No single alert crosses the threshold for escalation. Each one, in its silo, looks like it might be a false positive, a misconfigured integration, or a legitimate business process that was never properly baselined. The exfiltration narrative — the recognition that these signals are one coordinated campaign — only becomes visible when someone threads them all together. In a SOC processing thousands of alerts daily across multiple teams with separate tooling and separate queues, that cross-source correlation never happens at the speed required. It happens weeks later, in the incident response engagement, when the data is already on a breach forum.

Three Playbooks, One Investigation Gap

The breadth of ShinyHunters’ approach makes the investigation gap worse, not better. A security team that has tuned its detections for cloud misconfiguration scanning may still be blind to vishing-initiated credential abuse. A team focused on identity anomalies may not correlate a suspicious login with the OAuth token activity that follows it. And a team monitoring SaaS integrations may miss the supply-chain compromise because the OAuth tokens are technically valid.

The pattern is consistent across all three playbooks. Business units deploy cloud portals under deadline pressure without thorough security review. Help desks process credential resets without correlating them against concurrent threat intelligence. OAuth integrations are authorized once and never audited again. In each case, the security organization is left monitoring alerts from systems it did not configure, for users it did not provision, through integrations it did not authorize — and doing so across separate teams with separate tooling.

Cloud posture management tools flag the misconfigurations. Identity governance platforms flag the anomalous logins. SaaS security tools flag the unusual API patterns. But the alerts enter the same overloaded triage queues, and a configuration finding on a portal that the security team has never heard of — or a help desk reset that looks routine — does not compete well for attention against active endpoint detections. The alerts persist unresolved for weeks, months, sometimes years, because the investigation that would have connected them never happened.

Closing the Gap

This is precisely what Intruex automates. AI agents investigate every alert by correlating activity across cloud, identity, help desk, and network telemetry sources automatically — not as a second-pass enrichment step, but as the primary investigation workflow.

When a help desk credential reset fires, the investigation does not stop at “verify the employee’s identity.” It automatically checks for subsequent login anomalies from unexpected geolocations. It correlates with Salesforce audit logs for Data Loader sessions initiated under the reset account. It cross-references DLP alerts for data volume spikes in the same time window. It checks connected app logs for OAuth token activity associated with the account. It assembles a timeline that spans every telemetry source the SOC ingests — not just the one that generated the alert.

The same cross-source correlation applies to the misconfiguration and OAuth supply-chain vectors. A Salesforce audit log anomaly from a guest user API call gets correlated with DLP alerts, identity events, and connected app logs in the same investigation. An OAuth integration behaving outside its normal scope gets investigated alongside the upstream compromise that enabled it. The investigation that ShinyHunters depends on SOC teams never performing — the one that connects signals across all three playbooks into a coherent exfiltration narrative — happens in minutes, automatically, for every alert.

Before 275 million records leave the environment.

Sources: CRN Mega-Breach Tracker H1 2026, Check Point Research Threat Intelligence Report 2026, Google Cloud Threat Intelligence (UNC6040 research), Varonis Threat Labs (ShinyHunters vishing documentation)