In a recent Dark Reading editors' roundtable, one of the stories that slipped through the cracks of daily coverage carried an uncomfortable irony: ShinyHunters — the prolific data-theft and extortion crew — claimed to have breached ReliaQuest, a major managed security services provider whose entire business is defending other organizations. At the time of reporting, the claim remained unverified, and ReliaQuest had not confirmed a compromise. But whether this specific claim proves true, exaggerated, or fabricated for clout, it deserves every defender's attention for one simple reason: ShinyHunters' playbook is well-documented, actively in use in 2026, and it works against organizations with mature security programs.
This post breaks down what we know about the claim, why MSSPs and their customers are high-value targets, how the ShinyHunters intrusion chain typically unfolds, and — most importantly — the concrete detection and hardening steps your SOC should implement this week.
What Happened
ShinyHunters posted claims suggesting access to ReliaQuest's environment. Details were thin — no large-scale data dump accompanied the claim at the time of the Dark Reading discussion — and ReliaQuest had not publicly validated the breach. The editors flagged it as a story worth watching, alongside new research indicating that AI-generated malware remains far less prevalent in the wild than hype cycles suggest.
Three things matter for defenders here:
- The claim itself is a TTP. Extortion actors routinely announce breaches against high-profile security vendors and MSSPs to build credibility, pressure victims, and market stolen data. A claim is not proof — but it is a trigger for threat hunting, not dismissal.
- MSSPs are force-multiplier targets. Compromising an MSSP potentially exposes customer telemetry, incident response data, and downstream tenant access. ShinyHunters understands this economics.
- ShinyHunters doesn't need zero-days. Their historical modus operandi — and their recent campaigns targeting SaaS environments — rely on identity compromise: voice phishing (vishing) against help desks, MFA fatigue and MFA-reset social engineering, OAuth token theft, and bulk data export from platforms like Salesforce, Snowflake, and other cloud data stores.
Technical Analysis: The ShinyHunters Intrusion Chain
ShinyHunters (overlapping with activity clusters tracked as UNC5537 and related Scattered Spider-adjacent tradecraft) follows a repeatable, identity-centric kill chain against SaaS-heavy enterprises:
Stage 1 — Initial Access via Social Engineering. Operators call the target's IT help desk impersonating an employee (often an executive or traveling worker), requesting an MFA device reset or new factor enrollment. AI-assisted voice cloning has lowered the skill bar here, even if fully AI-generated malware remains rare. In parallel, targeted phishing pages proxy Okta/Entra ID sessions to capture credentials and session cookies in real time (adversary-in-the-middle).
Stage 2 — Identity Persistence. Once inside the IdP, attackers register their own MFA devices, create OAuth application grants, or mint API tokens. They rarely touch endpoint malware — which is exactly why traditional EDR goes silent during these intrusions.
Stage 3 — Discovery and Bulk Collection. Using legitimate SaaS APIs and admin consoles, the actors enumerate connected data stores — Salesforce instances, Snowflake warehouses, cloud storage buckets — and run bulk queries/exports. In recent ShinyHunters-attributed campaigns, data theft from SaaS platforms occurred without a single malicious binary touching a managed endpoint.
Stage 4 — Extortion. Data is exfiltrated over legitimate HTTPS to attacker-controlled cloud storage or VPS infrastructure, followed by extortion contact — sometimes with fabricated or inflated breach claims to increase pressure.
Exploitation status: This tradecraft is confirmed active in the wild throughout 2025–2026. No CVE is associated with this campaign — it exploits process and identity weaknesses, not software bugs. That makes it harder to patch and more important to detect behaviorally.
Why an MSSP Target Raises the Stakes
If you are a ReliaQuest customer — or a customer of any MSSP — a claim like this should trigger a standing playbook: review what telemetry and credentials your provider holds, confirm whether their SOC platform has persistent access into your environment (API keys, service accounts, agents), and monitor your own identity plane for anomalies in the days following the claim. Don't wait for confirmation; hunt on the claim.
Detection & Response
The detections below target the observable behaviors in the ShinyHunters SaaS-theft chain: MFA manipulation, anomalous IdP activity, bulk SaaS data export, and OAuth abuse.
---
title: Help Desk MFA Reset Followed by New Factor Enrollment
description: Detects an Okta/Entra MFA factor reset or deactivation followed within a short window by enrollment of a new factor — a hallmark of help-desk social engineering used by ShinyHunters and UNC5537-style actors.
references:
- https://attack.mitre.org/techniques/T1078/
- https://attack.mitre.org/techniques/T1556/006/
author: Security Arsenal
date: 2026/04/06
tags:
- attack.persistence
- attack.t1078
- attack.t1556.006
logsource:
product: okta
service: okta
detection:
selection_reset:
eventtype:
- 'system.mfa.factor.deactivate'
- 'user.mfa.factor.reset_all'
- 'user.mfa.attempt_bypass'
selection_enroll:
eventtype:
- 'user.mfa.factor.update'
- 'system.mfa.factor.activate'
condition: selection_reset or selection_enroll
falsepositives:
- Legitimate help desk MFA resets — correlate with help desk ticket IDs and verify via out-of-band callback to the user's registered number
level: high
---
title: Impossible Travel or Anomalous ASN Authentication to Identity Provider
description: Detects successful IdP authentication from a new country, anonymizing VPN/TOR exit node, or consumer ASN inconsistent with the user's historical baseline — typical of AiTM phishing and stolen-session replay.
references:
- https://attack.mitre.org/techniques/T1557/
- https://attack.mitre.org/techniques/T1078/
author: Security Arsenal
date: 2026/04/06
tags:
- attack.initial_access
- attack.t1557
- attack.t1078
logsource:
category: authentication
detection:
selection:
outcome: 'success'
security_threat_detected|contains:
- 'anonymizer'
- 'tor'
- 'vpn'
filter_known_good:
source_ip|cidr:
- '10.0.0.0/8'
- '192.168.0.0/16'
condition: selection and not filter_known_good
falsepositives:
- Executives traveling internationally — tune with per-user geo baselines and managed VPN egress allowlists
level: medium
---
title: Bulk Data Export from SaaS Platform via API
description: Detects mass export, report download, or high-volume SOQL/API query activity in Salesforce and similar SaaS platforms consistent with ShinyHunters' data-theft staging behavior.
references:
- https://attack.mitre.org/techniques/T1530/
- https://attack.mitre.org/techniques/T1567/
author: Security Arsenal
date: 2026/04/06
tags:
- attack.collection
- attack.exfiltration
- attack.t1530
- attack.t1567
logsource:
category: application
detection:
selection:
operation|contains:
- 'ReportExport'
- 'DataExport'
- 'BulkApiQuery'
- 'ApiQuery'
rows_processed|gt: 10000
falsepositives:
- Scheduled ETL/integration service accounts — scope to interactive user accounts and exclude known integration identities
level: high
// Hunt: ShinyHunters-style identity compromise — MFA changes + anomalous sign-in + SaaS export
// Correlate Entra ID/Okta sign-in anomalies with MFA registration changes and cloud app activity.
// Run across Sentinel tables; adjust TimeWindow for your environment.
let TimeWindow = 7d;
let SuspiciousSignins =
SigninLogs
| where TimeGenerated > ago(TimeWindow)
| where ResultType == 0
| extend LocationDetail = tostring(LocationDetails)
| where LocationDetail has_any ("anonymous", "vpn", "tor")
or NetworkLocationDetails has "tor"
| summarize FirstSeen=min(TimeGenerated), IPs=make_set(IPAddress), Apps=make_set(AppDisplayName)
by UserPrincipalName;
let MFAChanges =
AuditLogs
| where TimeGenerated > ago(TimeWindow)
| where OperationName has_any ("Update user", "Delete", "Register security info")
| where OperationName has "authentication method"
or ActivityDisplayName has_any ("user registered security info", "user deleted security info",
"Admin updated user", "Reset user password")
| extend TargetUser = tostring(TargetResources[0].userPrincipalName),
Actor = tostring(InitiatedBy.user.userPrincipalName)
| project TimeGenerated, Actor, TargetUser, OperationName, ActivityDisplayName;
MFAChanges
| join kind=inner SuspiciousSignins on $left.TargetUser == $right.UserPrincipalName
| project TimeGenerated, TargetUser, Actor, OperationName, IPs, Apps, FirstSeen
| order by TimeGenerated desc;
// Companion hunt: bulk export activity via Office/SaaS connectors (ingest Salesforce Event Log or Snowflake logs via CEF/Syslog)
// CommonSecurityLog
// | where DeviceEventClassID has_any ("ReportExport", "DataExport", "BulkApi")
// | summarize ExportCount=count(), TotalRows=sum(toint(AdditionalExtensions)) by SourceUserID, SourceIP, bin(TimeGenerated, 1h)
// | where ExportCount > 3
-- Hunt endpoints for evidence of AiTM phishing kit artifacts and session theft precursors:
-- browsers launched toward short-lived phishing domains, plus recent credential-store access.
-- Deploy as a fleet hunt; pair results with IdP telemetry for confirmation.
SELECT Pid, Name, Exe, CommandLine, Username, CreateTime
FROM pslist()
WHERE Name =~ '(?i)chrome|msedge|firefox|brave'
AND CommandLine =~ '(?i)--remote-debugging|headless|user-data-dir=.*temp'
-- Follow-on artifact: enumerate recently modified browser Login Data / Cookies copies
-- SELECT FullPath, Mtime, Size FROM glob(globs='C:\\Users\\*\\AppData\\Local\\*\\*\\User Data\\**\\Cookies*')
-- WHERE Mtime > now() - 86400
# Verify-IdentityHardening.ps1 — Audit Entra ID for ShinyHunters-style persistence artifacts
# Run with an account holding AuditLog.Read.All / Directory.Read.All (Microsoft Graph)
Import-Module Microsoft.Graph.Identity.SignIns -ErrorAction Stop
Connect-MgGraph -Scopes "AuditLog.Read.All","Directory.Read.All","Policy.Read.All" -NoWelcome
# 1. MFA/auth-method changes in the last 14 days (help-desk social engineering artifact)
$cutoff = (Get-Date).AddDays(-14)
Get-MgAuditLogDirectoryAudit -All | Where-Object {
$_.ActivityDateTime -gt $cutoff -and
($_.ActivityDisplayName -match 'security info|authentication method|Reset user password')
} | Select-Object ActivityDateTime, ActivityDisplayName,
@{n='Actor';e={$_.InitiatedBy.User.UserPrincipalName}},
@{n='Target';e={$_.TargetResources[0].UserPrincipalName}} |
Export-Csv -Path .\MFA_Changes_Audit.csv -NoTypeInformation
Write-Host "[+] MFA/auth-method changes exported to MFA_Changes_Audit.csv — verify each against help desk tickets" -ForegroundColor Yellow
# 2. New app registrations / OAuth consent grants (persistence + data-access vector)
Get-MgAuditLogDirectoryAudit -All | Where-Object {
$_.ActivityDateTime -gt $cutoff -and
$_.ActivityDisplayName -match 'Add application|Consent to application|Add service principal|Add app role assignment'
} | Select-Object ActivityDateTime, ActivityDisplayName,
@{n='Actor';e={$_.InitiatedBy.User.UserPrincipalName}},
@{n='Target';e={$_.TargetResources[0].DisplayName}} |
Export-Csv -Path .\OAuth_Consent_Audit.csv -NoTypeInformation
Write-Host "[+] OAuth/app consent events exported — investigate any grant not tied to a change request" -ForegroundColor Yellow
# 3. Report users NOT protected by phishing-resistant MFA (FIDO2/passkeys/cert-based)
$report = Get-MgReportAuthenticationMethodUserRegistrationDetail -All
$weak = $report | Where-Object { $_.IsMfaRegistered -eq $false -or
($_.MethodsRegistered -notmatch 'fido2|passkey|certificateBasedAuthentication') }
$weak | Select-Object UserPrincipalName, IsMfaRegistered, MethodsRegistered |
Export-Csv -Path .\NonPhishResistantMFA.csv -NoTypeInformation
Write-Host ("[!] {0} users lack phishing-resistant MFA — prioritize help desk and admin roles" -f $weak.Count) -ForegroundColor Red
Remediation & Hardening
There is no patch for social engineering — the fixes are architectural and procedural:
- Deploy phishing-resistant MFA everywhere it matters. FIDO2 security keys or passkeys for all administrators, help desk staff, and anyone with SaaS admin/export privileges. SMS and push-based MFA are the primary bypass targets in these campaigns. In Entra ID, enforce via Authentication Strengths in Conditional Access; in Okta, require WebAuthn for high-risk apps.
- Hard-code help desk verification. Require out-of-band identity proofing for any MFA reset or factor enrollment: manager callback on a registered number, or an ID-verification service (e.g., verified-ID workflows). Log every reset as a security-relevant event and alert SOC on resets for privileged accounts. ShinyHunters' vishing succeeds because resets are treated as routine IT ops, not security events.
- Constrain OAuth and API access. Disable user consent for third-party apps; require admin consent workflows. Inventory all existing service principals and revoke grants not tied to documented business need. For Salesforce and Snowflake, restrict bulk API access and
API Enabledpermissions to named integration accounts with IP allowlisting. - Detect the export, not the binary. Enable and centralize SaaS audit logging: Salesforce Event Monitoring, Snowflake ACCESS_HISTORY, Okta System Log, Entra Audit Logs — stream all of it to your SIEM. Alert on volume-based export anomalies per user, per hour. The exfiltration stage is your last reliable tripwire.
- MSSP/customer due diligence. If you consume managed security services, invoke your contract's breach-notification SLA, confirm the provider's tenant isolation model, rotate any shared API keys or service account credentials on claim (not on confirmation), and review what data of yours resides in their platforms.
- Watch for the extortion follow-through. Monitor criminal forums and leak sites via your threat intel provider for data samples that would validate or refute the claim. Validation changes your IR posture; fabrication is a reputational event, not a technical one.
The Bottom Line
Whether ShinyHunters actually breached ReliaQuest is almost beside the point. The claim is a live-fire reminder that identity is the perimeter, SaaS is the data center, and the help desk is the front door. Organizations with excellent EDR and network controls have fallen to this exact playbook because none of those controls saw anything to stop. Fix the identity plane, instrument the export path, and treat every help desk reset as a potential incident.
Related Resources
Security Arsenal Incident Response Services AlertMonitor Platform Book a SOC Assessment incident-response Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.