A security firm got phished and the attacker approved MFA. Device trust is why nothing was stolen. That is the whole case for it, in one incident
ShinyHunters vished a ReliaQuest employee to a lookalike SSO page and got a password and an approved MFA push. Device-trust controls then blocked every application, because the attacker's device was not enrolled. No data was touched.
By Parminder Kumar Sharma · · 6 min read

What happened
A security company got phished, and the interesting part is which control caught it.
ReliaQuest confirmed on 24 August 2026 that the extortion group ShinyHunters ran a voice-phishing attack against its staff, impersonating a named member of ReliaQuest's own security team. The attacker called employees and steered them to a fake single sign-on page hosted on a lookalike domain, reliaquest.claims, part of a wider ShinyHunters campaign registering company.claims domains to impersonate help desks and IT teams.
One employee fell for it: entered their credentials on the fake page and approved an MFA push notification. The attacker got in, and reached ReliaQuest's identity dashboard with view-only access.
Then it stopped.
Where the attack stopped
The control that mattered
Two of the layers everyone talks about failed. The password was captured. The multi-factor push, the control widely sold as the answer to phishing, was approved by a tricked human and did nothing. What held was the layer few procurement conversations mention: device trust. Because the attacker's device was not an enrolled, trusted endpoint, every attempt to open an application from the dashboard was denied. ReliaQuest terminated the sessions, revoked the password and reset authentication tokens, and its investigation found no access to applications, systems or customer data.
The lesson is uncomfortable for anyone whose phishing-resistance story ends at MFA. A push notification is a human decision, and humans under a convincing pretext approve them. The control that does not depend on the human getting it right is the one that checks whether the request comes from a device you trust.
Which layer did what
| Layer | Outcome | Why |
|---|---|---|
| Password | Failed | Entered on a lookalike SSO page, reliaquest.claims |
| MFA push | Failed | Approved by the tricked employee; a push is a human decision |
| Device trust | Held | Attacker device was not enrolled; application access denied |
| Response | Contained | Sessions killed, password revoked, tokens reset; no data touched |
The irony, and why it helps
ReliaQuest had, the week before, publicly documented this exact ShinyHunters .claims campaign. The attackers noticed, taunted the company with "Who's hunting who?", and posted screenshots of the compromised dashboard. A security firm being caught by the campaign it just reported is an easy headline, but the useful reading is the opposite. The company that studies this for a living still had an employee approve a malicious MFA push, which tells you no amount of awareness reliably prevents the click. The defence has to assume the click happens and hold anyway. Here it did.
Take this with you
What to take from a contained breach
- Do not let your phishing-resistance story end at MFA. A push a human can approve is a control a human can be tricked into defeating. Assume the approval happens.
- Deploy device trust, or phishing-resistant factors bound to the device, so access depends on a trusted endpoint and not only on a human decision. This is the layer that held here.
- Watch for company.claims and similar lookalike domains impersonating your help desk and IT. Registering or monitoring for them is cheap; ShinyHunters is using this pattern at scale.
- Rehearse the containment, not just the prevention. ReliaQuest killed sessions, revoked the password and reset tokens quickly, which is why view-only access stayed view-only.
- Brief staff that the caller claiming to be internal security is the attack. The impersonated employee here was real and named, which is exactly what makes the pretext work.
The position
The honest way to write this is not as a security firm's embarrassment but as a working demonstration of defence in depth. Prevention failed, twice, at the two layers most organisations stop at. The breach was contained anyway, because a control that does not trust the human held the line. That is the whole argument for device trust in one incident, and it is more persuasive coming from a case where the human got it wrong than from any vendor slide where they get it right.
It is worth being precise about why MFA underperformed here, because the lesson is not "MFA is useless". A push-based second factor stops an attacker who has only a stolen password and no way to make the real user approve a prompt. It does nothing against an attacker who can get the real user to approve the prompt, which is exactly what a convincing pretext, a real employee's name and a lookalike domain achieve. The factor was not bypassed technically; it was satisfied by the legitimate user, on the attacker's behalf. Phishing-resistant factors, the kind bound to a specific device or a hardware key that will not authenticate against a lookalike origin, remove that possibility because there is no human decision left to manipulate. Device trust sits in the same family: it asks a question the human cannot answer wrongly under pressure, because the human is not asked at all.
Sources
- PrimaryReliaQuest confirms failed data-theft attack after ShinyHunters breachBleepingComputeraccessed 2026-08-24


