Credential Compromise

Credential Compromise occurs when AWS credentials (access keys, secret keys, session tokens, console passwords) are exposed to unauthorized parties. This is the most common and dangerous AWS security incident, and the speed at which it unfolds surprises most teams: keys pushed to a public repository are routinely discovered and abused by automated scanners within minutes, not days.

How Credentials Get Compromised

• Git Commits: accidentally pushed to public repositories (GitHub, GitLab)
• SSRF Attacks: exploiting IMDSv1 to steal EC2 instance role credentials
• Logs: credentials printed in application logs or CI/CD output
• Phishing: social engineering targeting console passwords
• Malware: credential-stealing malware on developer machines
• Third Parties: shared credentials with contractors or SaaS services

Immediate Response

1. Disable the compromised credentials (deactivate access key, revoke sessions)
2. Assess impact via CloudTrail - what did the attacker do?
3. Contain: apply deny-all policy to the compromised identity
4. Eradicate: remove any backdoors (new IAM users, roles, policies created by attacker)
5. Recover: rotate all related credentials, restore any modified resources

How It Goes Wrong in Practice

The textbook incident starts with a developer committing a .env file or a hardcoded key pair to a public GitHub repository. Scanners operated by attackers watch the public commit stream continuously, so the key is tested and abused within minutes. The typical first actions are reconnaissance calls, then resource creation for cryptomining (EC2 spot fleets, SageMaker jobs) or, increasingly, Bedrock model invocations billed to the victim. AWS also scans public repositories: when it detects an exposed key it opens a support case and attaches the managed policy AWSCompromisedKeyQuarantineV3 to the affected user. That policy denies a long list of high-abuse actions (running EC2 instances, creating IAM users and keys, invoking Bedrock models, deleting S3 objects, and more), but it is a damage limiter, not a fix. The recurring mistake is treating the quarantine policy or the key deactivation as the end of the incident. Attackers know they have a short window, so the first thing a competent one does is create persistence: a new IAM user, a second access key on an existing user, or a role with a trust policy pointing at their own account. If you rotate the leaked key but skip the CloudTrail review, you have locked the front door while the attacker holds a copy of the back door key.

A Practical Check: Tracing What a Key Actually Did

First, kill the key, then pull its history. Deactivate rather than delete so the key ID stays visible in your investigation:

aws iam update-access-key --user-name ci-user --access-key-id AKIAIOSFODNN7EXAMPLE --status Inactive

Then query CloudTrail for everything that key did:

aws cloudtrail lookup-events --lookup-attributes AttributeKey=AccessKeyId,AttributeValue=AKIAIOSFODNN7EXAMPLE --start-time 2026-07-01T00:00:00Z

The lookup-events command covers the last 90 days of management events in the Region you query, returns up to 50 events per page, and is rate limited to two requests per second. Pay particular attention to iam:CreateUser, iam:CreateAccessKey, iam:CreateRole, iam:UpdateAssumeRolePolicy, and sts:AssumeRole events: those are the persistence and pivot moves. For investigations older than 90 days you need a CloudTrail trail delivering to S3, queried with Athena.

Reducing the Odds

Most compromises are preventable with unglamorous hygiene: prefer IAM roles and temporary credentials over long-lived access keys, enforce IMDSv2 on EC2 so SSRF cannot reach instance credentials, run secret scanning in CI and as a pre-commit hook, require MFA on console access, and alert on GuardDuty findings that indicate credential misuse, including instance credentials being used from outside AWS.

Frequently Asked Questions

Can I revoke a leaked session token?

Not directly. STS session tokens remain valid until they expire. The mitigation is attaching a deny policy to the role with an aws:TokenIssueTime condition, which invalidates every session issued before the timestamp you set, then letting legitimate workloads re-assume the role.

Is rotating the exposed key enough to end the incident?

No. Rotation stops that one credential. You still have to review CloudTrail for persistence mechanisms (new users, keys, roles, modified trust policies) and remove them, otherwise the attacker walks back in with credentials you never knew existed.

How far back can I investigate API activity?

The CloudTrail LookupEvents API covers 90 days per Region. Anything older requires a trail that was already delivering events to S3 or CloudWatch Logs, which is one of the strongest arguments for configuring an organization trail before you ever need it.