A caller reaches an employee and says they're from the security team. They know the employee's name. They ask them to sign in to a page that looks exactly like the company's single sign-on portal. The employee enters a password and approves the push notification.
Then…nothing happens.
That's the unusual ending to the story ReliaQuest told (opens in new tab) a little over a month ago. Most breach write-ups end with a ransom note. This one ends with an "access denied" screen, which is the best genre of security writing.
It's also a rare public look at the full social engineering attack chain, from fake infrastructure to a successful call to a blocked pivot. Walking through it shows where the defender won, where the attacker nearly did, and which warning signs were visible before the phone rang.
What happened on August 22
According to ReliaQuest, ShinyHunters-linked attackers registered a lookalike domain and stood up a fake single sign-on (SSO) page behind a content delivery network. They then called multiple employees, each time posing by name as a security teammate. One employee entered their password and approved the push on their phone.
The Health-ISAC summary (opens in new tab) fills in the mechanics. A reverse-proxy phishing kit relays the victim's credentials to the real login portal in real time. The caller then coaxes the victim into approving the MFA prompt, which hands the attacker a live session.
Here is how that maps to the attack chain:
- Setup: The attacker registers a lookalike domain and puts a fake SSO page behind a content delivery network.
- Launch: The attacker uses that infrastructure as the weapon, phoning multiple employees and posing by name as a member of the security team.
- Contact: The lure lands on the employee's device. The caller steers them toward the fake login page.
- Engagement: The live conversation does the work. One employee enters their password and approves the push notification, which gives the attacker a brief session on the identity dashboard.
- Compromise: The attacker tries to move from the dashboard into applications and is refused every time, so the data theft never happens.
None of this is new. Mandiant described a similar campaign (opens in new tab) earlier this year, built around stolen SSO credentials and attacker-controlled devices enrolled in victims' MFA. What's new is how openly the outcome was documented.
Why the attack stopped at the front door
The attacker got in. The attacker just didn't get anywhere.
Device trust did the heavy lifting
ReliaQuest says device trust controls keep non-company devices from reaching any application or system. The session came from an unmanaged external device, so it could see only the dashboard's top-level application tiles. When the attacker tried to move further, the requests were denied. Responders then ended the sessions, expired the password, and reset every authentication factor.
Health-ISAC's analysis reaches the same conclusion: Identity verification alone isn't enough without device-context checks and defense in depth.
Humans still got fooled. That's the point
An employee still gave up a password and approved a push. ReliaQuest's own framing is that its defense assumes someone will eventually be phished, so a successful sign-in isn't treated as permission to do anything.
This isn't proof that awareness training failed. A convincing caller who knows a teammate's name is hard to resist, and the architecture absorbed the mistake. Technical controls and prepared people need to work together.
The lookalike domain was the earliest signal
Here's what’s tough: ReliaQuest describes this playbook as using a throwaway lookalike domain that is registered and burned within the hour. A weekly review of newly registered domains won't catch something that's gone by lunch.
But the pattern wasn't invisible. Health-ISAC reports (opens in new tab) that the domains are named for the target company, with variable endings tailored to the lure, such as company-claims[.]com or company[.]claims.
Help Net Security reports (opens in new tab) that ReliaQuest's researchers had warned about this .claims registration pattern days before the attempt.
This table pairs the signals defenders could see with why each one matters and what to do about it.
Signal | Why it matters | What to do |
Domains named for your company, especially under .claims | The naming pattern was published before the attack | Monitor registrations for your brand and block .claim and .claims unless you need them |
An SSO-style login page behind a CDN | The CDN hides the real hosting, and the page copies your portal | Detect cloned login pages and disrupt the infrastructure behind them |
Hour-long domain lifespans | A ticket queue can't keep up | Automate detection and takedown so the response runs at attacker speed |
Calls and voicemails to personal phones | Employees are reached outside corporate controls | Train for the call and publish how IT will and won't contact people |
The takeaway is that a lookalike domain is a leading indicator, not a trailing one. Catching it takes continuous monitoring and automated takedown, not a manual triage queue. That's the difference between legacy DRP that reports alerts and Brand Protection built to dismantle the infrastructure. It's also why customers like ARK Invest cut scam takedown times from weeks to minutes.
Seeing the domain as part of a larger campaign matters too. The Doppel Threat Graph links related infrastructure so a takedown doesn't stop at a single URL, and campaign-level threat visibility shows the whole scam rather than isolated symptoms. We've made the same argument about measuring takedown speed instead of alert volume.
When the target is healthcare
Health-ISAC says ShinyHunters is actively targeting the health sector with medical-themed impersonation domains.
Once an identity is compromised, the actors move from the identity dashboard into connected platforms like Microsoft 365, SharePoint, and Salesforce to steal data. They also reach employees on personal phones through calls and pressuring voicemails.
More than a dozen (opens in new tab) organizations have been hit. On September 29, the FBI arrested an alleged ShinyHunters leader (opens in new tab). A playbook that works doesn't leave with its author, so defenders shouldn't assume the technique has gone away.
For healthcare teams, the same priorities apply: Block risky domains, verify devices, harden MFA, and rehearse the call.
An attack that skips the inbox needs training that skips it too
Traditional awareness programs focus on email. This attack never needed it. It arrived as a phone call, sometimes backed by a voicemail, often on a personal device. The caller supplied the urgency, the name, and a reason to hurry.
Employees need practice with that kind of pressure, not another lesson on spotting typos. The harder part is rehearsal: what to say when a caller who sounds legitimate asks you to approve something right now.
A few practices help:
- Verify the request, not the voice. A familiar name and a confident tone prove nothing, as we explored in Verifying What's Real in 2026.
- Rehearse the helpdesk moment. MFA resets and recovery requests are prime targets, and we've covered how to stop helpdesk and recovery abuse.
- Practice conversations, not just clicks. Dialogue is the payload.
- Close the loop on brand abuse. The same lookalike infrastructure used against employees can target customers.
A realistic phishing simulation should measure more than click rate. Track whether employees verify through a second channel, how quickly they report, and whether they hold their ground when someone pushes back.
What to do this week
You don't need a new architecture to act on this.
Start here:
- Block risky TLDs. Block .claim and .claims unless you have a legitimate reason to use them, as Health-ISAC recommends.
- Watch for lookalikes. Monitor domain registrations that include your company name, especially login-flavored ones, and automate takedown.
- Enforce device trust. Restrict SSO-connected apps to managed devices so an unmanaged session sees very little.
- Move to phishing-resistant MFA. Prioritize admins and high-risk groups, and tighten push-based approvals.
- Harden resets. Make sure employees know IT won't reset MFA on an inbound call.
- Rehearse the call. Run vishing exercises aimed at personal phones and the helpdesk.
- Prepare the cleanup. Have a plan to end sessions, expire passwords, and reset authentication factors quickly, as ReliaQuest did.
Assume someone will pick up the phone
The most useful part of ReliaQuest's account isn't that the attack failed. It's the assumption behind why it failed: someone will eventually answer, so a single sign-in can't be the keys to the kingdom.
Could your team spot a lookalike domain within the hour, and would your employees verify a caller who knows their name?
Request a demo to see how brand protection and realistic simulation can help close the gaps before the phone rings.