> ## Content Index > Fetch the complete content index at: https://f4n6.co.uk/llms.txt > Use this file to discover other available public pages before exploring further. # ReliaQuest Confirms ShinyHunters Hack, but Says Impact Was Limited - URL: https://f4n6.co.uk/security-feed/reliaquest-confirms-shinyhunters-hack-but-says-impact-was-limited/ - Published: 2026-08-24T20:52:13.000Z - Updated: 2026-08-24T20:52:13.000Z - Author: Jeff Davies - Tags: #security-feed, ShinyHunters ## 1\. Executive summary Cybersecurity firm ReliaQuest has confirmed a limited breach attributed to the ShinyHunters threat actor (MITRE G1057). The attack combined a voice social-engineering call — impersonating a named security employee — with a fake SSO phishing page, resulting in one employee entering credentials and approving a push notification. The attacker obtained a brief, view-only session on ReliaQuest's Okta identity dashboard but was denied access to all downstream applications and customer data; no persistence was established. EMEA financial services clients using ReliaQuest as an ICT third-party provider should note the vendor's assertion that no customer data was accessed, while recognising that the initial-access vector (vishing + adversary-in-the-middle SSO phishing) is broadly applicable to their own identity-security posture. ## 2\. Regulatory framing | Article | Trigger (the fact in this item) | Practical impact | | ------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | DORA Art. 28: ICT third-party risk — general principles | ReliaQuest is a cybersecurity vendor likely engaged as an ICT third-party provider by EMEA financial institutions; a confirmed (if limited) breach of that provider's identity infrastructure directly engages third-party risk obligations. | Clients must verify whether their ReliaQuest integration involves any data-sharing or SSO federation that could have been exposed through the Okta dashboard session, and document this incident in their third-party risk register. | | DORA Art. 17: ICT-related incident management process | A ReliaQuest employee's credentials were compromised via social engineering, resulting in unauthorised access to an identity management dashboard — a confirmed ICT-related incident at a service provider. | Clients should invoke their incident management process to assess whether the provider incident constitutes an ICT-related incident on their own side, particularly if SSO federation or delegated administration is in place. | No specific NIS2 or UK NIS article is directly engaged beyond the general incident-management and supply-chain obligations that apply to any provider compromise; clients should assess based on their individual OES/RDSP designation and dependency on ReliaQuest. ## 3\. Technical analysis & attack chain ### Confirmed attack chain (corroborated by ReliaQuest statement and ShinyHunters leak-site posting) 1. **Reconnaissance & domain registration.** The threat actor registered a fake domain designed to mimic ReliaQuest and configured it to host a phishing page replicating the ReliaQuest SSO login (Okta end-user login at `reliaquest.okta[.]com`). 2. **Vishing campaign — targeted social engineering.** The attacker telephoned multiple ReliaQuest employees ("teammates"), each time posing as a specific, named security employee. The call was designed to steer the recipient toward the fake SSO phishing page. ReliaQuest had previously (August 17, in a now-deleted X post) warned of a broader ShinyHunters phishing campaign using domains with the `company.claims` URL pattern and noted the group's expansion into legal-team impersonation alongside IT and help-desk impersonation. 3. **Credential capture.** One employee entered their password into the fake SSO phishing page. 4. **MFA push-notification approval.** The same employee approved a push notification on their phone, handing the attacker an authenticated session. 5. **Identity dashboard access.** The attacker obtained a brief session on ReliaQuest's Okta identity dashboard. Screenshots showing access to `reliaquest.okta[.]com/enduser/settings` were posted by ShinyHunters on their leak site as proof of compromise. 6. **Attempted lateral access — denied.** The attacker attempted to access downstream applications from the dashboard but was "consistently denied due to the security controls in place." 7. **Session terminated / no persistence.** ReliaQuest states no additional identities were accessed, no business applications were reached, no customer or ReliaQuest data was accessed beyond the user's login credentials, and no persistence was established. **Attribution:** ShinyHunters (MITRE G1057). Attribution is corroborated by ReliaQuest's own August 17 warning naming the group and by ShinyHunters posting the screenshots on their dedicated leak site. The actor's message on the leak site was taunting in tone but, per DataBreaches.net, provided no substantive proof of data theft or deeper compromise. ### Key technical observations - **Initial access vector:** Combined vishing (voice phishing) + adversary-in-the-middle SSO phishing. No CVE or software vulnerability was exploited; the vector was purely social engineering against identity infrastructure. - **Targeted component:** Okta identity dashboard (end-user settings page). - **MFA bypass mechanism:** The attacker did not bypass MFA technically; the user was socially engineered into approving a push notification (MFA fatigue / vishing-prompted approval). - **Blast radius:** Contained to view-only access on a single user's Okta dashboard session. ReliaQuest's security controls blocked all attempts to pivot to applications. - **Ransomware claims:** ShinyHunters' leak site (indexed by ransomware.live) lists ReliaQuest as a victim. ReliaQuest explicitly states: "Claims that ReliaQuest was compromised or targeted by ransomware are false." No ransomware deployment or data-theft/extortion evidence has been provided by the actor. The leak-site listing appears to be a reputation-pressure tactic. ### Single-sourced claims / confidence caveats - The `company.claims` URL pattern and the expansion into legal-team impersonation come from a now-deleted ReliaQuest X post reported by SecurityWeek — single-sourced; verify before enforcement. - ReliaQuest's assertion that no customer data was accessed and no persistence was established is vendor-self-reported and has not been independently verified by a third party at the time of writing. ## 4\. Mitigation & containment ### P1 — Within 24 hours - **If ReliaQuest is an ICT third-party provider:** Confirm whether your organisation has any SSO federation, delegated administration, or data-sharing integration with ReliaQuest's Okta tenant. If so, audit Okta system logs for any sessions originating from or federating through ReliaQuest's identity provider during the incident window (August 17–24, 2026). - **Block the phishing infrastructure pattern:** Add URL-filtering / DNS-blocking rules for domains matching the `*.claims` pattern used in the broader ShinyHunters campaign, particularly any impersonating your own organisation's SSO. Example proxy/SWG block rule: block category `company.claims` or wildcard `*.claims` where the page content matches known SSO login form patterns. - **Hunt for the vishing pattern internally:** Review help-desk ticketing systems and call logs for inbound calls from individuals claiming to be named security staff requesting credential entry or MFA approval. Alert security operations if any matches are found. ### P2 — Within 72 hours - **Strengthen MFA push-approval controls:** If your identity provider supports number-matching MFA (Okta, Entra ID, Duo), enforce it. This directly mitigates the push-approval social-engineering vector used in this incident. In Okta: navigate to Security > Authenticators > Okta Verify > Configure > enable "Number matching challenge." - **Implement phishing-resistant MFA where feasible:** FIDO2/WebAuthn hardware keys (YubiKey, Titan) or platform authenticators (Windows Hello, Touch ID) are immune to adversary-in-the-middle phishing. Prioritise enrolment for help-desk, IT, and security staff — the roles most likely to be targeted by vishing impersonation. - **Review Okta session policies:** Enforce short session lifetimes for administrative and end-user dashboard access. Configure session timeout to 15–30 minutes for idle sessions and require step-up authentication for application access from the dashboard. - **Brief all staff on the vishing + SSO phishing pattern:** The specific TTP — a phone call from someone naming a real security employee, directing the target to a fake SSO page, followed by an MFA push — should be communicated as a concrete scenario, not a generic "be alert to phishing" notice. ### P3 — Within 7 days - **Conduct a tabletop exercise** simulating this exact attack chain (vishing → fake SSO → MFA push approval → dashboard access) to test detection and response readiness. - **Review third-party risk documentation** for ReliaQuest specifically: confirm the vendor's incident notification timelines, request their post-incident report when available, and update the third-party risk register. - **Audit Okta admin logs** for any anomalous application access attempts or denied access events that may indicate a similar session-hijack attempt against your own tenant. ## 5\. Indicators of compromise No atomic indicators of compromise (IPs, domains, hashes, email addresses) are present in the source material in a form suitable for machine pivoting. The fake domain used in this specific attack is not named in the sources; only the broader campaign pattern (`company.claims`) and the legitimate Okta endpoint (`reliaquest.okta[.]com`) are referenced. ### Behavioural indicators | Behaviour | Where to observe | Confidence | | ---------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------- | ------------------------------------------------------------- | | Inbound phone calls to staff from individuals claiming to be a named security employee, directing targets to a fake SSO login page | Help-desk call logs, staff reports, call-recording systems | High — confirmed by ReliaQuest | | Phishing domains using the \*.claims TLD pattern impersonating corporate SSO | DNS logs, SWG/proxy logs, email security gateway | Medium — from a now-deleted ReliaQuest X post; single-sourced | | MFA push-notification approvals shortly after credential entry on an unrecognised device or IP | Okta system logs, MFA provider logs | High — confirmed mechanism | | Screenshots of reliaquest.okta\[.\]com/enduser/settings posted on ShinyHunters leak site | Threat-intel monitoring of ShinyHunters DLS | High — corroborated by DataBreaches.net and SecurityWeek | | Social engineering expanding to legal-team impersonation (not just IT/help-desk) | Staff reports, phishing mailbox | Medium — from now-deleted ReliaQuest X post; single-sourced | ## 6\. Detection Insufficient indicators to author detection rules. The source material describes behaviours and a URL pattern (`company.claims`) but does not provide specific file hashes, command-line artefacts, registry keys, mutex names, or other threat artefacts suitable for YARA or Sigma rule construction. The `company.claims` pattern alone is a domain-registration TLD, not a threat artefact, and would generate excessive false positives as a detection string. ### Recommended detection approach (behavioural, not rule-based) - Monitor Okta system logs for: (1) successful authentication from a new device or IP followed by denied application access attempts, and (2) MFA push approvals within a short time window of credential submission from an unrecognised geolocation. - Alert on inbound calls to IT/help-desk/legal staff where the caller claims to be a named internal security employee — this requires integration with call-recording or ticketing systems, not a SIEM rule. ## Threat actor context **ShinyHunters** · [G1057](https://attack.mitre.org/groups/G1057?ref=f4n6.co.uk) · aka UNC6240, Bling Libra [ShinyHunters](https://attack.mitre.org/groups/G1057?ref=f4n6.co.uk) is a cyber criminal collective that has been active since at least 2019 operating under the ShinyCorp persona. [ShinyHunters](https://attack.mitre.org/groups/G1057?ref=f4n6.co.uk) has targeted multiple industries and geographic regions gathering legitimate credentials and personally identifiable information (PII) for resale or extortion of victims. … ## 7\. Sources - SecurityWeek — "ReliaQuest Confirms ShinyHunters Hack, but Says Impact Was Limited" — https://www.securityweek.com/reliaquest-confirms-shinyhunters-hack-but-says-impact-was-limited/ — 2026-08-24 - DataBreaches.net — "ShinyHunters provided no real proof they hacked ReliaQuest– because they didn't get anywhere: ReliaQuest (2)" — https://databreaches.net/2026/08/23/shinyhunters-provided-no-real-proof-they-hacked-reliaquest-because-they-didnt-get-anywhere-reliaquest-2/ — 2026-08-23 - Ransomware.live — ShinyHunters victim listing for ReliaQuest, LLC — https://www.ransomware.live/id/UmVsaWFRdWVzdCwgTExDQHNoaW55aHVudGVycw== — updated 2026-08-23 ## 8\. Adverse Trace position This is a confirmed but low-impact breach of a cybersecurity vendor's identity infrastructure via social engineering — not a vulnerability exploitation or ransomware deployment. ShinyHunters (MITRE G1057) attribution is corroborated by both the vendor's own prior warning and the actor's leak-site posting, though the actor provided no evidence of data theft. ReliaQuest's claim of limited impact (view-only dashboard access, no persistence, no customer data access) is plausible given the described security controls but is vendor-self-reported and not independently verified at time of writing. For EMEA financial services clients, the direct risk is low if no SSO federation or data-sharing integration exists with ReliaQuest's Okta tenant; the indirect risk is that the same vishing + SSO phishing + MFA-push-approval TTP will be used against your own staff. We are monitoring for any independent verification of ReliaQuest's impact assessment and for additional ShinyHunters victims using the `company.claims` phishing pattern. Clients with ReliaQuest as an ICT third-party provider should request the vendor's post-incident report and document the event under DORA Art. 28 third-party risk obligations. --- [Read the original source →](https://www.securityweek.com/reliaquest-confirms-shinyhunters-hack-but-says-impact-was-limited/?ref=f4n6.co.uk) *Published via PulseTrace — Adverse Trace threat intelligence.*