Ransomware Breaches at Five U.S. Healthcare Providers: Detection and Hardening Guide for Defenders

Five healthcare providers — Alta Orthopaedics in California, Cornerstone Behavioral Healthcare in Maine, Cameron Regional Medical Center in Missouri, and two additional organizations in Florida and Michigan — have confirmed data breaches stemming from encryption-based cyber incidents, according to reporting by The HIPAA Journal. While each notification differs in detail, the pattern is one we see repeatedly in our IR caseload: attackers gain a foothold, stage for days or weeks, exfiltrate PHI, and only then detonate encryption. By the time the ransom note appears, the data is already gone and the regulatory clock under HIPAA's Breach Notification Rule (45 CFR §§ 164.400–414) is already running.

For defenders, the operational takeaway is blunt: if your detection strategy begins at the encryption event, you have already lost the breach. Encryption is the final observable stage of an intrusion chain that typically spans initial access (phishing, exposed RDP, VPN appliance exploitation, or third-party/MSP compromise), credential theft, lateral movement, staging of exfiltration archives, and only then mass file encryption. This post breaks down that chain from a defensive standpoint, provides production-ready Sigma, KQL, and VQL detections tuned to the behaviors that precede and accompany encryption, and closes with a hardening and verification script your team can run today.

What We Know About the Incidents

The five providers span very different care settings — orthopedic specialty practice, behavioral health, and a regional medical center — which is itself instructive. Ransomware crews are not selectively targeting large hospital systems; small and mid-sized providers with thin IT staffing, legacy infrastructure, and valuable PHI are squarely in scope. Behavioral health records are particularly attractive to extortion groups because of the sensitivity of psychotherapy notes, which carry heightened protection under HIPAA and extraordinary reputational leverage in double-extortion schemes.

In incidents of this type, the common observable chain we reconstruct in forensics looks like this:

1. Initial access — phishing with credential capture, brute-forced or vendor-default remote access, or exploitation of an internet-facing appliance. In healthcare, we routinely find unmanaged remote access tools (ScreenConnect, AnyDesk, Atera, Splashtop) installed by the attacker or abused from a compromised MSP.
2. Discovery and credential theft — nltest, net group /domain, AD enumeration, and access to LSASS memory via rundll32 comsvcs.dll MiniDump or ProcDump.
3. Lateral movement and staging — SMB/ADMIN$ pushes of the encryptor, PsExec-style service creation, and staging of exfiltration archives (*.7z, *.rar) in temp directories.
4. Defense impairment — vssadmin delete shadows /all /quiet, bcdedit recovery tampering, and mass termination of backup, EDR, and database services.
5. Encryption and extortion — high-rate file rename/write operations, ransom notes (HOW_TO_DECRYPT.txt, README.txt variants) dropped across directories, and wallpaper changes on servers and workstations.

Each stage generates telemetry. The detections below target stages 4 and 5 (the last reliable interdiction points) plus the staging behaviors that precede them.

Technical Analysis: The Encryption Kill Chain in Healthcare Environments

No CVE has been publicly attributed to these incidents as of this writing, and we will not speculate on one. The majority of healthcare ransomware intrusions we respond to do not hinge on a novel vulnerability at all — they hinge on exposed remote access, missing MFA on remote portals, flat network segmentation between clinical and administrative VLANs, and backups that were either online (and got encrypted) or untested (and failed restoration).

The defenders' focus should therefore be on behavioral detection of the encryption precursor chain, which is platform-agnostic and survives whatever initial-access vector was used:

• Shadow copy deletion is executed by nearly every modern ransomware family minutes before encryption. On a healthy clinical workstation or file server, vssadmin delete shadows is an extraordinarily rare event.
• Mass file modification with high-entropy writes and rapid renames is detectable at the endpoint and, on file servers, at the SMB layer. A single process touching hundreds of files per minute with rename operations is a near-deterministic ransomware signal.
• Ransom note creation — the same note filename written into dozens of directories in seconds — is a clean, low-noise indicator.
• Service control tampering (bcdedit /set {default} recoveryenabled no, wbadmin delete catalog) almost never has a legitimate administrative basis on endpoints.

Detection & Response

Sigma Rules

The following rules target the highest-fidelity, lowest-noise behaviors in the encryption chain. Tune the false-positive sections to your environment's backup software before deploying broadly.

---
title: Shadow Copy Deletion via vssadmin or wmic - Ransomware Precursor
id: 8f3a1c92-4d67-4e5b-9c12-2a6b8d3e4f01
status: experimental
description: Detects deletion of volume shadow copies, a near-universal precursor to ransomware encryption observed in healthcare breach intrusions. Rarely legitimate outside of controlled storage administration.
references:
  - https://attack.mitre.org/techniques/T1490/
  - https://www.hipaajournal.com/ransomware-healthcare-providers-ca-ma-mo-fl-mi/
author: Security Arsenal
date: 2026/02/14
tags:
  - attack.impact
  - attack.t1490
logsource:
  category: process_creation
  product: windows
detection:
  selection_img:
    Image|endswith:
      - '\vssadmin.exe'
      - '\wmic.exe'
      - '\powershell.exe'
  selection_cmd:
    CommandLine|contains:
      - 'delete shadows'
      - 'shadowcopy delete'
      - 'shadows delete'
      - 'Delete-WmiObject'
      - 'Win32_ShadowCopy'
  condition: selection_img and selection_cmd
falsepositives:
  - Controlled storage reclamation by backup administrators (rare; restrict to known admin accounts/hosts)
level: high
---
title: Boot Configuration Recovery Tampering via bcdedit
id: 3c7d2e41-8a9b-4f56-a1d3-5e9c7b2a8f44
status: experimental
description: Detects modification of boot configuration data to disable recovery mode, a standard ransomware technique to prevent victims from restoring via Windows Recovery Environment.
references:
  - https://attack.mitre.org/techniques/T1490/
author: Security Arsenal
date: 2026/02/14
tags:
  - attack.impact
  - attack.t1490
  - attack.defense_evasion
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    Image|endswith: '\bcdedit.exe'
    CommandLine|contains:
      - 'recoveryenabled no'
      - 'bootstatuspolicy ignoreallfailures'
falsepositives:
  - Golden image preparation; some OEM provisioning scripts
level: high
---
title: Mass Ransom Note File Creation in Multiple Directories
id: 61b9f3d2-7c4a-4e88-b5d6-9f2a4c1e7d33
status: experimental
description: Detects creation of common ransom note filenames in user and server directories. Correlate with the mass rename KQL query for high-confidence alerting.
references:
  - https://attack.mitre.org/techniques/T1486/
author: Security Arsenal
date: 2026/02/14
tags:
  - attack.impact
  - attack.t1486
logsource:
  category: file_event
  product: windows
detection:
  selection:
    TargetFilename|contains:
      - 'HOW_TO_DECRYPT'
      - 'RECOVER_FILES'
      - 'RESTORE_YOUR_FILES'
      - 'DECRYPT_INSTRUCTION'
      - 'README_FOR_DECRYPT'
      - '!!!_READ_ME_!!!'
  filter_backup_sw:
    Image|endswith:
      - '\veeam.agent.exe'
      - '\BackupExec.exe'
  condition: selection and not filter_backup_sw
falsepositives:
  - Legitimate README files (mitigated by requiring ransom-specific naming patterns)
level: critical

KQL — Microsoft Sentinel / Defender

This query hunts for mass file-rename behavior consistent with an active encryption event. It buckets file rename operations by device and process over 5-minute windows and surfaces outliers. Set your baseline threshold to your environment — clinical imaging (PACS) systems and EHR file shares can legitimately produce bursts, so start with a threshold of 200 renames per device per 5 minutes and tune down on quiet servers.

let RenameThreshold = 200;
DeviceFileEvents
| where TimeGenerated > ago(24h)
| where ActionType in ("FileRenamed", "FileModified")
| where InitiatingProcessFileName !in~ ("msmpeng.exe", "svchost.exe", "TiWorker.exe", "Veeam.Backup.Service.exe")
| summarize RenameCount = count(),
            DistinctExtensions = dcount(split(FileName, ".")[-1]),
            DistinctFolders = dcount(FolderPath),
            SampleFiles = make_set(strcat(FolderPath, "\\", FileName), 5)
    by DeviceName, InitiatingProcessFileName, InitiatingProcessAccountName, bin(TimeGenerated, 5m)
| where RenameCount >= RenameThreshold and DistinctFolders > 20
| project TimeGenerated, DeviceName, InitiatingProcessFileName, InitiatingProcessAccountName, RenameCount, DistinctFolders, SampleFiles
| order by RenameCount desc

Companion query — hunt for shadow copy deletion and recovery tampering process execution across the fleet over the last 7 days:

DeviceProcessEvents
| where TimeGenerated > ago(7d)
| where (FileName =~ "vssadmin.exe" and ProcessCommandLine has "delete shadows")
   or (FileName =~ "wmic.exe" and ProcessCommandLine has "shadowcopy delete")
   or (FileName =~ "bcdedit.exe" and ProcessCommandLine has_any ("recoveryenabled no", "ignoreallfailures"))
   or (FileName =~ "wbadmin.exe" and ProcessCommandLine has "delete catalog")
| project TimeGenerated, DeviceName, FileName, ProcessCommandLine, AccountName, InitiatingProcessFileName, InitiatingProcessCommandLine
| order by TimeGenerated desc

Velociraptor VQL

This artifact hunts for two artifacts simultaneously: processes with ransomware-precursor command lines currently running, and ransom note files staged across user and server file systems. Deploy it as a fleet hunt with a 48-hour recency filter.

-- Hunt: Ransomware precursor processes and ransom note artifacts
-- Scope: fleet-wide, lookback 48h

LET notes = SELECT FullPath, Size, Mtime
FROM glob(globs=[
  'C:/Users/*/Desktop/*DECRYPT*.txt',
  'C:/Users/*/Documents/*DECRYPT*.txt',
  'C:/**/HOW_TO_DECRYPT*.txt',
  'D:/**/README_FOR_DECRYPT*',
  'E:/**/RECOVER_FILES*'
], accessor='ntfs')
WHERE Mtime > now() - 172800

LET procs = SELECT Pid, Name, CommandLine, Exe, Username
FROM pslist()
WHERE CommandLine =~ 'delete shadows|shadowcopy delete|recoveryenabled no|ignoreallfailures|delete catalog'

SELECT * FROM notes
UNION ALL
SELECT FullPath=NULL, Size=NULL, Mtime=NULL, Pid=Pid, Name=Name, CommandLine=CommandLine, Exe=Exe, Username=Username FROM procs

Hardening and Verification Script

Run this PowerShell audit on your file servers, EHR-adjacent application servers, and a sample of clinical workstations. It verifies the controls that most directly determine whether a ransomware intrusion becomes a breach notification or a contained event: shadow copy protection, recovery configuration, backup service health, SMBv1, and remote access surface.

# Security Arsenal - Ransomware Resilience Audit (Healthcare)
# Run elevated. Review output before making changes; this script is audit-first.

Write-Host "=== [1] Volume Shadow Copy Status ===" -ForegroundColor Cyan
vssadmin list shadows 2>$null | Select-String -Pattern "Shadow Copy Volume" | Measure-Object | ForEach-Object { "Existing shadow copies: $($_.Count)" }
Get-ScheduledTask | Where-Object { $_.TaskName -like "*ShadowCopy*" } | Select-Object TaskName, State

Write-Host "`n=== [2] Recovery Configuration (should NOT be disabled) ===" -ForegroundColor Cyan
$bcd = bcdedit /enum {current} | Out-String
if ($bcd -match "recoveryenabled\s+No") { Write-Host "[ALERT] Recovery is DISABLED - ransomware-style tampering or misconfiguration" -ForegroundColor Red } else { Write-Host "[OK] Recovery enabled" -ForegroundColor Green }

Write-Host "`n=== [3] SMBv1 Status (must be disabled) ===" -ForegroundColor Cyan
$smb1 = Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol -ErrorAction SilentlyContinue
if ($smb1.State -eq "Enabled") { Write-Host "[ALERT] SMBv1 enabled - disable: Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol" -ForegroundColor Red } else { Write-Host "[OK] SMBv1 disabled" -ForegroundColor Green }

Write-Host "`n=== [4] Backup Service Health ===" -ForegroundColor Cyan
Get-Service | Where-Object { $_.DisplayName -match "Veeam|Backup|Commvault|Rubrik|Cohesity|Datto" } | Select-Object Name, Status, StartType | Format-Table -AutoSize
$wbadmin = wbadmin get versions 2>$null
if ($LASTEXITCODE -ne 0) { Write-Host "[WARN] No Windows Server Backup versions found - verify third-party backup independently" -ForegroundColor Yellow }

Write-Host "`n=== [5] RDP Exposure ===" -ForegroundColor Cyan
$rdp = Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server' -Name fDenyTSConnections
if ($rdp.fDenyTSConnections -eq 0) { Write-Host "[REVIEW] RDP enabled - confirm NLA enforced, firewall-restricted, and MFA-brokered" -ForegroundColor Yellow }

Write-Host "`n=== [6] Shadow Copy Tampering - Recent vssadmin deletions (Sysmon/Sec events) ===" -ForegroundColor Cyan
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4688; StartTime=(Get-Date).AddDays(-7)} -ErrorAction SilentlyContinue |
  Where-Object { $_.Message -match 'vssadmin.*delete shadows|wmic.*shadowcopy delete|bcdedit.*recoveryenabled' } |
  Select-Object TimeCreated, Message -First 10 | Format-List

Write-Host "`nAudit complete. Investigate any [ALERT] items immediately." -ForegroundColor Cyan

Remediation and Defensive Priorities

There is no patch for these incidents — the remediation is architectural and operational. Prioritize in this order:

1. Immutable, offline, and tested backups. Ensure at least one backup tier is offline or immutability-locked (object lock / WORM) so the encryptor cannot reach it. Then — and this is where most healthcare organizations fail — perform a timed restoration test of your EHR database and file shares quarterly. HIPAA's Security Rule contingency plan requirement (45 CFR § 164.308(a)(7)) is not satisfied by a backup job that reports green; it is satisfied by proven recoverability.
2. MFA on every remote access path. VPN, RDP gateways, remote monitoring and management (RMM) tooling, and third-party vendor access. In nearly every healthcare IR engagement we run, the access vector was an unauthenticated or password-only remote path.
3. Constrain lateral movement. Segment clinical VLANs from administrative and guest networks; restrict SMB/RPC between workstation subnets; disable SMBv1 everywhere; deploy LAPS so a single stolen local admin hash does not unlock the fleet.
4. Alert on the precursor chain. Deploy the Sigma, KQL, and VQL detections above. Shadow copy deletion on a file server should page a human, day or night — that alert has minutes of value, not hours.
5. Exfiltration visibility. In double-extortion breaches, the encryption is survivable; the exfiltration is the breach. Egress filtering, TLS inspection where lawful, and alerting on large outbound transfers to unfamiliar cloud storage or VPS destinations materially change your breach-notification exposure.
6. Breach notification readiness. If PHI of 500+ individuals is implicated, HHS OCR notification within 60 days and media notification are mandatory; state attorneys general (California, Maine, and Missouri all have their own timelines) add parallel obligations. Pre-stage your IR retainer, outside counsel, and forensics workflow before you need them — the organizations in this news item are executing that plan right now.

If your organization runs any of the affected care settings — specialty orthopedics, behavioral health, or regional hospital infrastructure — assume you are in-scope for the same threat activity and treat this as a detection-validation exercise this week, not a policy review next quarter.

Related Resources

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