Back to Intelligence

ShinyHunters Social Engineering Incident at ReliaQuest: Identity, Help Desk, and MSSP Defense Guide

SA
Security Arsenal Team
August 26, 2026
10 min read

ReliaQuest has publicly rejected claims that ShinyHunters successfully compromised its internal systems after an incident linked to the extortion-focused actor. According to the report, ReliaQuest described the activity as a social engineering attack and denied that the actor achieved the claimed level of compromise. That distinction matters for defenders: even when a vendor says core systems were not breached, the attempted intrusion path is still a live fire exercise for every enterprise identity team.

No CVE was named in the source summary, and there is no indication this is a software vulnerability story. The defensive issue is identity intrusion through human workflows: vishing, help desk pressure, MFA prompt abuse, credential phishing, token capture, and attempts to convert one convincing interaction into durable access. For MSSPs, SOC providers, and their customers, the blast radius is amplified because analysts, service accounts, RMM tooling, API keys, and customer-facing integrations often sit behind a small number of identity decisions.

Act on the assumption that ShinyHunters-style crews will test your reset desk, your MFA exceptions, your contractor onboarding, and your executive support processes. If a claim is disputed, do not wait for certainty. Verify telemetry, search for identity artifacts, and remove the pathways that make a phone call equal a password reset.

Technical Analysis

What is known

The public summary is narrow: ReliaQuest detailed a social engineering attack linked to ShinyHunters and denied reports that the threat actor successfully compromised its systems. The item does not provide malware hashes, a CVE, a CVSS score, specific product versions, or named compromised controls. Because no CVE appears in the source, this guide intentionally avoids inventing one.

The relevant attack class is not memory corruption. It is identity abuse through social engineering. In practical terms, defenders should model a chain like this:

  1. Reconnaissance against employees, contractors, service desk workflows, executives, and public customer relationships.
  2. Contact by phone, SMS, email, or collaboration platforms while impersonating IT, payroll, a vendor, a customer, or an executive.
  3. Pressure to reset a password, change an MFA method, approve a push, read back a one-time code, install a remote support tool, or grant OAuth consent.
  4. Initial access to an identity provider, cloud tenant, email mailbox, endpoint, or remote access path.
  5. Rapid expansion toward data collection, extortion staging, customer artifacts, service accounts, CI/CD secrets, ticketing systems, EDR consoles, and MSSP management planes.

Affected products, versions, and platforms

No specific affected product or version is identified in the news summary. The platforms most likely to determine impact are identity and access systems rather than a single vulnerable binary:

  • Microsoft Entra ID, Okta, Ping, Duo, Active Directory, and hybrid identity paths
  • Email and collaboration platforms such as Microsoft 365 and Google Workspace
  • Help desk and ITSM platforms used for resets and approvals
  • Remote access and support tools such as Quick Assist, AnyDesk, TeamViewer, ScreenConnect-style tooling, and corporate RMM agents
  • SOC and MSSP control planes: SIEM, EDR, ticketing, case management, threat intel platforms, customer onboarding APIs, and vaults
  • SaaS data stores likely to be targeted for extortion: CRM, source code, HR, finance, legal, and customer success platforms

Exploitation status

This is a claimed or attempted compromise narrative tied to a named extortion actor, not a confirmed vulnerability exploit. There is no CISA KEV entry and no CVE to prioritize from the provided source. Treat exploitation status as active social engineering threat activity with disputed impact. The right response is identity-centric verification and hardening, not emergency patching of an unspecified flaw.

For an MSSP or any customer-connected provider, the severity model should be conservative until evidence proves otherwise: assume targeted personnel were profiled, assume help desk scripts were studied, and assume customer-facing trust relationships may be leveraged next.

Detection and Response

The highest-value telemetry is not a lone IOC. It is sequence detection: failed MFA, a new device or unfamiliar ASN, an authentication method change, a mailbox rule, OAuth consent, remote support tool launch, and access to sensitive systems shortly afterward. Tune for rarity and correlate across IdP, email, endpoint, and SaaS audit logs.

YAML
---
title: High Risk Entra ID Sign-In With New Device or Unfamiliar Network
description: Detects successful interactive sign-ins marked risky or coming from unfamiliar locations, a common post-social-engineering signal after MFA push approval or credential capture.
references:
  - https://attack.mitre.org/techniques/T1078/
  - https://attack.mitre.org/techniques/T1621/
author: Security Arsenal
date: 2026/04/06
logsource:
  product: azure
  category: signinlogs
detection:
  selection_success:
    status.errorCode: 0
    authenticationRequirement: multiFactorAuthentication
  selection_risk:
    riskLevelDuringSignIn:
      - high
      - medium
  selection_context:
    deviceDetail.deviceId: null
  condition: selection_success and selection_risk
falsepositives:
  - Users traveling with legitimate new devices
  - Conditional Access testing in controlled pilots
level: high
---
title: Entra ID Authentication Method or Password Change Around Sign-In Anomaly
description: Flags audit operations where MFA methods, phone numbers, or credentials are changed, especially relevant when help desk social engineering is suspected.
references:
  - https://attack.mitre.org/techniques/T1098/
  - https://attack.mitre.org/techniques/T1556/
author: Security Arsenal
date: 2026/04/06
logsource:
  product: azure
  category: auditlogs
detection:
  selection_ops:
    operationName|contains:
      - 'Update user'
      - 'Reset user password'
      - 'Admin resets user password'
      - 'Update authentication methods'
      - 'User registered security info'
      - 'User changed default MFA method'
  selection_targets:
    targetResources.type:
      - User
      - AuthenticationMethod
  condition: selection_ops and selection_targets
falsepositives:
  - Normal joiner, mover, leaver operations
  - Scheduled self-service password reset campaigns
level: medium
---
title: OAuth Consent or Service Principal Credential Addition After User Interaction
description: Detects consent grants and app credential additions that can convert a phished session into persistent cloud access.
references:
  - https://attack.mitre.org/techniques/T1550/
  - https://attack.mitre.org/techniques/T1098.001/
author: Security Arsenal
date: 2026/04/06
logsource:
  product: azure
  category: auditlogs
detection:
  selection_ops:
    operationName|contains:
      - 'Consent to application'
      - 'Add service principal credentials'
      - 'Add application'
      - 'Update application'
  selection_scope:
    targetResources.modifiedProperties.displayName|contains:
      - 'Mail.Read'
      - 'Files.Read'
      - 'Directory.Read'
      - 'offline_access'
      - 'full_access_as_app'
  condition: selection_ops
falsepositives:
  - Approved enterprise application onboarding
  - Developer tenant testing isolated from production
level: high
KQL — Microsoft Sentinel / Defender
// Correlate MFA failures, risky success, authentication method changes, mailbox rules, OAuth consent, and remote tool process starts.
let lookback = 14d;
let risky = SigninLogs
| where TimeGenerated > ago(lookback)
| where ResultType == 0
| where RiskLevelDuringSignIn in ('medium','high') or IsRisky == true
| project UserPrincipalName, IPAddress, Location, AppDisplayName, DeviceDetail, TimeGenerated, CorrelationId;
let mfaPressure = SigninLogs
| where TimeGenerated > ago(lookback)
| summarize FailedMFA=countif(ResultType != 0 and AuthenticationRequirement == 'multiFactorAuthentication'), Success=countif(ResultType == 0) by UserPrincipalName, IPAddress, bin(TimeGenerated, 30m)
| where FailedMFA >= 5 and Success >= 1;
let authChanges = AuditLogs
| where TimeGenerated > ago(lookback)
| where OperationName has_any ('Update user','Reset user password','Admin resets user password','Update authentication methods','User registered security info')
| extend TargetUser = tostring(TargetResources[0].userPrincipalName)
| project TimeGenerated, OperationName, InitiatedBy, TargetUser, CorrelationId;
let consent = AuditLogs
| where TimeGenerated > ago(lookback)
| where OperationName has_any ('Consent to application','Add service principal credentials','Add application')
| project TimeGenerated, OperationName, InitiatedBy, TargetResources, CorrelationId;
risky
| join kind=leftouter mfaPressure on UserPrincipalName
| join kind=leftouter authChanges on $left.UserPrincipalName == $right.TargetUser
| join kind=leftouter consent on $left.UserPrincipalName == tostring($right.InitiatedBy.user.userPrincipalName)
| project UserPrincipalName, IPAddress, Location, AppDisplayName, FailedMFA, OperationName, OperationName1, TimeGenerated, CorrelationId
| order by TimeGenerated desc;
VQL — Velociraptor
-- Endpoint hunt for remote support and RMM tooling often requested during vishing or fake IT support.
SELECT Pid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE Name =~ '(?i)(quickassist|anydesk|teamviewer|screenconnect|connectwise|splashtop|logmein|ammyy|rustdesk)'
   OR CommandLine =~ '(?i)(quickassist|anydesk|teamviewer|screenconnect|connectwise|splashtop|logmein|rustdesk)'

-- Recent executables in user-writable locations that frequently follow a social engineering handoff.
SELECT FullPath, Size, Mtime, Ctime
FROM glob(globs=['C:/Users/*/Downloads/*.exe','C:/Users/*/Downloads/*.msi','C:/Users/*/AppData/Local/Temp/*.exe','C:/ProgramData/*/AnyDesk/*.exe'])
WHERE Mtime > now() - 1209600
PowerShell
# Read-only audit for Entra ID and Exchange artifacts commonly seen after help desk or MFA social engineering.
# Run with least-privilege Graph scopes first: AuditLog.Read.All, UserAuthenticationMethod.Read.All, Policy.Read.All, Directory.Read.All.
Import-Module Microsoft.Graph.Authentication -ErrorAction Stop
Connect-MgGraph -Scopes 'AuditLog.Read.All','UserAuthenticationMethod.Read.All','Policy.Read.All','Directory.Read.All' -NoWelcome
$start = (Get-Date).AddDays(-14)

# Risky users and recent risky sign-ins
$riskyUsers = Get-MgRiskyUser -All | Where-Object { $_.RiskLastUpdatedDateTime -ge $start }
$riskySignIns = Get-MgAuditLogSignIn -All | Where-Object { $_.CreatedDateTime -ge $start -and ($_.RiskLevelDuringSignIn -in @('medium','high')) }
$riskyUsers | Select-Object UserPrincipalName,RiskState,RiskLevel,RiskLastUpdatedDateTime | Export-Csv .\audit-risky-users.csv -NoTypeInformation
$riskySignIns | Select-Object CreatedDateTime,UserPrincipalName,AppDisplayName,IpAddress,Location,RiskLevelDuringSignIn,Status | Export-Csv .\audit-risky-signins.csv -NoTypeInformation

# Recently changed authentication methods for targeted users
foreach ($u in ($riskySignIns | Select-Object -ExpandProperty UserPrincipalName -Unique)) {
  Get-MgUserAuthenticationMethod -UserId $u -ErrorAction SilentlyContinue |
    Select-Object @{n='User';e={$u}},Id,CreatedDateTime,
      @{n='Type';e={$_.AdditionalProperties.'@odata.type'}} |
    Export-Csv .\audit-auth-methods.csv -Append -NoTypeInformation
}

# Recent app registrations and consent events
Get-MgAuditLogDirectoryAudit -All |
  Where-Object { $_.ActivityDateTime -ge $start -and $_.ActivityDisplayName -match 'Consent to application|Add service principal credentials|Add application|Add owner to application' } |
  Select-Object ActivityDateTime,ActivityDisplayName,InitiatedBy,TargetResources |
  Export-Csv .\audit-app-consent.csv -NoTypeInformation

# Exchange inbox forwarding or deletion rules, if Exchange Online module is available
if (Get-Module -ListAvailable ExchangeOnlineManagement) {
  Connect-ExchangeOnline -ShowBanner:$false
  Get-Mailbox -ResultSize Unlimited | ForEach-Object {
    Get-InboxRule -Mailbox $_.UserPrincipalName -ErrorAction SilentlyContinue |
      Where-Object { $_.ForwardTo -or $_.RedirectTo -or $_.DeleteMessage -eq $true } |
      Select-Object MailboxOwnerId,Name,ForwardTo,RedirectTo,DeleteMessage,Description
  } | Export-Csv .\audit-inbox-rules.csv -NoTypeInformation
}

Remediation

Because there is no CVE and no vendor patch to apply, remediation is control verification and pressure reduction on the exact human pathways ShinyHunters-style actors exploit.

  1. Immediately review ReliaQuest-facing or provider-facing trust relationships if you are a customer: API tokens, alert forwarding, analyst accounts, shared mailboxes, escalation contacts, emergency access procedures, and data export permissions. Confirm no new accounts, keys, forwarding endpoints, or consent grants were added during the reporting window.
  2. Enforce phishing-resistant MFA for help desk staff, SOC analysts, administrators, executives, finance, HR, and anyone able to approve resets. Prefer FIDO2 passkeys or certificate-based authentication. Remove SMS and voice as usable factors for high-impact roles where feasible.
  3. Lock down password and MFA reset workflows. Require independent verification using a known-good channel, manager approval for privileged users, cooldown periods after method changes, and automatic alerts when a reset is followed by sign-in from a new ASN, device, or country.
  4. Create Conditional Access or equivalent IdP policies that block legacy auth, require compliant devices for admin portals, restrict token replay by using token protection where available, and step up authentication for risky sign-ins rather than allowing repeated push retries.
  5. Disable or tightly govern consumer-grade remote support tools. Maintain an allowlist for approved support sessions, require ticket numbers for elevation, log session initiation, and alert on execution of unapproved tools such as unauthorized AnyDesk, RustDesk, ScreenConnect-like clients, or ad hoc Quick Assist use outside support windows.
  6. Hunt for persistence that survives a password reset: inbox forwarding rules, OAuth grants, new app credentials, added owners to service principals, new devices in Intune or MDM, unfamiliar session cookies, and API keys in SaaS platforms.
  7. Rotate credentials only where telemetry indicates exposure. Blanket resets create noise and fatigue. Prioritize users with risky sign-ins, auth method changes, mailbox rule creation, consent events, remote tool execution, or contact reports matching the social engineering window.
  8. For MSSPs and providers, separate customer contexts by design: tenant isolation, per-customer credentials, just-in-time elevation, hardware-backed admin keys, recorded privileged sessions, and explicit break-glass accounts monitored end-to-end.
  9. Brief executives and service desk teams with a short script: never approve MFA on request, never move to personal email or encrypted chat, never read back codes, never install tools during an inbound call, and always hang up and call back using the directory number.
  10. Preserve evidence even when compromise is denied: IdP logs, call records, ticket transcripts, email headers, EDR telemetry, VPN logs, MDM events, SaaS audit logs, and customer notification decisions. Denial without preserved telemetry is not assurance.

Related Resources

Security Arsenal Managed SOC Services AlertMonitor Platform Book a SOC Assessment soc-mdr Intel Hub

Is your security operations ready?

Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.