Aesto Health Breach: 9.5M Records Stolen from AWS — Detection and Cloud Hardening Guide for Healthcare Defenders

Aesto Health, a healthcare technology company, has disclosed a data breach impacting approximately 9.5 million individuals. Attackers gained unauthorized access to the company's Amazon Web Services (AWS) infrastructure and exfiltrated personal and protected health information (PHI) belonging to patients whose providers rely on Aesto's platform.

This is not a niche incident. A breach of this magnitude places it among the largest healthcare compromises of the year, and it lands squarely in the blast radius of HIPAA Breach Notification Rule obligations — meaning covered entities and business associates in Aesto's downstream chain are now racing to determine whether their patients' data is involved. If your organization uses Aesto Health services, or operates PHI workloads in AWS, this incident is your incident too.

What defenders should internalize immediately: the attack surface here was cloud infrastructure, not a hospital endpoint or a legacy medical device. That means the detections, hunting queries, and hardening controls that matter live in CloudTrail, IAM, S3, and identity telemetry — not in EDR console alerts on workstations.

Technical Analysis

What We Know

Per the reporting, threat actors accessed Aesto Health's AWS environment and stole a combination of personal and health information. While full forensic details have not been published, the pattern matches a well-established playbook we have seen repeatedly in healthcare cloud intrusions over the past 18 months:

1. Initial access via identity compromise — stolen or abused IAM credentials, leaked access keys, compromised third-party/vendor credentials, or MFA-fatigued/federated identity sessions. In healthcare cloud breaches, the entry point is overwhelmingly an identity problem, not an exploited zero-day.
2. Discovery and enumeration — attackers map S3 buckets, RDS snapshots, EBS volumes, and backup locations containing PHI. AWS CLI enumeration (s3 ls, iam list-*, rds describe-*) is the hallmark of this phase.
3. Collection and staging — bulk reads against S3 objects (GetObject at scale), or creation of database snapshots shared to attacker-controlled accounts.
4. Exfiltration — large-volume egress from S3 or RDS to external infrastructure, often routed through attacker-owned cloud accounts or commodity VPN exits to blend with legitimate cloud traffic.

Why Healthcare Cloud Environments Are Being Picked Apart

Healthcare technology vendors sit at a dangerous intersection: they aggregate PHI from many covered entities, they frequently under-invest in cloud security engineering relative to their data gravity, and they carry significant third-party trust. A single compromised vendor account can yield millions of patient records — exactly the economics we see reflected in the 9.5 million figure here. Ransomware crews and data-extortion groups specifically target healthcare intermediaries because the downstream notification pressure (HIPAA, HHS OCR, state AGs) maximizes leverage.

Exploitation Status

This is confirmed active compromise with completed data theft, not a theoretical exposure. The data has already left the environment. For Aesto's customers and similarly-architected organizations, the correct posture is assume the same techniques are being attempted against your AWS estate right now — because they are. Credential abuse against healthcare cloud tenants is continuous and automated.

Detection & Response

The detections below target the observable behaviors of an AWS-based PHI exfiltration intrusion: anomalous IAM activity, bulk S3 access, snapshot sharing, and unusual egress. These assume CloudTrail is enabled in all regions and ingested into your SIEM. If it isn't, that is your first remediation item.

Sigma Rules

---
title: AWS Bulk S3 Object Access Potential Data Theft
id: 3f8a1c72-6d4e-4b91-a2c7-9e5f0d3b8a41
status: experimental
description: Detects abnormally high volume of S3 GetObject calls from a single principal, consistent with bulk PHI/PII collection prior to exfiltration, as seen in healthcare AWS breaches.
references:
  - https://attack.mitre.org/techniques/T1530/
  - https://attack.mitre.org/techniques/T1567/002/
author: Security Arsenal
date: 2026/04/10
tags:
  - attack.collection
  - attack.t1530
  - attack.exfiltration
logsource:
  product: aws
  service: cloudtrail
detection:
  selection:
    eventSource: s3.amazonaws.com
    eventName: GetObject
  condition: selection
  timeframe: 10m
  aggregation: count() by userIdentity.arn > 1000
falsepositives:
  - Legitimate ETL/backup pipelines using dedicated service roles — exclude known automation ARNs
level: high
---
title: AWS RDS or EBS Snapshot Shared Externally
id: 8c2d4e91-7f3a-4b55-9d61-2a8e6c1f9b07
status: experimental
description: Detects sharing of RDS database snapshots or modification of EBS snapshot permissions to external AWS accounts — a common exfiltration technique for stealing full healthcare database copies without touching S3.
references:
  - https://attack.mitre.org/techniques/T1537/
author: Security Arsenal
date: 2026/04/10
tags:
  - attack.exfiltration
  - attack.t1537
logsource:
  product: aws
  service: cloudtrail
detection:
  selection:
    eventName:
      - ModifyDBSnapshotAttribute
      - ModifySnapshotAttribute
      - CopyDBSnapshot
      - CopySnapshot
  condition: selection
falsepositives:
  - Approved cross-account DR/backup replication — baseline destination account IDs and alert on deviations
level: critical
---
title: AWS IAM Credential Abuse Indicators From Unusual Source
id: 5e1b9f34-2c8d-4a76-b3e0-7d4a1f6c8523
status: experimental
description: Detects IAM enumeration and credential manipulation activity from principals not known to perform administrative duties — consistent with post-compromise discovery in AWS healthcare intrusions.
references:
  - https://attack.mitre.org/techniques/T1087/004/
  - https://attack.mitre.org/techniques/T1098/001/
author: Security Arsenal
date: 2026/04/10
tags:
  - attack.discovery
  - attack.persistence
  - attack.t1098
logsource:
  product: aws
  service: cloudtrail
detection:
  selection:
    eventName:
      - CreateAccessKey
      - CreateLoginProfile
      - AttachUserPolicy
      - AttachRolePolicy
      - PutUserPolicy
      - ListAccessKeys
      - GetCallerIdentity
  condition: selection
falsepositives:
  - Legitimate IAM administration — tune by principal ARN and approved source IP ranges
level: high

KQL — Microsoft Sentinel (AWS CloudTrail via S3/CEF Ingestion)

This query hunts for the composite behavior: a principal performing IAM enumeration followed by high-volume S3 reads — the discovery-to-collection chain we expect in this breach pattern. It assumes CloudTrail data in AWSCloudTrail (Sentinel connector) or CommonSecurityLog.

let lookback = 24h;
let bulk_threshold = 500;
let EnumActivity = AWSCloudTrail
| where TimeGenerated > ago(lookback)
| where EventName in ("ListAccessKeys","ListBuckets","ListObjects","ListObjectsV2","GetCallerIdentity","ListUsers","ListRoles")
| summarize EnumOps=count() by UserIdentityArn=UserIdentityArn, SourceIP=SourceIpAddress;
let BulkReads = AWSCloudTrail
| where TimeGenerated > ago(lookback)
| where EventName == "GetObject"
| summarize ReadOps=count(), BucketsAccessed=dcount(tostring(parse_json(RequestParameters).bucketName))
    by UserIdentityArn, SourceIP=SourceIpAddress
| where ReadOps > bulk_threshold;
EnumActivity
| join kind=inner BulkReads on UserIdentityArn
| project UserIdentityArn, SourceIP, EnumOps, ReadOps, BucketsAccessed
| order by ReadOps desc;
// Secondary hunt: snapshot sharing to external accounts
AWSCloudTrail
| where TimeGenerated > ago(7d)
| where EventName in ("ModifyDBSnapshotAttribute","ModifySnapshotAttribute","CopyDBSnapshot")
| project TimeGenerated, UserIdentityArn, EventName, SourceIpAddress, RequestParameters, AwsRegion
| order by TimeGenerated desc;

Velociraptor VQL — Endpoint Hunt for AWS CLI Exfiltration

If Aesto's attackers touched any managed endpoints or jump hosts (common when engineers' workstations hold cloud credentials), hunt for AWS CLI usage patterns consistent with bulk download and staging. Deploy this artifact across engineering and administrative workstations.

-- Hunt for suspicious AWS CLI usage and staged data archives on endpoints
SELECT Pid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE CommandLine =~ '(?i)aws\s+s3\s+(sync|cp).*(--recursive|s3://)'
   OR CommandLine =~ '(?i)aws\s+rds\s+(copy-db-snapshot|create-db-snapshot)'
   OR CommandLine =~ '(?i)(7z|rar|tar)\s.*\.(db|bak|sql|csv|dmp)'

-- Correlate with established external connections from CLI/tooling processes
SELECT Pid, Name, Ppid, DestAddr, DestPort, Status
FROM netstat()
WHERE Status =~ 'ESTAB'
  AND Name =~ '(?i)(aws|rclone|winscp|filezilla|curl)'
  AND DestPort in (443, 22, 21)

Remediation Script — AWS Hardening Verification

Run this against every AWS account hosting PHI. It checks the controls whose absence most commonly enables breaches of this type: CloudTrail coverage, S3 public exposure, access key hygiene, and logging on sensitive buckets.

#!/bin/bash
# aws-phi-hardening-check.sh — Security Arsenal
# Requires: aws cli v2, jq, appropriate IAM read permissions

echo "=== [1] CloudTrail multi-region coverage ==="
aws cloudtrail describe-trails --query 'trailList[*].{Name:Name,MultiRegion:IsMultiRegionTrail,Logging:IsLogging}' --output table
aws cloudtrail get-trail-status --query 'IsLogging' 2>/dev/null || echo "WARN: verify per-trail status"

echo "=== [2] Publicly exposed S3 buckets ==="
for b in $(aws s3api list-buckets --query 'Buckets[*].Name' --output text); do
  pab=$(aws s3api get-public-access-block --bucket "$b" 2>/dev/null)
  if [ -z "$pab" ]; then echo "EXPOSED-CHECK: $b has NO public access block config"; fi
done

echo "=== [3] Access keys older than 90 days ==="
cutoff=$(date -d '90 days ago' +%Y-%m-%d)
aws iam list-users --query 'Users[*].UserName' --output text | while read u; do
  aws iam list-access-keys --user-name "$u" \
    --query "AccessKeyMetadata[?Status=='Active'].{Key:AccessKeyId,Created:CreateDate}" --output json \
  | jq -r --arg u "$u" --arg cutoff "$cutoff" '.[] | select(.Created < $cutoff) | "STALE KEY: \($u) \(.Key) created \(.Created)"'
done

echo "=== [4] Root account MFA & access keys ==="
aws iam get-account-summary --query 'SummaryMap.{RootMFA:AccountMFAEnabled,RootKeys:AccountAccessKeysPresent}' --output table

echo "=== [5] S3 server access logging on data buckets ==="
for b in $(aws s3api list-buckets --query 'Buckets[*].Name' --output text); do
  log=$(aws s3api get-bucket-logging --bucket "$b" 2>/dev/null | jq -r '.LoggingEnabled // "NONE"')
  [ "$log" = "NONE" ] && echo "NO LOGGING: $b"
done

echo "=== [6] RDS snapshots shared publicly or cross-account ==="
aws rds describe-db-snapshots --include-shared --query 'DBSnapshots[*].{ID:DBSnapshotIdentifier}' --output table 2>/dev/null
echo "Manually verify each shared snapshot's destination account is an approved internal account ID."

Remediation

If You Are an Aesto Health Customer or Business Associate

1. Invoke your incident response and BAA review process today. Confirm with Aesto whether your patients' records are in the affected dataset. HIPAA's Breach Notification Rule (45 CFR §§ 164.400-414) puts notification obligations on covered entities — do not wait passively for the vendor's timeline.
2. Rotate every credential ever shared with or stored in the vendor environment. API keys, SFTP credentials, service accounts, integration tokens. Assume exposure.
3. Pull your own logs for the integration paths. Review SFTP/API access logs to and from Aesto systems for anomalous transfers over the past 12 months.
4. Prepare patient communication and regulatory workflows. HHS OCR reporting for breaches affecting 500+ individuals is mandatory within 60 days of discovery; state attorneys general and, in many states, consumer notification statutes will also apply.

For Every Healthcare Organization Running PHI in AWS

• Enforce phishing-resistant MFA (FIDO2/passkeys) on all human access and eliminate long-lived IAM access keys in favor of IAM Roles Anywhere or SSO with short-lived sessions. Credential theft is the front door in this breach class.
• Enable CloudTrail in all regions with management + data events for S3 buckets containing PHI, shipped to a log archive account the primary account cannot modify. Data events on sensitive buckets are non-negotiable — they are how you see GetObject at scale.
• Deploy S3 Block Public Access at the organization level (SCP), enable Macie for PHI discovery and anomalous access alerting, and turn on GuardDuty with S3 and RDS protection plans in every account and region.
• Baseline and alert on RDS/EBS snapshot sharing. The ModifyDBSnapshotAttribute and ModifySnapshotAttribute events above should be near-zero in steady state; any occurrence warrants an immediate page.
• Apply least-privilege IAM with permission boundaries. The enumeration-to-exfiltration chain only works when the compromised identity has broad read across buckets and databases. Scope service roles to exactly the buckets they need.
• Encrypt PHI with customer-managed KMS keys and restrict decrypt permissions — exfiltrated ciphertext without key access materially reduces breach impact.
• Test the detections above in your environment this week. Run the Sigma rules against your CloudTrail pipeline and validate they fire on a simulated bulk-read scenario.

The Aesto breach is a reminder that in healthcare, your security posture is only as strong as your least-defended vendor's cloud account. Third-party risk assessments that end at a questionnaire are theater — demand evidence of CloudTrail coverage, MFA enforcement, and exfiltration detection from every business associate holding your patients' data.

Related Resources

Security Arsenal Healthcare Cybersecurity AlertMonitor Platform Book a SOC Assessment healthcare Intel Hub