EHR Vendor Breach Exposes Patient Data at New York Counseling Practices — Third-Party Risk Detection and Response Guide

Hispanic Counseling Center and Brooklyn Counseling Services, two behavioral health practices in New York, have begun notifying patients that their personal and health information was compromised — not because of a failure in their own networks, but because of a security incident at their electronic health record (EHR) vendor. This is the pattern that should keep every healthcare CISO awake in 2026: the covered entity did everything "right" on paper, outsourced clinical records to a business associate, and is now the one mailing breach letters, fielding patient calls, and potentially facing OCR scrutiny.

Behavioral health data is among the most sensitive categories of PHI. Psychotherapy notes, substance use treatment records (potentially covered under 42 CFR Part 2), diagnoses, and demographic data command premium value on criminal markets and carry devastating blackmail and social-engineering potential. When an EHR vendor is compromised, the blast radius isn't one practice — it's every practice on that platform, and every patient those practices serve.

If your organization relies on a hosted EHR, practice management platform, or medical billing vendor, this incident is your tabletop exercise made real. This post breaks down the defensive lessons, provides concrete detection content for identifying mass PHI access and exfiltration behaviors, and lays out the remediation and contractual controls that actually reduce third-party risk.

Technical Analysis: The Anatomy of an EHR Vendor Breach

While the specific vendor's root cause details remain limited in public reporting, incidents of this class overwhelmingly follow a small set of well-understood patterns. Understanding them matters because your detection strategy should map to the technique, not the headline.

Common Attack Chains Against Hosted EHR/Practice Management Platforms

1. Credential compromise against vendor-facing portals or SaaS tenants. Phishing, credential stuffing, or infostealer-harvested credentials used to authenticate to the EHR's web portal or administrative console. MFA gaps on service accounts or legacy authentication endpoints are the usual entry point.
2. Exploitation of internet-facing application vulnerabilities in the EHR platform's web tier, patient portal, or API endpoints — frequently leading to SQL injection or direct object access against patient records (MITRE ATT&CK T1190 – Exploit Public-Facing Application).
3. Abuse of vendor support/remote access tooling. RMM tools and vendor support accounts are high-value pivot points with broad, often unaudited access to hosted data.
4. Bulk data export via legitimate functionality. Once inside, attackers rarely need exotic tooling — the EHR's own reporting, export, or API features (bulk patient list exports, CSV/PDF report generation, FHIR bulk data endpoints) provide the exfiltration channel. This is T1530 – Data from Cloud Storage, executed through sanctioned application logic.

Why This Is Hard to Detect

The dirty secret of hosted EHR breaches: the covered entity often has zero telemetry until the vendor notifies them. The data lives in the vendor's environment, access logs are the vendor's property, and the first "detection" is frequently a call from the vendor's counsel or a notification from HHS OCR's breach portal. That's precisely why your compensating controls must focus on (a) contractual telemetry rights, and (b) detecting the downstream symptoms — mass access events, anomalous export volumes, and patient-reported misuse — from whatever data you can collect.

Exploitation Status

No CVE has been publicly associated with this incident, and no CISA KEV entry applies. Treat this as a confirmed third-party breach event with active patient notification obligations under HIPAA (45 CFR §§ 164.400–414) and New York State breach notification law. The 60-day HIPAA notification clock runs from the date the covered entity knew or should have known of the breach — which is typically the vendor's notification date to the practice, not the date of the intrusion.

Detection & Response

Even though the compromise occurred in a vendor's environment, your SOC should be hunting for the behavioral signatures of PHI mass-access and exfiltration across your own clinical systems, endpoints, and cloud tenants — because the same techniques apply if your organization is targeted directly, and because many EHR deployments are hybrid (local caches, integrated workstations, on-prem databases syncing to hosted platforms).

Sigma Rules

The following rules target two of the most reliable high-signal behaviors in EHR/PHI theft scenarios: mass access to clinical data repositories on endpoints/servers, and bulk export/staging activity using built-in tooling. Tune paths to your environment's actual EHR client and data directories.

---
title: Mass File Access to Clinical or PHI Data Directories
id: 3f8a2b41-9c6e-4d7a-b2f1-8e5c0d9a3b47
status: experimental
description: Detects a single process accessing an abnormally high number of files in directories associated with EHR databases, document imaging stores, or PHI repositories, consistent with bulk collection during a breach.
references:
  - https://attack.mitre.org/techniques/T1530/
  - https://attack.mitre.org/techniques/T1219/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.collection
  - attack.t1005
  - attack.t1530
logsource:
  category: file_event
  product: windows
detection:
  selection_paths:
    TargetFilename|contains:
      - '\EHR\'
      - '\PatientData\'
      - '\ClinicalDocs\'
      - '\DocumentImaging\'
      - '\MSSQL\DATA\'
      - '\Backup\'
  filter_legit:
    Image|endswith:
      - '\sqlservr.exe'
      - '\MsMpEng.exe'
      - '\backupexec.exe'
      - '\veeam.backup.service.exe'
  condition: selection_paths and not filter_legit
falsepositives:
  - EHR client applications and database engines performing normal operations
  - Approved backup and antivirus agents (extend filter with environment-specific agents)
level: medium
---
title: Bulk Data Staging via Archive Utilities on Clinical Workstations
id: 9d1c4e76-2a8b-4f35-9c07-6b3e8d2a1f59
status: experimental
description: Detects invocation of archive utilities (rar, 7z, winzip) with command lines referencing clinical, patient, or export directories — a common staging step before exfiltration of EHR data.
references:
  - https://attack.mitre.org/techniques/T1560/001/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.collection
  - attack.t1560.001
  - attack.exfiltration
logsource:
  category: process_creation
  product: windows
detection:
  selection_tool:
    Image|endswith:
      - '\rar.exe'
      - '\7z.exe'
      - '\7za.exe'
      - '\winzip64.exe'
      - '\tar.exe'
  selection_target:
    CommandLine|contains:
      - 'patient'
      - 'ehr'
      - 'emr'
      - 'clinical'
      - 'export'
      - 'backup'
  condition: selection_tool and selection_target
falsepositives:
  - IT administrators packaging EHR exports for vendor support tickets
  - Scheduled archival jobs (suppress by scheduled task account and parent process)
level: high

KQL — Microsoft Sentinel / Defender Hunt

This query hunts for anomalous process execution on servers and workstations hosting EHR clients or PHI shares — specifically looking for scripting and archive tooling launched outside of approved maintenance contexts, plus unusual network egress volumes from those same devices. Run it as a scheduled analytics rule scoped to your clinical asset group.

// Hunt: suspicious tooling on clinical/EHR-hosting devices followed by elevated egress
let ClinicalDevices = dynamic(["EHR-APP", "EHR-DB", "MEDREC"]);
let WindowStart = ago(14d);
let SuspiciousProcs = DeviceProcessEvents
| where Timestamp > WindowStart
| where DeviceName has_any (ClinicalDevices)
| where FileName in~ ("rar.exe","7z.exe","7za.exe","tar.exe","powershell.exe","cmd.exe","wscript.exe","cscript.exe","curl.exe","certutil.exe","bitsadmin.exe","rclone.exe","megacmd.exe")
| where ProcessCommandLine has_any ("patient","ehr","emr","clinical","export","backup",".sql",".bak",".csv")
| project DeviceName, ProcTime=Timestamp, FileName, ProcessCommandLine, InitiatingProcessAccountName;
let EgressSpikes = DeviceNetworkEvents
| where Timestamp > WindowStart
| where DeviceName has_any (ClinicalDevices)
| where RemoteUrl !has_any ("microsoft.com","windowsupdate.com","digicert.com") // baseline allowlist — extend with your EHR vendor domains
| summarize Connections=count(), DistinctRemoteIPs=dcount(RemoteIP) by DeviceName, bin(Timestamp, 1h)
| where Connections > 500 or DistinctRemoteIPs > 50; // tune to baseline
SuspiciousProcs
| join kind=inner (EgressSpikes) on DeviceName
| project DeviceName, ProcTime, FileName, ProcessCommandLine, InitiatingProcessAccountName, Connections, DistinctRemoteIPs
| order by ProcTime desc;

For environments ingesting EHR or SaaS audit logs into Sentinel (via CEF/Syslog or API connectors), hunt for bulk record access patterns — this is the single highest-fidelity indicator of an in-progress vendor-side breach that you can sometimes catch yourself:

// Hunt: single identity accessing abnormally high volume of distinct patient records
// Assumes EHR/SaaS audit logs ingested via Syslog or a custom table (adjust table/fields to your connector)
Syslog
| where TimeGenerated > ago(7d)
| where SyslogMessage has_any ("record.view","patient.read","chart.open","export","report.generate")
| extend UserId = extract(@"user[=:]([\w@\.\-]+)", 1, SyslogMessage),
         RecordId = extract(@"(?:patient|record|chart)[Ii][Dd][=:](\w+)", 1, SyslogMessage)
| where isnotempty(UserId) and isnotempty(RecordId)
| summarize DistinctRecords=dcount(RecordId), Events=count() by UserId, bin(TimeGenerated, 1h)
| where DistinctRecords > 200 // tune against clinical workflow baselines (providers vs. billing vs. HIM staff)
| order by DistinctRecords desc;

Velociraptor VQL — Endpoint Hunt

Deploy this as a hunt across clinical workstations and any on-prem servers that cache or integrate with the hosted EHR. It looks for recently created archive files in user-writable and staging locations alongside evidence of bulk data tooling execution (prefetch/execution artifacts are covered by the process hunt above; this targets the artifacts themselves).

-- Hunt for recently created archives and data dumps in staging locations on clinical endpoints
SELECT FullPath, Size, Mtime, Btime
FROM glob(globs=[
  'C:/Users/*/Downloads/*.zip',
  'C:/Users/*/Downloads/*.rar',
  'C:/Users/*/Downloads/*.7z',
  'C:/Users/*/Desktop/*.zip',
  'C:/Users/*/AppData/Local/Temp/*.zip',
  'C:/Users/*/AppData/Local/Temp/*.rar',
  'C:/ProgramData/*.zip',
  'C:/ProgramData/*.7z',
  'C:/**/*.csv'
])
WHERE Mtime > now() - 1209600  -- last 14 days
  AND (FullPath =~ '(?i)patient|ehr|emr|clinical|export|backup|dump|extract'
       OR Size > 10485760)  -- archives larger than 10MB in staging paths
ORDER BY Mtime DESC

Remediation and Hardening Script

There is no patch for a vendor breach — but there is hardening work on your side of the trust boundary. The following PowerShell script audits the controls that matter most when a business associate holds your PHI: it verifies MFA enforcement across Microsoft 365/Entra ID (the identity plane most practices use to access hosted EHR portals), enumerates privileged accounts and third-party app consent grants that could be abused, and confirms advanced audit logging is enabled so you actually have telemetry when you need it.

#Requires -Modules Microsoft.Graph.Authentication, Microsoft.Graph.Identity.SignIns, Microsoft.Graph.Applications
# EHR Third-Party Risk Hardening Audit — run as Global Reader or higher
# Purpose: verify MFA enforcement, inventory risky app consents, confirm audit logging

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

$report = @{}

# 1. Verify MFA coverage via Conditional Access policies
$caPolicies = Get-MgIdentityConditionalAccessPolicy -All
$mfaPolicies = $caPolicies | Where-Object {
    $_.State -eq 'enabled' -and
    $_.GrantControls.BuiltInControls -contains 'mfa'
}
$report['MFA_ConditionalAccess_Policies_Enabled'] = $mfaPolicies.Count
$report['MFA_Policy_Names'] = ($mfaPolicies | Select-Object -ExpandProperty DisplayName) -join '; '

if ($mfaPolicies.Count -eq 0) {
    Write-Warning "NO enabled Conditional Access policies enforce MFA. Remediate immediately — this is the #1 control against credential-based access to hosted EHR portals."
}

# 2. Inventory third-party OAuth app consents (shadow integrations with clinical data access)
$servicePrincipals = Get-MgServicePrincipal -All
$thirdParty = $servicePrincipals | Where-Object { $_.AppOwnerOrganizationId -ne (Get-MgOrganization).Id }
$report['ThirdParty_App_Count'] = $thirdParty.Count
$thirdParty | Select-Object DisplayName, AppId, CreatedDateTime |
    Export-Csv -Path ".\ThirdPartyApps_Audit.csv" -NoTypeInformation
Write-Host "Third-party app inventory exported to .\ThirdPartyApps_Audit.csv — review each for business justification."

# 3. Confirm unified audit logging is enabled (required for post-incident forensics)
# Note: Graph does not expose audit config directly; verify via Exchange Online
# Connect-ExchangeOnline - then:
#   Get-AdminAuditLogConfig | Select UnifiedAuditLogIngestionEnabled
Write-Host "ACTION REQUIRED: Run 'Get-AdminAuditLogConfig' in Exchange Online PowerShell and confirm UnifiedAuditLogIngestionEnabled = True" -ForegroundColor Yellow

# 4. Flag privileged accounts for manual MFA verification
$privilegedRoles = Get-MgDirectoryRole | Where-Object { $_.DisplayName -match 'Global Administrator|Privileged' }
foreach ($role in $privilegedRoles) {
    $members = Get-MgDirectoryRoleMember -DirectoryRoleId $role.Id
    Write-Host "Role: $($role.DisplayName) — $($members.Count) member(s). Verify MFA registration via Get-MgReportAuthenticationMethodUserRegistrationDetail." -ForegroundColor Cyan
}

$report.GetEnumerator() | Format-Table -AutoSize

Remediation: What Covered Entities Must Do Now

If your organization is affected by this incident — or uses any hosted EHR — execute the following in order:

Immediate (0–72 hours)

1. Obtain the vendor's incident details in writing. Your Business Associate Agreement (BAA) obligates the vendor to report breaches. Demand: attack vector, data elements exposed per patient, timeline of compromise vs. detection, and what forensic evidence supports the stated scope. Do not accept "we're still investigating" as a final answer.
2. Start the HIPAA Breach Notification Rule clock analysis. Notifications to affected individuals are required without unreasonable delay and no later than 60 calendar days from discovery. Breaches affecting 500+ individuals require contemporaneous notification to HHS OCR and prominent media outlets; New York also requires notice to the Attorney General, Department of State, and State Police under the SHIELD Act/Information Security Breach and Notification Act.
3. Preserve your own evidence. Export and retain every log you control: EHR portal authentication logs, practice-side access logs, email records of vendor communications, and the vendor's incident report. If litigation or an OCR investigation follows, your documentation of diligence is your defense.
4. Force-rotate credentials for every account that touches the vendor platform — staff portal logins, API keys, interface engine credentials, and any SSO federation service accounts. Assume vendor-side session tokens are compromised.

Short Term (1–4 weeks)

5. Contract for telemetry. Amend or renegotiate the BAA/vendor agreement to require: (a) breach notification within 24–72 hours of vendor discovery (far tighter than HIPAA's 60-day outer bound), (b) annual SOC 2 Type II and/or HITRUST reports, (c) access to audit logs for your tenant's record access, and (d) incident response cooperation obligations.
6. Implement patient-record access monitoring wherever technically available. Many EHRs expose per-user chart access audit trails — ingest them into your SIEM and baseline normal access volumes per role (the KQL queries above are a starting point).
7. Patient-facing response readiness. Prepare call-center scripts, credit monitoring offers where SSNs were exposed, and specific guidance given the behavioral health context — victims of mental health record theft face elevated targeted-scam risk.

Strategic (Quarter)

8. Build a real third-party risk program. Inventory every business associate with PHI access, tier them by data volume and sensitivity, and assess annually against NIST CSF 2.0's Supply Chain Risk Management category and HIPAA Security Rule § 164.308(b). CIS Control 15 (Service Provider Management) is your implementation roadmap.
9. Data minimization. Question why full historical records live in systems that don't need them. Every field you don't share with a vendor is a field that can't be breached.
10. Tabletop this exact scenario. Your IR plan must have a documented play for "vendor calls us with a breach." Most don't. Run the exercise with legal, compliance, and clinical leadership in the room.

The uncomfortable truth of this incident is that Hispanic Counseling Center and Brooklyn Counseling Services likely could not have prevented the vendor's compromise. What they can control — and what you can control today — is detection speed, contractual leverage, notification readiness, and the breadth of data exposed when the next vendor falls. Build those controls now, because in healthcare, the question is never whether a business associate will be breached. It's whether you'll find out from them, or from OCR.

Related Resources

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