The data breach disclosed by Eskenazi Health in Indianapolis demonstrates why trusted-contact phishing remains so effective even in organizations with mature security programs. According to Eskenazi Health, an attacker first compromised the email account of one of its trusted business contacts and then used that account to send thousands of unauthorized messages to people in the contact’s address book. One of those emails reached an Eskenazi Health employee and appeared to contain a legitimate secure-document notification. After the employee followed the link and completed the requested authentication process, the attacker gained access to the employee’s cloud-based work account.

This is more dangerous than an ordinary phishing message from an unfamiliar domain because the email originated from a real compromised account belonging to a known contact. Many traditional security controls and user-awareness habits depend on obvious warning signs such as unfamiliar senders, unusual domains, misspellings, or poor formatting. When attackers hijack a genuine business relationship, several of those warning signals disappear. The message arrives from somebody the recipient has communicated with before and may even be part of an existing conversation or contact history.

The forensic investigation determined that unauthorized access began on June 3, 2026 and continued until July 27, when Eskenazi Health discovered the suspicious activity and terminated access. During that period, the attacker may have accessed emails and attachments stored in the compromised account. That nearly eight-week dwell time is significant because cloud email accounts are no longer merely communications tools. They can contain years of correspondence, attachments, appointment information, billing records, internal discussions, password-reset messages, collaboration links, and data copied from clinical or administrative systems.

The breach therefore illustrates a broader shift in enterprise security: the mailbox itself has become a data repository. Organizations may spend heavily protecting databases and electronic health-record systems while sensitive information quietly accumulates in email because employees use mailboxes to exchange documents and discuss patient cases. Compromising one account can therefore expose information that originated in several otherwise well-protected systems.

Eskenazi Health says the information involved varied by individual and may have included personal demographic and contact information, health insurance and billing information, medical record numbers, medical and treatment information, Social Security numbers, and sensitive health information including substance-use disorder diagnosis and treatment information.

That last category makes the incident particularly sensitive. Medical information can create harms that differ substantially from ordinary financial identity theft. A stolen credit-card number can be cancelled. A password can be changed. A person's medical history, diagnosis, treatment record, or substance-use information cannot simply be replaced after exposure.

Healthcare organizations therefore need to treat protected health information as long-life intelligence. Attackers may use it for identity theft and fraud, but it can also support highly targeted phishing, insurance fraud, extortion, impersonation, or social engineering against patients and their families.

The combination of health information and Social Security numbers creates an especially valuable dataset. An attacker possessing a patient's name, medical provider, treatment history, insurance information, and Social Security number can construct communications that appear extremely credible. A fraudulent message referring to a real medical provider, recent treatment, or insurance relationship is far more convincing than generic phishing.

Affected patients should therefore be particularly cautious about messages claiming to relate to medical bills, insurance claims, prescriptions, appointments, refunds, or breach compensation. Attackers using stolen healthcare information may already know enough about the victim to make the contact seem legitimate.

Another important aspect of the incident is the authentication workflow itself. Eskenazi Health says the employee clicked the malicious document link and completed the requested authentication process. That raises the possibility of an adversary-in-the-middle phishing technique or another mechanism capable of capturing credentials or authenticated session information, although Eskenazi Health has not publicly described the technical phishing platform used.

That distinction matters because MFA alone does not stop every modern phishing attack. If an attacker proxies a legitimate authentication session in real time and captures the resulting session token, the victim may successfully complete MFA while the attacker inherits the authenticated session.

Organizations should therefore move beyond the simple message that “MFA solves phishing.” MFA remains essential, but the type of MFA matters. Phishing-resistant authentication, such as FIDO2 security keys, passkeys bound to legitimate domains, or certificate-based authentication, provides stronger protection than methods where users type reusable passwords and one-time codes into web pages.

Conditional access can provide another layer. A valid cloud session should not automatically be trusted simply because authentication succeeded. Security platforms should evaluate the device, geography, IP reputation, authentication history, session behavior, and sensitivity of the requested resource.

An employee account suddenly authenticating from unfamiliar infrastructure or exhibiting unusual mailbox behavior should trigger investigation even when the correct username, password, and MFA sequence were presented.

Cloud-email monitoring is particularly important because attackers commonly abuse compromised accounts in several ways after gaining access. They may search for financial correspondence, download attachments, create inbox rules to hide security notifications, register malicious OAuth applications, reset passwords for other services, or use the account to continue the phishing chain against additional trusted contacts.

That last technique can create a trust-propagation attack.

The chain becomes:

one organization compromised → trusted mailbox hijacked → phishing sent to business contacts → another organization compromised → new trusted mailbox obtained → phishing continues

Each successful compromise improves the credibility of the next attack.

This is why organizations investigating business-email compromise should not focus solely on the original account. Security teams should determine whether the compromised mailbox sent malicious messages to external contacts and, where appropriate, notify those organizations quickly.

The Eskenazi incident also demonstrates why mailbox auditing and session telemetry need adequate retention periods. If unauthorized access persists for weeks, investigators must be able to reconstruct searches, message access, forwarding rules, authentication events, token usage, downloads, and administrative changes over the full intrusion period.

Short log-retention periods can leave investigators unable to determine what happened early in the breach.

For Microsoft 365, Google Workspace, and similar cloud environments, organizations should ensure that high-value audit events are retained centrally in a SIEM or other independent repository. Logs stored solely inside the compromised platform may also be more difficult to rely upon if the attacker gained sufficient privileges.

OAuth tokens deserve particular attention during remediation. Resetting an employee's password may not terminate every authenticated session or delegated application token. Following a confirmed cloud-account compromise, defenders should invalidate active sessions, revoke refresh tokens, inspect registered devices, review OAuth grants, and examine mailbox rules and forwarding configurations.

Any credentials or secrets contained in affected messages should also be considered potentially exposed.

Employees routinely send API keys, temporary passwords, database exports, VPN configurations, spreadsheets, and system credentials through email despite decades of security teams politely begging them not to. If the attacker could search the mailbox, those artifacts may become lateral-movement opportunities.

Healthcare organizations also face an additional challenge because operational requirements encourage rapid communication. Clinicians, administrative teams, insurers, laboratories, pharmacies, and outside providers exchange information constantly. That makes email extremely valuable and extremely difficult to restrict.

The answer therefore cannot simply be “never send sensitive information by email.”

Instead, organizations need data minimization, encryption, secure messaging platforms, retention controls, DLP, and strong identity security around those workflows.

Sensitive attachments should ideally be stored in controlled document repositories rather than remaining indefinitely in user mailboxes. The email can contain a time-limited link rather than a permanent copy of the underlying medical record.

The incident is also notable because Eskenazi Health has experienced a major cyberattack before. In 2021, cybercriminals gained access to its network, stole patient and employee information, and published some of the stolen data on the dark web. That earlier incident involved a different attack mechanism and should not be conflated with the 2026 phishing compromise.

However, the historical comparison illustrates how the attack surface has evolved.

The 2021 incident centered on compromise of the organization's network.

The 2026 incident centered on compromise of a cloud identity.

That reflects a broader industry trend: organizations can harden their network perimeter considerably and still be breached through the identities used to access cloud services.

The perimeter increasingly follows the user.

Eskenazi Health says it has secured the affected account, implemented additional safeguards, and is evaluating enhanced security controls and employee education. It is also offering impacted individuals identity-protection and credit-monitoring services at no cost.

Employee education is worthwhile, but the incident demonstrates why training cannot be the primary security boundary.

The phishing email succeeded precisely because it appeared to come from a legitimate trusted contact.

Even a well-trained employee can make a reasonable mistake when the attacker has already compromised part of the trust chain.

Technology should therefore assume that eventually someone will click.

The more durable defenses are phishing-resistant authentication, conditional access, behavioral monitoring, session revocation, mailbox anomaly detection, and controls that limit the amount of sensitive information stored in individual accounts.

Organizations should also monitor for unusual authentication characteristics following document-sharing notifications. A common pattern in modern cloud phishing involves fake Microsoft 365, SharePoint, DocuSign, Dropbox, or secure-document prompts that redirect victims to credential-harvesting infrastructure.

The login page may look almost identical to the legitimate service.

Employees should therefore be taught to verify not only the sender but also the actual authentication domain. More importantly, identity systems should technically prevent credentials from being accepted by the wrong domain wherever possible.

The breach also reinforces the value of out-of-band verification when unexpected sensitive documents are received, even from known contacts. A quick phone call or separate message asking, “Did you send this?” can defeat a compromised-account phishing chain.

That is mildly inconvenient.

So is explaining to thousands of patients that somebody spent nearly two months reading a compromised mailbox.

From an incident-response perspective, Eskenazi Health will need to determine not merely which emails existed in the account but which information the attacker actually accessed where logs permit that conclusion. The organization's public wording says certain emails and attachments may have been accessed, so it would be inappropriate to state that every piece of listed patient information was definitively downloaded.

That distinction should remain clear in reporting.

Potential exposure describes the information available within the compromised account.

Confirmed exfiltration requires evidence that specific information was actually acquired.

In many cloud-account investigations, complete certainty is difficult because mailbox access may not generate sufficiently granular records for every historical action.

Healthcare breach response therefore often needs to proceed conservatively: if sensitive information was accessible during unauthorized access and investigators cannot establish that it was untouched, affected individuals may need to be notified.

The broader cybersecurity lesson from the Eskenazi breach is that trust itself has become an attack surface.

The attacker did not need to convince the employee that a random stranger was trustworthy.

They first compromised somebody who was already trusted.

The attack chain can be summarized as:

trusted business contact compromised → legitimate account sends phishing message → Eskenazi employee receives believable document notification → authentication captured → cloud work account compromised → attacker maintains access for nearly eight weeks → patient emails and attachments potentially accessed

Each step exploits an existing business relationship rather than trying to defeat it.

That is why organizations need to move from asking:

“Is this sender trusted?”

to asking:

“Is this particular request normal for this sender, this user, this device, and this session?”

In a world of compromised identities, trusted email addresses are no longer proof of trusted intent.

And in healthcare, where one mailbox can contain medical histories, Social Security numbers, insurance information, and deeply sensitive diagnoses, that distinction becomes extremely important.

Eskenazi Health data breach exposed patient SSNs, medical info, and more. If affected, check your details and secure your identity.

Source: Eskenazi Health Data Breach Exposes Sensitive Personal and Medical Info via claimdepot.com.