# how to respond to an AWS access key exposure alert

## TL;DR
Deactivate the exposed key immediately, then use CloudTrail to find out what it did between exposure and deactivation. Rotate anything it could have touched, delete the key once you are sure nothing legitimate needs it, and find how it leaked so it does not happen again. Speed matters more than elegance here: revoke first, investigate second.

## The query
```text
how to respond to an AWS access key exposure alert
```

## Use this when
- GuardDuty, GitHub secret scanning, or an employee reports an exposed AWS key
- someone asks "what do I do when an access key leaks"
- you need the CloudTrail queries that show what a key did
- you are writing the runbook before you need it

## Not for this skill when
- the key belongs to a different cloud (same ideas, different console)
- you only suspect exposure with no evidence (rotate proactively, lighter process)
- you are setting up key-leak prevention (pre-commit hooks and secret scanning, different skill)

## Steps
1. Deactivate the key now: in IAM, set the key status to Inactive (do not delete yet; you need it for the investigation).
   Expected output: the key shows Inactive and new API calls with it fail.
2. Find the exposure window: note when the key was published or committed and when you deactivated it.
   Expected output: a start and end timestamp bounding the investigation.
3. Query CloudTrail for the key's activity in that window: filter events by the access key ID and look for iam CreateUser, AttachUserPolicy, ec2 RunInstances, and any unusual regions or services.
   Expected output: a list of every API call the key made, or an empty list if it was never used.
4. If the key did anything malicious, treat it as a full incident: isolate affected resources, snapshot volumes before terminating, and assume persistence until proven otherwise.
   Expected output: a contained environment with evidence preserved.
5. Rotate what the key could reach: database passwords, other keys on the same user, tokens in the same repo.
   Expected output: nothing the exposed key touched is still valid.
6. Delete the deactivated key, fix the leak source (remove from history, fix the logging that printed it, revoke the paste), and document the timeline.
   Expected output: the key is gone, the leak vector is closed, and the timeline is written down.

### Variant: key found in a public repo
Assume it was used. GitHub secret scanning notifies AWS automatically, but run the CloudTrail check yourself anyway and rotate everything in that repo.

### Variant: key exposed in logs
Scrub the logs, fix the logger to redact credentials, and rotate. Log pipelines keep old copies, so check retention and replicas.

### Variant: automated response
A Lambda on the GuardDuty finding can deactivate the key automatically. Keep a human in the loop for the investigation, but let the machine do the revoking in seconds.

## Why this happens
Access keys are bearer credentials: whoever holds the string has the permissions. Keys leak through committed code, pasted logs, screenshots, and chat messages, and scanners plus attackers both watch for them continuously. The window between leak and revocation is the whole game.

## Edge cases and pitfalls
- Deleting the key before investigating destroys your ability to query its history cleanly. Deactivate first, delete last.
- Service accounts using the key will break when you deactivate. Identify legitimate users of the key before you pull it, or have the replacement ready.
- CloudTrail has a delay of several minutes. Re-run your queries after 15 minutes to catch late-arriving events.
- If the attacker created new IAM users or keys, revoking the original key is not enough. Audit IAM for anything created in the window.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_zj6KMrH_luNmlkVyYACIHw