Incident response guide for AWS CloudTrail investigations – Part 1 | Amazon Web Services

What it is

Part 1 of an AWS SIRT walkthrough teaching how to read specific CloudTrail fields during two incident types. The summary names the scenarios and the fields; what it can't carry is the interpretation logic — what each field value proves and how the team chained inferences into a timeline. Part 2 (previewed) covers SSRF → IMDSv1 credential harvesting → cross-Region Bedrock abuse, plus the "root user vs. IAM user named root," role-name imitation, and HIDDEN_DUE_TO_SECURITY_REASONS username tricks.

How it works (the interpretive signatures)

Scenario 1 — scripted deletion tell. The session dev-migration-script on role CrossAccountS3Access was flagged as masquerading only after cross-referencing the session name against source IP and historical deployment logs (no such project authorized). Scripted execution was inferred from timing: 14-minute silence after recon, then three deletions at precise 6–7 second intervals (q4-2024.xlsx, pii-database.csv, prod-database-backup.sql), each returning HTTP 204. Selective targeting of the three highest-value files — not a bulk delete — plus a CLI-on-Linux user-agent, marks automation over manual operation.

Scenario 2 — the CloudShell pivot. The decisive combination:

• mfaAuthenticated: false — session never MFA-verified (the control gap that enabled everything).
• sessionCredentialFromConsole: true — access originated in the console, not external API keys.
• userAgent: exec-env/CloudShell — but execution ran via CloudShell, not manual UI clicks.

Together these show the actor signed in with stolen console creds and launched a prepackaged script from CloudShell, gaining automated speed while evading static API-key monitoring. Stack CRYPTO was created ~50 seconds after session start (18:06:22Z → 18:07:12Z), confirming a prepared script. Role used: AssumedRole usingWSParticipantRole, Region us-east-1.

What to do (detection methodology)

• Pivot on the session token. Filter CloudTrail for the same session token across the full session duration to surface recon, cross-service/cross-Region access, and persistence attempts (new IAM users/access keys) before or after the visible action.
• Treat sessionCredentialFromConsole as the fork for deciding console vs. programmatic investigation paths — console activity has different patterns and needs a different approach.
• Correlate on consistent source IP to find related activity and lateral movement.
• Inspect the CloudFormation template as evidence — instance types (cost/output), security-group network reach to internal resources, user-data scripts pulling mining software, and any IAM roles the stack self-created for lateral movement. If the template was staged in S3, the upload event dates tool staging.
• Confirm exfiltration-before-deletion by searching GetObject/CopyObject on the same objects prior to DeleteObject.
• Cost spikes are a security signal — unexpected EC2 charges in a Region flagged the mining stack.

Caveats

The CloudTrail records shown are redacted, and the CRYPTO scenario is presented partly as a reader exercise; the "50 seconds" and interval timings are the team's inferences from event gaps, not logged intent. Field-value formatting in the source has OCR artifacts (usingWSParticipantRole, andCopyObject).