McKesson Breach After ShinyHunters Claims 284M Patient Records Stolen — Third-Party Application Access Detection and Hardening Guide

McKesson — one of the largest pharmaceutical distributors and healthcare services companies in North America — has disclosed a cybersecurity incident involving unauthorized access to third-party applications and confirmed data theft. The ShinyHunters extortion group has claimed responsibility, alleging it exfiltrated approximately 284 million patient data records.

If those numbers hold, this would rank among the largest healthcare data breaches ever reported — dwarfing the 78.8 million-record Anthem breach and rivaling the Change Healthcare incident in scale. For healthcare CISOs, privacy officers, and SOC teams, the immediate concern is not just McKesson's posture: it is the attack pattern. Once again, a major enterprise was not breached through a firewall exploit or a zero-day. It was breached through trusted third-party application access — the exact vector ShinyHunters and affiliated clusters have industrialized over the past two years.

This post breaks down what we know, how this tradecraft works, and what your organization should be hunting for and hardening today.

What Happened

Based on McKesson's disclosure and reporting:

• Unauthorized access was gained to third-party applications integrated with McKesson's environment — not, based on current public statements, through a direct compromise of McKesson's core internal network.
• Data was stolen, and the attacker has engaged in an extortion play consistent with ShinyHunters' established model: steal, threaten publication or sale, demand payment.
• ShinyHunters claims the haul includes ~284 million patient data records, which would imply access to large-scale database or SaaS data stores through the compromised third-party pathway.

The specifics of which third-party application served as the entry point have not been fully detailed publicly. However, ShinyHunters' recent campaign history provides a well-documented playbook that defenders should treat as the working hypothesis until McKesson's forensic findings say otherwise.

Technical Analysis: How ShinyHunters Breaches Third-Party and SaaS Applications

No CVE has been associated with this incident, and none should be assumed. This class of breach is overwhelmingly identity- and configuration-driven, not vulnerability-driven. That distinction matters for your defensive strategy: you cannot patch your way out of this one.

The ShinyHunters Attack Chain (Defender's View)

ShinyHunters — and overlapping clusters associated with scattered-spider-style social engineering — have repeatedly executed the following chain against SaaS and third-party application ecosystems (Salesforce, Snowflake, cloud storage, and downstream healthcare data processors have all featured in recent campaigns):

1. Initial Access — Identity, Not Exploit (MITRE T1078, T1566)

• Voice phishing (vishing) against help desks and employees to harvest SSO credentials and bypass MFA via push fatigue or SIM swap.
• Credential harvesting from infostealer logs purchased on criminal marketplaces — employee credentials for third-party SaaS portals that lack SSO enforcement.
• Abuse of OAuth tokens, service accounts, or API keys belonging to third-party integrated applications that are over-privileged and rarely audited.

2. Access via Trusted Third-Party Application (MITRE T1199 — Trusted Relationship)

• The compromised application or integration account inherits broad data access — often read access to entire customer or patient databases via API.
• Because the access path is a legitimate integration, traditional network controls and even many CASB policies do not flag it.

3. Bulk Data Exfiltration via API (MITRE T1530, T1567)

• Mass record retrieval using the application's own API or reporting/export functionality.
• Exfiltration to attacker-controlled cloud storage or via direct download over the sanctioned SaaS session — traffic that looks like normal application use.
• In prior ShinyHunters-attributed campaigns, tooling such as rclone and custom API scrapers running from cloud VPS infrastructure has been observed for staging and transfer.

4. Extortion (MITRE T1657 — Financial Theft / Extortion)

• Public claims, leak-site posts, and direct victim contact. Claims of record counts are frequently inflated — but in healthcare, even a fraction of 284 million records constitutes a reportable mega-breach under HIPAA and state breach notification laws.

Exploitation Status

• No CVE, no patch. This is active, ongoing criminal tradecraft against SaaS and third-party integrations.
• Confirmed active campaigns: ShinyHunters-attributed third-party/SaaS data theft campaigns have been continuously active through 2025 and into 2026, hitting retail, telecom, aviation, and now healthcare distribution.
• Assessment: Every organization with SaaS-integrated patient or customer data stores should treat itself as a target of this same playbook now, not after the McKesson forensics conclude.

Detection & Response

The detections below target the observable behaviors of this attack class: anomalous bulk data access via third-party/SaaS integrations, suspicious OAuth application activity, and endpoint exfiltration tooling. They are tuned to minimize noise — bulk exports by sanctioned analytics jobs are common in healthcare, so pair these with a baseline of approved service principals and export schedules.

Sigma Rules

---
title: Bulk Data Download from Cloud Storage or SaaS Export Endpoint
id: 3f8c1a52-7b94-4e61-b9d3-2a5f7c8e9146
status: experimental
description: Detects abnormally large download/export activity against cloud storage or SaaS data platforms consistent with mass record exfiltration via a compromised third-party integration, as seen in ShinyHunters-style campaigns.
references:
  - https://attack.mitre.org/techniques/T1567/
  - https://attack.mitre.org/techniques/T1530/
  - https://www.bleepingcomputer.com/news/security/mckesson-discloses-breach-after-shinyhunters-claims-patient-data-theft/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.exfiltration
  - attack.t1567.002
  - attack.t1530
logsource:
  category: proxy
  product: generic
detection:
  selection:
    cs-method: 'GET'
    sc-bytes|gt: 500000000
    cs-host|contains:
      - '.blob.core.windows.net'
      - '.s3.amazonaws.com'
      - 'storage.googleapis.com'
      - 'salesforce.com'
      - 'snowflakecomputing.com'
  filter_known_export_hosts:
    c-ip|contains:
      - '10.'
      - '192.168.'
  condition: selection and not filter_known_export_hosts
falsepositives:
  - Scheduled analytics or backup jobs performing large exports from approved IP space
level: high
---
title: Suspicious OAuth Application Consent or New Service Principal Grant
id: 91d4e7b3-2c6a-4f58-a1d9-8b3c5e7f2041
status: experimental
description: Detects new OAuth application consent grants or service principal creation with broad data scopes, a common persistence and access mechanism in third-party application compromise campaigns.
references:
  - https://attack.mitre.org/techniques/T1550/
  - https://attack.mitre.org/techniques/T1199/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.persistence
  - attack.t1199
  - attack.t1550.001
logsource:
  product: azure
  service: auditlogs
detection:
  selection:
    OperationName|contains:
      - 'Consent to application'
      - 'Add service principal'
      - 'Add app role assignment to service principal'
  selection_scope:
    TargetResources|contains:
      - 'Mail.Read'
      - 'Files.Read.All'
      - 'Sites.Read.All'
      - 'full_access_as_app'
      - 'Directory.Read.All'
  condition: selection and selection_scope
falsepositives:
  - Legitimate enterprise application onboarding — maintain an allowlist of approved app IDs
level: high
---
title: Rclone or Cloud Sync Exfiltration Tool Execution
id: 6b2a9f14-3d85-4c72-b7e1-5f9a2d8c6137
status: experimental
description: Detects execution of rclone and similar cloud-sync exfiltration tooling commonly used to stage and transfer bulk stolen data in extortion campaigns.
references:
  - https://attack.mitre.org/techniques/T1567.002/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.exfiltration
  - attack.t1567.002
logsource:
  category: process_creation
  product: windows
detection:
  selection_img:
    Image|endswith:
      - '\rclone.exe'
      - '\megacmd.exe'
      - '\aws.exe'
      - '\azcopy.exe'
  selection_cli:
    CommandLine|contains:
      - 'rclone copy'
      - 'rclone sync'
      - 'rclone move'
      - ' --config '
      - 's3 sync'
  filter_it:
    ParentImage|endswith:
      - '\SCCM\ccmexec.exe'
      - '\IntuneManagementExtension\'
  condition: (selection_img or selection_cli) and not filter_it
falsepositives:
  - IT-approved cloud backup or migration tooling — scope exclusions tightly
level: medium

KQL — Microsoft Sentinel / Defender Hunt Query

Use this to hunt for anomalous bulk data access by service principals and third-party application identities — the exact access pattern at the heart of the McKesson incident. Tune the threshold (5,000 sign-ins/records proxy) to your environment's baseline.

// Hunt: Anomalous third-party app / service principal bulk data access
// Covers identity (AAD), SaaS audit activity, and endpoint exfil staging
let lookback = 14d;
let baseline_window = 30d;
// Part 1: Service principals with spike in data-plane sign-in volume vs 30-day baseline
let baseline = AADServicePrincipalSignInLogs
| where TimeGenerated between (ago(baseline_window + lookback) .. ago(lookback))
| summarize BaselineAvg = count() / baseline_window by ServicePrincipalId, AppId;
AADServicePrincipalSignInLogs
| where TimeGenerated >= ago(lookback)
| summarize RecentCount = count(), IPs = make_set(IPAddress), Resources = make_set(ResourceDisplayName)
    by ServicePrincipalId, AppId, AppDisplayName, bin(TimeGenerated, 1d)
| join kind=leftouter baseline on ServicePrincipalId
| where RecentCount > (BaselineAvg * 5) and RecentCount > 1000
| project TimeGenerated, AppDisplayName, AppId, ServicePrincipalId, RecentCount, BaselineAvg, IPs, Resources
| order by RecentCount desc;
// Part 2: Endpoint staging of large archives or exfil tooling near DB/reporting hosts
DeviceFileEvents
| where TimeGenerated >= ago(lookback)
| where FileName has_any (".zip", ".7z", ".tar.gz", ".csv", ".sql", ".bak")
   or FileName has "rclone"
| where FolderPath has_any ("\\Temp\\", "\\Downloads\\", "\\Users\\Public\\")
| join kind=inner (DeviceNetworkEvents
   | where TimeGenerated >= ago(lookback)
   | where RemoteUrl has_any ("mega.nz", "transfer.sh", "file.io", "storage.googleapis.com", "s3.amazonaws.com"))
   on DeviceId, $left.Timestamp == $right.TimeGenerated
| project Timestamp, DeviceName, FileName, FolderPath, RemoteUrl, RemoteIP, InitiatingProcessAccountName
| order by Timestamp desc;

Velociraptor VQL — Endpoint Hunt

-- Hunt for bulk data staging archives and cloud exfil tool artifacts on endpoints
SELECT Pid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE CommandLine =~ '(?i)rclone|azcopy|aws s3|megacmd|curl.*-T|scp .*@(?!.*internal)'
   OR Name =~ '(?i)rclone|azcopy|megacmd'

-- Enumerate recently created large archives in staging locations
SELECT FullPath, Size, Mtime
FROM glob(globs=['C:/Users/*/Downloads/*.zip', 'C:/Users/*/Downloads/*.7z', 'C:/Windows/Temp/*.zip', 'C:/Users/Public/**/*.zip', 'C:/Users/Public/**/*.csv'])
WHERE Size > 100000000
   AND Mtime > now() - 1209600
ORDER BY Mtime DESC

Remediation & Verification Script

This PowerShell audits Entra ID (Azure AD) for third-party application consent grants and service principals with dangerous scopes — the control plane you need to review first if you suspect the same class of exposure McKesson is dealing with.

# Requires: Microsoft.Graph PowerShell SDK, signed in with Application.Read.All + Directory.Read.All
Connect-MgGraph -Scopes "Application.Read.All","Directory.Read.All","AuditLog.Read.All" -NoWelcome

# 1) Enumerate all OAuth2 permission grants with high-risk scopes
$highRiskScopes = @("Mail.Read","Files.Read.All","Sites.Read.All","Directory.Read.All","full_access_as_app","User.Read.All")
$grants = Get-MgOauth2PermissionGrant -All
$report = foreach ($g in $grants) {
    $matched = ($g.Scope -split ' ') | Where-Object { $highRiskScopes -contains $_ }
    if ($matched) {
        $sp = Get-MgServicePrincipal -ServicePrincipalId $g.ClientId -ErrorAction SilentlyContinue
        [PSCustomObject]@{
            AppDisplayName = $sp.DisplayName
            ClientId       = $g.ClientId
            ConsentType    = $g.ConsentType
            GrantedScopes  = ($matched -join ';')
        }
    }
}
$report | Export-Csv -Path ".\HighRisk_OAuth_Grants_$(Get-Date -Format yyyyMMdd).csv" -NoTypeInformation
$report | Format-Table -AutoSize

# 2) List recently created service principals (last 30 days) for review
$cutoff = (Get-Date).AddDays(-30)
Get-MgServicePrincipal -All | Where-Object {
    $_.AdditionalProperties.createdDateTime -and [datetime]$_.AdditionalProperties.createdDateTime -gt $cutoff
} | Select-Object DisplayName, AppId, Id, @{N='Created';E={$_.AdditionalProperties.createdDateTime}} | Format-Table -AutoSize

# 3) REMEDIATION EXAMPLE: Remove an unauthorized grant (uncomment after review)
# Remove-MgOauth2PermissionGrant -OAuth2PermissionGrantId "<grant-id-from-step-1>"

# 4) Verify CA policies block legacy auth (required to blunt credential-phish replay)
Get-MgIdentityConditionalAccessPolicy | ForEach-Object {
    if ($_.Conditions.ClientAppTypes -contains 'other' -or $_.Conditions.ClientAppTypes -contains 'exchangeActiveSync') {
        Write-Output "$($_.DisplayName) :: State=$($_.State)"
    }
}

Remediation & Hardening — What to Do This Week

There is no vendor patch for this attack class. Remediation is architectural and procedural:

1. Inventory every third-party application with access to PHI/PII data stores. For each integration, document the identity it uses, the scopes/permissions granted, the data it can reach, and the business owner. You cannot defend integrations you have not inventoried.
2. Right-size third-party permissions. Revoke any grant broader than the integration's documented function. Full-database read access for a reporting or scheduling app is a breach waiting for a phishing email.
3. Enforce phishing-resistant MFA (FIDO2/passkeys or certificate-based auth) on all SaaS administrative and data-access accounts — and extend it to help desk verification workflows, which ShinyHunters-style actors specifically target via vishing. Require identity proofing for any MFA reset or device enrollment request.
4. Alert on data egress volume per identity, per application. Establish baselines for normal API/export volume for each service principal and SaaS integration; alert on 3–5x deviations. McKesson-scale theft is never a single small query — it is a sustained bulk pull that a volume-based control catches.
5. Block unsanctioned exfil tooling and destinations at the endpoint (rclone, azcopy, megacmd via WDAC/AppLocker) and at the egress proxy (personal cloud storage, paste/file-drop domains) for any host that touches PHI systems.
6. Audit OAuth consent grants and disable user consent in Entra ID (set to admin-consent workflow only). Review all existing grants against an approved application allowlist — the script above produces exactly this list.
7. Contractual controls: Verify BAAs and third-party security requirements include MFA enforcement, breach notification SLAs (24–72 hours), and logging/audit rights. HIPAA's Security Rule and the proposed 2025 Security Rule updates push explicitly toward these controls — get ahead of it.
8. Prepare for extortion-specific IR. ShinyHunters operates on publicity pressure. Pre-stage your decision framework on ransom engagement, legal counsel, OCR/HHS notification obligations (60-day HIPAA clock for large breaches), and patient notification workflows before you need them.

If you are a McKesson downstream customer or a healthcare entity sharing data with pharmaceutical distribution platforms: assume your records may be in scope, monitor for breach notifications, and begin patient-communication planning in parallel with your technical review.

Related Resources

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