ShinyHunters Impersonates Security Staff to Breach ReliaQuest: Detecting and Defeating Help Desk Social Engineering

ReliaQuest — a well-known managed detection and response provider — has publicly confirmed that one of its own employees was targeted in a social engineering attack in which threat actors impersonated a member of the company's security team. The attack, attributed to the ShinyHunters extortion group, aimed at data theft. According to ReliaQuest's disclosure, the attempt failed: internal controls and detection mechanisms caught the activity before data could be exfiltrated.

That outcome matters, and it should not be read as a reason for complacency. It should be read as a case study. ShinyHunters — the group behind the Ticketmaster, Santander, and AT&T-linked data theft campaigns tied to compromised SaaS accounts — has been refining an identity-first playbook: impersonate trusted personnel, manipulate help desks and employees into resetting credentials or MFA, pivot into SaaS environments, and extort. If a mature security vendor like ReliaQuest is being targeted directly, every organization with a help desk, an identity provider, and a human being answering the phone is in scope.

This post breaks down what happened, why this TTP is surging in 2025–2026, and — most importantly — gives your SOC concrete detection content and remediation steps to make sure your organization ends up on the right side of the same headline.

What Happened: Attack Breakdown

Based on the public reporting and ReliaQuest's confirmation:

• Attack vector: Pure social engineering. No malware, no exploit, no CVE. The attackers impersonated a member of ReliaQuest's security team in order to socially manipulate an employee — the classic pretexting pattern (MITRE ATT&CK T1656 / T1078).
• Threat actor: ShinyHunters, a financially motivated extortion group with a long history of SaaS credential abuse and large-scale data theft/extortion campaigns.
• Objective: Data theft. ShinyHunters' monetization model is exfiltrate-then-extort; initial access through identity compromise, not vulnerability exploitation.
• Outcome: The attempt failed. ReliaQuest's internal detection and response processes identified and contained the activity before data loss occurred.

The critical lesson: identity is the perimeter the attacker chose, and identity telemetry is what saved the defender. There was no malicious binary to signature, no exploit to patch. The only available defense was behavioral detection, hardened identity processes, and an employee/response pipeline that recognized something was wrong.

The ShinyHunters Identity Playbook

Across recent campaigns, ShinyHunters and affiliated actors consistently execute the following chain:

1. Reconnaissance (T1589): Scrape LinkedIn, corporate directories, and data broker sites to build org charts — identifying help desk staff, security team members (to impersonate), and high-value targets (executives, SaaS administrators).
2. Pretexting / Vishing (T1656, T1566.004): Call or message employees posing as internal security or IT, claiming an account issue, a "security incident," or an MFA migration that requires immediate action.
3. MFA manipulation (T1621 / T1078.004): Trick the target or the help desk into approving an MFA prompt, enrolling an attacker-controlled device, or resetting credentials. In help-desk variants, the attacker calls the help desk impersonating the employee and requests an MFA reset — the exact pattern seen in the Scattered Spider / MGM-class intrusions.
4. SaaS access and collection (T1530, T1213): Use valid cloud accounts to access CRM, data warehouse, ticketing, and file-sharing platforms — environments where DLP and EDR coverage is historically weakest.
5. Extortion (T1657): Stolen data is leveraged for financial extortion, often with public leak threats.

Every one of these steps generates telemetry. Your job is to make sure that telemetry is collected, correlated, and alerted on.

Detection & Response

This is a technical threat with no CVE and no payload — the detection surface is identity, help-desk workflow, and endpoint behavior following an account compromise. The rules below are tuned for a mature SOC; validate thresholds against your baseline before production deployment.

Sigma Rules

The following rules target the highest-signal behaviors in this attack pattern: post-compromise persistence setup (inbox rules and forwarding — a standard move after voice-phished credential capture), and credential-harvest landing artifacts. Identity-provider events (Okta/Entra ID MFA enrollment, impossible travel) should additionally be handled via your IdP alerting and the KQL queries below.

---
title: Suspicious Inbox Rule Creation or Mail Forwarding After Credential Compromise
id: 9c4e2b71-3d85-4a1f-b6c2-7e8f9a0d1c3b
status: experimental
description: Detects creation of inbox rules that delete, move, or forward mail — a common persistence and suppression technique after successful vishing/social-engineering credential theft, consistent with ShinyHunters-style account takeover tradecraft.
references:
  - https://www.bleepingcomputer.com/news/security/reliaquest-confirms-failed-data-theft-attack-after-shinyhunters-breach/
  - https://attack.mitre.org/techniques/T1098/002/
  - https://attack.mitre.org/techniques/T1114/003/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.persistence
  - attack.collection
  - attack.t1098.002
  - attack.t1114.003
logsource:
  product: m365
  service: exchange
detection:
  selection:
    Operation:
      - 'New-InboxRule'
      - 'Set-InboxRule'
  suspicious_parameters:
    Parameters|contains:
      - 'DeleteMessage'
      - 'ForwardTo'
      - 'ForwardAsAttachmentTo'
      - 'RedirectTo'
      - 'MoveToFolder'
  filter_archive_folder:
    Parameters|contains: 'MoveToFolder'
    Parameters|contains: '\Archive'
  condition: selection and suspicious_parameters and not filter_archive_folder
falsepositives:
  - Users legitimately creating forwarding or cleanup rules; baseline per-user rule creation frequency and alert on first-time or off-hours creation
level: high
---
title: Credential Harvesting Landing Page or Phishing Kit Artifact Access
id: 2f7a9d14-6c83-4e50-a291-5b8c3d7e1f04
status: experimental
description: Detects browser processes accessing suspicious local or short-lived credential-harvest artifacts and commonly abused reverse-proxy phishing infrastructure patterns following a vishing-driven link delivery.
references:
  - https://www.bleepingcomputer.com/news/security/reliaquest-confirms-failed-data-theft-attack-after-shinyhunters-breach/
  - https://attack.mitre.org/techniques/T1566/004/
  - https://attack.mitre.org/techniques/T1656/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.initial_access
  - attack.t1566.004
  - attack.t1656
logsource:
  category: dns
  product: windows
detection:
  selection_abuse_tlds:
    QueryName|contains:
      - '.workers.dev'
      - '.pages.dev'
      - '.web.app'
      - '.firebaseapp.com'
  selection_phish_keywords:
    QueryName|contains:
      - 'sso-'
      - '-sso'
      - 'okta-verify'
      - 'mfa-reset'
      - 'helpdesk-'
      - 'it-support-'
      - 'verify-account'
  condition: selection_abuse_tlds and selection_phish_keywords
falsepositives:
  - Legitimate internal tooling hosted on serverless platforms; tune against your approved domain inventory
level: medium

KQL — Microsoft Sentinel / Defender

The highest-value hunt for this exact scenario is identity-layer: anomalous MFA changes, new authentication method enrollment, and help-desk-driven password resets clustered in time — the mechanical signature of the vishing workflow that ShinyHunters used here. Run these against your Entra ID (Azure AD) audit logs ingested into Sentinel.

// Hunt: MFA/Auth method changes followed by new sign-ins from unfamiliar locations
// Maps to vishing-driven MFA enrollment abuse (T1621 / T1078.004)
let timeframe = 14d;
let AuthChanges =
    AuditLogs
    | where TimeGenerated > ago(timeframe)
    | where OperationName has_any (
        "User registered security info",
        "User changed default MFA method",
        "Add strong authentication method",
        "Admin updated user"
    ) or (OperationName =~ "Update user" and tostring(TargetResources[0].modifiedProperties) has "StrongAuthentication")
    | extend UserPrincipalName = tostring(TargetResources[0].userPrincipalName)
    | extend InitiatedBy = tostring(parse_json(InitiatedBy).user.userPrincipalName)
    | extend ActorIPAddress = tostring(parse_json(InitiatedBy).user.ipAddress)
    | project AuthChangeTime=TimeGenerated, UserPrincipalName, OperationName, InitiatedBy, ActorIPAddress, CorrelationId;
AuthChanges
| join kind=inner (
    SigninLogs
    | where TimeGenerated > ago(timeframe)
    | project SigninTime=TimeGenerated, UserPrincipalName, IPAddress, Location=tostring(LocationDetails.countryOrRegion), AppDisplayName, ResultType
) on UserPrincipalName
| where SigninTime between (AuthChangeTime .. AuthChangeTime + 4h)
| summarize SigninCount=count(), Locations=make_set(Location), IPs=make_set(IPAddress), Apps=make_set(AppDisplayName)
    by UserPrincipalName, AuthChangeTime, OperationName, InitiatedBy, ActorIPAddress
| order by AuthChangeTime desc

// Hunt: Password resets clustered by help-desk/admin actors — detect reset-spray patterns
// A single admin/helpdesk identity resetting many users in a short window is a strong indicator
// of either a compromised help-desk account or a successful impersonation of IT staff.
AuditLogs
| where TimeGenerated > ago(7d)
| where OperationName in ("Reset user password", "Reset password (by admin)")
| extend Actor = tostring(parse_json(InitiatedBy).user.userPrincipalName)
| extend TargetUser = tostring(TargetResources[0].userPrincipalName)
| summarize ResetCount = count(), Targets = make_set(TargetUser) by Actor, bin(TimeGenerated, 1h)
| where ResetCount >= 5
| order by ResetCount desc

Velociraptor VQL

Post-compromise, the first endpoint-side artifacts worth hunting are evidence of remote-access tooling or OAuth/session theft staging on the targeted user's machine — because sophisticated vishing operators frequently pair the social call with instructions to install "support software" (AnyDesk, ScreenConnect, TeamViewer) as a fallback access path.

-- Hunt for unauthorized remote access tools commonly pushed during vishing calls
SELECT Pid, Name, Exe, Username, CommandLine, CreateTime
FROM pslist()
WHERE Name =~ '(?i)(anydesk|screenconnect|connectwise|teamviewer|rustdesk|splashtop|ammyy|logmein)'
   OR Exe =~ '(?i)(anydesk|screenconnect|teamviewer|rustdesk|splashtop)'

-- Hunt for browser credential store access by non-browser processes (session/token theft staging)
SELECT Pid, Name, Exe, Username, CommandLine, CreateTime
FROM pslist()
WHERE CommandLine =~ '(?i)(Login Data|Cookies|Local State)'
  AND NOT Name =~ '(?i)(chrome|msedge|firefox|brave|opera)'

Hardening Script — Help Desk Identity Verification Controls

The single most effective remediation against this attack class is procedural, enforced technically: strong identity proofing before any credential or MFA change. The following PowerShell script audits your Entra ID tenant for the exact configurations attackers abuse — permissive MFA reset workflows, legacy authentication, and missing authentication-strength policies — so you can close them.

# Requires: Microsoft.Graph PowerShell SDK
# Connect-MgGraph -Scopes "Policy.Read.All","UserAuthenticationMethod.Read.All","AuditLog.Read.All","Directory.Read.All"

Write-Host "=== Help Desk Social Engineering Hardening Audit ===" -ForegroundColor Cyan

# 1. Check for users with no MFA methods registered (prime vishing targets)
Write-Host "`n[1] Users without registered authentication methods:" -ForegroundColor Yellow
$report = Get-MgReportAuthenticationMethodUserRegistrationDetail -All
$noMfa = $report | Where-Object { $_.IsMfaRegistered -eq $false -and $_.UserType -eq 'Member' }
$noMfa | Select-Object UserPrincipalName, UserDisplayName | Format-Table -AutoSize
Write-Host "Users without MFA: $($noMfa.Count)" -ForegroundColor $(if ($noMfa.Count -gt 0) {'Red'} else {'Green'})

# 2. Check for SMS/Voice as an auth method (phishable — should be phased out for high-value users)
Write-Host "`n[2] Users still relying on SMS/Voice MFA (phishable factors):" -ForegroundColor Yellow
$weak = $report | Where-Object { $_.MethodsRegistered -contains 'mobilePhone' -and $_.MethodsRegistered -notcontains 'microsoftAuthenticatorPush' -and $_.MethodsRegistered -notcontains 'windowsHelloForBusiness' }
Write-Host "Users on phishable-only factors: $($weak.Count)" -ForegroundColor $(if ($weak.Count -gt 0) {'Red'} else {'Green'})

# 3. Review recent admin-initiated password resets (help desk impersonation surface)
Write-Host "`n[3] Admin-initiated password resets in last 7 days:" -ForegroundColor Yellow
$start = (Get-Date).AddDays(-7).ToString("yyyy-MM-ddTHH:mm:ssZ")
Get-MgAuditLogDirectoryAudit -Filter "activityDisplayName eq 'Reset user password' and activityDateTime ge $start" -All |
    Select-Object ActivityDateTime,
        @{n='InitiatedBy';e={$_.InitiatedBy.User.UserPrincipalName}},
        @{n='Target';e={$_.TargetResources[0].UserPrincipalName}} |
    Format-Table -AutoSize

# 4. Check legacy authentication blocking via Conditional Access
Write-Host "`n[4] Conditional Access policies (verify legacy auth block + auth strength):" -ForegroundColor Yellow
Get-MgIdentityConditionalAccessPolicy -All |
    Select-Object DisplayName, State,
        @{n='ClientApps';e={$_.Conditions.ClientAppTypes -join ','}},
        @{n='AuthStrength';e={$_.GrantControls.AuthenticationStrength.Id}} |
    Format-Table -AutoSize

Write-Host "`n=== Audit complete. Review findings against the remediation checklist below. ===" -ForegroundColor Cyan

Remediation & Hardening Recommendations

There is no patch for social engineering. The fix is a combination of process engineering, identity configuration, and detection coverage. Prioritize the following:

1. Engineer the Help Desk Out of the Kill Chain

• Mandatory identity proofing before any password reset, MFA reset, or device enrollment change: callback to a number on file (never the number the caller provides), manager approval for privileged or executive accounts, and verification questions drawn from HR records — not from anything findable on LinkedIn or breach data.
• Cooling-off periods: enforce a delay and secondary approval for MFA resets on privileged accounts. The entire vishing model depends on urgency; a 30-minute delay kills it.
• Log and alert on every admin-initiated reset (see KQL above). A reset event should never be invisible.

2. Deploy Phishing-Resistant MFA

• Migrate high-value users (executives, IT, security, SaaS admins) to FIDO2/passkeys or Windows Hello for Business. ShinyHunters' pretexting works against push-based and SMS MFA; it does not work against origin-bound hardware keys.
• Disable SMS/voice as authentication factors for privileged roles.
• Use Conditional Access authentication strengths to require phishing-resistant MFA specifically for admin portals and sensitive SaaS apps.

3. Harden the Identity Provider

• Alert on: new MFA method enrollment + sign-in within 4 hours, security info registration from new IPs/devices, impossible-travel sign-ins, and token protection anomalies.
• Block legacy authentication tenant-wide.
• Review OAuth app consent grants — ShinyHunters-adjacent actors routinely use consented apps as durable SaaS access that survives password resets.

4. Train for the Specific Scenario, Not Generic Phishing

• Your security awareness program almost certainly covers email phishing. It almost certainly does not cover an authoritative caller claiming to be from your own security team demanding urgent MFA action. Add vishing and impersonation modules, and run live-fire vishing simulations against help desk staff specifically.
• Establish and publicize a simple rule: the security team will never ask you to approve an MFA prompt, read back a code, or install software over the phone.

5. Assume the Call Succeeds Somewhere

• Segment SaaS access with Conditional Access and least-privilege scopes so one phished account doesn't expose the data warehouse.
• Deploy the Sigma and KQL content above; validate in a test environment, tune to baseline, then promote to production.
• Tabletop this exact scenario — "an employee just reported a call from someone claiming to be our CISO's office requesting an MFA reset" — with your SOC, help desk, and comms teams. ReliaQuest's outcome shows the value of a workforce and response process that recognizes and escalates quickly.

Conclusion

The ReliaQuest incident is a near-miss with a happy ending — and that's exactly why it deserves your attention. ShinyHunters targeted a company whose entire business is detecting attacks, impersonated its security team, and was still stopped. That is a validation of defense-in-depth at the identity layer, not evidence that the threat is overblown. The same pretext that failed against a mature MDR provider will succeed against an organization whose help desk resets MFA with a smile and no callback verification. Close the procedural gaps, deploy phishing-resistant MFA, instrument your identity telemetry, and make sure your team's response to an impersonation call is a page to the IR on-call — not a password reset.

Related Resources

Security Arsenal Incident Response Services AlertMonitor Platform Book a SOC Assessment incident-response Intel Hub