Healthcare has moved to the cloud faster than most security programs have adapted. EHR extensions, patient portals, analytics pipelines, imaging archives, and telehealth platforms now run on AWS, and with them comes protected health information (PHI) spread across S3 buckets, RDS databases, Lambda functions, and data lakes. Signing a Business Associate Addendum (BAA) with AWS does not make any of that HIPAA compliant. It only means AWS will protect its side of the shared responsibility model. Everything you configure is still on you.
That is why AWS healthcare penetration testing has become one of the most requested engagements Redfox Cybersecurity runs for hospitals, payers, and health tech companies. In this case study, we walk through an anonymized and representative AWS assessment for a healthcare SaaS provider: how a misconfigured S3 bucket exposed PHI, how a chain of IAM permissions led to a production RDS database full of patient records, and how we map every cloud pentest to HIPAA and the AWS Well-Architected Framework.
Traditional network penetration testing looks for open ports and unpatched hosts. In AWS, the perimeter is identity. A single overly permissive IAM policy can be more dangerous than an unpatched server, because it can grant access to every database, bucket, and secret in the account through legitimate API calls that look like normal activity.
AWS is responsible for security of the cloud: physical data centers, hypervisors, and the underlying infrastructure of its HIPAA-eligible services. You are responsible for security in the cloud: IAM, network configuration, encryption settings, logging, application code, and how PHI is stored and accessed. Every finding in this case study sits on the customer side of that line.
The HIPAA Security Rule is technology neutral, but its technical safeguards translate directly into AWS controls:
The Security Rule also requires an accurate and thorough risk analysis. A cloud penetration test is one of the most defensible ways to show that your risk analysis reflects how an attacker would actually move through your environment.
No prior approval is required to test a defined list of common services, including EC2, RDS, Aurora, Lambda, API Gateway, CloudFront, Elastic Beanstalk, and Lightsail. AWS does prohibit certain activities, such as denial of service testing, DNS zone walking against Route 53 hosted zones, and protocol or port flooding. A qualified tester will scope the engagement within AWS's customer penetration testing policy and document that alignment in the rules of engagement.
Redfox Cybersecurity's AWS methodology combines automated configuration review with manual, attacker-driven testing. Tools find misconfigurations; humans find the chains that turn several medium-severity issues into a PHI breach.
We start by identifying where PHI lives and how it moves: which accounts, regions, buckets, databases, queues, and functions store or process it, and which identities can reach them. We also confirm that every service touching PHI is on the AWS HIPAA-eligible services list and covered by the BAA.
From the internet, we enumerate public endpoints, DNS records, CloudFront distributions, API Gateway stages, and S3 bucket names derived from the organization's naming patterns. We also search public code repositories and container images for leaked access keys, which remain one of the most common initial footholds in cloud breaches.
Using read-only credentials, we run tools such as Prowler, ScoutSuite, and CloudFox to baseline the environment against CIS AWS Foundations and the Well-Architected Security Pillar. This surfaces public resources, missing encryption, disabled logging, and risky IAM policies at scale.
This is where the real testing happens. We start from a realistic foothold, such as a developer's low-privilege IAM user, a compromised EC2 instance, or a vulnerable web application, and attempt to escalate. We map IAM relationships with tools like PMapper and Pacu, then manually validate each escalation path to confirm it actually works.
When we reach a resource containing PHI, we prove access with minimal, controlled evidence (record counts and redacted samples), never bulk extraction. We then check whether GuardDuty, Security Hub, CloudTrail alerts, or the client's SIEM detected any of our activity. Detection gaps are findings in their own right.
The scenario below is a representative composite of the issues we see in healthcare AWS environments, with all identifying details removed. The client in this scenario provides care management software to hospitals and clinics. Their platform ran in a multi-account AWS Organization with separate accounts for production, staging, and data analytics. Patient demographics, diagnoses, and care plans lived in an Amazon RDS for PostgreSQL instance, and exported reports and uploaded documents were stored in S3.
The scope covered all three accounts. We were given a low-privilege IAM user representing a junior developer and access to a standard user account on the web application.
During external reconnaissance, we noticed that the web application generated download links for patient reports. The links pointed to a predictable bucket name following the company's naming convention. We tested related names for the staging and analytics environments and found an analytics bucket that responded to unauthenticated list requests.
The bucket contained nightly CSV exports used by a business intelligence tool. Each file included patient names, dates of birth, medical record numbers, diagnosis codes, and assigned care managers. The exports went back more than a year. Anyone on the internet who guessed or discovered the bucket name could have listed and downloaded every file.
S3 Block Public Access had been disabled at the account level in the analytics account to support a legacy dashboard integration. A bucket policy later added for that integration granted s3:ListBucket and s3:GetObject to "Principal": "*" with a condition intended to restrict access by source IP. The condition key was misspelled, and because it did not evaluate as intended, the policy effectively allowed public access. Nobody noticed because the dashboard kept working.
This is an impermissible disclosure of PHI. If logs showed any unauthorized access, it would likely trigger breach notification obligations under the HIPAA Breach Notification Rule. Worse, server access logging was disabled on the bucket, so the client could not determine whether anyone had downloaded the data before our test.
Public S3 exposure is still one of the fastest ways healthcare data ends up in breach reports, and it is often invisible to teams that only test their production web application. If you have not had your buckets, policies, and data flows reviewed by an attacker's eye, our HIPAA penetration testing engagements include full cloud storage exposure analysis mapped to Security Rule safeguards.
The second finding started from the low-privilege developer identity and ended with full read access to the production patient database.
The developer user had a custom policy intended to let engineers deploy serverless functions in the staging account. Among other permissions, it included lambda:CreateFunction, lambda:InvokeFunction, and iam:PassRole with a resource of *.
The combination of iam:PassRole on any role and the ability to create and invoke Lambda functions is a well-known escalation path. We listed roles in the account and found a deployment role used by the CI/CD pipeline. That role had broad permissions and, critically, a trust relationship allowing it to assume a cross-account role in production. We created a Lambda function, passed it the deployment role, and invoked it. The function now ran with the deployment role's permissions.
From the Lambda execution context, we assumed the cross-account role in the production account. That role was intended for deployments only, but its policy included secretsmanager:GetSecretValue on all secrets, added during a past troubleshooting session and never removed.
Secrets Manager held the master credentials for the production RDS instance. The database sat in a private subnet, but the same production role could launch resources in that VPC. We deployed a temporary Lambda function into the database subnet, connected with the retrieved credentials, and confirmed read access to tables containing patient demographics, diagnoses, and care plans. We collected only a row count and a single redacted record as evidence.
GuardDuty was enabled in the production account, but it did not generate a high-severity alert for this chain. CloudTrail recorded every API call, but no alerting existed for cross-account role assumptions from staging or for secret retrieval by the deployment role. The full chain took under two hours and generated no actionable alert.
iam:PassRole to specific roles and use the iam:PassedToService condition key.AssumeRole events, unusual GetSecretValue calls, and new Lambda functions in production VPCs.IAM escalation chains like this rarely show up in automated scanners because each permission looks reasonable in isolation. Finding them takes manual, assumed-breach testing. Redfox Cybersecurity's healthcare penetration testing team runs exactly this kind of attack path analysis across AWS, Azure, and hybrid environments.
Engineering teams act faster when findings are mapped to frameworks they already use. We map every AWS finding to the Security Pillar of the AWS Well-Architected Framework and, where relevant, to the Healthcare Industry Lens.
The Security Pillar recommends using strong identity foundations, granting least privilege, and managing permissions centrally. The PassRole escalation and the over-permissioned production role violated these principles directly.
Well-Architected guidance calls for configuring service and application logging and analyzing logs centrally with automated alerting. The missing S3 logs and the absence of alerts on cross-account activity both mapped here.
Network segmentation and control of traffic at every layer limited the blast radius in this case, since the database was not internet facing. However, the ability to deploy compute into the database subnet showed that segmentation must be paired with identity controls.
The Security Pillar recommends classifying data, protecting it at rest and in transit, and keeping people away from data. Plaintext CSV exports of PHI in an analytics bucket, with no classification or Macie monitoring, fell short on all counts.
When the client attempted to scope the S3 exposure, they could not, because the logs did not exist. Well-Architected incident response guidance stresses preparing forensic capabilities before you need them.
Use this checklist to evaluate whether your next cloud pentest will actually cover HIPAA risk:
At minimum, test annually and after significant changes such as new accounts, major architecture changes, new data pipelines, or a migration of PHI workloads. Cloud environments change daily through infrastructure as code, so many healthcare organizations pair an annual deep assessment with continuous configuration monitoring and targeted retests after major releases. If you are preparing for a HIPAA audit, HITRUST assessment, or SOC 2 report that includes cloud scope, a recent cloud pentest for HIPAA provides concrete evidence that your risk analysis reflects real attack paths.
iam:PassRole with broad resources can open a path from a junior developer to your patient database.If your organization runs PHI workloads in AWS, the question is not whether misconfigurations exist, but whether you find them before an attacker does. Talk to Redfox Cybersecurity about AWS healthcare penetration testing and get a clear picture of how an attacker would reach your patient data, and exactly how to stop them.
Redfox Cyber Security Inc.
8 The Green, Ste. A,
Dover, Delaware 19901,
United States.
.avif)
