ReliaQuest Says Device Trust Stopped ShinyHunters Data Theft

Cybersecurity company ReliaQuest says layered identity controls stopped a social-engineering attack from reaching its business applications or customer data, even after one employee surrendered login credentials and approved a fraudulent multi-factor authentication request.

The incident was attributed to a campaign associated with the ShinyHunters data-extortion group. Attackers reportedly called employees while impersonating security personnel and directed targets to a fake single sign-on page hosted on a lookalike domain. Using the identity of a real security employee can make this type of voice-phishing attempt unusually convincing.

Credentials and MFA were not enough

One targeted employee entered credentials into the phishing page and approved an MFA push notification. That gave the attacker temporary, view-only access to an identity dashboard, according to the company's account. The attacker then attempted to open applications connected to the identity system.

Those attempts were denied because the connection did not satisfy device-trust requirements. ReliaQuest said the intruder did not reach its applications or systems and did not access customer data. The company terminated the session, revoked the exposed password and reset authentication tokens while investigating whether any other identity or persistence had been established.

ShinyHunters later displayed screenshots that appeared to show access to an employee's identity account. The evidence illustrates an important distinction between seeing an identity dashboard and successfully reaching protected company data. ReliaQuest and the alleged attackers both described the access as limited, although claims made by criminal groups should always be treated cautiously.

The defensive lesson

The incident demonstrates why MFA should not be the final security checkpoint. Push-based authentication can fail when a user is pressured by a convincing caller or overwhelmed with prompts. Device trust adds another condition by requiring access to come from an approved or properly managed computer.

Organizations can reduce similar risk by combining phishing-resistant authentication, device compliance, conditional access and short-lived sessions. Help desks should use a separate verification procedure before asking employees to take account actions. Newly registered domains that imitate a company's name should also be monitored and blocked where possible.

Employees should be trained that legitimate security teams do not need them to enter credentials into links supplied during an unsolicited call. When a questionable MFA prompt appears, the safest response is to deny it and contact the help desk through a known internal channel. The failed theft attempt shows that a single compromised factor does not have to become a full breach when additional controls remain independent and enforced.