A Leaked Key, Ninety Days of Logs, and One Anomalous Region

The forensic analyst is right about the sequence, but the window is measured in minutes, not days.

Order:

1. Preserve first, in parallel with containment. Export the relevant CloudTrail events to a separate, write-once location in a different account or bucket. This takes minutes and is irreversible-proof: 90-day retention is a rolling window, and 11 days of exposure already sits inside it.
2. Contain the key. Disable (deactivate) rather than delete the access key. Deactivation is reversible, immediately stops use, and preserves the key ID and any attached metadata for the investigation. Deleting it destroys linkage you may need.
3. Rotate anything the key could reach - the IAM user's credentials, and check whether the key was used to create new users, roles, or keys of its own. Revoking the original key does nothing if a persistence key was minted on day two.
4. Contain the public exposure - enable account-level block public access, then remediate the * bucket policy. Note that block public access may break legitimate workloads; confirm before enabling.
5. Eradicate and recover - review the instance profile, scan the web app for SSRF paths that could reach the metadata service, then restore normal operation.

Disabling first would be defensible only if you had already captured the logs. You have not.

Build the picture from what exists, and be explicit about the gaps.

Available evidence:

• CloudTrail management events: every API call made with that key - source IP, user agent, timestamp, region, and the specific objects requested. This answers "what did they touch and from where" for object-level GetObject calls, because S3 data events recorded via CloudTrail include the bucket and key name if data events were enabled - check this first; if they were not, you only see management-plane activity.
• GuardDuty findings history: the original detection plus any correlated findings in the account.
• Repository history: when the key was committed, whether it was ever truly public, and whether it was scraped. Commit timestamps bound the exposure window.
• The IAM user's permission set: simulate the policy to enumerate exactly which buckets and prefixes were reachable. That defines the maximum possible loss.

Gaps to state plainly:

• With S3 server access logging off and no data events, you may be unable to say which specific PDFs were downloaded. Report that as an evidence gap, not as "nothing was taken."
• With no flow logs, internal lateral movement via the instance profile cannot be ruled out; recommend enabling both going forward.

The honest deliverable distinguishes "confirmed accessed" from "could have accessed". Treat the delta as the breach-notification scope.

The customer is responsible for the bucket - the exposure is a configuration decision, not a provider failure.

Under the shared responsibility model, the provider secures the infrastructure, the availability zones, and the managed service itself; the customer owns identity, permissions, bucket policies, ACLs, and data classification. A bucket policy granting * on GetObject with account-level public-access blocking off is squarely a customer-side misconfiguration. Do not let the conversation drift toward "AWS let this happen" - it will not survive contact with the provider's own documentation.

Recommendations, in order of effect:

1. Account-level block public access, then re-enable selectively only where a public bucket is genuinely required and reviewed.
2. Replace * principals with explicit principals on the offending bucket; if public read is required for a website, serve it through CloudFront with an origin access control.
3. Remove full S3 access from the EC2 instance profile and scope it to specific buckets and prefixes. A web application with instance-wide S3 rights is one SSRF away from the same outcome, and it will not appear in a key-leak report.
4. Add S3 data events and Flow Logs, and extend CloudTrail retention or archive to an immutable store.
5. Secret scanning in CI with push protection, plus pre-commit hooks - the cheapest control in this entire list, and the one that would have prevented the incident.