{"id":77690,"date":"2026-08-24T13:55:43","date_gmt":"2026-08-24T17:55:43","guid":{"rendered":"https:\/\/overcentral.com\/en\/?p=77690"},"modified":"2026-08-24T13:55:43","modified_gmt":"2026-08-24T17:55:43","slug":"reliaquest-shinyhunters-attack-77690","status":"publish","type":"post","link":"https:\/\/overcentral.com\/en\/reliaquest-shinyhunters-attack-77690\/","title":{"rendered":"ReliaQuest Confirms ShinyHunters Hack, Impact Limited"},"content":{"rendered":"

Cybersecurity firm ReliaQuest<\/a> has confirmed that it was targeted by hackers affiliated with the notorious ShinyHunters group, but the company maintains that the impact of the<\/a> attack was sharply limited, with no customer data, business applications, or internal systems compromised. The incident, which unfolded over the weekend of August 16<\/a>aaa\u201317, underscores the growing sophistication of social engineering<\/a> campaigns that now involve impersonating not only IT and help desk staff but also legal teams.<\/p>\n

ShinyHunters Phishing Campaign: The “Company.Claims” Domain Pattern<\/h2>\n

On August 17, ReliaQuest posted on X (formerly Twitter) that it had been tracking a widespread phishing campaign orchestrated by ShinyHunters. The campaign was characterized by the use of domains following a “company.claims” URL pattern, a tactic designed to lend an air of legitimacy to fraudulent login pages. The company warned that the hacker gang had expanded its social engineering tactics to include legal team impersonation alongside more traditional IT and help desk impersonation, indicating a broader repertoire of deceptive approaches.<\/p>\n

That post, subsequently deleted, drew immediate attention. In response, a user shared several screenshots that appeared to show access to a ReliaQuest Okta dashboard. The same screenshots were posted on ShinyHunters\u2019 own website, accompanied by a taunting message directed at the security firm. The incident quickly became a test case for how a mature cybersecurity company handles a targeted social engineering attack.<\/p>\n

What Happened in the ReliaQuest Social Engineering Attack?<\/h2>\n

ReliaQuest addressed the incident on Monday, August 19, admitting it had been targeted in a social engineering attack over the weekend. The hackers registered a fake domain and set it up to host a ReliaQuest single sign-on (SSO) phishing page. The threat actor then called multiple ReliaQuest teammates, each time posing as a security employee by name in an attempt to steer them toward the fake page. One teammate entered their password and approved the push notification on their phone, handing the attacker a brief session on the company\u2019s identity dashboard.<\/p>\n

This is a classic example of a multi-factor authentication (MFA) fatigue attack, where the attacker repeatedly prompts the victim to approve a push notification until they eventually do so out of annoyance or confusion. The key takeaway is that even with MFA in place, a determined social engineer can bypass it if the human element is not properly trained and protected.<\/p>\n

Limited Impact: View-Only Access, No Customer Data Compromised<\/h2>\n

ReliaQuest stated that the attackers obtained view-only access to the dashboard. The company\u2019s applications, systems, and customer data were not compromised. The threat actor continued with attempts to access these applications from the dashboard but was consistently denied due to the security controls in place. No additional identities were accessed, no business applications were reached, no customer or ReliaQuest data was accessed beyond the user\u2019s login credentials, and no persistence was established. Claims that ReliaQuest was compromised or targeted by ransomware are false, the company emphasized.<\/p>\n

This is a significant distinction: while the attacker successfully breached the first layer of authentication, the internal security controls prevented any lateral movement or data exfiltration. The incident highlights the importance of defense-in-depth, where a single compromised credential does not automatically lead to a full-scale breach.<\/p>\n

ShinyHunters: A Persistent Threat Group<\/h2>\n

ShinyHunters first gained notoriety in 2020 for a series of high-profile data breaches, including those affecting Microsoft\u2019s GitHub repository, Tokopedia, Wattpad, and other major platforms. The group is known for selling stolen databases on dark web forums and has been linked to other hacker collectives. Their tactics have evolved over time, moving from brute-force attacks and SQL injection to more sophisticated phishing and social engineering campaigns. The use of “company.claims” domains is a recent innovation, designed to bypass traditional email security filters that may block known phishing domains.<\/p>\n

The group\u2019s ability to impersonate multiple roles within an organization \u2014 IT, help desk, and now legal \u2014 demonstrates a deep understanding of corporate hierarchies and trust structures. Legal team impersonation is particularly dangerous because employees are often conditioned to treat legal requests as urgent and confidential, bypassing normal security protocols.<\/p>\n

How the Attack Unfolded: Technical Breakdown<\/h2>\n

The attack began with domain registration. The hackers registered a domain that closely resembled a legitimate ReliaQuest address, likely using a “company.claims” top-level domain. They then set up a phishing page that mimicked the ReliaQuest SSO login portal. The next step involved reconnaissance: the threat actor likely gathered employee names and roles, possibly through LinkedIn or other public sources, to identify potential targets.<\/p>\n

The attacker then placed phone calls to multiple ReliaQuest teammates, each time posing as a security employee by name. This is a technique known as vishing (voice phishing). The goal was to convince the recipient that they were speaking to a legitimate internal security team member who needed them to verify their credentials by logging into a specific page. One employee fell for the ruse, entering their password and approving the MFA push notification. This gave the attacker a temporary session token, which was then used to access the Okta identity dashboard.<\/p>\n

Once inside the dashboard, the attacker had view-only access. This means they could see the list of applications, users, and perhaps some configuration settings, but they could not modify anything or initiate any actions. ReliaQuest\u2019s security controls \u2014 likely including conditional access policies, session timeouts, and application-level permissions \u2014 prevented the attacker from using the session to access actual business applications or customer data. The attacker\u2019s repeated attempts to access applications from the dashboard were denied, and the session was eventually terminated.<\/p>\n

What Does This Incident Mean for the Cybersecurity Industry?<\/h2>\n

The ReliaQuest incident serves as a powerful reminder that no organization is immune to social engineering, even those that specialize in cybersecurity. The fact that a single employee fell for the attack, despite the company\u2019s own expertise, illustrates the persistent vulnerability of human factors. It also highlights the need for continuous security awareness training that specifically addresses vishing and MFA fatigue attacks.<\/p>\n

From a broader perspective, the incident underscores the importance of implementing robust identity and access management (IAM) controls. Conditional access policies, such as requiring trusted devices or locations for MFA approval, can help mitigate the risk of MFA fatigue. Additionally, session monitoring and anomaly detection can alert security teams to unusual access patterns, such as a user logging in from an unexpected IP address or attempting to access multiple applications in rapid succession.<\/p>\n

ReliaQuest\u2019s response was swift and transparent. By publicly disclosing the incident and providing a detailed breakdown of what happened, the company demonstrated a commitment to accountability and helped the industry learn from the event. This is a stark contrast to the many organizations that downplay or delay disclosure of security incidents, leaving customers and partners in the dark.<\/p>\n

How to Protect Against Legal Team Impersonation Attacks<\/h2>\n

Legal team impersonation is a particularly insidious tactic because it preys on the fear of legal consequences. Employees may be reluctant to question a request that appears to come from legal counsel, especially if it involves sensitive information or urgent action. Organizations should implement clear verification procedures for any request that involves credential changes, data access, or financial transactions. A simple rule \u2014 always verify through a separate communication channel \u2014 can prevent many such attacks.<\/p>\n

Multi-factor authentication remains a critical defense, but it must be implemented with care. MFA push notifications should only be sent in response to a user-initiated action, not as a one-time password (OTP) or approval request that can be triggered by an attacker. Some organizations are now adopting number-matching MFA, where the user must enter a number displayed on the login screen into their authenticator app, preventing the kind of fatigue-based approval that occurred in this case.<\/p>\n

What Is the “Company.Claims” Phishing Pattern?<\/h2>\n

The “company.claims” domain pattern is a relatively new phishing technique that uses top-level domains (TLDs) like .claims to create URLs that appear legitimate. For example, a phishing site might be “reliaquest.claims” instead of “reliaquest.com.” The .claims TLD is often used for insurance or warranty claims, but threat actors have repurposed it to host fake login pages. The pattern is effective because it is not immediately obvious that the domain is malicious, and many users do not scrutinize the full URL.<\/p>\n

Enterprises should consider blocking or flagging the .claims TLD in their email and web filtering systems, at least for organizations that have no legitimate reason to use it. Additionally, browser extensions and security tools that warn users about newly registered domains can help prevent access to these phishing sites.<\/p>\n

ReliaQuest\u2019s Response and Industry Reactions<\/h2>\n

ReliaQuest\u2019s public statement on Monday was measured and factual. The company acknowledged the incident, explained the attack vector, and provided clear evidence that the impact was limited. This transparency is likely to enhance trust among its customers, who can see that the company has robust security controls in place. The incident also serves as a case study for other security teams, demonstrating how to respond to a social engineering attack that manages to breach the first line of defense.<\/p>\n

Industry analysts have noted that the attack was relatively unsophisticated in its execution \u2014 a simple phishing page and phone calls \u2014 but it succeeded because of the attacker\u2019s persistence and the victim\u2019s momentary lapse. The fact that the attacker chose to target a cybersecurity firm is notable; it suggests that threat actors are increasingly willing to go after the security industry itself, perhaps to gain bragging rights or to access sensitive threat intelligence.<\/p>\n

Lessons for Security Teams: Prevention, Detection, and Response<\/h2>\n

Prevention begins with training. Employees should be taught to recognize vishing calls and to verify the identity of anyone claiming to be from IT, help desk, or legal. A simple callback to a known number can confirm the legitimacy of the request. Detection involves monitoring for unusual login attempts, especially from new IP addresses or devices, and for multiple failed MFA approvals. Response should include immediate session revocation, password reset, and investigation of the attacker\u2019s activity.<\/p>\n

For ReliaQuest, the incident was contained because their security controls prevented lateral movement. Many organizations would not be so fortunate. Without proper application-level permissions, a single compromised credential can lead to a full-scale breach. The lesson is clear: even if an attacker bypasses MFA, strong internal controls can still prevent them from doing damage.<\/p>\n

What the Future Holds for ShinyHunters and Similar Threat Groups<\/h2>\n

ShinyHunters shows no signs of slowing down. The group has repeatedly demonstrated an ability to adapt its tactics, and the “company.claims” campaign is just the latest evolution. As organizations improve their email security, threat actors will increasingly turn to voice and text-based social engineering. The use of generative AI to create convincing deepfake audio or video impersonations is a looming threat that could make these attacks even more effective.<\/p>\n

Security teams must stay ahead of these trends by investing in advanced threat detection, conducting regular red team exercises, and fostering a culture of security where employees feel empowered to question suspicious requests. The ReliaQuest incident, while limited in scope, is a valuable reminder that the human factor remains the weakest link in any security chain.<\/p>\n

For the broader cybersecurity industry, the incident reinforces the importance of transparency and rapid disclosure. By sharing the details of the attack, ReliaQuest has helped other organizations understand the threat and prepare their defenses. The company\u2019s cautionary tale is a textbook example of how a well-prepared security team can turn a near-miss into a learning opportunity, ultimately strengthening the entire ecosystem against future attacks.<\/p>\n","protected":false},"excerpt":{"rendered":"

Cybersecurity firm ReliaQuest has confirmed that it was targeted by hackers affiliated with the notorious ShinyHunters group, but the company maintains that the impact of the attack was sharply limited, with no customer data, business applications, or internal systems compromised. The incident, which unfolded over the weekend of August 16aaa\u201317, underscores the growing sophistication of […]<\/p>\n","protected":false},"author":7,"featured_media":82795,"comment_status":"closed","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"fifu_image_url":"https:\/\/cards.overcentral.com\/cards\/en\/77690.png","fifu_image_alt":"ReliaQuest Confirms ShinyHunters Hack, Impact Limited","footnotes":""},"categories":[40668],"tags":[],"class_list":["post-77690","post","type-post","status-publish","format-standard","has-post-thumbnail","category-security"],"fifu_image_url":"https:\/\/cards.overcentral.com\/cards\/en\/77690.png","fifu_image_alt":"ReliaQuest Confirms ShinyHunters Hack, Impact Limited","_links":{"self":[{"href":"https:\/\/overcentral.com\/en\/wp-json\/wp\/v2\/posts\/77690","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/overcentral.com\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/overcentral.com\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/overcentral.com\/en\/wp-json\/wp\/v2\/users\/7"}],"replies":[{"embeddable":true,"href":"https:\/\/overcentral.com\/en\/wp-json\/wp\/v2\/comments?post=77690"}],"version-history":[{"count":0,"href":"https:\/\/overcentral.com\/en\/wp-json\/wp\/v2\/posts\/77690\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/overcentral.com\/en\/wp-json\/wp\/v2\/media\/82795"}],"wp:attachment":[{"href":"https:\/\/overcentral.com\/en\/wp-json\/wp\/v2\/media?parent=77690"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/overcentral.com\/en\/wp-json\/wp\/v2\/categories?post=77690"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/overcentral.com\/en\/wp-json\/wp\/v2\/tags?post=77690"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}