Your AWS Account Got Hacked. What Happens Now?

Transcript

1. Your AWS Account Got Hacked. What Happens Now? Sena Yakut, 2025
2. Sena YAKUT Cloud Security Architect @CyberWhiz AWS Security Hero
3. Imagine you wake up to a $20,000 AWS bill… your EC2 instances are mining crypto in Singapore, and your S3 bucket data is gone. So what do you do now?
4. Understanding the Attack Surface • Publicly leaked credentials, • Publicly resources, • Unrestricted IAM roles, • No MFA or weak console passwords, • Compromised access keys in CI/CD, • Over-permissive IAM policies, • Unused resources, • SSRF cases, • Cloud parameter misconfigurations, • AND MORE. Everyday, a new attack path is discovered.
5. What Actually Happens After a Cloud Breach
6. Scenario: “The Compromised EC2 Instance” Background: You’re a cloud engineer managing an AWS account for your startup. One morning, your billing alarm triggers → your EC2 costs is $10000. You check the AWS Console and see several unrecognized EC2 instances running in unfamiliar regions. This is where our journey begins.
8. Step 1: Detect → Identifying the Breach Indicators: • AWS Billing alarm shows sudden cost increase. • GuardDuty findings: • “CryptoCurrency:EC2/BitcoinTool.B” • “UnauthorizedAccess:EC2/MaliciousIPCaller.Custom” • CloudTrail logs show instance launches from a new IAM user: test-admin. Goal: Confirm that an EC2 instance has been launched or modified by an attacker.
9. Step 2: Contain → Stopping the Damage Immediate actions: Isolate the compromised EC2 instance. $ aws ec2 modify-instance-attribute --instance-id i-12345 --no-source-dest-check $ aws ec2 modify-instance-attribute --instance-id i-12345 --groups sg-isolated Revoke or disable the attacker’s IAM user. Detach IAM roles or policies from compromised instances.
10. Step 3: Investigate → Understanding What Happened What to check: • CloudTrail → Actions performed by test-admin • GuardDuty → Alerts in unfamiliar regions • VPC Flow Logs → Suspicious inbound/outbound IP traffic And if you’re lucky or done right… • The attacker didn’t disable CloudTrail or GuardDuty. • You actually have multi-region logging enabled. • The CloudTrail S3 bucket wasn’t deleted or public. • You find evidence before it’s wiped. • Or even better → your automation caught it first!
11. Your future security investigation depends on today’s logging.
12. Step 4: Eradicate → Removing the Threat • Terminate the compromised instance. • Delete unauthorized users, roles, and access keys. • Rotate all IAM credentials. • Run malware scan on any AMIs created from the compromised EC2.
13. Step 5: Recover → Restore and Harden • Launch a clean EC2 instance from a trusted AMI. • Restore configurations and data from verified backups or snapshots. • Re-enable CloudTrail and GuardDuty in all regions. • Apply least-privilege IAM roles and ensure MFA enforcement.
14. Step 6: Postmortem → Learn and Improve Lessons learned: • The attacker used an exposed access key from a public GitHub repo. • CloudTrail logging was not enabled in all regions — critical blind spot. • Response took 2 hours because no automated isolation process existed. Actions: • Automate detection → EventBridge + Lambda alert for GuardDuty findings. • Enable cross-region CloudTrail. • Create a Security Incident Runbook for EC2 compromises.
15. Thank you!