ReliaQuest says it has been targeted in a ShinyHunters hack, but it insists the incident did not turn into a broader compromise of systems or customer data. In a statement posted on X on August 17, the cybersecurity firm described ongoing tracking of a phishing effort linked to the ShinyHunters threat activity.
While the company acknowledges a weekend social engineering attack, its account focuses on containment: the threat resulted in only limited access to an identity dashboard and did not reach business applications or sensitive information stored in the environment.
What ReliaQuest reported about the phishing campaign
ReliaQuest reported that it had been monitoring a widespread ShinyHunters phishing campaign. The campaign involved domains using a specific URL pattern that the company described as “company.claims.” That naming structure helped the attackers direct targets to fraudulent pages designed to steal credentials and push approvals.
According to ReliaQuest, the group’s approach also showed a pattern of escalation. Beyond impersonating typical internal support roles, it warned that the attackers were expanding their social engineering techniques to include legal team impersonation. In other words, the attempts were designed to feel legitimate depending on who was being contacted.
Screenshots and a taunting message
After ReliaQuest’s initial public warning, someone shared multiple screenshots that appeared to show access to a ReliaQuest Okta dashboard. The same screenshots were reportedly posted on ShinyHunters’ website alongside a message that mocked the security firm.
ReliaQuest later addressed the incident on Monday, acknowledging it had been targeted over the weekend using social engineering as the primary method.
How the attack worked step by step
ReliaQuest’s account describes a chain of events built around identity phishing and targeted phone calls. In short, the attackers created a fake domain, configured it to host an SSO phishing page, and then attempted to steer employees toward that page through direct outreach.
The company explained that the threat actor called multiple ReliaQuest teammates. Each time, the attacker posed as a security employee by name, aiming to remove friction and encourage the recipient to take action quickly.
ReliaQuest said at least one teammate ultimately entered their password and approved a push notification on their phone. The firm added that this sequence granted the attacker a brief session on its identity dashboard.
Limited access: view-only, no further systems reached
A key part of ReliaQuest’s message is what did not happen. The company stated that the attackers obtained view-only access to the identity dashboard.
It also noted that applications, systems, and customer data were not compromised. Even after attempts to access applications from the dashboard, the attackers were reportedly denied repeatedly due to the security controls already in place.
In other words, the incident did not progress from stolen credentials and a short session into successful access to downstream services. The firm framed the outcome as constrained by controls and by the nature of the access obtained during the social engineering sequence.
No extra identities, no persistence, no ransomware activity
ReliaQuest further addressed the scope of identity exposure and claims circulating online. The company stated that no additional identities were accessed beyond the user whose login credentials were used.
ReliaQuest also said there were no business applications reached and no customer or ReliaQuest data accessed beyond those login credentials. It added that no persistence was established after the brief session, suggesting the attackers did not gain a lasting foothold.
Finally, ReliaQuest rejected specific ransomware narratives. It asserted that claims describing ReliaQuest as compromised or targeted by ransomware were false.
Why impersonation is an effective lever
This incident highlights a broader social engineering pattern that security teams often struggle to neutralize with technical controls alone. When attackers impersonate internal staff and use familiarity—like using names and role-specific cues—they can reduce skepticism in high-pressure moments.
ReliaQuest’s warning about legal team impersonation alongside IT and help desk impersonation shows how threat actors may broaden their “target list” by choosing the role that best fits a plausible request. The goal is not only to trick a person into visiting a phishing page, but also to prompt them to complete credential entry and approve multi-factor prompts.
When a push notification is approved, even for a moment, the window for an attacker to operate can be extremely short. That is precisely why the difference between a brief session and a fully authorized takeover matters. ReliaQuest says it stayed on the safer side of that line.
Practical takeaways for organizations
While every environment differs, there are several lessons that align with the way this attack is described. First, organizations should treat unexpected messages and calls—even those that reference internal titles—as untrusted until verified through a separate channel.
Second, teams should reinforce how employees handle authentication prompts. Confirming who initiated a login attempt and where the approval request originated can prevent “one-click” compromises during social engineering incidents.
Third, having security controls that limit what an identity session can do matters. ReliaQuest’s statement about view-only access and consistent denials suggests that least-privilege approaches and protective checks can reduce damage when phishing succeeds.
What happens next after a social engineering incident
Even when a company reports limited impact, incidents like this still warrant follow-up. Common steps include reviewing identity logs, validating authentication events tied to the phishing page timing, and checking whether any other accounts showed unusual activity—even if the organization believes only one user was affected.
ReliaQuest’s public account indicates that it already assessed the situation and concluded that no additional identities were accessed and no persistence was established. Still, the presence of taunting screenshots and public claims typically drives more scrutiny and additional incident hardening across identity workflows.
As threat actors adapt their tactics, defenders usually respond by tightening verification processes, improving user training for role-based impersonation attempts, and tuning access policies to limit session capabilities.
Conclusion
ReliaQuest says it was targeted in a ShinyHunters hack involving a fake domain and an SSO phishing page, supported by calls that impersonated internal security staff by name. The firm reports that one employee entered a password and approved a push notification, enabling a brief session on its identity dashboard.
Importantly, ReliaQuest maintains that the outcome was limited: attackers reportedly received view-only access, were consistently denied when trying to reach applications, and did not obtain additional identities or access customer or company data beyond the user login credentials. The company also denies ransomware-related claims.
Source: https://www.securityweek.com/reliaquest-confirms-shinyhunters-hack-but-says-impact-was-limited/
