NEW: The State of AWS Security 2026 - Free WhitepaperFree AWS Security Whitepaper

CRITICALCredential Compromise20-40 min containment15 steps across 5 phases

Secrets Manager / Credential Leak

Secrets stored in AWS Secrets Manager have been accessed by an unauthorized principal, or secrets have been leaked through logs, code repositories, or application output. This may expose database credentials, API keys, tokens, and certificates that unlock access to downstream systems.

iam

Phase 1: Detection

$ tail -f /var/log/cloudtrail/events.log

Search CloudTrail for secret access events

Identify who accessed secrets and when. Look for GetSecretValue calls from unusual principals or IPs.

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=GetSecretValue \
  --start-time <incident-start> --max-items 50

CloudTrail:GetSecretValueDescribeSecretListSecretsPutSecretValueDeleteSecret

Check for batch secret enumeration

Attackers often list all secrets first, then access them one by one.

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=ListSecrets \
  --start-time <incident-start>

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=BatchGetSecretValue \
  --start-time <incident-start>

CloudTrail:ListSecretsBatchGetSecretValue

Identify the scope of exposure

List all secrets that were accessed during the incident window to understand the blast radius.

aws secretsmanager list-secrets \
  --query 'SecretList[].{Name:Name,LastAccessed:LastAccessedDate}' \
  --output table

Phase 2: Containment

$ ./containment.sh --isolate --immediate

Add a deny policy on the compromised principal

Block the compromised IAM principal from accessing any more secrets.

aws iam put-user-policy \
  --user-name <username> \
  --policy-name DenySecretsAccess \
  --policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Deny","Action":"secretsmanager:*","Resource":"*"}]}'

Add a resource policy to restrict secret access

If you cannot immediately identify the compromised principal, lock down the most critical secrets with a resource policy.

aws secretsmanager put-resource-policy \
  --secret-id <secret-name> \
  --resource-policy '{"Version":"2012-10-17","Statement":[{"Effect":"Deny","Principal":"*","Action":"secretsmanager:GetSecretValue","Resource":"*","Condition":{"StringNotEquals":{"aws:PrincipalArn":"<trusted-role-arn>"}}}]}'

Rotate all compromised secrets immediately

Force immediate rotation of every secret that was accessed during the incident.

aws secretsmanager rotate-secret \
  --secret-id <secret-name> \
  --rotate-immediately

This triggers the Lambda rotation function. Ensure your rotation function is working before forcing rotation.

Phase 3: Eradication

$ ./eradicate.sh --purge --verify

Manually rotate secrets without automatic rotation

For secrets that do not have automatic rotation configured, manually update the secret value and all systems that use it.

aws secretsmanager put-secret-value \
  --secret-id <secret-name> \
  --secret-string '<new-credential-value>'

Audit KMS key usage

Secrets Manager encrypts secrets with KMS. Check if the KMS key was used by unauthorized principals.

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=Decrypt \
  --start-time <incident-start>

CloudTrail:DecryptGenerateDataKey

Check for secrets exposed in application logs

Search CloudWatch Logs and application outputs for accidentally logged secret values.

Phase 4: Recovery

$ ./recovery.sh --restore --validate

Update all downstream systems with new credentials

Update every application, service, and pipeline that uses the rotated secrets.

Verify all rotated secrets work correctly

Test each downstream system to confirm it can authenticate with the new credentials.

Enable automatic rotation on all secrets

Configure rotation schedules for all secrets that do not already have them.

aws secretsmanager rotate-secret \
  --secret-id <secret-name> \
  --rotation-lambda-arn <rotation-function-arn> \
  --rotation-rules '{"ScheduleExpression":"rate(30 days)"}'

Phase 5: Lessons Learned

$ cat POST_INCIDENT_REVIEW.md

Implement least-privilege access to secrets

Each application should only have access to the specific secrets it needs. Use resource-level permissions.

Enable CloudTrail alerting for secret access

Set up EventBridge rules to alert on unusual GetSecretValue or BatchGetSecretValue patterns.

Never log secret values

Audit your application code and logging configuration to ensure secrets are never written to logs, error messages, or debug output.

Need Help with Incident Response?

When an incident strikes, every minute counts. We help AWS teams prepare, detect, and respond to security incidents with proven expertise.

All Playbooks Get in Touch