MyDr: The Vulnerability May Have Been Only the Beginning

MyDr Data Breach: What Could Have Happened After AWS Access?

The MyDr incident potentially exposed historical medical data relating to millions of people in Poland.

The full technical Root Cause Analysis has not been published yet. Polish authorities are still investigating the incident, while the Polish Data Protection Authority is reviewing the technical and organisational safeguards, risk analysis and security testing around the affected environment.

There is, however, an interesting account from the people claiming responsibility for the attack.

According to their version, the initial path looked roughly like this:

XXE in PKCS#12 certificate handling → Remote Code Execution → GitHub API key → source code → AWS access

This sequence has not been independently confirmed.

Sources reporting the attackers' account:

• CPO Magazine — Medical Data Breach on Medical Technology Firm MyDr Impacts Half of Polish Population
• CTI Pilot — MyDr, a Polish electronic health record platform, confirms a deliberate criminal intrusion
• SANS NewsBites — reporting on the MyDr breach

For this case study, let's assume that the reported sequence is broadly correct.

What matters next is the privilege model behind that access:

How could one compromised identity reach such a large amount of historical medical data?

AWS access alone does not explain the scale of the incident.

The real security question is what the compromised identity could do once the attacker had it.

---

Our hypothesis

The attack path could have continued roughly like this:

Public application ↓ XXE / application compromise ↓ Credential discovery ↓ GitHub access ↓ Source code and infrastructure discovery ↓ AWS access ↓ Production identity ↓ Historical medical data

We do not know if this was the actual path.

The interesting part is the transition between:

AWS access → production identity → sensitive data

That transition should be deliberate, limited and observable.

---

Why could one identity reach so much data?

Production applications need access to data. That is normal.

But every workload identity should have a clearly defined purpose and access scope.

Imagine a service account used by a production application that can read:

• every tenant,
• several years of historical records,
• multiple sensitive datasets,
• large volumes of data without additional controls.

Compromising that identity immediately creates an enormous blast radius.

Its role may be called:

application-reader

or:

production-service

That does not make it low-risk.

Its real privilege is determined by:

Permissions × Reachability × Business Impact

If one credential can expose a large historical medical dataset, it should be treated as a critical privileged identity.

---

Could the access have been narrower?

This is one of the first questions we would ask.

Can access be separated by:

• tenant,
• service,
• data domain,
• operation,
• environment,
• time,
• workload?

Could the public-facing application access only the operational data it actually requires?

Could historical records be placed behind a different identity, service or access policy?

For example:

Online application → current operational data

while:

Archive / reporting service → historical data

The exact implementation depends on the application architecture.

The principle is simple:

Compromising one production workload should expose only what that workload genuinely needs.

---

What if broad access is required?

Sometimes it is.

Reporting, migration, administration, backup or analytics services may legitimately require access to large datasets.

That changes how the identity should be protected.

A high-blast-radius identity should have stronger controls around it.

Short-lived credentials

Where possible, static AWS keys and long-lived secrets should be replaced with:

• workload identities,
• federation,
• temporary cloud sessions,
• short-lived tokens,
• automated credential rotation.

A credential stolen today should lose its usefulness quickly.

Strong trust boundaries

Access paths between these environments should be explicitly controlled:

Application → Developer tooling

Developer → Production

CI/CD → Production data

Production workload → Historical archive

Every unnecessary connection increases the potential blast radius.

Stronger monitoring

Broad access also means that normal behaviour needs to be understood.

Consider a service identity that normally reads:

20,000 records per hour

and suddenly reads:

3,000,000 records per hour.

The credential may be valid.

The IAM policy may allow the operation.

The behaviour is still highly abnormal.

Useful detection signals include:

• unusual query volumes,
• access to rarely used historical datasets,
• large sequential reads,
• unexpected API patterns,
• unusual source workloads,
• abnormal network egress,
• large data transfers,
• activity outside expected operating windows.

A powerful identity requires powerful monitoring.

---

Identity paths matter

Individual permissions rarely tell the whole story.

Consider this path:

Application → GitHub → CI/CD → AWS role → Production → Database

Every individual relationship might appear reasonable when reviewed in isolation.

Together, they may create a direct path from an Internet-facing application to highly sensitive data.

That is why one of the most useful questions in Identity Security is:

What can this identity reach next?

At Zelto, we think about this as the Identity Blast Radius.

---

How Zelto would approach the environment after the breach

After an incident like this, our focus would be understanding and reducing that blast radius.

1. Identify potentially compromised identities

Including:

• service accounts,
• AWS roles,
• API keys,
• GitHub tokens,
• CI/CD identities,
• OAuth clients,
• database accounts,
• certificates.

2. Map what each identity can reach

We would look beyond direct permissions and include:

• role assumption paths,
• secrets available to workloads,
• deployment permissions,
• trust policies,
• access to other identities,
• production and data-plane access.

The result is an Identity Attack Graph.

For example:

Compromised application → GitHub token → deployment pipeline → AWS role → production service → database

3. Check for persistence

An attacker with sufficient access may have created another way back in:

• additional API keys,
• new service accounts,
• deploy keys,
• OAuth applications,
• cloud roles,
• modified trust policies.

Rotating the first known credential may therefore be insufficient.

4. Reduce the blast radius

The immediate objective is to remove or narrow unnecessary paths.

Examples:

Application → Developer tooling

CI/CD → Production data

Developer → Production

One service identity → Entire historical archive

Then rebuild a known-good identity state and rotate or revoke the affected credentials in a controlled way.

---

How we would design against this scenario

Our starting assumption is simple:

Assume compromise.

Applications can have vulnerabilities.

Credentials can leak.

Workloads can be exploited.

Developer accounts can be compromised.

The architecture determines what happens afterwards.

A resilient model looks like:

Compromised identity → limited permissions → limited reachable resources → behavioural detection → containment

The dangerous model looks like:

Compromised identity → another privileged identity → production → complete dataset

---

What can a compromised identity reach?

If one credential can access an organisation's most sensitive historical dataset, that access should exist because of a deliberate architectural decision.

The organisation should know:

• why the access exists,
• who owns the identity,
• how long its credentials remain valid,
• which resources it can reach,
• what its normal behaviour looks like,
• how abnormal behaviour is detected,
• how quickly it can be revoked,
• what happens if it is compromised.

That is how we approach Identity Security at Zelto:

Understand privilege. Limit reachability. Monitor powerful identities. Reduce the blast radius.

Assume compromise. Control the blast radius.