AMCA Breach Settlement: $6.4M Third-Party Healthcare Vendor Compromise — Detection and Defense Guide

A settlement has been agreed to partially resolve litigation stemming from the cyberattack on American Medical Collection Agency (AMCA), the Elmsford, New York-based billing and collections vendor whose compromise became one of the most consequential third-party healthcare breaches in history. The $6.4 million settlement is a legal milestone — but for defenders, the operational lessons are far from settled.

For context: between August 2018 and March 2019, an unauthorized actor maintained access to AMCA's web-based payment portal, harvesting personal, medical, and financial data belonging to patients of some of the largest clinical laboratories in the United States — including Quest Diagnostics, LabCorp, BioReference Laboratories, and Opko Health. The breach ultimately affected more than 20 million individuals across dozens of covered entities, exposed Social Security numbers, payment card data, dates of birth, and medical information, and drove AMCA into Chapter 11 bankruptcy within months of disclosure.

This was not a sophisticated zero-day campaign. It was a long-dwell-time compromise of an internet-facing payment application at a vendor that sat deep inside the healthcare data supply chain — trusted by covered entities, but operating outside their security monitoring perimeter. The settlement numbers tell you what the breach cost in court. What follows is what it should cost you in attention: how this class of attack works, how to detect it in your own environment and your vendors' environments, and how to harden against it before your organization becomes the next plaintiff exhibit.

Technical Analysis

What Was Compromised

AMCA operated a web-facing payment portal that processed patient billing and collections on behalf of its healthcare clients. The attacker gained unauthorized access to this system and maintained persistence for roughly eight months (August 1, 2018 – March 30, 2019). Data exposed varied by covered entity but included:

• Full names, dates of birth, and addresses
• Social Security numbers (for subsets of affected patients)
• Payment card numbers and banking information
• Medical information, including lab test details, provider names, and dates of service
• Health insurance information

Attack Chain (Defender's View)

While public disclosures never attributed a specific CVE to the intrusion — and we will not speculate on one — the observable anatomy of the AMCA compromise follows a pattern we have responded to repeatedly in healthcare payment environments:

1. Initial access via the web tier. The target was an internet-facing payment application. In incidents of this profile, initial access typically arrives through an unpatched web framework, weak or stolen application credentials, or injection against a poorly validated input field. The web tier is the blast radius entry point.
2. Persistence through web-tier tooling. Attackers who land on a web server and stay for eight months almost always establish durable access — web shells dropped into the document root, rogue scheduled tasks, or legitimate admin credentials harvested from application configuration files (connection strings are a goldmine).
3. Lateral movement to the data tier. The payment portal's database connection gave the attacker a trusted path to the patient and payment data store. Application-tier credentials typically carry far more privilege than the application actually needs — a design failure we see in the majority of healthcare billing environments we assess.
4. Low-and-slow collection and exfiltration. Eight months of dwell time indicates the actor avoided bulk, bandwidth-spiking exfiltration. Query-level collection and staged outbound transfers blended with normal application traffic — precisely the traffic pattern most covered entities do not baseline at their vendors.

The Structural Failure: Vendor Trust Without Telemetry

The critical lesson of AMCA is not a specific vulnerability. It is that dozens of HIPAA-covered entities funneled PHI into a vendor whose security posture they could not observe. Business Associate Agreements existed. Contracts existed. But contractual language is not a compensating control — it is a legal remedy after the fact, as this $6.4 million settlement demonstrates. Nobody's patients were protected by the settlement; they were merely compensated, partially, years later.

No CVE identifier is associated with the public record of this breach, and the exploitation is historical rather than actively ongoing. The present-day relevance is that the same architectural pattern — internet-facing payment portal, over-privileged database connectivity, no egress monitoring, no file integrity monitoring on the web root — remains endemic in healthcare billing and collections vendors in 2026.

Detection & Response

The detections below target the behavioral pattern of the AMCA intrusion class: web-tier compromise leading to database-tier collection. They are tuned to fire on the specific parent-child process relationships and data access behaviors that indicate a payment application has been turned against its own database — not on generic noise.

SIGMA Rules

---
title: Web Server Worker Process Spawning Command Shell
tid: 2f8c1a44-7b3e-4d19-a6c2-9e1f5b8d4037
status: experimental
description: Detects web server worker processes (IIS w3wp.exe or Linux httpd/nginx/php-fpm) spawning command shells or scripting interpreters, a hallmark of web shell activity following compromise of an internet-facing payment or portal application, as seen in the AMCA breach pattern.
references:
  - https://attack.mitre.org/techniques/T1505/003/
  - https://www.hipaajournal.com/amca-customer-data-breach-litigation-settlement/
author: Security Arsenal
date: 2026/02/17
tags:
  - attack.persistence
  - attack.t1505.003
  - attack.execution
logsource:
  category: process_creation
  product: windows
detection:
  selection_parent:
    ParentImage|endswith:
      - '\w3wp.exe'
      - '\httpd.exe'
  selection_child:
    Image|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
      - '\pwsh.exe'
      - '\wscript.exe'
      - '\cscript.exe'
      - '\mshta.exe'
      - '\rundll32.exe'
  condition: selection_parent and selection_child
falsepositives:
  - Rare legitimate application frameworks that invoke scripting for report generation; baseline per application pool identity
level: high
---
title: Database Export Utility Execution From Web or Non-Admin Context
tid: 6a1d9e52-3c84-4f27-b915-4d7e2c9a6180
status: experimental
description: Detects execution of database dump/export utilities (sqlcmd, bcp, mysqldump, pg_dump) by service accounts, web application pool identities, or from web server contexts, indicating potential bulk extraction of patient or payment data consistent with the AMCA intrusion pattern.
references:
  - https://attack.mitre.org/techniques/T1530/
  - https://www.hipaajournal.com/amca-customer-data-breach-litigation-settlement/
author: Security Arsenal
date: 2026/02/17
tags:
  - attack.collection
  - attack.t1530
  - attack.exfiltration
logsource:
  category: process_creation
  product: windows
detection:
  selection_tool:
    Image|endswith:
      - '\sqlcmd.exe'
      - '\bcp.exe'
      - '\mysqldump.exe'
      - '\pg_dump.exe'
      - '\osql.exe'
  selection_user:
    User|contains:
      - 'IIS APPPOOL'
      - 'NETWORK SERVICE'
      - 'LOCAL SERVICE'
  condition: selection_tool and selection_user
falsepositives:
  - Scheduled maintenance tasks running under service accounts; exclude known backup job accounts by name
level: high
---
title: Script File Created in Web Document Root
tid: 9b4e7d31-8f52-4a6c-c327-1e8a4d2f7956
status: experimental
description: Detects creation of executable script files (aspx, asp, php, jsp) within web server document roots, a primary indicator of web shell deployment following compromise of an internet-facing portal such as the AMCA payment system.
references:
  - https://attack.mitre.org/techniques/T1505/003/
  - https://www.hipaajournal.com/amca-customer-data-breach-litigation-settlement/
author: Security Arsenal
date: 2026/02/17
tags:
  - attack.persistence
  - attack.t1505.003
logsource:
  category: file_event
  product: windows
detection:
  selection_path:
    TargetFilename|contains:
      - '\inetpub\wwwroot\'
      - '\inetpub\custerr\'
      - '\www\'
  selection_ext:
    TargetFilename|endswith:
      - '.aspx'
      - '.asp'
      - '.ashx'
      - '.php'
      - '.jsp'
  condition: selection_path and selection_ext
falsepositives:
  - Legitimate application deployments and CMS updates; alert on files created outside of established deployment windows or by non-deployment accounts
level: medium

KQL (Microsoft Sentinel / Defender)

The following hunt query identifies web server worker processes spawning shells or reaching for database/export tooling — the two highest-fidelity behaviors in this intrusion class. It works natively in Defender for Endpoint and in Sentinel where Syslog/CEF ingestion covers Linux web tiers.

let WebProcesses = dynamic(["w3wp.exe", "httpd", "httpd.exe", "nginx", "php-fpm", "php-cgi.exe", "node.exe", "java.exe", "tomcat", "catalina"]);
let SuspiciousChildren = dynamic(["cmd.exe", "powershell.exe", "pwsh.exe", "bash", "sh", "zsh", "wscript.exe", "cscript.exe", "mshta.exe", "rundll32.exe", "sqlcmd.exe", "bcp.exe", "mysqldump", "pg_dump", "curl.exe", "wget", "certutil.exe"]);
DeviceProcessEvents
| where TimeGenerated > ago(7d)
| where InitiatingProcessFileName has_any (WebProcesses)
| where FileName has_any (SuspiciousChildren)
| project TimeGenerated, DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine, FileName, ProcessCommandLine, AccountName, AccountDomain, ReportId
| order by TimeGenerated desc;

For environments ingesting web server and firewall logs into Sentinel, pair the process hunt with an egress anomaly check — long-dwell-time actors exfiltrate slowly, but they still exfiltrate:

CommonSecurityLog
| where TimeGenerated > ago(30d)
| where DeviceVendor =~ "Palo Alto Networks" or DeviceVendor =~ "Fortinet" or DeviceVendor =~ "Check Point"
| where SourceAddress startswith "10." or SourceAddress startswith "192.168."
| summarize TotalBytesOut = sum(tolong(SentBytes)), DistinctDestinations = dcount(DestinationAddress) by SourceAddress, bin(TimeGenerated, 1d)
| where TotalBytesOut > 50000000
| order by TotalBytesOut desc;

Baseline the egress query against your web and database server VLANs specifically. A payment application server that suddenly averages tens of megabytes per day outbound to a small set of novel destinations is exactly the signal that went unseen at AMCA for eight months.

Velociraptor VQL

Use this hunt artifact to sweep web servers for recently created or modified script files in document roots — the forensic footprint of web shell deployment. Pair with process listing to identify web workers spawning anomalous children.

-- Hunt for recently created/modified executable scripts in web document roots
-- and enumerate web server processes with suspicious children
SELECT FullPath, Size, Mtime, Ctime
FROM glob(globs=['C:/inetpub/wwwroot/**/*.aspx', 'C:/inetpub/wwwroot/**/*.ashx', 'C:/inetpub/wwwroot/**/*.asp', 'C:/inetpub/wwwroot/**/*.php'])
WHERE Mtime > timestamp(epoch=now() - 60*24*3600)
ORDER BY Mtime DESC

-- Enumerate processes spawned by web server workers
SELECT Pid, Ppid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE CommandLine =~ '(cmd|powershell|pwsh|sqlcmd|bcp|certutil|mshta|rundll32)'
   OR Name =~ '(w3wp|httpd|nginx|php-cgi)'
ORDER BY CreateTime DESC

On Linux web tiers, adjust the glob to /var/www/**/*.php, /srv/www/**, and application-specific document roots, and hunt for files whose mtime is newer than the last known-good deployment timestamp.

Remediation / Verification Script

The following PowerShell script audits an IIS web server for the artifacts described above: recently modified scripts in web roots, suspicious child processes of w3wp.exe, and the status of logging that would catch this class of intrusion. Run it on every internet-facing web server, and require your vendors to demonstrate equivalent controls.

# AMCA-pattern web tier audit: web shells, anomalous processes, logging hygiene
# Run elevated on each internet-facing IIS server

$daysBack = 60
$cutoff = (Get-Date).AddDays(-$daysBack)
$webRoot = "C:\inetpub\wwwroot"
$report = @()

# 1. Recently created/modified executable scripts in the web root
Write-Host "[*] Scanning $webRoot for script files modified in last $daysBack days..." -ForegroundColor Cyan
$recentScripts = Get-ChildItem -Path $webRoot -Recurse -Include *.aspx,*.ashx,*.asp,*.php,*.asmx -ErrorAction SilentlyContinue |
    Where-Object { $_.LastWriteTime -gt $cutoff } |
    Select-Object FullName, LastWriteTime, CreationTime, Length
$recentScripts | Format-Table -AutoSize
$report += $recentScripts

# 2. Child processes spawned by IIS worker processes (live check)
Write-Host "[*] Checking for suspicious children of w3wp.exe..." -ForegroundColor Cyan
$w3wpPids = (Get-Process -Name w3wp -ErrorAction SilentlyContinue).Id
foreach ($ppid in $w3wpPids) {
    Get-CimInstance Win32_Process -Filter "ParentProcessId = $ppid" |
        Where-Object { $_.Name -match 'cmd|powershell|pwsh|sqlcmd|bcp|certutil|mshta|rundll32' } |
        Select-Object ProcessId, ParentProcessId, Name, CommandLine, CreationDate
}

# 3. Verify IIS logging is enabled and capturing fields needed for IR
Write-Host "[*] Verifying IIS log configuration..." -ForegroundColor Cyan
Import-Module WebAdministration -ErrorAction SilentlyContinue
Get-Website | ForEach-Object {
    $logDir = "$($_.logFile.directory)" -replace '%SystemDrive%', $env:SystemDrive
    [PSCustomObject]@{
        Site        = $_.Name
        LogEnabled  = $_.logFile.enabled
        LogFormat   = $_.logFile.logFormat
        LogPath     = $logDir
    }
} | Format-Table -AutoSize

# 4. Verify file integrity / auditing on the web root via SACL presence
Write-Host "[*] Checking audit policy on web root..." -ForegroundColor Cyan
$acl = Get-Acl $webRoot -Audit -ErrorAction SilentlyContinue
if ($acl.Audit.Count -eq 0) {
    Write-Host "[!] No SACL configured on $webRoot. Enable Object Access auditing for Write/Create by non-deployment accounts." -ForegroundColor Yellow
}

# 5. Export findings
$report | Export-Csv -Path ".\webtier_audit_$(Get-Date -Format 'yyyyMMdd').csv" -NoTypeInformation
Write-Host "[+] Audit complete. Findings exported." -ForegroundColor Green

Remediation

Because no single CVE is implicated, remediation is architectural. These are the controls that would have detected or prevented the AMCA intrusion pattern, and that remain the correct control set in 2026:

1. Third-Party and Vendor Risk Management (the core failure)

• Treat every vendor that touches PHI as an extension of your attack surface. Require evidence of monitoring, not attestations: ask for SOC 2 Type II reports, penetration test summaries, and — critically — confirmation of EDR coverage and egress monitoring on systems that process your data.
• Bake security telemetry and breach-notification SLAs into Business Associate Agreements. AMCA's clients learned of the breach from AMCA; the timeline of discovery to notification is a contractual problem as much as a technical one.
• Map your data flows. Many covered entities did not know exactly which patient data elements AMCA held until the breach forced the question. You cannot assess blast radius you have not inventoried.

2. Web Tier Hardening

• Patch internet-facing application frameworks on an accelerated cadence; the web tier does not get the standard 30-day window.
• Deploy file integrity monitoring (or the audit script above on a schedule) across all web document roots. Alert on any executable script file created outside a deployment pipeline.
• Enforce the detection boundary: web worker processes (w3wp.exe, httpd, nginx, php-fpm) should never spawn shells or database utilities. Alert on it every time.

3. Data Tier Containment

• Application database accounts must be least-privilege: the payment portal needs to write transactions and read its own records, not run bulk SELECT operations across patient tables. Separate read scopes, deny ad-hoc query capability where the application doesn't need it, and alert on query volume anomalies per service account.
• Tokenize or vault payment card data (PCI DSS 4.0 scope reduction) so that compromise of the application database does not yield cardholder data. AMCA lost card numbers because card numbers were reachable.

4. Egress and Dwell-Time Controls

• Baseline and alert on outbound data volume from web and database server segments. Eight months of dwell time means eight months of exfiltration traffic that a simple egress anomaly rule would have surfaced.
• Cap log retention at no less than 12 months hot/searchable for internet-facing systems handling PHI — you cannot scope an incident you cannot look back through.

5. Governance and Compliance Alignment

• Map these controls to HIPAA Security Rule §164.312 technical safeguards and CIS Controls v8 (Controls 3, 8, 13, and 15 — data management, audit log management, network monitoring, and service provider management).
• Run a third-party-breach tabletop exercise this year with the AMCA scenario as the inject: your vendor calls, says they found an intruder with eight months of access to your patients' data, and asks what you want to do. If your IR plan starts at that phone call, it starts too late.

6. Legal/Settlement Context for Leadership

• Use the $6.4 million settlement figure in board reporting — but contextualize it. The settlement is partial, spread across millions of affected individuals, and represents only one litigation track. The true cost of the AMCA breach — bankruptcy of the vendor, regulatory scrutiny of the covered entities, reputational damage, and years of litigation — dwarfs the settlement number. That is the argument for funding vendor monitoring, and it is a strong one.

Related Resources

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