By 
There is an uncomfortable irony at the center of this story. Days before it happened, ReliaQuest’s own threat researchers published a warning about the extortion group ShinyHunters registering lookalike “.claims” domains to impersonate company help desks. Then, on August 22, attackers used a domain reported to be reliaquest.claims to try exactly that trick against ReliaQuest itself. A security company got targeted by the playbook it was actively tracking.
The attack was a textbook piece of voice phishing, or vishing. The attackers stood up a fake ReliaQuest single sign-on page, hid it behind a content delivery network to make it look legitimate, then phoned multiple employees while impersonating a named member of the company’s own security team. The goal was simple: get someone to log in on the fake page. One employee did, entering their password and then tapping approve on the multi-factor authentication push that landed on their phone. With that, the attackers had a live session inside ReliaQuest’s identity dashboard.
Why it stopped there
This is the part that matters, and it is why ReliaQuest is telling the story rather than burying it. That stolen session had only view-only access, and when the attackers tried to pivot from the dashboard into actual business applications, they hit a wall. ReliaQuest’s device-trust controls refuse to let unmanaged, non-corporate devices reach company systems, so a valid login from the wrong laptop got them nowhere. The company killed the session, expired the password, reset every authentication factor tied to that identity, and combed 48 hours of logs, finding no other compromised accounts, no persistence, and no access to customer or company data.
ShinyHunters has since listed ReliaQuest on its leak site, and the company has flatly denied the group’s claims of a ransomware incident or a wider breach. Worth noting: a name on a leak site is a marketing tactic, not evidence, and by outside accounts the material posted does not back up the access ReliaQuest disputes.
The lesson is not “MFA works”
It would be easy to draw the wrong conclusion here. The comforting version is that multi-factor authentication saved the day. It did not. MFA is precisely what failed, because a human being can be talked into approving a push notification, and this one was. The thing that contained the damage was an architectural choice: separating the act of logging in from the right to reach anything valuable. A password and an approved prompt got the attackers a session, and that session, by design, was nearly worthless.
That is the takeaway for everyone else. Push-based MFA is not phishing-resistant, and the fix is to move toward methods that are, like FIDO2 security keys or passkeys, while enforcing device checks, restricting who can enroll new authenticators, and watching identity sessions for anything odd. Just as important is the human protocol: an unexpected call from IT or security should be a red flag to verify, not an instruction to follow. Hang up, and confirm through a channel you trust.
If a company that does this for a living can have an employee approve a malicious prompt, so can yours. So what saves you when someone inevitably clicks? Not the hope that they won’t, but the assumption that they will, and a system built so that a single stolen login opens almost nothing.
Comments