How ShinyHunters Exploits Helpdesk Vulnerabilities and Weaponizes Social Engineering in 2026 Breaches
How ShinyHunters Exploits the Human Layer @channel So I already had a draft of this weeks’ post, but my reading of the recent cyber news has made me reconsider, and I think this is the more important topic right now. In the last month alone, ShinyHunters has: · breached Kodak (2.2 million records published after a three-day ransom deadline expired), · threatened One Medical patients across 250 clinics with the release of 8.8TB of healthcare data, · targeted Madison Square Garden Sports, releasing 26 million customer records, and · exploited a critical Oracle PeopleSoft zero-day to compromise over 100 organisations worldwide. June 2026 is not an anomaly — it is the new rhythm. ShinyHunters has now stolen data on over 400 million individuals this year alone, across more than 40 confirmed breaches, and their pace is accelerating. It’s vital we understand how they operate as it’s within our capability to do a better job of resisting them! Although the recent Oracle PeopleSoft campaign is a stark illustration of ShinyHunters’ expanding technical capability, it is an exception in one important respect: it relied on a software vulnerability (CVE-2026-35273). The majority of ShinyHunters’ 2026 portfolio is NOT technical: the Kodak extortion; the Council of Europe payroll dump (429,000 documents including 15 years of payslips), and the Coinbase breach earlier in the year all share a common thread — the attackers got in through people, not technical vulnerabilities. The Playbook: Weaponizing the Helpdesk Experience ⚡ ShinyHunters has industrialised social engineering at a scale that most organisations are not prepared for. The group now deploys AI-generated vishing calls at scale 🤖 — meaning a human attacker need not even be on the line for the initial contact ☎️ Technique 1 - Attacking the Helpdesk 🎯 Every organisation has either internal IT helpdesks or outsourced third-party versions — staffed by agents trained to be helpful. That helpfulness is the vulnerability. When a caller knows an employee's name, manager, and the systems they commonly log into (all trivially assembled from LinkedIn and prior breaches), their instinct is to assist – it’s what their metrics drive them to do! Without robust caller authentication protocols, that instinct is an open door to password resets, MFA bypass, and policy exceptions. ShinyHunters knows this. Their operational cadence suggests they actively profile organisations before calling, selecting targets where helpdesk controls are weakest. Technique 2 - Attacking the User 🎯 Additionally, these AI agents impersonate IT support staff, manufacture urgency around fake outages, and guide service desk agents into resetting credentials or reading back one-time authentication codes. MFA fatigue attacks compound this further: flood an employee with push notifications, then call them pretending to be IT and asking them to "approve the one that just came through to stop the error." What Good Authentication Looks Like 👍 The controls required to defend both these attacks are well understood. What is missing is consistent enforcement across both internal and third-party desks. Security leaders should act on four priorities immediately:
Caller verification: Helpdesk agents must strongly verify identity, ideally though independent channels before acting on any account request. Similarly, users must validate that it’s their Helpdesk colleagues calling before engaging.
MFA reset lockdown: Password resets that could disable or bypass MFA must require elevated approval workflows — never single-agent discretion.
Phishing-resistant MFA: Where possible, migrate away from push-based authenticators as they are vulnerable to both fatigue attacks and real-time phishing interception (NB. This is what my planned post was about – so look forward to something on this in the next week or two!)
Third-party contractual controls: Service desk providers must meet the same authentication standards as internal teams. So, include contractual obligations, audit rights, and regular red team exercises that address social engineering scenarios.
Take Action Now 🫵 The volume and velocity of ShinyHunters' June 2026 activity should be a clear signal - this is not a threat to monitor, it is a threat to act on. We, as security leaders should be reaching out this week to internal Helpdesk management and every third-party provider with access to production systems, auditing caller authentication procedures against the techniques documented here, and scheduling live social engineering tests. The group has made clear, breach after breach, that they will keep calling until someone picks up and helps them in. The question is whether your ‘Help” desks are ready to refuse. Over To You 💬
- 1.
What caller authentication processes have you found that work well for your Helpdesk interactions?
- 2.
Are your Helpdesk willing to say ‘no’, and refuse help?
- 3.
How do you audit your third-party Helpdesk providers to ensure they meet your standards and robustly defend against social engineering attacks?