Hunting in CloudTrail — Finding the Attack in the Noise

Understanding the CloudTrail format is one thing. Actually using it to find attacker activity is another.

n this article, we walk through the most common CloudTrail investigation scenarios — tracking who logged into the console, detecting new API keys being created, finding evidence of exposed keys being abused, and running proactive threat hunts.

Scenario 1: Tracking Console Logins

Console logins leave a specific CloudTrail footprint.

The event is called ConsoleLogin from eventSource: signin.amazonaws.com.

Key fields: ARN (which account) eventTime (UTC), sourceIPAddress (browser IP), userAgent (browser), responseElements.ConsoleLogin (Success/Failure), additionalEventData.MFAUsed (Yes/No).

Example log (modified):

userIdentity.arn = arn:aws:iam::417823659031:user/Dean, sourceIPAddress = 82.114.73.19, ConsoleLogin = Success, MFAUsed = No.

Red flags: MFA not used, unfamiliar IP, unusual browser.

💡 IR Tip: AWS does not enforce MFA on IAM users by default — unlike Azure. If you land on an incident and find most users don't have MFA enabled, that's a systemic finding worth documenting.

Scenario 2: Detecting New API Key Creation

When an attacker compromises an account, one of the first things they do is create new API keys for persistence — even if the original password gets changed.

The CloudTrail event to look for is CreateAccessKey.

Key fields: ARN of who created it, eventTime, userAgent (console vs CLI vs API), sourceIPAddress, requestParameters.userName (which user the key is for), responseElements.accessKey.accessKeyId (the actual key ID created).

Example:

eventName = CreateAccessKey, sourceIPAddress = 91.200.14.77, requestParameters.userName = svc-billing, responseElements.accessKey.accessKeyId = AKIAXYZ98765LMNOQRST.

If the account making the request is NOT svc-billing — that's a pivot. An attacker creating keys on service accounts is classic persistence.

Scenario 3: Finding Evidence of Exposed API Keys

Exposed API keys trigger a burst of IAM enumeration calls in CloudTrail from a single IP in a

short timeframe: ListUsers, ListRoles, GetPolicy, GetPolicyVersion, ListAttachedUserPolicies, SimulatePrincipalPolicy.

The attacker is looking for shadow admin roles — overpowered accounts the organisation forgot about.

💡 IR Tip: Filter CloudTrail by the specific AKIA key ID you're tracking. Every API call made with that key shows up — gives you the complete activity timeline from the moment it was first used.

API Calls That Return Credentials — The Pivot List

These API calls all return new credentials that can be used to impersonate a different role or service:

• iam:CreateAccessKey — creates a new permanent API key

• sts:AssumeRole — temporarily assumes another IAM role's permissions

• sts:AssumeRoleWithSAML — assumes a role via federated authentication

• sts:GetFederationToken — returns temporary credentials via federation

• cognito-identity:GetCredentialsForIdentity — returns credentials via Cognito

• redshift:GetClusterCredentials — returns credentials for a Redshift database

---------------------------------------------------------------------------------------------------

CloudTrail Threat Hunting Scenarios

• Impossible Travel — same account logs in from London at 09:00 and Sydney at 09:45. Physically impossible.

• New Source IPs — build a 30-60 day baseline of known IPs per account. New IPs on privileged accounts need scrutiny.

• API Keys Accessing Console — AKIA-prefixed keys generating ConsoleLogin events = attacker using stolen credentials.

• GPU Instance Creations — crypto mining abuse. Look for RunInstances where instanceType contains g4, g5, p3, p4.

• New Accounts with Admin Roles — CreateUser followed by AttachUserPolicy for the same new user = persistence.

---------------------------------------------------------------------------------------------------

⚡ Update (2024): GuardDuty now includes many of these as automated detection rules — impossible travel, credential exfiltration patterns, cryptomining detection. Enabling GuardDuty removes the need to write these hunts manually, but understanding the CloudTrail logic makes you a far better investigator when you need to go beyond what GuardDuty surfaces.

-------------------------------------------------------------------------------------------------------------

What's Next

Next Article covers EC2 instances, EBS volumes, and snapshot-based evidence collection — how to capture a disk image from a running AWS instance without taking it offline.

-----------------------------------------------Dean------------------------------------------------