Skip to content
BreachPathAttack Path LibraryStart
IntermediateData theft

Patient portal to clinical records

A weakness in a patient-facing portal or its integration is used to move from a single account's view to broad access to clinical records held in connected systems.

Technologies
Custom web applications, SaaS (generic)
Entry points
Vulnerable application, Stolen credentials
Sectors
Healthcare
Stages
3
01

A weakness in the patient portal is reached

The attacker probes a patient-facing portal and finds an access-control or input-handling weakness that lets them influence which records the application returns, moving beyond their own account's boundary.

Attacker objective

Get the portal to return data or perform actions beyond one account's scope.

Controls that should stop this
  • Robust object-level authorisation on every record access
  • Secure development lifecycle with access-control testing
  • Web application firewall and anomaly monitoring
What defenders should see
  • Requests iterating over record identifiers
  • Access-control failures or unusual authorisation patterns
  • One account requesting many other patients' records
What a pentest validates
  • Application test focused on broken object-level authorisation
  • Review access-control enforcement per record
  • Validate monitoring for enumeration of record IDs
Business impact

The attacker can reach records beyond their own account.

02

Portal integrations are used to widen reach

The portal integrates with record systems using service credentials or APIs. The attacker abuses this trusted integration to query the connected systems more broadly than any single patient should be able to.

Attacker objective

Leverage the portal's back-end connections to reach the clinical systems behind it.

Controls that should stop this
  • Least-privilege, tightly-scoped integration credentials
  • Segmentation between the public portal and clinical record systems
  • Per-request authorisation rather than trusting the integration wholesale
What defenders should see
  • Integration credential use outside normal query patterns
  • Bulk record queries via the portal back-end
  • Access to record systems from the portal tier at unusual volume
What a pentest validates
  • Review what portal integration credentials can reach
  • Test segmentation between portal and clinical systems
  • Validate per-request authorisation on integrated queries
Business impact

The attacker reaches clinical record systems through the portal's trust.

03

Patient records are extracted

The attacker retrieves patient records in volume and moves them out, targeting the special-category data that is most sensitive and most valuable.

Attacker objective

Collect and remove the sensitive health records.

MITRE ATT&CK
Controls that should stop this
  • DLP and egress controls tuned to clinical data
  • Volume alerting on record access and export
  • Encryption and strict access logging on record stores
What defenders should see
  • Bulk record retrieval or export
  • Access to many patient records in a short window
  • Egress to unfamiliar destinations
What a pentest validates
  • Authorised, controlled test of bulk record access and export
  • Validate DLP and volume alerting on clinical data
  • Confirm access logging and retention on record stores
Business impact

Sensitive patient data is exfiltrated โ€” a severe breach with regulatory, safety and trust impact.

ATT&CK techniques in this chain

If this chain completes

Exposure of highly sensitive special-category health data โ€” carrying acute regulatory, safety and trust consequences, and often high value to attackers for fraud and extortion.

Should you test this against your environment?

Turn this chain into a scoped red-team brief โ€” objective, systems and identities in scope, testing assumptions and the questions to answer before commissioning.