Identify IAM Breaches with CloudTrail and Athena

What this lab covers

You configure CloudTrail delivery, stand up Athena over the resulting log files, and write queries that identify credential attacks against IAM users rather than reading events one at a time.

The lab teaches a workflow rather than a product. The queries you write here are the ones you would run in a real incident, and the skill of expressing an investigative question as SQL is what makes large log volumes tractable.

It suits anyone doing cloud incident response or detection engineering. No prior Athena experience is assumed, and it pairs naturally with any lab where the question is what an attacker did rather than how they got in.

How querying CloudTrail at scale works

CloudTrail delivers compressed JSON files to S3 on a schedule. That format is durable and cheap but not queryable, and the console view is limited in both retention and expressiveness, which is why it is adequate for spot checks and useless during an incident.

Athena reads directly from those files in place using SQL. There is no cluster to run and no ingestion step, which matters during an incident because you can be querying months of history within minutes rather than waiting on a pipeline. Partitioning by date and region is what keeps queries fast and costs sensible, since Athena charges by data scanned.

Credential attacks have a distinctive shape in this data. Password spraying trades depth for breadth, attempting one or two passwords across many accounts to stay under lockout thresholds, so it appears as a wide, shallow pattern of failures rather than a concentrated burst against one user. That shape is easy to express as a query and nearly invisible when reading events individually.

How to detect this in your own environment

Query for failures grouped by source rather than by user. A single address failing against many distinct usernames in a short window is the signature of spraying, and grouping the other way round hides it completely.

Pay particular attention to console sign-in events, which record whether multi-factor authentication was used. An account with a successful sign-in and no second factor is the highest-priority finding in this dataset, regardless of whether anything else looks wrong.

Watch for the success that follows the failures. The transition from many failures to one success from the same source is the moment the incident starts, and it is often the only clean timestamp you will get for initial access.

How to prevent it

Enforce multi-factor authentication on every human identity, without exception for administrators. Password spraying is only viable where a correct password is sufficient, so this converts a likely compromise into a logged failure.

Move humans off IAM users entirely and federate through an identity provider. That centralises authentication policy, conditional access and monitoring in one place, and removes the standing console credentials that spraying targets.

Partition and lifecycle your log storage before you need it. Investigations fail as often on cost and query time as on missing data, and a trail nobody can afford to query is not much better than no trail.

Real-world context

Password spraying against cloud identity is one of the most consistently reported intrusion techniques, precisely because it defeats lockout policies that were designed for repeated attempts against a single account. It requires no exploit and scales cheaply.

The pattern is well documented under MITRE ATT&CK T1110.003 Password Spraying, and the follow-on use of the resulting credentials under T1078.004 Cloud Accounts. Both describe activity that is entirely legitimate at the level of any individual request.

For defenders the significant point is that the evidence is almost always already collected. Organizations that cannot answer whether they were sprayed usually have the CloudTrail data and no practical way to query it, which is a tooling gap rather than a visibility gap.

Applying this at work

• Stand up Athena over your existing CloudTrail bucket before you need it, and partition it by date and region.
• Save a small library of investigative queries: failed sign-ins grouped by source, sign-ins without a second factor, and first-time API actions per principal.
• Confirm multi-factor authentication is enforced on every human identity, then verify it by query rather than by policy review.
• Check your log retention against the time it realistically takes you to detect an incident. Thirty days of logs and a ninety day dwell time is not a working combination.
• Run one query today for successful console sign-ins without a second factor. It takes minutes and frequently surfaces something.

Frequently asked questions

Why use Athena instead of the CloudTrail console?

The console has limited retention and cannot express aggregate questions. Athena runs SQL directly over the log files in S3 with no ingestion step, which is what makes questions like failures grouped by source address across months answerable.

What does password spraying look like in CloudTrail?

A wide, shallow pattern: one or two attempts against many distinct usernames from the same source, deliberately staying below lockout thresholds. It is obvious when you group failures by source and almost invisible when reading events individually.

Does Athena get expensive on large trails?

It charges by data scanned, so cost is controlled by partitioning. Partitioning by date and region means a query covering one week scans one week of data rather than the entire bucket.

Do I need my own AWS account to practice this?

No. The lab runs in a live AWS environment that Pwned Labs provisions for you, so there is nothing to set up and no risk to your own infrastructure.

Which certification covers this in depth?

The Amazon Cloud Red Team Professional (ACRTP) covers AWS attack paths and the detection opportunities against them, and is assessed hands-on in a live AWS account.