IAM Is Where AWS Breaches Start: Seven Years of Incidents, Four Recurring Patterns

In 2019, a server-side request forgery (SSRF) vulnerability in a web application allowed an attacker to issue HTTP requests from the EC2 instance running it. The target of those requests was the EC2 Instance Metadata Service at169.254.169.254. Because the metadata service was running in its default mode — IMDSv1, which requires no authentication — the attacker received temporary AWS credentials for the EC2 instance’s IAM role in the response body.

The IAM role attached to that instance hads3:GetObjectands3:ListBucketson Resource: "*" — covering every S3 bucket in the AWS account. Those credentials provided read access to the data they were ultimately used to access. The facts above are drawn from the DOJ criminal complaint and the company’s own SEC filings.

The SSRF vulnerability in the application is what made the attack possible. But SSRF vulnerabilities exist across an enormous range of codebases — web application firewalls, image processors, webhook handlers, proxy services. The Terraform pattern that determined the blast radius when one was exploited is this: an EC2 instance without IMDSv2 enforcement, attached to a role with broader permissions than the application required.

Neither Terraform attribute is immediately visible as dangerous in isolation. An EC2 instance without a metadata_options block is standard — it is what Terraform produces if you follow the basic provider documentation. An IAM policy with Resource: "*"on specific actions (not wildcards) passes most linter checks. Together, they create the condition where one application vulnerability unlocks an entire S3 account.

Two changes break the attack chain. IMDSv2 requires that the metadata request include a session token obtained through a PUT request — which SSRF vulnerabilities cannot issue (they can only follow redirects, not initiate PUT requests with specific headers). Even if the application vulnerability still exists, the credential retrieval step fails.

Scoping the IAM role to the specific bucket and path the application actually reads limits the blast radius if the IMDSv2 enforcement is somehow bypassed or if credentials are obtained through another vector.

Two separate incidents illustrate this pattern from different angles.

In the LastPass breach (2022), disclosed across a series of security bulletins through early 2023, a threat actor compromised a DevOps engineer’s personal computer through a vulnerability in a third-party media application. That computer had access to a set of static AWS IAM credentials. Those credentials had privileges sufficient to access encrypted customer vault backups — and, because they were long-lived static keys with no expiry, they had been valid and unchanged for long enough to be present on a personal device without any active rotation mechanism. Details are drawn from LastPass’s own security bulletins published in November 2022, December 2022, and March 2023.

In the Sisense compromise (2024), addressed in CISA Alert AA24-101A, credentials including AWS access keys were found in a self-managed GitLab repository. When the repository or the instance hosting it was accessed by the threat actor, those credentials provided direct access to cloud storage containing customer data. The alert notified organisations that use Sisense to rotate any credentials that the product had access to.

The connecting thread: static, long-lived IAM access keys are credentials that exist in files, in environment variables, in developer toolchains, and in version control history. Unlike short-lived STS credentials (which expire in minutes to hours), a static key remains valid until it is explicitly rotated or deleted — which often does not happen until after a breach.

Creating an IAM user with a static access key is the default pattern for granting CI pipelines AWS access. It is what most Terraform tutorials demonstrate. It is also what stores the secret access key value in Terraform state — which itself must be stored somewhere, encrypted or not.

OIDC federation eliminates static keys from the CI picture entirely. The CI platform authenticates with AWS using a signed JWT token issued by the CI platform’s own identity provider (GitHub, GitLab, CircleCI all support this). AWS STS verifies the token against the registered OIDC provider and issues short-lived credentials — typically valid for one hour — that are scoped to the trust policy conditions.

The Condition block on the assume-role policy is critical: without it, any GitHub Actions workflow in any repository could assume the role. Scoping to a specific repository and branch via thesub claim limits the role to exactly the deployment workflow that needs it.

Lambda functions need IAM permissions to interact with other AWS services. The fastest way to get a Lambda working is to give its execution role broad permissions, deploy, iterate on the function logic, and plan to “tighten the permissions later.” Later rarely comes.

The blast radius of an overly permissive Lambda execution role depends on what the Lambda can reach with those permissions. For a Lambda that can call any AWS API on any resource, a code injection vulnerability — a deserialization bug, an unsafe eval, an SSRF in Lambda that reaches the metadata service — translates directly to full account access.

Checkov’s CKV_AWS_40 checks for the AdministratorAccess managed policy attached to a Lambda role. It does not check for Action: "*" in inline policies — a common alternative that provides the same access through a different mechanism.

The correct approach is to enumerate exactly which API calls the Lambda function makes and grant only those — scoped to the specific resources the function interacts with. This is more work than a wildcard, but it can be done once at the time the function is deployed and updated when the function’s dependencies change.

The three statements in the fixed policy below cover what a typical SQS-triggered Lambda that writes to DynamoDB and emits logs actually requires. Nothing more.

In January 2025, security researchers at Halcyon documented a threat actor they named Codefinger — the first publicly documented ransomware campaign using AWS’s own encryption infrastructure against its customers.

The attack mechanism: the threat actors obtained valid AWS IAM access keys (through means consistent with credential exposure, though the initial access method has not been fully disclosed publicly). They then used those keys to re-encrypt victim S3 objects using SSE-C — Server-Side Encryption with Customer-Provided Keys. In SSE-C, the encryption key is provided by the caller and is never stored by AWS. The attackers provided a key they controlled; without that key, neither the victim nor AWS can decrypt the objects.

The IAM condition that enabled this: the access keys had sufficient S3 permissions and no MFA requirement. An attacker with the key alone — no second factor — could perform the full re-encryption. The AWS Security Bulletin issued at the time recommended restricting s3:PutObject permissions and auditing IAM credentials.

The pattern is not specific to SSE-C: any high-privilege IAM user without MFA enforcement is a single credential away from full exploitation.

Terraform has no built-in mechanism for enforcing MFA — the enforcement lives in IAM policy conditions attached to the user or their group. Without explicit MFA condition policies, IAM users with static access keys can perform any permitted action with the key alone.

A deny-without-MFA policy, applied to the user or their group, blocks any API call that is not on the MFA-enrollment exception list unlessaws:MultiFactorAuthPresentis true in the session. The key detail is theBoolIfExistscondition operator — it applies the condition even when the key is not present in the request context, which is the case for programmatic access without an MFA session.

GuardDuty is a runtime threat detection service. It analyses CloudTrail events, VPC Flow Logs, and DNS logs for anomalous behaviour patterns — credentials used from an IP address not previously seen for that account, unusual S3 data exfiltration rates, IAM enumeration from a Tor exit node.

GuardDuty is genuinely useful: it is one of the cheapest per-finding signals available for active credential abuse and lateral movement. Enable it.

What GuardDuty cannot do: evaluate Terraform before deployment. GuardDuty begins producing signals only after a resource is deployed and generating CloudTrail events. An overly permissive Lambda execution role, an IAM user without MFA enforcement, or an EC2 instance with IMDSv1 enabled — none of these produce any GuardDuty finding simply by existing. They produce findings only when they are actively exploited.

The Codefinger attack was caught by security researchers studying victim reports — not by GuardDuty findings surfaced before the re-encryption occurred. The detection-after-exploitation model is the fundamental limitation of any runtime signal when the risk lies in a configuration.

Enable GuardDuty. But treat pre-deployment IAM review as a distinct and necessary layer — not a substitute for runtime detection, and not something that runtime detection makes redundant.

The AWS Shared Responsibility Model divides security into two domains: security of the cloud (AWS’s responsibility — physical facilities, hardware, hypervisor, IAM service availability) and security in the cloud (your responsibility — what you configure in IAM, which principals you trust, what permissions you grant).

For IAM specifically, this means: AWS guarantees that the IAM service enforces the policies you write, that OIDC token verification is correct, and that the metadata service behaves as documented. AWS does not guarantee that the policies you write are appropriate for your workload, that the roles you create are scoped correctly, or that the IAM users you create have MFA enforced.

Every pattern in this post is in the customer’s half of the responsibility model. Which means it is configurable in Terraform, reviewable before deployment, and fixable before any attacker has had a chance to exploit it.

This is the operational conclusion from seven years of incidents: the conditions that determined the blast radius of each breach were in place in Terraform (or its predecessor configurations) before the breach occurred. The SSRF vulnerability, the compromised personal machine, the phishing email — those were the triggers. The IAM configuration was what determined whether triggering those vulnerabilities resulted in a critical incident or a near-miss.

For a broader treatment of the six-step architecture review process and how IAM review fits within the full Well-Architected Security pillar evaluation, see the Terraform Architecture Review: A Complete Guide.