LetsDefend: AWS Bucketware — thinking your way through CloudTrail

Set yourself up before you start. I extracted every zip I needed up front and put my files in chronological order so I could follow a clean timeline. Small thing, big difference.

Build a cheat sheet first#

Before reading a single log, get a list of AWS API calls grouped by attacker intent — reconnaissance, persistence, exfiltration. Ask an LLM for a table, or pull one from AWS documentation.

It won't be exhaustive. It doesn't need to be. It gives you a shortlist of what to Ctrl+F for instead of reading thousands of events hoping something jumps out.

Keep it open on a second screen.

Which identity was compromised?#

I started by reading a handful of logs just to get a feel for normal. The IAM admin looked entirely legitimate — nothing odd about what it was doing.

Then the S3 user started making calls it had no business making. It was getting AccessDenied on ListIdentities — not authorised, because no policy attached ever allowed it.

That's the tell, and it's a behavioural one rather than a technical one:

As I went, I kept a notepad open and wrote down every API call that matched my cheat sheet and every user that looked off. That list becomes the answer to several later questions.

The reconnaissance calls#

Same method — Ctrl+F inside the log files for calls from your shortlist: ListBuckets, ListObjects, GetBucketAcl, GetBucketPolicy.

GetBucketAcl is worth flagging as soon as you see it, because an access control list tells the attacker who has what permissions on the bucket. That's exactly what you'd check before deciding whether an attack is worth attempting.

Here's the trick for ordering them. Reconnaissance comes before the attack. So find the first call where they actually did something — and the recon calls are the ones immediately before it.

Persistence#

Put yourself in their position. You have credentials in an AWS environment and you want to keep access. What do you do?

You create a user.

So look at the user list and find the ones that don't belong. Real accounts follow their organisation's naming convention. Attacker-created ones tend to be variations on admin, or a normal-looking word with a number stuck on the end — things a professional naming standard would never produce.

Then: was it successful? That's a clean binary. If the CreateUser call succeeded, persistence was achieved. If it came back access-denied, it wasn't. The log tells you directly.

For the ordering question, this is where having your files in chronological order pays off — read the odd usernames out in the order they appear.

Which bucket, and how they checked its protection#

The bucket answers itself. As you read, one bucket keeps appearing, over and over. There's only really one candidate.

The protection question is the interesting one, and it wasn't on my cheat sheet. I had to go and research which API call would protect a bucket.

The concept you're looking for is S3 versioning. If versioning is on and you have a file — say, a picture of your cat — then editing it tomorrow creates a new version rather than replacing the old one. It tracks changes, and critically it makes an attacker's life much harder: deleting or encrypting data doesn't actually destroy the earlier versions.

So an attacker checks whether versioning is enabled, and if it is, they turn it off before doing anything destructive.

The exfiltrated file#

There's a mention of a ransom note in the challenge, which tells you the file type to hunt for. I tried the obvious extensions — PDF, CSV, txt, doc — and searched the logs for each until one came back.

What did we learn?#

1. Set up before you start: extract everything, sort chronologically.
2. Build a recon/persistence/exfiltration API cheat sheet and keep it open.
3. Read normal logs first so abnormal ones stand out.
4. Repeated AccessDenied is somebody mapping their permissions.
5. Recon happens before the attack — anchor on the first successful action and look backwards.
6. Attacker-created accounts break naming conventions.
7. S3 versioning is the protection here. Find the check, and you'll find the removal.
8. Build a timeline as you go. Write down what happened and when.

Honestly, I don't think this is a hard challenge in the technical sense. What it requires is that you educate yourself first, then have the patience to actually look through the files. You can do it with a terminal and scripts if you prefer — I chose to read the raw files this time.

I try to keep my videos under ten minutes, so if you want more depth or want the cheat sheets I build for myself, reach out and I'll gladly send them over.

Have a great day!