Cloud IAM Key Exfiltration and the 72-Hour Clock
At 03:22, GuardDuty raises UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS for role svc-reporting, used from an IP in the Netherlands. CloudTrail shows 14,000 S3 GetObject calls on fin-reports-prod in nine minutes, then a DeleteTrail attempt that failed. The access key belongs to an EC2 instance in us-east-1 that has no business reason to call from outside AWS. S3 server access logging was enabled only three weeks ago; bucket versioning is on, but object lock is not. The bucket contains quarterly financial reports with customer account numbers. The company is subject to GDPR and has a 72-hour notification window once a personal-data breach is confirmed. The IR lead must decide containment and notification.
1. What steps confirm whether this is a true compromise versus a misconfigured proxy or pen test?
Read the worked answer
Confirm the source and authorization first. Check whether a penetration test or red-team engagement is active and whether the Netherlands IP belongs to the tester. Review the EC2 instance's metadata and IAM role attachment to see if the key could have been used from outside AWS legitimately; instance credentials should not appear from a foreign IP. Examine CloudTrail for the user agent, event source, and API sequence, and compare with the instance's normal behavior in VPC Flow Logs. Check whether the instance has a NAT or proxy egress that could explain the IP, and whether any recent IAM policy change allowed external use.
The failed DeleteTrail attempt is a strong malicious signal because legitimate operations do not usually try to disable logging during a reporting job. A misconfigured proxy would not normally produce 14,000 GetObject calls in nine minutes followed by a logging tamper attempt. Treat it as a true compromise unless the pen-test owner produces matching authorization and scope.
2. Rank containment actions and explain why deleting the access key first can be harmful.
Read the worked answer
First, preserve evidence: export CloudTrail to a separate logging account, capture S3 access logs, and snapshot the EC2 instance's EBS volumes. Second, disable the access key and attach an explicit IAM deny policy for the role; do not delete the key yet. Third, revoke active sessions with AWS STS and isolate the instance with a security group or network ACL that blocks egress while allowing forensic access.
Deleting the key first is harmful because it removes an important record of key age, attachment, and last-used context, and it may not stop an already-issued temporary session token. Deleting also destroys evidence that could show how the key was exposed. Disabling preserves the artifact while stopping new signatures, and an explicit deny overrides any lingering policy. Revoking sessions addresses the token the attacker may already hold. Snapshots and log exports must precede instance isolation changes that could alter metadata or lose volatile evidence.
3. What notification and evidence-preservation steps apply within the 72 hours?
Read the worked answer
Start the privacy assessment immediately: determine whether the accessed reports contained personal data and which customers and data subjects are affected. Preserve CloudTrail, S3 access logs, GuardDuty findings, VPC Flow Logs, and EBS snapshots with hashes and timestamps; document who accessed each artifact and where it is stored. Keep the compromised instance isolated but not terminated.
Notify the DPO and legal counsel first and use their determination to decide whether the 72-hour GDPR clock has started. If personal data was exfiltrated, prepare a regulator notification with the nature of the breach, categories and approximate number of data subjects, likely consequences, and measures taken. Review customer contracts for additional notification deadlines. Do not notify customers or regulators before legal confirms scope, but do not let that review consume the 72-hour window. If confirmation is delayed, document the reasons and keep a decision log.