ReliaQuest disclosed on August 23, 2026, that it was targeted by a social engineering attack the previous day, and the ShinyHunters group has since claimed responsibility on its leak site.
What to Know?
- Attackers called ReliaQuest staff while impersonating a named security employee, directing them to a cloned single sign-on page.
- One employee entered a password and approved a push notification, handing the attacker a view-only dashboard session.
- Device-trust controls blocked every attempt to reach company applications from non-managed devices, according to ReliaQuest.
- ShinyHunters listed ReliaQuest, LLC on its leak site claiming the breach, but per CyberInsider, the posted material has not demonstrated the group obtained the access ReliaQuest disputes.
On August 22, ReliaQuest said the attack briefly exposed one employee’s identity session before its controls shut the intrusion down. That opening move, detailed in coverage by CyberInsider reporter Alex Lekander, matches the Voice phishing campaigns that rely on a convincing phone call rather than a malicious link.
Pretexting of this kind, where the caller invents a scenario and a named colleague, is a recurring pattern in Cybersecurity threats and attacks. The call script, not the login page, is the part worth rehearsing against.
How It Happened?
Attackers registered a lookalike domain and hosted a fake ReliaQuest single sign-on page behind a content delivery network before working the phones. They called multiple ReliaQuest teammates, each time posing by name as a real security employee, to steer them toward the fake page.
One employee entered a password and approved an authentication push notification on their phone, the moment that gave the attacker a foothold. ReliaQuest said the resulting access was limited to a view-only session on its identity dashboard. The threat actor continued with attempts to access these applications from the dashboard but was consistently denied due to the security controls in place.
ReliaQuest attributes that block to device trust, which prevents non-ReliaQuest-managed devices from reaching any application or system. The attacker had a valid session but no company-managed device, and that gap between “signed in” and “authorized” is exactly where phone-based social engineering campaigns usually win or lose.
ReliaQuest said it terminated the attacker’s sessions, expired the compromised password, and reset every authentication factor tied to the account. Its follow-up investigation covered device-trust enforcement, network access, control effectiveness, and suspicious activity over the preceding 48 hours.
The company said no additional identities were accessed, no business applications were reached, and no persistence was established. Claims that ReliaQuest was compromised or targeted by ransomware are false.
The Attribution Dispute
A ShinyHunters leak site listing, posted after ReliaQuest’s August 23 disclosure, now contests the company’s own account of the incident. ShinyHunters listed ReliaQuest, LLC on its leak site, claiming responsibility for the incident, and CyberInsider reports the attacker was not identified in ReliaQuest’s own report.
Critically, the material ShinyHunters posted does not demonstrate that the group obtained the application or customer access ReliaQuest disputes. That gap between a named claim of responsibility and a vendor’s itemized denial is the real open question here, and neither ReliaQuest’s post nor the leak site listing resolves it alone.
A security vendor disclosing its own staff got phished is unusual candor, and it doubles as a case study in why identity teams increasingly treat a successful sign-in as meaningless on its own. The pattern ReliaQuest describes, a fabricated CDN-hosted login page paired with impersonation calls and MFA push approval, is a known playbook, and it starts on the phone rather than in the inbox.
What’s Next?
Security teams running similar identity stacks should verify their own device trust enforcement actually blocks application access after a phished sign-in, not assume it works because ReliaQuest’s held. ShinyHunters is likely to keep adding entries to its leak site faster than victims can confirm or deny them, so a listing there should not be read as proof of a successful breach on its own.
SQ Magazine’s Takeaway
This incident, involving ReliaQuest, reads as a genuine test of layered identity defense, and the layer that mattered was not employee awareness. ReliaQuest’s own framing, that even trained staff can be fooled by a caller who knows a colleague’s name, is the more useful lesson than the fact that one employee clicked through.
ReliaQuest credits device trust as the control that halted the intrusion: on its account, a valid session on a non-managed device could not reach anything. That is a stronger signal for other security teams than “we caught the phish,” because most organizations will eventually have an employee who doesn’t.
The unresolved piece is attribution, and it deserves to be held loosely. ReliaQuest’s account is a first-party disclosure describing its own systems, not an independently audited finding, and ShinyHunters’ leak site claim is likewise an unverified assertion from a group with a financial incentive to inflate its reach.
