The attack was simple enough: a phone call compromised a Microsoft Entra account, that hijacked account then accessed a Salesforce environment. That environment then yielded tens of millions of customer records. The Charter Communications breach, attributed to ShinyHunters, did not require a sophisticated exploit chain or a zero-day. It required a convincing voice and an authentication architecture that could not contain the ensuing movement.
That sequence: entry through social engineering, lateral movement through identity infrastructure, mass extraction from SaaS provider is now all too common and a documented, repeatable pattern across dozens of organizations. The question for enterprise security leaders, SaaS providers, and platform operators like Salesforce is what they need to change to better stop it.
Eric Parizo, founder, president and chief analyst at Cernivera, has been closely tracking ShinyHunters’ activity. The scale of it, he said, is hard to overstate. The group’s 2026 hit list alone includes Panera, GrubHub, Wynn Resorts, Rockstar Games, the European Commission, ADT, Instructure, 7-Eleven, and Charter, among others, and the operation seems to be running with a playbook that many platform providers and enterprise security programs are not structured to match.
Related:

The enterprise identity security gap
Most enterprise identity programs were designed to verify who gets in. Fewer were designed to detect when a legitimate credential is being used by someone who shouldn’t have it, in a session that shouldn’t be happening. Unauthorized accounts pulling high volumes of data should be considerably more difficult than they are currently.
That asymmetry is the structural gap ShinyHunters has been exploiting. Voice phishing attacks succeed not because MFA is universally absent, but because helpdesk and support workflows routinely require bypassing or resetting it. An attacker who can impersonate a credible user during a phone call can, in many enterprise environments, walk straight through the controls designed to stop them.
“Help desk and service desks continue to be the target, because the help desk deals with sensitive business transactions, credential management, account lockouts, and are trained and measured on being helpful,” said Keith Stewart, CEO of Humanix, a social-engineering detection startup. “The help desk agents themselves are put in an impossible position that no amount of security training will resolve.”
Andrew Chipman, GRC lead analyst at ProCircular, says the prescription is organizational, not technical. A well-constructed social engineering exercise in which someone poses as an executive demanding that a control be bypassed exposes exactly where that pressure point breaks down. But the exercise only works if the groundwork has been laid. “Provide the training and empowerment before the first exercise,” he said. “Let your help desk know they can say no and follow the process. Then leave time between the training and the exercise to simulate realism.”
The goal is to build the organizational muscle needed to push back.
The industry, Chipman added, needs to stop punishing helpdesk staff for doing what executives demand. “Executives can help by setting the tone at the top: no exceptions for security controls.”
Stewart added that enterprises should mandate MFA for identity verification in sensitive helpdesk workflows and deploy AI-native observability tools capable of detecting when these attacks or near-misses occur in real time. “To protect our laptops, we use EDR (endpoint detection and response),” he said. “We should do the same thing here,” he said, adding that organizations should also implement threat detection and response technologies that are non-intrusive and provide direct controls to mitigate these attacks.
He also recommends auditing helpdesk identity verification procedures against actual practice. Many organizations, he noted, are still running outdated verification approaches, including security questions, mother’s maiden names, even when stronger controls exist elsewhere in the environment but haven’t been connected to every procedure.
Salesforce must answer
Salesforce is the system that held the data, and where the data reportedly surfaced on demand. Many contend that creates obligations that go beyond standard shared-responsibility language.
Parizo’s analysis identifies four specific control gaps that have recurred across ShinyHunters’ Salesforce-focused intrusions.
- MFA has not been mandatory — it has been opt-in, a posture that is difficult to defend when a well-documented attack campaign has been exploiting that gap for over a year.
- IP range restrictions, which allow administrators to limit logins to known corporate addresses, are available on the platform but are widely underutilized, in part because the configuration is non-obvious and competes with other administrative workloads.
- Anomaly detection, including flagging a login from an unfamiliar IP that immediately exports thousands of records, has been available only as a paid add-on through the Shield Event Monitoring module, at an additional cost representing roughly 10% of an organization’s total Salesforce spend.
- Data exfiltration controls apply to manual exports but not to the Salesforce API, which ShinyHunters’ tooling uses for extraction and which is not subject to rate-limiting.
“In our opinion, Salesforce deserves scrutiny for not doing more to help defend its customers in the year-plus since these ShinyHunters attacks began,” Parizo said, “both by enabling key security capabilities within its platform, and through more robust customer awareness communications.”
Salesforce is making changes, he noted. Anomaly detection has recently been moved to a standard feature. The platform is blocking more suspicious logins. Mandatory MFA is scheduled for July. But the timing matters. “If I’m one of the many Salesforce customers like 7-Eleven or Charter Communications that were recently breached after seeing dozens of other major Salesforce customers breached with similar TTPs for more than a year,” Parizo said, “I’m asking: what took so long?”
With the established pattern: controls that existed as optional features or premium add-ons while a motivated threat group was actively exploiting their absence it’s now fair o ask if the shared-responsibility model is holding up as platforms don’t seem to always be doing their share.
Why are the seams still being left open
Unfortunately, identity security and SaaS security have evolved as adjacent disciplines. Identity teams manage authentication. SaaS security teams, if they exist at all, manage application configurations and permissions. Neither group typically has full visibility into what a compromised session looks like as it moves between them.
Adam Issa, senior threat intelligence consultant at NCC Group, said the real battle is often decided before an attack is visible. “Initial access and credential harvesting are the silent, early-stage phases of an intrusion that frequently slip under the radar,” he said. “Organizations must move past relying solely on human behavior and implement rigorous architectural controls.” That means enforcing MFA for all remote and administrative access, strictly limiting the use of domain administrator accounts, and actively monitoring administrative activity.
Once credentials are stolen, Issa added, attackers pivot fast. Network segmentation and restricted lateral movement protocols can slow that progression. But defenders also need to go beyond static signature-based detection and monitor for behavioral indicators, including outbound proxy traffic and SOCKS-style tunneling, that signal a hidden intruder operating on valid credentials.
For immediate risk reduction, Issa pointed to Group Policy Object controls as a critical bottleneck. Without strict change controls on GPOs, an attacker can trigger near-simultaneous domain-wide ransomware deployment with virtually no response window for defenders. Secure, regularly tested offline backups close out the loop.
Closing the seam between identity and SaaS requires treating them as a single risk surface with unified monitoring, documented access baselines, and response playbooks that account for cross-platform lateral movement. It also requires security teams to pressure SaaS vendors in procurement conversations, not just after incidents, on what their platforms will detect, alert on, and limit by default.
Parizo went back and read the Malwarebytes analysis from a year ago. The TTPs have evolved, he said, but the attack playbook is substantially the same. The gaps that enabled these intrusions are largely the same ones that enable them now.
A year of documented breaches later, very little has changed: that is a problem that belongs to enterprises and platform providers in equal measure.
