The ReliaQuest incident is a useful example of why modern identity attacks cannot be judged simply by whether an attacker obtained a username, password and MFA approval. In this case, the attacker successfully socially engineered a ReliaQuest employee, captured their SSO credentials through a fake login page, and convinced the employee to approve an MFA push notification. That was enough to provide temporary access to the employee’s Okta identity dashboard. However, the attack stopped there because additional device-trust controls prevented the attacker from opening business applications through the compromised identity. ReliaQuest says no applications, systems or customer data were accessed, and even the threat actor acknowledged that the access remained view-only.

The attack reportedly began with telephone-based social engineering. The threat actor called multiple ReliaQuest employees while impersonating a legitimate member of the company’s security team and attempted to direct them toward a fake ReliaQuest SSO page. The phishing infrastructure used a highly convincing lookalike domain, `reliaquest.claims`, matching a broader ShinyHunters campaign in which attackers have registered company-name domains under the `.claims` top-level domain to impersonate corporate IT departments and help desks. One targeted employee eventually entered credentials into the fraudulent SSO page and approved the corresponding MFA request.

This attack path is important because it shows how phishing has evolved beyond simply sending a fake Microsoft 365 login link by email. Attackers increasingly combine several channels: they call the employee, use the name of an actual IT or security staff member, direct the victim toward a convincing corporate-looking domain, capture credentials in real time and immediately trigger an MFA request. Every part of the interaction reinforces the others. The phone call makes the website seem legitimate, and the MFA notification appears to confirm that the login process the caller described is actually taking place.

ShinyHunters and related threat actors have increasingly specialised in this type of identity-focused intrusion. The group has repeatedly targeted corporate SSO environments through phishing and vishing rather than relying exclusively on software vulnerabilities. ReliaQuest itself had recently warned that ShinyHunters was registering `.claims` domains resembling targeted organisations and using them to impersonate internal support teams. The irony of the researchers subsequently becoming the target of essentially the same technique is difficult to miss, but the incident also provides an unusually useful demonstration of how layered identity controls behave when the first several layers fail.

The attacker successfully defeated the password layer. They also defeated conventional push-based MFA because the victim approved the authentication request. At that point, many organisations would consider the attacker authenticated and allow access to whatever applications the user could normally reach. ReliaQuest’s device-trust controls created an additional requirement: possession of valid credentials and successful MFA was not sufficient unless the authentication originated from an approved device. The attacker could therefore see the employee’s identity dashboard but could not actually enter the applications behind it.

This is an important distinction between MFA and phishing-resistant access. Push-based MFA proves that somebody possessing the registered authentication device approved a request. It does not necessarily prove that the person approving the request understands what they are approving. Social engineering can therefore convert MFA from a security control into another button the attacker asks the victim to press. Device trust, certificate-based authentication, FIDO2 security keys and passkeys provide stronger signals because they bind authentication more closely to the legitimate device or origin rather than depending exclusively on human judgement.

The incident also demonstrates why SSO environments represent such attractive targets. A successful SSO compromise can provide attackers with access to multiple cloud applications through one identity. ShinyHunters has repeatedly targeted this trust concentration point because stealing one corporate identity can potentially provide access to Salesforce, cloud storage, support systems, HR applications and other SaaS platforms. Their broader campaigns have frequently focused on stealing data from cloud platforms and then using that information for extortion rather than deploying traditional ransomware.

ReliaQuest’s architecture prevented that progression. According to the company, every attempt by the attacker to open applications from the compromised identity dashboard was denied because the session did not meet device-trust requirements. This is a very practical demonstration of Zero Trust principles. Authentication was not treated as a one-time binary decision in which successful credentials plus MFA automatically granted broad access. Additional context about the device was required before downstream applications became reachable.

The term “breach” therefore needs some precision in this case. The attacker unquestionably compromised an employee’s credentials and gained access to the employee’s identity dashboard. Screenshots published by ShinyHunters appear to demonstrate that access. However, the evidence currently available does not support a claim that ReliaQuest’s applications, corporate systems or customer data were compromised. Both ReliaQuest and the threat actor told BleepingComputer that the access was view-only and did not extend into business applications or customer information.

That difference matters because criminal groups naturally have an incentive to describe every successful authentication as a major corporate breach. Publicly listing a well-known cybersecurity company on an extortion site creates reputational pressure even when the operational compromise is limited. Security reporting therefore needs to distinguish between initial access, application access, persistence and data exfiltration rather than treating them as equivalent stages of an intrusion.

ReliaQuest responded by terminating the attacker’s sessions, revoking the exposed password and resetting authentication tokens. The subsequent investigation reportedly found no evidence that other accounts, applications or data had been accessed and no signs that the attacker established persistence. The company also reviewed device-trust enforcement and on-network access activity dating back to August 21 and reported no suspicious findings.

The incident offers several important lessons for customers. The first is that MFA should still be deployed everywhere, but organisations should increasingly move away from simple push notifications for sensitive access. Number matching is better than blind approval, but phishing-resistant methods such as FIDO2 security keys and passkeys provide significantly stronger protection because authentication is cryptographically bound to the legitimate site. A fake SSO domain cannot simply replay the authentication in the same way.

Device trust should be considered another important layer. Sensitive applications can require authentication from corporate-managed devices that possess a valid certificate, meet endpoint-security requirements and demonstrate compliance with organisational policy. This means stolen credentials become much less useful when the attacker attempts to authenticate from an unmanaged system. The ReliaQuest incident provides unusually clear evidence of this control doing exactly what it was intended to do.

Conditional Access can further strengthen the architecture. Organisations should evaluate user identity, device posture, geographic location, source network, application sensitivity and authentication strength before permitting access. An administrator accessing a sensitive system from an unknown device and unusual location should face significantly stronger controls than the same user accessing a routine application from a managed workstation.

Help-desk and security-team impersonation should also become part of user-awareness training. Employees need to know that legitimate IT personnel should never ask them to enter credentials into a link provided during an unsolicited phone call or approve an unexpected MFA notification. Security teams should establish clear support procedures so employees can independently verify anyone claiming to be IT. A caller who knows the name of a real employee should not automatically be considered legitimate because attacker reconnaissance can easily provide that information.

Organisations should monitor for newly registered lookalike domains as well. In this campaign, the `.claims` top-level domain was specifically used to create addresses that resemble corporate support or account portals. Domain monitoring can identify registrations containing the organisation’s name, abbreviations or trademarks and provide early warning before those domains are used in phishing. Blocking newly registered or suspicious lookalike domains through DNS security, secure web gateways and email systems can reduce the chance that users reach the phishing infrastructure.

Identity telemetry should receive the same attention historically given to endpoint logs. Security teams should monitor unusual MFA registrations, new device enrollments, impossible travel, sudden changes in authentication factors, session creation from unfamiliar infrastructure and attempts to open multiple SaaS applications shortly after a suspicious login. In this incident, the attacker repeatedly attempted to move from the Okta dashboard into downstream applications. That sequence itself is useful behavioural information.

Session security is particularly important because attackers increasingly focus on stealing authenticated sessions rather than passwords. Revoking the compromised password alone may not terminate an already established session. ReliaQuest therefore also reset authentication tokens, which is the correct response. Incident-response procedures for identity compromise should include password resets, token revocation, session termination and review of any newly registered authentication factors.

Privileged accounts should receive even stronger controls. Administrators should ideally use dedicated privileged identities from managed administrative workstations with phishing-resistant MFA. If a normal employee can be socially engineered, a privileged administrator can be socially engineered too. The consequences are simply much worse. Separating administrative accounts from daily browsing and collaboration reduces the chance that a successful social-engineering call turns directly into control of the identity infrastructure.

Network controls still have a role even in identity-centric attacks. Corporate applications can be configured to allow access only through approved devices, secure access gateways or known network paths. This should not become a return to blindly trusting internal IP addresses, but network context can provide another independent signal alongside identity and device posture.

The incident also demonstrates why Zero Trust should be understood as a series of independent decisions rather than a marketing replacement for VPNs. The attacker successfully passed two security checks: password authentication and MFA. A third control still rejected the session. That is exactly what defence in depth should look like. One failed layer does not automatically convert into complete access.

Another useful lesson is that security controls need to be tested against realistic attack chains rather than individually. An organisation might proudly report 100% MFA coverage while never testing what happens when an employee willingly approves an attacker’s request. Purple-team exercises should include help-desk impersonation, MFA social engineering, fake SSO portals and attempts to access SaaS applications from unmanaged devices. The purpose should be to determine which control actually stops the attacker after users inevitably make mistakes.

The ShinyHunters campaign also demonstrates why organisations should not view SaaS environments as automatically safer simply because infrastructure is managed by another provider. Attackers increasingly avoid compromising servers entirely. They compromise the identity authorised to use Salesforce, Okta or another SaaS platform and then operate through legitimate application interfaces. From the cloud provider’s perspective, the requests may look perfectly valid because they are backed by real credentials and authenticated sessions.

This means security teams increasingly need contextual identity controls capable of asking not simply whether authentication succeeded but whether the session makes sense. Is the device known? Is its security posture acceptable? Is the location consistent with previous behaviour? Is the user attempting to access applications they normally use? Did the identity provider see a corresponding phishing-resistant authentication event? These additional signals are what prevented this particular incident from progressing further.

The incident is also a useful reminder not to underestimate social engineering just because an organisation employs security professionals. Cybersecurity companies, banks and government agencies are staffed by humans, which remains an inconveniently persistent architectural dependency. Attackers only need one person to respond incorrectly, so effective security assumes that somebody eventually will and designs controls capable of containing that mistake.

For customers, the most practical defence is therefore layered: use phishing-resistant MFA wherever possible, require managed-device trust for sensitive SaaS applications, implement Conditional Access, monitor lookalike domains, restrict external support channels, train employees to independently verify IT requests, centralise identity telemetry, revoke sessions rapidly after suspicious authentication and protect privileged accounts with stronger device and authentication requirements.

The ReliaQuest incident is ultimately more interesting as a defence success than as a data breach. The attacker successfully executed social engineering, stole valid credentials and obtained MFA approval. Those are usually the ingredients security teams spend most of their time trying to prevent. Yet the attack still failed to reach business applications because another independent control asked a different question: not merely “Does this person know the password and have access to the MFA device?” but “Is this authentication coming from a device we trust?”

That is the broader security lesson. Credentials can be phished, users can approve MFA requests and even security professionals can be socially engineered. A resilient identity architecture assumes those failures will eventually occur and ensures they do not automatically become access to sensitive systems or customer data. In this case, device trust turned what could have become a significant cloud data-theft incident into temporary, view-only access to an identity dashboard. That is exactly the kind of containment modern identity security should be designed to achieve.

Cybersecurity company ReliaQuest has confirmed that one of its employees was targeted in a social engineering attack after hackers impersonated a member of the security team. [...]

Source: ReliaQuest confirms failed data-theft attack after ShinyHunters breach via Bleeping Computer — published 24 Aug 2026.