A typical AWS hack does not begin with a zero-day; it begins with a credential that should never have been exposed, and it ends with an attacker using your own IAM permissions against you. Understanding the real path an AWS compromise takes, from initial access to impact, is what lets you close the doors that matter. This is a defensive walkthrough of how these incidents unfold and the concrete controls that stop each stage.
Initial access: leaked and over-scoped credentials
The overwhelming majority of AWS intrusions start with valid credentials, not broken software. An access key gets committed to a public GitHub repo, baked into a Docker image, pasted into a support ticket, or left in a laptop that walks off. Automated scanners crawl public code continuously; a live AWS key can be found and used within minutes of being pushed.
The defenses here are unglamorous and effective. Stop minting long-lived IAM user access keys at all where you can, and use short-lived credentials from IAM roles, IAM Identity Center, or OIDC federation for CI/CD instead. Scan every commit for secrets before it lands, and scan your build artifacts too, because keys hide in image layers as often as in source. If a key does leak, rotation speed is everything, so make rotation a one-command operation you have actually practiced. Turn on GuardDuty, which flags anomalous credential use like a key from your CI suddenly calling from a residential IP in another country.
Discovery: what the attacker does first
Once inside, an attacker's first move is reconnaissance, and they use the same API calls your engineers use. They enumerate their own permissions and look at what the environment contains:
# The attacker is mapping their blast radius, not exploiting anything yet
aws sts get-caller-identity
aws iam get-account-authorization-details
aws s3 ls
This stage is quiet because none of it is inherently malicious. Your leverage is CloudTrail. Every one of those calls is logged, and a burst of enumeration API calls from a principal that normally only does three things is a strong signal. Make sure CloudTrail is on in every region, delivered to a bucket the workload account cannot alter, and wired to alerts for reconnaissance patterns. An attacker who can turn off your logging first has already won, so protect the trail itself.
Privilege escalation: turning a foothold into control
A limited credential is only a starting point. AWS privilege escalation abuses legitimate IAM features when policies are too loose. Classic paths include a principal allowed to attach policies to itself, to create a new access key for a more powerful user, to pass a powerful role to a service it can invoke, or to edit a Lambda function that already runs with an admin role. None of these are bugs in AWS. They are the predictable result of policies that grant iam:* or *:* "to save time."
The countermeasure is least privilege enforced by tooling, not willpower. Use IAM Access Analyzer to find policies that are broader than the access actually used, and tighten them toward the real usage. Forbid wildcards in IAM actions during code review of your infrastructure-as-code. Add permission boundaries so that even a compromised admin-ish role cannot exceed a hard ceiling. Every one of these shrinks the distance between a foothold and full account control.
Impact: exfiltration, ransom, and abuse
The end goals cluster into a few patterns. Data theft, most visibly from misconfigured S3 buckets left public or over-shared. Resource abuse, where the attacker spins up expensive GPU instances for cryptomining and leaves you the bill. And increasingly, extortion, where data is copied out and the originals deleted or encrypted.
Block public S3 access at the account level with S3 Block Public Access so an individual bucket cannot be made public by mistake. Enable versioning and MFA delete on buckets that hold anything you cannot lose, so deletion is recoverable. Set billing anomaly alerts that fire when spend spikes, because a mining campaign shows up on the invoice before you might otherwise notice. And keep backups in a separate account with separate credentials, so a compromise of the production account does not reach the backups.
S3 misconfiguration: the most common single mistake
Because it comes up so often, S3 deserves its own note. The recurring failure is a bucket policy or ACL that grants access to "Principal": "*" or to AllUsers, usually added to make a quick demo work and never removed. Audit for it directly:
# Review the account-level public access block
aws s3control get-public-access-block --account-id 111122223333
If any of the four block settings are false without a documented reason, that is a finding. Treat public-by-default as the exception you justify, not the state you drift into.
Building a defensible AWS account
Stepping back, the through-line of every AWS hack is that attackers use your identity and configuration rather than exploiting AWS itself. So the highest-leverage investments are identity hygiene and configuration monitoring, not exotic tooling. Enforce MFA on every human principal, especially the root account, which should then be locked away and never used. Prefer federated, short-lived access over static keys. Enable CloudTrail, GuardDuty, and Config across all regions and route their findings somewhere a human sees them. And treat your infrastructure-as-code and dependencies as part of the attack surface, because a compromised build pipeline is a direct route into the account. Our SCA product page covers how pipeline and dependency risk feed into cloud exposure, and the Safeguard Academy has hands-on cloud hardening material.
FAQ
How do most AWS accounts actually get hacked?
Through leaked or over-privileged credentials, not software exploits. A key ends up in public code, an image, or a shared file, gets discovered by automated scanners, and is used to enumerate and escalate within the account. Secret scanning, short-lived credentials, and least privilege address the root cause.
Can attackers break into AWS through a vulnerability in AWS itself?
That is rare. AWS's own platform is heavily hardened, and the shared responsibility model means most incidents happen on the customer's side of the line: identity, configuration, and application code. Your controls, not AWS's, are usually the deciding factor.
What is the single most important AWS security control?
If forced to pick one, enforce multi-factor authentication everywhere and eliminate long-lived access keys in favor of short-lived, role-based credentials. Identity is the primary attack surface, so hardening it delivers the most risk reduction.
How do I know if my AWS account has been compromised?
Watch CloudTrail and GuardDuty for anomalies: credential use from unusual locations, bursts of enumeration API calls, new IAM users or keys you did not create, and unexpected resource launches or billing spikes. Those signals catch most active intrusions if someone is actually monitoring them.