Tampa-based managed detection and response provider ReliaQuest has confirmed that it was the target of a ShinyHunters-linked social engineering attack on August 22, 2026, in which one employee entered credentials on a cloned single sign-on page and approved an MFA push, handing the attacker a brief, view-only session on the company's identity dashboard. ReliaQuest says the intrusion went no further: "It was unsuccessful beyond temporarily exposing one identity," a spokesperson told The Register. "The extent of the access was view only. No ReliaQuest applications or systems were accessed, and no customer data was ever touched." ShinyHunters listed the company on its leak site on August 23 and published Okta dashboard screenshots, but as of publication no stolen data samples, ransom demand, or evidence of customer impact have surfaced.
What Happened
The sequence is unusually well documented because both sides argued about it in public.
On August 17, ReliaQuest's Threat Research team posted on X that it was tracking a widespread ShinyHunters campaign registering domains under the .claims TLD following a company[.]claims pattern, incorporating each target organisation's name or abbreviation. The same post warned that the group had broadened its social engineering repertoire beyond IT and help desk impersonation to include impersonation of corporate legal teams.
Five days later, on August 22, the campaign turned on the researchers. An attacker registered a lookalike domain, identified by BleepingComputer as reliaquest.claims, and stood up a cloned ReliaQuest SSO page behind a content delivery network. The actor then telephoned multiple ReliaQuest employees, each time posing by name as a real member of ReliaQuest's own security staff, and tried to steer them to the fake portal. One employee entered their password and approved the resulting push notification. "That handed the attacker a brief session on our identity dashboard," the company said.
From there the attacker tried to pivot into ReliaQuest applications and was repeatedly blocked. Per the company's incident analysis, access controls require a trusted, ReliaQuest-managed device before an identity can reach internal applications or systems, and the attacker's attempts were "consistently denied due to the security controls in place." ReliaQuest states that no additional identities were accessed and no business applications were reached.
On August 23, a newly created X account associated with the crew replied to ReliaQuest's .claims research post with the taunt "Who's hunting who?" and screenshots of what appeared to be a compromised Okta SSO session. The same screenshots went up on ShinyHunters' leak site alongside a message mocking the firm. Both X posts were subsequently deleted.
What Was Taken
On the available evidence, nothing beyond a single set of employee SSO credentials and a short-lived authenticated session.
ReliaQuest's position across every account is consistent: view-only visibility of one employee's identity dashboard, no application access, no system access, no customer data. The attacker's own published proof supports rather than contradicts this. The leak site entry contained screenshots of an Okta dashboard, not data samples. The Register noted the listing "did not publish any stolen customer data," and SOCRadar reported finding no validated data samples, no ransom demand, and no evidence of customer impact.
It is worth being explicit about where the sources diverge, because two of them read very differently. SOCRadar and Undercode News, both published on August 24, frame the incident as an unverified extortion claim with "no publicly verified evidence" and no confirmation from ReliaQuest. Those assessments appear to predate or overlook ReliaQuest's public statement and technical write-up, which SecurityWeek, BleepingComputer and The Register all report on the same day. The reconciliation is straightforward: ReliaQuest has confirmed an intrusion occurred, and it has disputed the scope ShinyHunters implied. The lack of validated stolen data that SOCRadar and Undercode describe is not in conflict with the company's account, it corroborates it.
What no source establishes independently is the negative. ReliaQuest's containment claims rest on ReliaQuest's own investigation, and no regulator filing, customer notification, or third-party forensic confirmation has been published.
Why It Matters
Three things make this worth a defender's attention beyond the schadenfreude of a threat intel vendor getting vished by the group it was writing about.
First, it is a rare public example of the control that actually stopped the attack. Credential theft and MFA push approval both succeeded. Device trust is what failed the attacker. That is a useful data point for anyone still treating push-based MFA as a terminal control rather than one layer among several.
Second, the targeting is deliberate. ShinyHunters hit a security operations provider days after that provider published infrastructure research on its campaign, and then used the leak site as a reputational weapon rather than a monetisation channel. For MDR, MSSP and threat intel firms, publishing on an active crew now carries a retaliation cost, and the retaliation is aimed at the vendor's credibility as much as its data.
Third, the tradecraft is the same tradecraft that has produced far worse outcomes elsewhere. Microsoft's July 2026 research on ShinyHunters-overlapping activity documents campaigns from mid-2025 through mid-2026 using vishing and supply chain compromise to reach customer SaaS platforms, abusing trusted OAuth relationships for unauthorised access, exfiltration and persistence. Microsoft observed two primary intrusion paths: vishing aimed at OAuth consent, and compromise of trusted workflows and integrations such as Salesloft and Gainsight. Inherited user and application privileges then allowed CRM enumeration and querying at scale while evading conventional authentication detections. Microsoft is emphatic that this was not a Salesforce vulnerability. ReliaQuest caught the identity-layer intrusion before it reached that stage. Many organisations have not.
The Attack Technique
The chain, as described by ReliaQuest and reported consistently across SecurityWeek, BleepingComputer, The Register and CyberInsider:
- Lookalike domain registration. A
.claimsTLD domain incorporating the target's name (reliaquest.claims), matching thecompany[.]claimspattern ReliaQuest itself had documented a week earlier. - CDN-fronted phishing infrastructure. The cloned SSO page was hosted behind a content delivery network, which complicates reputation-based blocking and IP-level detection.
- Named-employee vishing. The actor called multiple staff, impersonating a specific, real member of the security team by name. This is a research-driven touch, not a spray campaign, and it aligns with the expansion into legal-team impersonation that ReliaQuest had flagged on August 17.
- Credential capture plus MFA push approval. One target entered a password and approved the push, yielding a valid session on the identity provider.
- Attempted pivot, blocked. Attempts to reach applications from the identity dashboard were denied by device-trust enforcement.
- Reputational extortion. With no data to sell, the crew posted dashboard screenshots to its leak site and taunted the victim publicly.
For broader context on how this crew's activity ends when the pivot succeeds, Microsoft's analysis describes OAuth relationship abuse producing persistent access and exfiltration at scale across retail, education and manufacturing tenants, with the recommended countermeasures being monitoring of OAuth-connected applications, validation of third-party integrations, configuration review, and Salesforce event monitoring. Microsoft also worked with Salesforce to increase telemetry granularity in Defender for Cloud Apps, adding near-real-time detection with connected application attribution.
What Organizations Should Do
- Enforce device trust on the identity provider, not just MFA. This is the control that ended the ReliaQuest incident. Require a managed, compliant device before any identity can reach internal applications, so a stolen session alone is worth nothing.
- Replace push-approval MFA with phishing-resistant factors. FIDO2 or passkeys bound to the origin would have failed silently against a lookalike domain. If push cannot be retired immediately, enable number matching and alert on approvals from anomalous locations or unmanaged devices.
- Hunt for lookalike domains against your own brand, including
.claimsand other novel TLDs. ReliaQuest's published pattern iscompany[.]claimsincorporating the organisation's name or abbreviation. Monitor certificate transparency logs and newly registered domain feeds, and pre-emptively block or sinkhole matches. - Brief the help desk and staff on named-impersonation vishing. The attacker used a real internal security employee's name. Establish an out-of-band verification procedure for any call requesting authentication actions, and make clear that legitimate security staff will never phone to walk someone through a login.
- Audit OAuth grants and third-party SaaS integrations. Per Microsoft, consent-phishing and compromised integrations such as Salesloft and Gainsight are this crew's other main path in. Inventory connected applications, revoke unused grants, restrict user consent, and enable Salesforce event monitoring where applicable.
- Instrument session-level detection at the IdP. Alert on new sessions from unrecognised devices or ASNs, repeated denied application access attempts from a single identity, and impossible-travel patterns. Make revoking all sessions for an identity a one-click runbook step.
- Treat leak site listings as a signal, not a verdict. As SOCRadar and Undercode News both stress, a listing is an early warning that warrants investigation, not proof of compromise. Validate before you escalate, and equally, do not dismiss a listing because the crew has not posted data yet.
Sources: ReliaQuest Confirms ShinyHunters Hack, but Says Impact Was Limited... | Defending SaaS-based applications against ShinyHunters OAuth abuse... | ReliaQuest confirms failed data-theft attack after ShinyHunters breach | ShinyHunters and ReliaQuest trade blows over claimed breach | Hackers hijack hotel Wi-Fi DNS to steal Microsoft 365 accounts | ReliaQuest says claimed ShinyHunters attack was ... | ShinyHunters Claims ReliaQuest Breach, but No Evidence Has Yet Conf... | ShinyHunters Claims ReliaQuest Breach