An employee handed over a password and approved the push notification. The intrusion failed at the next control rather than at the user.

 

What happened

ShinyHunters listed the security firm ReliaQuest on its leak site on August 23, 2026, publishing screenshots it said showed access to the company's Okta identity dashboard, The Register reported. No stolen customer data accompanied the listing, and researchers reviewing it found no validated data samples, no ransom demand, and no evidence that customers were affected. ReliaQuest confirmed an attack occurred on August 22 while disputing the characterization, saying the attempt was unsuccessful beyond briefly exposing a single identity. The exchange followed a public spat, since ReliaQuest researchers had days earlier documented ShinyHunters registering domains ending in ".claims" that carried target company names, prompting an account tied to the group to reply with screenshots and the question of who was hunting whom.

 

Going deeper

Attackers built a replica of the company's single sign-on page and telephoned several employees while posing as members of its own security team, and one employee entered their password and approved a multi-factor push notification, which handed the attacker a live identity session. What stopped the attack was device-trust enforcement, meaning a policy requiring that the machine holding a session be one the organization manages and recognizes. The attacker held a valid session on an unrecognized device, and every application behind that policy refused it. The security team then killed the session, expired the employee's password, and reset their authentication factors. The disagreement between the two parties is narrower than it appears, since it turns entirely on whether a foothold that reached nothing counts as a breach.

 

What was said

"It was unsuccessful beyond temporarily exposing one identity," a ReliaQuest spokesperson told The Register, adding that the access was view-only, that no applications or systems were reached, and that no customer data was touched. ShinyHunters answered from its leak site with a post reading, "This time the post is about you, not us," telling the company to let Mandiant report on the group instead.

 

In the know

ShinyHunters has become one of the most active data extortion operations working against healthcare, and its method in this case matches what it has used against the sector all year. Health-ISAC, the health sector's information sharing centre, warned members in July of rising successful attacks by the group, describing an operation that steals data and extorts without deploying encryption and gains entry by phoning employees to reset passwords or enroll new devices. Its 2026 healthcare victims include DentaQuest, which has notified roughly 15 million people, and Abbott's cancer diagnostics business, where the group published 10.9 million email addresses after negotiations failed. Health-ISAC's recommended response is to treat single sign-on infrastructure as the organization's most sensitive tier and require compliant, managed devices for access to it, which is the control that is held in this case.

 

The big picture

NIST states that the objective of verifier impersonation resistance is "to not depend on the claimant detecting a phishing attack," and notes that one-time password devices can never provide it because such an authenticator cannot control where its output is entered, in the implementation resources for SP 800-63B. A push notification carries the same limitation, since approving it confirms that someone is trying to log in without confirming who or from where. Healthcare organizations that have deployed social engineering training and push-based authentication have built a defense that assumes the employee will notice something wrong, and this case is a documented instance of a trained employee at a security company not noticing. Device compliance requirements and phishing-resistant authentication both work regardless of what the user does, which is the property worth prioritizing when deciding where the next control investment goes.

 

FAQs

What is device trust and how does it differ from multi-factor authentication?

Multi-factor authentication verifies the person, while device trust verifies the machine, checking that a session originates from hardware the organization enrolled, manages, and considers compliant with its policies. An attacker holding valid credentials and a valid session still fails if their device is unrecognized.

 

Why does approving a push notification carry risk?

The prompt confirms only that an authentication attempt is happening, not that the person approving it initiated it or that the login is going to the genuine site. An attacker relaying a real login triggers a genuine prompt, and a user expecting one because they just entered a password on a convincing page will approve it.

 

Does a foothold that reaches nothing require breach notification?

Under HIPAA, it depends on whether protected health information was accessed or acquired, which requires a documented risk assessment rather than an assumption. An organization able to demonstrate through logs that a session never reached systems holding PHI is in a considerably stronger position than one that cannot.

 

What should happen immediately after an identity is exposed this way?

Terminate active sessions rather than only resetting the password, since sessions survive password changes, then reset authentication factors, review whether any new devices or applications were registered, and check audit logs for what the session touched before it was killed.

 

How do organizations begin moving toward phishing-resistant authentication?

Most start with the highest-risk populations, covering administrators, executives, and anyone with access to systems holding sensitive data, then expand as hardware keys or passkeys are distributed. Interim measures include requiring compliant devices, number matching on push prompts, and blocking legacy authentication methods that bypass modern controls entirely.