SURIQ
The notable part of the ReliaQuest incident is not that attackers tricked an employee. It is that every control wrapped around that employee gave way, and the theft still failed. On a phone call, the attacker posed as the company's own security team, walked the employee onto a fake login page, and got a multi-factor push approved. Three layers that all depend on a person making the right decision failed in sequence. What stopped the intrusion was a control that only runs after the login already succeeded. That inversion is the whole lesson for anyone defending single sign-on.
ReliaQuest, a managed security company, confirmed on August 24 that one of its employees was targeted three days earlier by ShinyHunters, a financially motivated data-extortion group. The attack was voice phishing, or vishing: a caller impersonating a real security-team member directed the employee to a lookalike domain, reliaquest.claims, that mirrored the company's single sign-on page. The employee entered credentials and approved the multi-factor authentication (MFA) prompt that followed.
Every human-facing layer failed, so map where the attack broke
Laying the incident out by layer shows the pattern clearly. The controls that asked a person to judge the moment all failed. The controls that made a decision without the human held.
| Defensive layer | Where it sits | Result |
|---|---|---|
| Security-awareness training | Before login | Failed: the employee trusted the caller |
| Password and SSO login | At login | Failed: credentials entered on a fake page |
| MFA push approval | At login | Failed: the push was approved |
| Device-trust and conditional access | After login | Held: blocked the unmanaged device from apps |
| Session-response playbook | After access | Held: sessions killed, tokens reset |
According to ReliaQuest's account, the approved login granted the attacker only view-only access to an identity dashboard. Device-trust controls then blocked every attempt to pivot from that dashboard into an actual application. The company says it cut off the attacker's sessions, changed the compromised password, and rotated the affected tokens, and that no customer data was touched. ShinyHunters, which posted the intrusion to its extortion portal, described the access the same way: view-only, nothing of value taken.
The control that held runs after the login, not at it
Most identity spending goes to the login itself: stronger passwords, an MFA prompt, awareness training so staff spot the fake page. This attack beat all three, and that is not unusual. A push notification a human can approve is only as strong as the human's certainty in a stressful phone call, and adversary-in-the-middle phishing kits relay the credential and the push in real time, so the second factor travels with the first.
The layer that actually stopped the theft sits one step later. Device-trust, sometimes enforced through conditional access, checks whether the machine reaching an application is known and compliant before it hands over anything. The attacker's device was neither, so the dashboard session was a dead end. The design principle worth taking from this: put your deciding identity control after authentication, on a signal the attacker cannot supply, not on a prompt your user can be talked into approving. We made a version of this argument when we covered phishing that steals live Microsoft 365 session tokens; the through-line is that the login is no longer where the fight is won.
Awareness training is not the backstop here
There is an uncomfortable detail in the timeline. In the days before its own employee was targeted, ReliaQuest's research team had published a spotlight on this exact ShinyHunters playbook: the vishing pretext, the branded lookalike domains, the real-time proxy that defeats push-based MFA. The people most informed about the technique still had a colleague approve the push. That is not a knock on the employee. It is evidence that training cannot be the control you rely on. If the org that wrote the warning can be caught by the thing it warned about, plan for the certainty that one of your people will approve a malicious prompt, and make sure that approval is not sufficient on its own. This is the same operational reality behind help-desk social engineering by Scattered Spider and the UNC6671 vishing campaign that emptied SaaS tenants.
Domain monitoring is losing the race to the lure
The incident used a registered lookalike, reliaquest.claims, which brand-monitoring tools can catch because the company name sits in the registered domain. ReliaQuest's own research notes the group has been shifting the brand out of the registered name and into subdomains instead, using a host that places the target's name ahead of domains such as sso.guide or okta.guide. When the brand no longer appears where certificate-transparency and domain-monitoring detections look first, the lure surfaces later, if at all. The practical response is to stop treating domain monitoring as the tripwire and add a behavioral one: alert on a successful SSO login from an unmanaged or first-seen device, on impossible-travel between the push approval and the session, and on a fresh session that immediately reaches for bulk data. Those signals fired conceptually in this case; the device check is what turned them into a block.
ShinyHunters has run this pattern at scale through 2026, against SSO tenants on Okta, Google, and Microsoft, so treat SSO help-desk vishing as an expected event in your threat model, not a tail risk. For teams that want those authentication signals watched around the clock and mapped to attacker techniques, that is the job of managed detection and response: it ingests the auth logs and raises the alert whether or not anyone is looking at 2 a.m.
Assume the push gets approved, and build for it
The takeaway is not "train harder." It is to design so that a socially engineered approval does not equal access. Concretely:
-
Move admin and high-value single sign-on to phishing-resistant MFA (FIDO2 or WebAuthn hardware keys), which binds the login to the real domain and cannot be relayed by a proxy page.
-
Require a managed, compliant device through conditional access before any sensitive application will open, so an approved login from an unknown machine goes nowhere. This is the control that held at ReliaQuest.
-
Keep a rehearsed session-response playbook: cut off active sessions, change the password, and rotate tokens at the first sign of a suspicious login, the steps ReliaQuest used to shut the window fast.
-
Add detections for a successful SSO login from a first-seen or unmanaged device and for a new session pulling bulk data, and watch for the newer subdomain-based lures, not just registered lookalikes.
The employee will occasionally approve the wrong prompt. The mature program treats that as a given and puts the deciding control somewhere the attacker's own device cannot pass.