AWS playbooks #

Playbooks for incidents in Amazon Web Services accounts. Expand a playbook for step-by-step actions; adapt the order to the environment and the rules of engagement, and record each step in your notes as you go. All playbooks.

Playbook - AWS compromise via leaked access keys
  1. Immediately: deactivate the leaked key (don't delete yet, preserve). get-account-authorization-details for IAM snapshot.
  2. Pull CloudTrail from the leak time forward into Athena. Query by userIdentity.accessKeyId.
  3. Build the API call graph - GetCallerIdentity, enumeration calls, then any privilege-grant or persistence calls (CreateAccessKey, UpdateLoginProfile, PutUserPolicy, AssumeRole).
  4. Trace every AssumeRole target - did they chain to broader privileges? Pull all sessions.
  5. Look for exfil - S3 GetObject data events, EBS snapshot sharing, cross-account trust creations, SES usage, RDS snapshot sharing.
  6. Anti-forensics check - StopLogging, DeleteTrail, DisableGuardDutyDetector, KMS ScheduleKeyDeletion, PutBucketLogging changes.
  7. Blast radius - all keys older than X days, all users without MFA, SCPs, external access analyzer results.
  8. Remediate - rotate everything the leaked identity touched, remove persistence, re-enable disabled logs, apply SCP gating, require MFA, enable GuardDuty incl. Malware/EKS/Runtime.
Playbook - BEC / fraud mail sent through Amazon SES

The scenario: someone with the victim's AWS credentials uses Simple Email Service to send invoice fraud or phishing from the victim's own verified domain, so it passes SPF, DKIM and DMARC and lands in partners' inboxes.

  1. Stop the sending: disable account-level sending (aws sesv2 put-account-sending-attributes --no-sending-enabled) in each Region where the account sends, then work out how it happened. Also handle the money question, bank recall and IC3, if partners paid fraudulent invoices.
  2. Preserve: CloudTrail for the window (all Regions). Know the gaps: SES send calls (SendEmail, SendRawEmail ...) are CloudTrail data events, off by default, and mail sent through the SES SMTP interface is never in CloudTrail. Save CloudWatch SES metrics (Send, Delivery, Bounce, Complaint) and any SES event-publishing destinations (configuration sets to CloudWatch / Firehose / SNS) or Mail Manager / VDM data that exist.
  3. Find the identity: SMTP credentials are IAM access keys (console-created SMTP users are named ses-smtp-user.*). In CloudTrail look for CreateUser / CreateAccessKey for such users, policies granting ses:SendRawEmail, and the principal behind any SES management calls.
  4. SES reconnaissance and setup calls (management events, logged by default): GetSendQuota / GetAccount, ListIdentities / ListEmailIdentities, VerifyEmailIdentity / CreateEmailIdentity for new senders, PutAccountDetails (request for production access), sending re-enabled, new configuration sets. A sudden GetSendQuota from an unfamiliar principal is a common first sign of stolen keys being tested for spam.
  5. What was sent and to whom: without data events or event publishing you won't have per-message records. Use SES sending metrics for volume and timing, bounce and complaint notifications, your domain's DMARC aggregate reports (they show SES IPs sending as your domain), and partners' copies of the messages.
  6. Contain: deactivate and delete the keys and SMTP users involved, revoke active role sessions, remove identities the attacker verified, rotate other secrets the principal could reach, then re-enable sending. Warn partners and customers who received mail.
  7. Harden: turn on CloudTrail data events for SES identities (or event publishing) so the next incident has per-message records, restrict ses:Send* with conditions on identity and source, and alert on new SMTP users and on GetSendQuota from unusual principals.
  8. Report with ATT&CK (T1078.004, T1098.001, T1566, T1534 where partners were targeted). See AWS.