MCBS, a Georgia-based healthcare management and revenue cycle company, discovered unauthorized network access on September 25, 2025. By the time the breach was contained, attackers had exfiltrated 3 TB of data containing protected health information for 1,261,464 patients across seven HIPAA-covered entity clients. The PEAR threat group claimed responsibility, publishing the stolen data when their ransom demand went unmet.
Timeline
September 22-25, 2025: Unauthorized network access occurs. The three-day window suggests credential-based access rather than exploitation of a zero-day vulnerability.
September 25, 2025: MCBS detects the intrusion and initiates containment. Third-party cybersecurity experts are engaged.
May 28, 2026: Data review completes, eight months after detection. The compromised information includes names, addresses, dates of birth, Social Security numbers, medical histories, mental health records, diagnosis information, treatment details, and health insurance data.
July 2026: Public notification begins.
The eight-month gap between detection and notification completion indicates a complex forensic review, likely because MCBS had to reconstruct events across multiple client environments.
Which Controls Failed or Were Missing
Network Segmentation and Access Controls
The attackers moved laterally across environments serving seven distinct covered entities. Proper network segmentation would have prevented a breach in one client's environment from affecting others. The 3 TB exfiltration over 72 hours shows the threat actor had broad access and encountered minimal internal barriers.
Monitoring and Detection
Three days of unauthorized access before detection indicates a failure in your security information and event management capability. The HIPAA Security Rule requires procedures to regularly review records of information system activity. If you're not alerting on anomalous data access patterns or unusual egress traffic, you're not meeting that requirement.
Data Loss Prevention
Moving 3 TB of data off your network should trigger alerts. The absence of automated blocking or real-time notification suggests MCBS lacked effective data loss prevention controls at network egress points.
Privileged Access Management
Credential-based attacks succeed when you don't enforce Just-in-Time Access for administrative privileges or haven't implemented multi-factor authentication on all privileged accounts. The speed and scope of this breach suggest the attackers obtained credentials with excessive permissions.
What the Standards Require
HIPAA Security Rule
§164.308(a)(1)(ii)(D) requires procedures for regularly reviewing records of information system activity, such as audit logs, access reports, and security incident tracking reports. MCBS's three-day detection window indicates this wasn't happening effectively.
§164.308(a)(4)(i) mandates policies and procedures to ensure all workforce members have appropriate access to electronic protected health information and to prevent unauthorized access. The lateral movement across seven client environments suggests access controls weren't appropriately scoped.
§164.312(a)(1) requires technical policies and procedures that allow only authorized persons to access electronic protected health information. When a threat actor can exfiltrate 3 TB across multiple client environments, your access controls have failed.
§164.312(b) addresses audit controls: you must implement hardware, software, and procedural mechanisms that record and examine activity in information systems containing electronic protected health information. If those audit mechanisms existed, they didn't generate timely alerts.
HITECH Act Breach Notification Rule
§164.404(b) requires notification without unreasonable delay and in no case later than 60 days following discovery of a breach. MCBS discovered the breach on September 25, 2025, but needed until May 28, 2026, to complete the data review before notifying affected individuals. That eight-month timeline is defensible only if you can document why the forensic review required that duration and what steps you took to expedite it.
Lessons and Action Items for Your Team
1. Segment client environments now
If you're a business associate serving multiple covered entities, treat each client's data as a separate security zone. Implement network segmentation, separate authentication directories, and dedicated administrative credentials per client. A breach in one environment should never automatically cascade to others.
Action: Map your current network architecture. Identify where client data commingles. Build a segmentation plan with hard network boundaries, separate VLANs, and firewall rules that default-deny traffic between client zones.
2. Tune your SIEM for healthcare-specific threats
Generic security monitoring won't catch healthcare-targeted attacks. Configure alerts for bulk downloads of patient records, access to protected health information outside normal business hours, and privileged account usage from unexpected locations.
Action: Review your last 90 days of SIEM alerts. How many were healthcare-specific? If the answer is "none," your detection rules aren't calibrated for the threats you actually face. Add use cases for: unusual database queries, bulk export of patient files, access to mental health records by non-treating providers, and changes to audit logging configurations.
3. Deploy data loss prevention at every egress point
You should know when someone attempts to move gigabytes of data off your network, especially protected health information. Configure DLP to inspect traffic at your internet gateway, email servers, cloud storage connections, and removable media.
Action: Identify every path data can leave your environment. Deploy monitoring or blocking at each point. For high-risk data types (Social Security numbers, diagnosis codes, treatment records), configure automated blocking with manual override requiring documented business justification.
4. Implement Just-in-Time Access for privileged accounts
Standing administrative access is how attackers move laterally. Require privileged users to request elevated permissions for specific tasks with defined time windows. Revoke access automatically when the window expires.
Action: Inventory all accounts with administrative privileges. Document which job functions genuinely require standing access versus time-limited access. Deploy a Privileged Access Management solution that enforces approval workflows and automatic de-provisioning.
5. Test your breach response timeline
MCBS took eight months to complete its data review. That's not necessarily unreasonable for a complex forensic investigation, but you need to know in advance how long your process will take and where the bottlenecks are.
Action: Run a tabletop exercise simulating a multi-client data breach. Walk through every step: detection, containment, forensic analysis, data review, legal notification requirements, and individual notifications. Identify which steps will take longest and what you can do now to accelerate them. Document your process so you're not figuring it out during an actual incident.
The MCBS breach wasn't sophisticated. It was credential-based access that went undetected for three days and encountered insufficient internal controls. That's not a zero-day exploit; it's a failure of fundamental security hygiene. Your controls should make this type of breach difficult to execute and impossible to sustain for 72 hours without detection.
