Remediate Vulnerabilities with Amazon Inspector

What this lab covers

You stand up an ELK deployment, ingest AWS log data including working through the import problems that always occur in practice, and use it to reconstruct the sequence of a compromise.

The lab is honest about the unglamorous parts. Most of the difficulty in log analysis is field mapping, timestamp handling and malformed records, and a lab that skipped those would not prepare you for the real thing.

It suits analysts and detection engineers, and uses tooling that is free to run, so the skills transfer to your own environment without a license discussion.

How log analysis platforms turn events into narrative

The pipeline has three stages: collection, normalisation and query. Collection is usually solved by the cloud provider. Normalisation is where the effort goes, because raw log records must be parsed into consistent fields with correctly typed timestamps before any aggregation is meaningful.

Timestamp handling deserves specific attention. Cloud logs arrive with delivery delays that vary by service, so event ordering by arrival time is unreliable. A timeline built on the wrong time field will place effect before cause, and that error is easy to make and hard to notice.

Once normalised, investigation is iterative rather than a single query. You pivot from an identity to its actions, from an action to its source address, from that address to everything else it touched, and each pivot narrows or widens the scope. The platform's value is making each pivot fast enough that you follow leads you would otherwise abandon.

How to detect this in your own environment

Hunt on aggregate behavior rather than individual events. First-seen analysis, asking which API actions a principal performed for the first time in the observed period, surfaces intrusions that no signature would match, and it is a query rather than a rule.

Build detections around identity and source pairs. In cloud environments the meaningful anomaly is usually a known identity behaving unusually or appearing from an unusual place, not an unknown identity appearing at all.

Retain access denied and other failure events. They are commonly dropped to reduce volume and they are among the highest-value records you have, because failures reveal intent and boundaries in a way successes do not.

How to prevent it

This is a detection and response capability rather than a preventive control, and it is worth being direct about that. It shortens dwell time and makes scoping possible, but it does not stop an intrusion.

The preventive value is indirect but real. Building the timeline for a simulated incident reliably reveals what you cannot see, and every gap found this way is a logging configuration to fix before it matters.

Ensure the log store is outside the blast radius of the environment it monitors. Logs an attacker can modify or delete are not evidence, so a separate account with independent access control is the baseline.

Real-world context

Dwell time, the interval between compromise and detection, remains the metric that most determines the cost of an incident, and it is a function of analysis capability rather than collection. Almost every organization collects more than it can query.

Regulatory reporting adds a hard requirement. Breach notification regimes ask which data was affected and when, and answering that requires a reconstructed timeline rather than an alert. Organizations that cannot produce one often have to notify more broadly than the facts require.

The techniques correspond to detection of activity catalogd across MITRE ATT&CK cloud tactics, particularly discovery, credential access and collection, all of which are visible in control plane logs when someone is looking.

Applying this at work

• Take a week of your own CloudTrail data into a test analysis stack and confirm the fields parse and the timestamps are correct before you need them.
• Write and save a first-seen query for API actions per principal, which is one of the highest-yield hunts available.
• Verify your log store is in a separate account with access controls independent of the monitored environment.
• Check whether failure events survive your ingestion pipeline, and restore them if they do not.
• Run a tabletop where the question is what happened and when, not whether an alert fired, and see how long the answer takes.

Frequently asked questions

Why build a timeline rather than rely on alerts?

An alert tells you something happened. A timeline tells you scope: which identities, which data, over what period. That is what determines remediation and regulatory notification, and it cannot be derived from an alert alone.

What is the hardest part of ingesting cloud logs?

Normalisation. Parsing records into consistent fields with correctly typed timestamps, and handling delivery delays that vary by service, so events order by when they occurred rather than when they arrived.

Is ELK a realistic choice for cloud log analysis?

Yes. It is open source, widely used, and handles the volume and query patterns involved. The skills transfer directly to commercial platforms, since the difficulty lies in the data and the questions rather than the product.

Do I need my own cloud account to practice this?

No. The lab runs in a live 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.