ShinyHunters 'Rey' Detained in Jordan: What the Arrest Means for Cloud Data-Extortion Defense in 2026

According to reporting by BleepingComputer, a suspected member of the ShinyHunters extortion group — known online by the handle "Rey" — has been detained in Jordan and is reportedly cooperating with the FBI to help locate other members of the group. For those of us who have spent the past several years responding to the breach-and-extortion wave that ShinyHunters helped define, this is a significant development. But it is not a signal to stand down.

ShinyHunters is not a single operator. It is a brand — a loosely federated ecosystem of actors specializing in large-scale data theft from cloud and SaaS platforms, followed by extortion, data leak site postings, and eventual resale or free release of stolen data on forums like BreachForums. The group has been linked to some of the highest-volume breach campaigns of the 2024–2026 period, including the mass exploitation of Snowflake customer environments and ongoing campaigns targeting Salesforce instances through third-party integrations and vishing-assisted OAuth abuse. One arrest — even a cooperating one — disrupts infrastructure and attribution, but the techniques, tooling, and stolen-credential pipelines remain in circulation and in active use by affiliates and copycats.

If your organization stores customer, financial, or regulated data in SaaS platforms, your exposure has not changed this week. Your detection posture is what matters. This post breaks down the tradecraft associated with ShinyHunters-style operations and gives your SOC concrete detection and hardening guidance.

Technical Analysis

What ShinyHunters-Style Campaigns Actually Look Like

From an IR seat, the consistent hallmark of these operations is that they rarely begin with a software vulnerability at all. The dominant initial access vectors we have observed across 2024–2026 engagements:

• Credential stuffing and infostealer-harvested credentials against SaaS tenants. The Snowflake campaign of 2024 demonstrated this at scale: attackers used credentials harvested by infostealer malware (Raccoon, Vidar, Lumma, RedLine families) — sometimes years old — to authenticate directly to cloud data warehouse instances lacking MFA. No exploitation required.
• OAuth application abuse and vishing-assisted consent. In Salesforce-targeting campaigns (attributed in reporting to overlapping ShinyHunters/UNC6040/Scattered Spider clusters), attackers socially engineer employees into authorizing a malicious connected app — often disguised as a legitimate "Data Loader" tool — granting API access that bypasses MFA and most endpoint controls entirely.
• Bulk API exfiltration. Once authenticated, the actors enumerate and extract data using standard, legitimate APIs (Salesforce Bulk API, SOQL queries; Snowflake SQL over the standard connector) at volumes far outside the victim's baseline.
• Extortion without encryption. These are pure data-theft operations. There is no ransomware payload, no EDR alert on file encryption, no obvious "malware" to find. The entire attack lives in the identity and API layer — which is precisely where most organizations have their weakest telemetry.

Affected Platforms and Scope

There is no CVE associated with this news item, and that is the point: the exposure is architectural. Organizations at elevated risk include:

• Snowflake customers with accounts lacking enforced MFA, network policies, or with stale service/human credentials
• Salesforce customers with permissive connected-app authorization settings and no API anomaly monitoring
• Any SaaS-heavy enterprise whose employees are reachable by phone (vishing) and whose identity provider does not restrict OAuth consent
• Organizations whose employee credentials circulate in infostealer logs (check your exposure via threat intel feeds or HIBP enterprise services)

Why the Arrest Matters — and Its Limits

A cooperating insider can degrade the group's operational security, expose infrastructure, leak escrowed data, and generate attribution that feeds prosecutions. Historically (REvil, LockBit disruptions), major law-enforcement pressure produces: short-term operational pause, forum drama, splintering, and then reconstitution under new handles. The underlying enabler — infostealer-harvested SaaS credentials and consent-phishing tradecraft — is commoditized and survives any single arrest. Treat this news as threat-actor context, not risk reduction.

Detection & Response

The detections below target the tradecraft, not the named group — which is exactly how it should be, since affiliates will keep operating under new branding.

Sigma Rules

---
title: Potential OAuth Consent Phishing - New Third-Party Application Authorized
detection_type: sigma
id: 3f8a1c72-9b4e-4d61-a8f2-1c3e5b7d9a01
status: experimental
description: Detects authorization of new OAuth/connected applications, a technique used in vishing-assisted consent phishing campaigns against SaaS tenants (e.g., Salesforce Data Loader impersonation).
references:
  - https://attack.mitre.org/techniques/T1550/001/
  - https://attack.mitre.org/techniques/T1566/
author: Security Arsenal
date: 2026/02/11
tags:
  - attack.credential_access
  - attack.t1550.001
logsource:
  product: azure
  service: auditlogs
detection:
  selection:
    OperationName: 'Consent to application'
  filter_admin_consent:
    Result: 'success'
    InitiatedBy|contains: 'admin'
  condition: selection and not filter_admin_consent
falsepositives:
  - Legitimate user consent to new business applications; maintain an allowlist of approved app IDs
level: high
---
title: Bulk Data Export Tool Execution from Command Line
id: 7c2e9a41-3d6b-4f58-b1a9-8e2c4d6f0b22
status: experimental
description: Detects execution of data extraction tools commonly abused for bulk export from databases and SaaS platforms during extortion campaigns.
references:
  - https://attack.mitre.org/techniques/T1530/
author: Security Arsenal
date: 2026/02/11
tags:
  - attack.collection
  - attack.t1530
  - attack.exfiltration
logsource:
  category: process_creation
  product: windows
detection:
  selection_img:
    Image|endswith:
      - '\mysqldump.exe'
      - '\pg_dump.exe'
      - '\sqlcmd.exe'
      - '\bcp.exe'
      - '\snowsql.exe'
      - '\rclone.exe'
  selection_cli:
    CommandLine|contains:
      - ' config create'
      - ' copy '
      - ' sync '
      - '--query'
      - ' OUT '
  condition: selection_img and selection_cli
falsepositives:
  - Legitimate DBA export jobs and ETL pipelines; baseline service accounts and scheduled task contexts
level: medium
---
title: Compressed Archive Staging in User-Writable Directories
id: 1d5b8f30-6a2c-4e97-c3d4-9f1a2b5c7e33
status: experimental
description: Detects creation of large archive files in temp/public directories consistent with pre-exfiltration data staging observed in cloud data-theft operations.
references:
  - https://attack.mitre.org/techniques/T1560/001/
author: Security Arsenal
date: 2026/02/11
tags:
  - attack.collection
  - attack.t1560.001
logsource:
  category: file_event
  product: windows
detection:
  selection_path:
    TargetFilename|contains:
      - '\AppData\Local\Temp\'
      - '\ProgramData\'
      - '\Users\Public\'
  selection_ext:
    TargetFilename|endswith:
      - '.zip'
      - '.7z'
      - '.rar'
      - '.tar.gz'
  filter_system:
    Image|endswith:
      - '\msiexec.exe'
      - '\svchost.exe'
  condition: selection_path and selection_ext and not filter_system
falsepositives:
  - Software packaging, user backups; tune with known admin tooling and software deployment paths
level: medium

KQL — Microsoft Sentinel / Defender

This query hunts for anomalous SaaS/cloud authentication patterns consistent with credential-based access to data platforms: logins from new geographies or ASNs combined with high-volume data retrieval. It assumes you are ingesting SaaS audit logs (Snowflake, Salesforce, or equivalent) into a custom table or via the relevant Sentinel connector — adapt the table name to your ingestion.

// Hunt: anomalous SaaS sign-ins followed by bulk query/export activity
// Assumes SaaS audit logs ingested via Sentinel connector (Snowflake/Salesforce) into *_CL or native tables
let lookback = 14d;
let baseline_days = 30d;
let SignIns = SigninLogs
| where TimeGenerated > ago(lookback)
| where ResultType == 0
| project TimeGenerated, UserPrincipalName, IPAddress, Location, AppDisplayName, UserAgent, AuthenticationRequirement;
// Flag sign-ins from ASNs/countries not seen for that user in the prior 30 days
let HistoricalIPs = SigninLogs
| where TimeGenerated between (ago(baseline_days) .. ago(lookback))
| where ResultType == 0
| distinct UserPrincipalName, IPAddress;
SignIns
| where IPAddress !in (HistoricalIPs | project IPAddress)
| summarize FirstSeen = min(TimeGenerated), Locations = make_set(Location), Apps = make_set(AppDisplayName), UserAgents = make_set(UserAgent) by UserPrincipalName, IPAddress
| order by FirstSeen desc

For endpoint-level hunting of the staging/exfiltration tooling on Windows endpoints and servers:

// Hunt: data staging and exfiltration tooling on endpoints (last 7 days)
DeviceProcessEvents
| where TimeGenerated > ago(7d)
| where FileName in~ ("rclone.exe", "snowsql.exe", "mysqldump.exe", "pg_dump.exe", "bcp.exe", "7z.exe", "winrar.exe", "megacmd.exe")
   or ProcessCommandLine has_any ("rclone", " copy ", " sync ", "mysqldump", "pg_dump")
| project TimeGenerated, DeviceName, AccountName, FileName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessAccountName, SHA256
| order by TimeGenerated desc

Velociraptor VQL

For rapid fleet-wide hunting when you suspect credential abuse has already led to hands-on access from an endpoint or jump host:

-- Hunt for exfiltration/staging tooling and archive artifacts on endpoints
SELECT Pid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE CommandLine =~ '(?i)rclone|mysqldump|pg_dump|snowsql|megacmd|7z.* a |winrar.* a '
   OR Exe =~ '(?i)\\\\(rclone|megacmd|snowsql)\\.exe$'

-- Hunt for recently created large archive files in user-writable staging paths
SELECT FullPath, Size, Mtime, Atime
FROM glob(globs=[
  'C:/Users/*/AppData/Local/Temp/**/*.zip',
  'C:/Users/*/AppData/Local/Temp/**/*.7z',
  'C:/Users/Public/**/*.zip',
  'C:/ProgramData/**/*.7z'
])
WHERE Size > 104857600
  AND Mtime > now() - 604800
ORDER BY Mtime DESC

Hardening Script

The single highest-leverage control against this tradecraft is at the identity layer. The PowerShell below audits your Microsoft Entra ID tenant for risky OAuth consent configuration and recently consented third-party applications — the exact consent-phishing surface used in Salesforce/SaaS-targeting campaigns. Run it with Global Reader or equivalent; review output before changing any settings.

# Audit Entra ID OAuth consent posture and recent third-party app consents
# Requires: Microsoft.Graph module; Connect-MgGraph -Scopes "Policy.Read.All","Application.Read.All","AuditLog.Read.All"

Connect-MgGraph -Scopes "Policy.Read.All","Application.Read.All","AuditLog.Read.All" -NoWelcome

# 1. Check user consent policy - should be disabled or restricted to verified publishers/low-risk permissions
$consentPolicy = Get-MgPolicyAuthorizationPolicy
Write-Host "=== User Consent Settings ===" -ForegroundColor Cyan
$consentPolicy.DefaultUserRolePermissions | Select-Object PermissionGrantPoliciesAssigned | Format-List
Write-Host "If PermissionGrantPoliciesAssigned contains 'ManagePermissionGrantsForSelf.microsoft-user-default-legacy', users can consent freely - RESTRICT THIS." -ForegroundColor Yellow

# 2. List OAuth consent grants created in the last 30 days
$cutoff = (Get-Date).AddDays(-30)
Write-Host "`n=== OAuth Grants Created Since $cutoff ===" -ForegroundColor Cyan
Get-MgAuditLogDirectoryAudit -Filter "activityDateTime ge $($cutoff.ToString('o'))" -All |
  Where-Object { $_.ActivityDisplayName -match 'Consent to application|Add OAuth2PermissionGrant' } |
  Select-Object ActivityDateTime, ActivityDisplayName,
    @{N='InitiatedBy';E={$_.InitiatedBy.User.UserPrincipalName}},
    @{N='TargetApp';E={$_.TargetResources[0].DisplayName}},
    Result |
  Format-Table -AutoSize

# 3. Enumerate service principals with broad mail/data permissions granted via app consent
Write-Host "`n=== Service Principals with High-Risk Delegated Grants ===" -ForegroundColor Cyan
$highRiskScopes = 'Mail.Read','Mail.ReadWrite','Files.Read.All','Sites.Read.All','full_access_as_app','User.Read.All'
Get-MgOauth2PermissionGrant -All |
  Where-Object { grant = $_.Scope; ($highRiskScopes | Where-Object { $grant -match $_ }) } |
  Select-Object ClientId, ConsentType, Scope |
  Format-Table -AutoSize

# 4. Remediation action (review first): disable user consent entirely
# Update-MgPolicyAuthorizationPolicy -DefaultUserRolePermission:... # see MS docs; requires Global Admin
Write-Host "`nRECOMMENDED: Set user consent to 'Do not allow' and enable the admin consent workflow." -ForegroundColor Green
Write-Host "Docs: https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/configure-admin-consent-workflow" -ForegroundColor Green

For Snowflake specifically, enforce MFA and network policies at the account level (every human user, no exceptions) and audit ACCOUNT_USAGE.LOGIN_HISTORY for failed logins and unfamiliar clients. For Salesforce, review Connected Apps OAuth Usage, restrict API access to approved profiles/permission sets, and enable Event Monitoring with Transaction Security policies to alert on Bulk API export volume anomalies.

Remediation

There is no patch for an extortion group — the remediation is architectural. Prioritized for defenders:

1. Enforce phishing-resistant MFA on every SaaS and cloud data platform. This is the control that would have neutralized the credential-stuffing vector behind the Snowflake campaign. No shared service accounts with password-only auth. Rotate any credential that has ever touched a developer workstation.
2. Lock down OAuth consent. Disable user consent to third-party apps in Entra ID; route everything through an admin consent workflow. In Salesforce, restrict connected-app installation to admins and audit existing authorized apps against an approved inventory — remove anything resembling an unsanctioned "Data Loader."
3. Baseline and alert on data egress volume. Enable and actually ingest audit logging: Snowflake ACCOUNT_USAGE, Salesforce Event Monitoring, Entra sign-in logs. Build per-user and per-service-account baselines for rows/bytes retrieved; alert on order-of-magnitude deviations.
4. Hunt your infostealer exposure. Subscribe to credential-leak/infostealer-log intelligence for your corporate domains. Force password resets and session revocation for any employee credential found in stealer logs — even if the log is months old; actors routinely use aged credentials.
5. Vishing-resistant help desk and user processes. These campaigns lean on phone-based social engineering. Implement caller verification for help-desk MFA resets and OAuth approvals, and train staff that no legitimate IT process asks them to "connect an app" or read back a code.
6. Prepare for the extortion playbook, not just the breach. Update your IR runbooks for pure data-theft extortion: legal/comms decision tree, leak-site monitoring, data-sample validation procedures, and a pre-approved policy on negotiation and payment. Notify counsel early if regulated data (HIPAA, PCI-DSS) is in scope — notification clocks start at discovery, not confirmation.
7. Assume persistence of tradecraft. One arrest does not retire a technique set. Treat every detectable behavior above as a durable SOC detection, not a campaign-specific rule to be retired when the headlines fade.

Related Resources

Security Arsenal Healthcare Cybersecurity AlertMonitor Platform Book a SOC Assessment healthcare Intel Hub