The Password and MFA Push Were Accepted. Device Trust Still Stopped the Attack.
A ReliaQuest employee entered a corporate password into a fake single sign-on page and approved the attacker’s multi-factor authentication push. The resulting session was valid. It still did not open the company’s applications.
ReliaQuest says device-trust controls required requests to come from a managed endpoint. The attacker could view the employee’s identity dashboard, but repeated attempts to launch applications were denied. The case is an unusually clear demonstration that successful authentication does not have to become successful authorisation.
A phone call, a lookalike domain and a real session
The attack began on 22 August 2026. According to ReliaQuest’s account as relayed by Health-ISAC and independent reporting, the operator registered a lookalike domain and placed a counterfeit corporate SSO page behind a content delivery network. BleepingComputer identified the domain as reliaquest.claims.
The caller contacted several employees while impersonating a named member of ReliaQuest’s own security team. One employee followed the instructions, submitted a password and approved a push notification on a mobile phone. Those actions handed the attacker a temporary authenticated session on the identity provider dashboard.
This was not merely a failed phishing email. The attacker crossed the primary authentication boundary and could see the employee’s top-level application tiles. ReliaQuest described the access as view-only.
The second boundary held
Application access was governed by a separate condition: the requesting device had to be trusted and managed by ReliaQuest. The attacker’s external endpoint did not satisfy that policy. Each attempt to pivot from the identity dashboard into an application was rejected.
ReliaQuest terminated the attacker’s sessions, expired the exposed password and reset the employee’s authentication factors. Its investigation reviewed device-trust controls, on-network activity, control fidelity and suspicious activity across the preceding 48 hours.
The company reported no unauthorised access to internal applications, enterprise systems, customer environments or telemetry. It also said no customer or company data was reached beyond the employee’s login credentials, no additional identities were accessed and no persistence was established.
What “compromised” means here
Reporting linked the operation to ShinyHunters after screenshots of an identity dashboard appeared in posts and on a leak site. Health-ISAC described the activity as ShinyHunters-linked. ReliaQuest’s own incident account did not publicly attribute the attack to a named actor, so that attribution should remain separate from the company’s confirmed findings.
ReliaQuest rejected claims that it had been compromised or targeted by ransomware. The wording can sound contradictory because one employee’s identity session was exposed. The useful distinction is between identity-provider visibility and downstream application access. The attacker obtained the former. ReliaQuest says its controls prevented the latter.
No independently verified customer-data sample or evidence of application access was published with the attacker’s claim. That does not erase the successful credential theft and MFA approval, but it constrains what can responsibly be called a breach of ReliaQuest systems.
Why MFA was not the endpoint
Push-based MFA can prove that a user approved a prompt. It does not prove that the request came from a safe device, that the user understood the transaction or that the session should inherit access to every application.
The ReliaQuest incident illustrates a more resilient sequence:
- Authentication established the employee’s identity session.
- Device compliance and trust were evaluated again at the application boundary.
- Application launches from the unmanaged endpoint were denied.
- Session and factor revocation contained the exposed identity.
The controls did not make the employee immune to social engineering. They reduced the authority of the session that social engineering produced.
Detection opportunities
- Alert on a successful password and MFA sequence followed by repeated device-compliance denials in the same session.
- Restrict sensitive SaaS applications, administrative portals and APIs to managed devices validated through certificates, endpoint health or mobile-device management.
- Monitor newly registered lookalike domains, including brand names under uncommon top-level domains.
- Train employees to distrust unsolicited calls that direct them to a login page or request immediate MFA approval, even when the caller knows internal names.
- Keep revocation playbooks capable of killing active sessions, expiring passwords and resetting every authentication factor quickly.
The strongest signal may be the sequence itself. A legitimate user normally signs in from a compliant endpoint and reaches an application. A valid login followed by a burst of device-trust failures is evidence that the phish may already have succeeded and that the second boundary is doing its job.
Sources
- Health-ISAC and American Hospital Association, “ShinyHunters-Linked Social Engineering and Identity-Targeting Campaign”, published 24 August 2026. The page provides no publication time.
- BleepingComputer, “ReliaQuest confirms failed data-theft attack after ShinyHunters breach”, published 24 August 2026 at 11:17. The page does not state a timezone.
- Infosecurity Magazine, “ReliaQuest Rejects Compromise Claims After ShinyHunters Incident”, published 25 August 2026. The page provides no publication time.
Source limitation: ReliaQuest’s original 23 August incident statement was extensively quoted by the sources above, but its primary publication URL could not be reliably resolved at drafting time. The article therefore attributes the company’s claims precisely and separates them from third-party actor attribution.
