Your AWS Account Got Compromised: The First 24 Hours

This article is not theoretical. We have walked into AWS accounts hours after a compromise, watched attackers spin up GPU fleets for crypto mining across half a dozen regions, and sat through the billing conversations with AWS afterwards. The pattern is remarkably consistent — and so is the playbook that limits the damage. Here is what the first 24 hours should look like, in order, based on incidents we have actually handled.

How you find out (usually too late)

Almost nobody detects the intrusion itself; they detect its side effects:

• A cost anomaly alert — or worse, the monthly bill. Mining fleets show up as sudden EC2/GPU spend in regions you have never used.
• Resources in unfamiliar regions — attackers deliberately use regions you don't watch (São Paulo, Osaka, Cape Town). If you operate only in Frankfurt, anything in ap-northeast-3 is a red flag.
• GuardDuty findings — if it was enabled. In most compromised accounts we enter, it wasn't.
• Quota-increase requests you never made — attackers file EC2 and SES limit increases to scale their operation. An unexplained quota case in your support history is a compromise indicator, not an administrative curiosity.
• SES sending spikes or a block notice — your account has become spam infrastructure.

Root cause, in our experience, is boringly consistent: a long-lived access key leaked — committed to a public repo, baked into an image, pasted into a CI log — or an IAM user with a weak password and no MFA.

Hour 0–1: cut access, don't clean up yet

• 1. Identify the compromised principal. CloudTrail → the resources you didn't create → which access key / user / role created them. Don't skip this: if you rotate the wrong credential, the attacker keeps working while you feel safe.
• 2. Kill the credential. Deactivate the access key, then delete it. Attach an explicit-deny policy to the compromised user/role before deleting sessions — temporary session tokens survive key deactivation, so a deny policy (or revoking sessions on the role) is what actually cuts live access.
• 3. Secure root. Rotate the root password, confirm MFA on root, check root email forwarding rules. If root itself was compromised, this is now an AWS Support conversation — open a case at the highest severity immediately.
• 4. Preserve evidence. Do not delete CloudTrail logs or terminate everything in a panic. You will need the timeline — for forensics, for AWS, and possibly for regulators.

Hour 1–6: containment across every region

• Sweep all regions, not just yours. Script it or use Resource Explorer: EC2 instances, spot fleets, auto scaling groups, Lambda functions, ECS clusters, SageMaker notebooks — in every region. Mining operations we've cleaned up ran in six regions simultaneously; ASGs recreate instances you terminate, so find and delete the ASG first.
• Hunt persistence. Attackers assume you'll find the miners; they plant ways back in. Check for: new IAM users and access keys, new roles with trust policies pointing at external accounts, modified role trust relationships, new Lambda functions with schedules, EC2 instance profiles that got extra policies, and backdoor OIDC/SAML identity providers.
• Check what they touched. CloudTrail tells you whether it was pure resource abuse (mining, spam) or data access: S3 GetObject storms, RDS snapshots shared externally, secrets read from Secrets Manager. The answer changes your legal obligations.
• Quarantine, then rebuild. Anything the attacker touched is untrusted. Snapshot for forensics, then rebuild from clean sources rather than "cleaning" live systems.

Hour 6–24: AWS, money, and obligations

• Open a support case that says "compromised account". AWS has a dedicated flow for this; Trust & Safety gets involved, and their team can see attacker activity you can't.
• Have the billing conversation. AWS routinely reviews unauthorized-usage charges caused by compromise — we have seen five-figure and larger incident bills substantially credited. The conditions that help: you detected and contained promptly, you can show the timeline, and you close the root cause (they will ask). File it as a billing case referencing the security case; be factual and complete.
• Check your notification duties. If personal data was accessed, breach-notification clocks may be running (72-hour regimes under GDPR and, in Türkiye, KVKK). Loop in counsel early — "we're still investigating" is a defensible interim answer; silence is not.
• Write the timeline while it's fresh. Detection time, containment actions, evidence. You will need it three times: for AWS, for any regulator, and for your own postmortem.

The week after: make round two impossible

Every incident we've handled traces back to the same short list, so the hardening list is equally short: eliminate long-lived access keys (use IAM roles and identity federation; scan repos for secrets), enforce MFA everywhere, enable GuardDuty and org-wide CloudTrail with logs in a separate locked-down account, set billing anomaly alerts with daily thresholds, and restrict unused regions via SCP. Our 98-point AWS security checklist covers all of it in checkbox form, and our incident response playbook generalizes this article beyond AWS.

Frequently asked questions

Will AWS refund charges from a hacked account?
There is no contractual guarantee, but in practice AWS reviews unauthorized-usage charges case by case and frequently credits substantial amounts — provided you contained promptly, documented the timeline, and fixed the root cause. Open a billing case referencing your security case.

How do attackers get in?
Overwhelmingly: leaked long-lived access keys (public repos, images, CI logs) and IAM users without MFA. Sophisticated zero-days are the exception; credential hygiene failures are the rule.

Is deactivating the access key enough?
No. Active session tokens can survive key deactivation. Attach an explicit-deny policy to the principal and revoke active sessions on roles, then rotate everything the attacker could have read.

Should we just close the AWS account?
Almost never as a first response — you lose evidence, break legitimate workloads, and don't actually revoke leaked credentials that may work against other accounts. Contain, investigate, then decide.

Bottom line

An AWS compromise is survivable — usually with most of the money recovered — if the first day is executed in the right order: cut access, contain everywhere, preserve evidence, talk to AWS, then harden. The teams that suffer most are the ones improvising that order at 3am for the first time.

In the middle of an incident right now? Our security team runs emergency incident response at €15,000/week with same-day start. Not on fire, but not confident either? The AWS Security Audit (fixed €8,000) finds the leaked-key and missing-MFA problems before an attacker does.