A Cybersecurity Company Got Phished — Here’s What Actually Stopped It
In short: Attackers linked to the extortion group ShinyHunters phoned ReliaQuest employees, impersonating a real named member of the company’s own security team, and directed them to a fake login page. One employee entered their password and approved a login notification on their phone — handing the attacker a brief, view-only session inside ReliaQuest’s identity dashboard. The attacker never got further than that, because ReliaQuest’s device-trust policy blocks access to company systems from any device it doesn’t already recognize, regardless of whether the login itself is valid. Notably, ShinyHunters’ own public account of what they accessed doesn’t actually contradict ReliaQuest’s — the dispute between the two sides is more about framing than about the underlying technical facts.
What actually happened
On 17 August, ReliaQuest’s own threat research team posted a warning — since deleted — that ShinyHunters was registering lookalike domains following a “company.claims” pattern to impersonate targets’ help desks and IT teams. Days later, ReliaQuest became one of those targets itself. According to BleepingComputer’s reporting, the attacker registered the domain reliaquest.claims, hosted a fake single sign-on page behind a content delivery network, and then phoned multiple ReliaQuest employees — using the real name of an actual security team member to sound credible.
One employee entered their credentials on the fake page and approved a multi-factor authentication push notification on their phone, handing the attacker a temporary, view-only session inside the company’s identity dashboard. ReliaQuest’s own account is direct about what happened next: further attempts from that session were “consistently denied due to the security controls in place.”
The control that actually stopped it
| What the attacker had | A valid, authenticated session inside ReliaQuest’s identity dashboard, obtained through a real employee’s credentials and a genuine MFA approval. |
| What the attacker didn’t have | A device ReliaQuest’s systems recognized as company-managed. Every attempt to move from the identity dashboard into an actual application was blocked on that basis alone. |
| Why that distinction matters | Multi-factor authentication proves who logged in. Device-trust policy separately checks what they logged in from. This incident is a real-world case where the first check was defeated and the second one wasn’t — which is a different, and arguably more important, story than “MFA failed.” |
| What ReliaQuest did next | Terminated the attacker’s sessions, revoked the exposed password, reset all authentication tokens, and audited its own device-trust and network-access logs back to 21 August, finding no other suspicious activity. |
Why this is worth remembering, not just filing away. Security awareness training gets a lot of attention, and it matters — but this incident is a case where the trained employee still clicked, still typed the password, still approved the push. What actually held the line was a layer of defense that didn’t depend on that employee making the right call under pressure from someone who already knew their colleague’s name. Phishing-resistant design beats phishing-resistant people, because people are inherently the less reliable of the two.
The dispute that isn’t really a dispute
ShinyHunters posted screenshots on X — later deleted — appearing to show access to the compromised Okta session, taunting ReliaQuest’s own security team with “Who’s hunting who?” The group then listed ReliaQuest on its extortion leak site. The Register’s coverage of the exchange frames it as the two sides “trading blows” over a claimed breach — but reading both parties’ actual statements side by side tells a different story.
When BleepingComputer asked ShinyHunters directly what they’d accessed, the group’s own answer was: no additional identities accessed, no business applications reached, no customer or company data beyond the login credentials themselves, no persistence established. That’s substantively the same account ReliaQuest gave. Independent threat-intelligence firm SOCRadar likewise reported finding no validated stolen data samples, no ransom demand, and no evidence of customer impact. The public friction between the two sides looks less like a factual disagreement and more like a fight over who gets to control the narrative — ShinyHunters wants this counted as a win, ReliaQuest wants it correctly understood as a contained incident.
Why a security vendor being targeted matters more than it might seem
ReliaQuest builds GreyMatter, a platform other organizations use to monitor and respond to security threats in their own environments — meaning its customers are trusting ReliaQuest’s own account access, tooling, and identity systems as part of their own security posture. An identity-provider compromise at a company whose product is other people’s security isn’t just an embarrassing headline; it’s a reasonable moment for ReliaQuest’s own customers to ask what would have happened if device-trust controls hadn’t held. This incident didn’t answer that question badly — ReliaQuest’s controls worked as designed — but it’s a legitimate question regardless of how this specific case turned out.
This isn’t an isolated incident — it’s a known playbook
ShinyHunters-branded vishing campaigns date back to at least January 2026, when Google’s Mandiant threat intelligence team first tracked coordinated voice-phishing clusters (identified as UNC6661, UNC6671, and UNC6240) compromising more than 100 organizations in a matter of weeks using this exact method: call an employee, impersonate IT or security staff, direct them to a branded fake login page, harvest credentials and MFA in real time. Named victims of related campaigns through 2026 have included Panera Bread, SoundCloud, Match Group, and Crunchbase, among others. ReliaQuest is a recent entry in a long list, not a novel target.
What this means for any organization, not just security vendors. Security researchers tracking this campaign consistently recommend the same fix: push-based MFA, SMS codes, and one-time-password apps can all be defeated by a live attacker coaching a victim through the process in real time. Phishing-resistant methods — FIDO2 security keys or passkeys — remove the human judgment call from the authentication step entirely, which is exactly the point of failure this style of attack is built to exploit.
This story also connects to a broader pattern: credential theft, not software exploitation, is increasingly how major breaches actually start. The TheHatman Azure directory breach claims reported on this site last week followed the same underlying logic — attackers going after people and credentials rather than finding a technical flaw to exploit, because it’s consistently the faster, cheaper route in.
Common questions
Did ReliaQuest actually get breached?
An employee was successfully phished and a session inside ReliaQuest’s identity dashboard was briefly exposed. ReliaQuest says no applications, systems, or customer data were accessed beyond that view-only session, and ShinyHunters’ own statement to BleepingComputer does not contradict that account.
How did the attackers get in if MFA was in place?
The employee was directed to a fake single sign-on page by an attacker impersonating a real, named security team member over the phone. The employee entered their password and approved a legitimate-looking MFA push notification, which handed the attacker a valid authenticated session rather than requiring them to defeat MFA technically.
What actually stopped the attack from going further?
Device-trust controls. ReliaQuest’s systems only grant access to internal applications from devices the company has already recognized as managed. The attacker had a valid login session but was not on a company-managed device, so every attempt to reach an actual application was blocked.
Is this connected to other recent breaches?
ShinyHunters-branded vishing campaigns using this same technique — phone impersonation plus a fake branded login page — have been tracked by Google’s Mandiant team since January 2026, with over 100 organizations compromised in the campaign’s early weeks and more added throughout the year.
What should organizations do to defend against this specific technique?
Security researchers tracking these campaigns recommend moving away from push-based, SMS, or one-time-password MFA toward phishing-resistant methods like FIDO2 security keys or passkeys, since those remove the live human decision point that vishing attacks are specifically designed to manipulate.
Sources
- ReliaQuest — official statement on the incident. reliaquest.com
- BleepingComputer — original reporting, including the phishing domain and full company statement. bleepingcomputer.com
- The Register — on the public exchange between ReliaQuest and ShinyHunters. theregister.com
- Cybernews — on why an identity-provider compromise at a security vendor carries particular risk. cybernews.com
- The Hacker News — on Mandiant’s tracking of the broader ShinyHunters-branded vishing campaign since January 2026. thehackernews.com
