More than 140 affected organizations, at least $70 million in extortion payments, and a single campaign that reportedly affected 1,000 Salesforce tenants and approximately 1.5 billion records. That is the track record of ShinyHunters, a cybercriminal collective that has been active since 2019 and is tracked by MITRE as G1057. Yet the scale of the operation is not the most striking thing about this group. Its methods are. It uses very little malware. The group simply logs in.
Our knowledge center, the Heimdallr Knowledge Center (HKC), has analyzed ShinyHunters’ threat actor profile: its MITRE mapping, campaigns from mid-2025 to mid-2026, arrests, and the question of whether there is any state-sponsored influence behind it. Not because this particular group is the most significant threat, but because its modus operandi illustrates exactly where the defenses of many Dutch organizations are currently vulnerable.
Let us start with one point: for years, we have argued that the perimeter is no longer the firewall, but identity, and that a valid login tells you nothing about whether a session is legitimate. ShinyHunters is proof of that. Virtually every step in its kill chain revolves around an account, a token, or an application function doing exactly what it was designed to do.
Who Is ShinyHunters?
The group operates under a recognizable brand and behaves more like a marketplace than a closed organization. Social engineers obtain access, so-called adjacent actors handle amplification and recruitment, and the stolen data is monetized under the shared name. The group also takes over access obtained by others.
Business model: Steal credentials and personal data, extort victims, extort them again, and then sell the dataset anyway.
One question we ask about every threat actor is whether state-sponsored influence is involved. Based on our current knowledge, the answer is no. All sources classify the group as criminal and financially motivated. Its only overlap with another cluster, UNC6671, is at the level of tradecraft; ShinyHunters operates independently.
The group is also resilient. The FBI is investigating it, Dutch police have arrested a 24-year-old from Amsterdam, and at least one confirmed arrest followed in September 2026. The brand continues to operate. Anyone who thinks an arrest solves the problem underestimates the modular structure of this group.
Three Access Routes, One Common Thread
The first and most important route is through identity. This includes vishing (voice phishing) under the guise of IT support, lookalike domains hosting fake single sign-on (SSO) pages, and bombarding users with multifactor authentication (MFA) push notifications until they eventually tap “Approve” out of fatigue.
In the Salesforce campaign, the core technique was device code phishing. The victim is directed to a legitimate login page and approves a session initiated by the attacker. The attacker then obtains an application token and never needs to log in again.
The danger lies in a distinction most users fail to make: proving who you are is not the same as granting an application access. Passkeys and hardware security keys do not protect against this attack because the authentication process itself has not been compromised.
During the campaign, the group used a malicious application called DataLoader, whose name imitates Salesforce’s legitimate data export functionality.
The second route is more conventional: exploiting publicly accessible applications. The best-known example is the breach of the FBI through CVE-2026-35273 in Oracle PeopleSoft.
One detail stood out to us as architects. Web Application Firewall (WAF) rules had been configured specifically for this vulnerability. The group bypassed them using simple URL encoding. A WAF is no substitute for patching, and according to our analysis, the breach was possible because a contractor had failed to patch the environment.
Once again, the chain is only as strong as its weakest link.
The third route runs through the software supply chain itself: scanning GitHub repositories and CI/CD pipelines for leaked secrets and using them to gain access through valid accounts.
The common thread: The attacker does not want malware on your endpoint. They want your keys.
Where the Evidence Gets Complicated
An honest analysis must also acknowledge what remains uncertain, and in this group’s case, there is more uncertainty than usual.
The figures of 1,000 tenants and 1.5 billion records cannot be traced to a primary measurement and are based in part on claims made by the group itself. ShinyHunters deliberately exaggerates; false claims are part of its modus operandi, intended to intensify the pressure of its extortion campaigns. The claim involving 284 million patient records at McKesson deserves the same skepticism as any statement issued by a perpetrator.
Furthermore, sources describe the PeopleSoft vulnerability both as a zero-day and as an unpatched vulnerability, although these cannot both be true in the same sense. And no one has fully explained the technical link between a Microsoft device login page and access to Salesforce data. There is no doubt that the technique works. Precisely how it works deserves a clearer answer.
For defenders, this is not an academic distinction. You should never take an extortion claim from this group at face value, but neither should you dismiss or downplay it. Forensic validation against your own export and audit logs must come before any communication with customers, regulators, or the media. That, of course, requires those logs to exist and to be retained for long enough.
ShinyHunters Through a Zero Trust Lens
Compare this profile with NIST SP 800-207, and you can see how precisely ShinyHunters exploits the weaknesses of an immature Zero Trust implementation.
Many organizations have implemented strong authentication and call that Zero Trust. But the Trust Algorithm should evaluate more than just who is logging in. It should assess every session, every token, and every application acting on behalf of a user.
A device code flow that falls outside Conditional Access is a Policy Enforcement Point with a hole in it. Allowing end users to approve OAuth consent requests themselves means handing over a policy decision that should remain under your control.
Continuous evaluation immediately points to the detection opportunities: a token issued through the device authorization endpoint, followed by use from an IP address or device that does not match the user’s normal behavior. Bulk API activity from an account that never normally performs such operations. A new application requesting broad scopes.
And the principle of assume breach means holding contractors to the same patching and access requirements as your own organization.
Three Practical Takeaways
First: Restrict or block the device code flow.
Restrict or disable the device code flow in your identity provider for anyone who demonstrably does not need it, and bring any remaining use under Conditional Access policies based on device compliance and location.
This is the one measure that would actually have stopped the Salesforce campaign. Phishing-resistant MFA alone is not enough.
Second: Remove OAuth consent from end users.
Only administrators should be able to grant applications permission. Existing consents should be reviewed during the next access review, and any permissions that are excessive or unused should be revoked.
Combine this with detection of mass exports from SaaS platforms and rate limits on bulk API operations.
Third: Patch publicly accessible applications and treat your WAF as a safety net, not a sticking plaster.
Place administrative interfaces behind identity-aware access controls and impose the same requirements on contractors as on your own organization.
There is also one recommendation that is not technical: adapt your security awareness program.
Generic phishing training teaches people to recognize suspicious URLs. With a device code or OAuth consent request, however, users are interacting with a genuine Microsoft page and may see nothing suspicious. The approval step itself must therefore be included in the training.
Ultimately, ShinyHunters is neither a malware story nor a zero-day story. It is a story about trust that has been granted too freely: trust in sessions, applications, and contractors.
Making that trust explicit and enforcing it at every step is what we help organizations achieve. This ranges from a maturity assessment based on NIST SP 800-207 to a working architecture in which a valid login does not automatically mean a valid session.
Curious about where your organization stands on device code flows and OAuth governance? Send us a message at info@heimdallr.nl.
This article is based on research by the Heimdallr Knowledge Center into the ShinyHunters threat actor profile (MITRE G1057, aliases UNC6240 and Bling Libra), October 2026. Figures concerning victims and records are drawn from public sources and claims made by the group itself.
