You discover AWS access keys committed to a public S3 bucket at 2 AM. Walk me through your response.
Expected Points
- ✓Immediately revoke or rotate the exposed keys — do not wait to investigate first. Use AWS IAM to disable or delete the access key pair.3
- ✓Query CloudTrail for all API calls made with those credentials, focusing on the window from when they were first exposed to now. Look for data exfiltration, new IAM users/roles, and unusual resource creation.3
- ✓Check S3 access logs and CloudTrail S3 data-plane events to determine if the bucket was accessed by unauthorized parties and what was read or downloaded.2
- ✓Escalate to the on-call security lead and relevant stakeholders (engineering, legal if PII may be involved) per the incident response plan — do not handle solo.2
- ✓Determine how the keys ended up in S3: CI/CD misconfiguration, hardcoded credentials in code, a misconfigured secrets manager, etc. Preserve evidence before remediation.2
- ✓Restrict the S3 bucket's public access (Block Public Access setting) and audit other buckets for similar exposure.1
- ✓File a post-mortem and implement systemic fixes: secrets scanning in CI (e.g. git-secrets, truffleHog), short-lived credentials (OIDC/AssumeRole), and S3 public-access guardrails via SCPs or AWS Config rules.2
Effective incident response here combines speed, containment, forensics, and communication. Rotate or revoke credentials immediately, then investigate blast radius before filing the post-mortem and fixing the root cause that allowed secrets to land in S3.