Change Healthcare: One Citrix Login and a National Outage

On 21 February 2024, a company most patients had never heard of went offline, and pharmacies across the United States stopped being able to tell customers what their medication would cost.

Change Healthcare is a clearinghouse. It sits between healthcare providers and insurers, handling eligibility checks, claims, prior authorisations and payments for a very large share of US healthcare transactions. When it stopped, providers could not bill, pharmacies could not verify coverage, and money stopped moving through a substantial part of the system.

The way in was a login. One remote access portal, stolen credentials, and no multi-factor authentication.

Timeline

Date	Event
12 February 2024	Attackers authenticate to a Citrix remote access portal using stolen credentials. The portal has no MFA
12 to 21 February 2024	Lateral movement and data exfiltration over nine days
21 February 2024	Ransomware is deployed. Systems are taken offline
Late February 2024	Pharmacies, providers and hospitals across the US report inability to process claims and prescriptions
March 2024	A ransom of 22 million dollars is paid. The affiliate reportedly does not receive their share and retains the data
April 2024	A second extortion attempt follows under a different group's name
1 May 2024	The parent company's chief executive testifies to Congress, confirming the missing MFA and the payment
2024 into 2025	Notification expands, eventually covering roughly 190 million individuals

The way in

There is not much to explain, which is the point worth sitting with given the consequences.

A Citrix portal provided remote access to desktops. Credentials for it had been compromised elsewhere. The portal did not require a second factor, so the credentials alone were sufficient.

The parent company's chief executive stated this publicly in congressional testimony. It is unusual to have a confirmation this direct from the top of an affected organisation, and it removes any ambiguity about the cause of initial access.

The same single missing control appears in Colonial Pipeline and in The Snowflake Customer Breaches. Three incidents of national significance, one absent control, in each case on a remote access path that had been forgotten or exempted.

Nine days

Between the login on 12 February and the ransomware on 21 February, attackers moved through the environment and exfiltrated data.

Nine days is a long time and it is also an opportunity that was available and missed. Everything that made the incident catastrophic happened at the end of that window. During it, the activity was an intruder using valid credentials, moving laterally, and copying large volumes of data out.

That activity is detectable. A remote access account authenticating from an unusual source, then accessing systems it has never touched, then generating outbound transfers at volumes that do not match its history, is exactly the sequence What Is a SIEM describes as the shape a correlation engine exists to catch. Detecting it on day three rather than day nine changes the incident from a national outage into a contained intrusion with a data theft problem.

Why one company's outage stopped a country

The systemic lesson is about concentration rather than about security.

Healthcare payment infrastructure consolidated over decades for good economic reasons: a clearinghouse that connects thousands of providers to hundreds of insurers is enormously more efficient than every provider integrating with every payer. The result was that a very large share of the transaction volume in a national healthcare system ran through one company's systems.

Efficiency at that scale creates a single point of failure whose blast radius is the sector. When it went down:

• Pharmacies could not check coverage, so patients paid full price or went without.
• Providers could not submit claims, so revenue stopped.
• Small practices with limited cash reserves faced payroll they could not meet within weeks.
• The parent company advanced billions of dollars to providers to keep them solvent, which is the clearest measure of how much economic activity had stopped.

The organisations hurt worst were the smallest ones. A large hospital system has reserves and alternative arrangements. A two-physician practice has neither, and their exposure came from a supplier decision made years earlier that nobody had modelled as a risk.

For anyone assessing supplier risk, the question this poses is uncomfortable and worth asking anyway: which single external service, if unavailable for a month, would stop you being paid? That is a different question from whether the supplier is secure, and it has a different answer.

Paying twice

The extortion sequence here is the clearest public example of what a service model does to the payment calculation.

A ransom of 22 million dollars was paid. In a ransomware-as-a-service arrangement, the operator provides the malware and infrastructure while an affiliate performs the intrusion, and they split proceeds. Reporting indicates the affiliate did not receive their share, retained the stolen data, and a second extortion attempt followed under another group's banner.

The lesson generalises past this incident. Payment is a transaction with a party that has no obligation and may not control the data. In an affiliate model there are at least two parties with a copy, and the one you paid may not be the one holding it. Ransomware as a Service Explained covers the structure.

Anyone weighing payment should assume publication happens anyway and decide on that basis. What payment can buy is a decryption tool and time; what it cannot buy is confidentiality.

The regulatory and legal tail

Healthcare data carries specific obligations, and the notification process ran for more than a year as the company worked out whose data was in the stolen files. The count rose repeatedly, ending around 190 million individuals and later reported above 192 million on the federal breach portal, making it the largest healthcare data breach recorded in the United States.

Two practical points for anyone in a regulated sector:

Notification obligations follow the data, so downstream providers whose patients' information sat in the clearinghouse had their own responsibilities, dependent on information they could not produce themselves.

Counting takes far longer than responding. The technical incident lasted weeks. Determining whose data was affected took a year, and that work is only possible if you know what data you hold and where it went, which is the argument in What Is DLP for knowing your data estate before you need to.

What generalises

1. MFA on every remote access path, with no exceptions. The exceptions are where these incidents start.
2. Dwell time is the window you are fighting for. Nine days of lateral movement and exfiltration is detectable with ordinary identity and network telemetry.
3. Map your single points of failure among suppliers, and ask what happens if one is gone for a month.
4. Have a manual mode. Organisations that could bill on paper suffered less than those that could not operate at all.
5. Payment does not restore confidentiality, and in an affiliate model it may not even reach the person holding your data.
6. Data minimisation reduces the size of the eventual notification. Records that were deleted on schedule are not in the count.

The verdict

One remote access portal without multi-factor authentication, nine days of undetected activity, and a national healthcare payments outage that left small practices unable to make payroll.

The organisational lesson is larger than the technical one. The security failure was a missing control that most organisations would recognise in their own estate. The systemic failure was that a country's healthcare payments had consolidated into a single point whose loss nobody had planned for, and that plan was never Change Healthcare's to make.

Related guides

• Anatomy of a Ransomware Attack
• Ransomware as a Service Explained
• Colonial Pipeline Explained
• Two-Factor Authentication Guide
• Incident Response 101