LetsDefend: AWS PerSEStence — building a timeline from CloudTrail

This one was a fun one. A hard cloud IR challenge: making thousands of CloudTrail JSON events readable with jq, and turning them into the story of how an attacker stayed in.

This one was a fun one!

Cloud incident response is a genuinely different discipline, and this challenge is a great demonstration of why. There is no disk to image. There is no memory to capture. There is an enormous pile of JSON, and the whole job is turning it into a story.

Careful

#

CloudTrail logs every API call made in your account. That is exactly what you want during an investigation, and exactly what makes it unreadable raw: thousands of deeply nested JSON events, one per call, and most of them completely routine.

A wall of minified JSON scrolling past faster than you can read it, with the one field you care about buried four levels deep.

#

Same data, formatted and indented. Suddenly you can see the structure — and once you can see the structure, you can start asking questions of it instead of reading it.

Then this is the one I kept coming back to:

Four columns per event. That is the difference between a file you cannot read and a table you can sort.

Tip

#

Four fields carry most of the story:

#

This is the real deliverable, and I think it is the skill the challenge is actually testing.

The output is not a list of suspicious events. It is a narrative with an order and a cause — this call succeeded, which made the next one possible. And if two events could genuinely have happened in either order, say so rather than implying a certainty the logs do not support.

#

The name is the hint.

Which is exactly why containment has to be scoped from the timeline and not from the initial alert. Rotate the compromised credential and stop there, and everything they built afterwards is still working.