Breach in the Cloud

What this lab covers

An incident has already happened, and you are handed what a real responder gets: AWS credentials belonging to an account that behaved oddly, and the CloudTrail logs covering the window. You establish what was accessed, which service was involved, and whether data left the environment.

The lab is built for red and blue together. You reconstruct the incident from the logs as a defender, then retrace the same route as the attacker to confirm your reading held up. Working both directions is deliberate. An attack you can only describe in theory is one you will not reliably recognize in log data at two in the morning.

It suits anyone moving into cloud security from a SOC, sysadmin or general infrastructure background. Basic Linux command line familiarity is the only prerequisite, and no prior AWS experience is assumed.

How AWS CloudTrail investigation works

CloudTrail writes one event per API call. Each event carries the identity that made the call, the source IP and user agent, the service and action, the request parameters, and whether it succeeded. Management events are enabled by default, which is why the control plane record usually survives even when an attacker has been careful everywhere else.

The practical difficulty is volume, not visibility. A modest account produces thousands of events an hour and almost all of it is automation doing exactly what it always does. Investigation is therefore a filtering problem before it is an analysis problem. Responders narrow to a time window, then to a principal, then to the services that principal touched, and only then read events in full.

Two categories carry most of the signal. Discovery calls ask the account what exists rather than doing anything with it, and a principal that suddenly starts asking broad questions about its own permissions and the resources around it is behaving nothing like a deployment pipeline. Data access is the second, and for S3 the distinction that matters is between listing a bucket and reading objects out of it.

How to detect this in your own environment

The highest-value detection is behavioral rather than signature-based. Establish which API actions each high-privilege role actually uses over ninety days, then alert when one steps outside that set. Most roles use a small fraction of what their policy permits, so the baseline is narrower and the alert quieter than teams expect.

Discovery activity is the earliest reliable signal. An identity that suddenly issues broad listing calls across multiple services, when it has no history of doing so, is high signal and low volume. Source context sharpens it further: an access key used from a region or network with no precedent for that principal is worth an alert on its own.

There is one blind spot that catches almost everybody. S3 object-level reads are data events, not management events, and they are not recorded unless someone explicitly enabled them. Teams routinely discover mid-incident that they can prove an attacker listed their buckets but cannot prove what was read. Check this before you need it.

How to prevent it

Long-lived access keys are worth eliminating wherever you can. Static keys committed to a repository or left on a developer laptop are a recurring source of valid credentials, and roles issuing short-lived credentials remove the artifact that gets stolen. Credentials are not the only way in, though. Exploitation of vulnerabilities in the applications running in the cloud is now a major initial access vector, and it puts an attacker on a workload whose attached role becomes the credential they use next.

Scope permissions to specific resources rather than wildcards, and use condition keys to constrain where and how a role can be assumed. This does not stop an attacker holding valid credentials, but it decides how far they travel, which is usually the difference between an incident and a breach.

Protect the evidence itself. A trail an attacker can stop, reconfigure or delete is not evidence. Enable multi-region logging, turn on log file validation, and deliver logs to a bucket in a separate account with its own access controls.

Real-world context

The 2019 Capital One breach is the reference case, and the US Department of Justice case record documents it in detail. According to Capital One's disclosure and the subsequent US Department of Justice indictment, an attacker exploited a server-side request forgery weakness against a misconfigured web application firewall, reached the EC2 instance metadata service, and obtained credentials for the IAM role attached to that instance. Those credentials were used to list and copy S3 buckets. Around 106 million people were affected across the United States and Canada, and the attacker was convicted in 2022.

What makes it instructive is not the initial exploit. Every step after the foothold was an ordinary, authenticated AWS API call made by a principal that was supposed to exist. Nothing was exploited at the AWS layer at all. The intrusion was visible only as a behavioral change in the control plane record, which is exactly what this lab trains you to see.

The pattern maps to MITRE ATT&CK techniques T1580 Cloud Infrastructure Discovery and T1530 Data from Cloud Storage Object, both of which remain among the most commonly reported in cloud intrusion analysis.

Applying this at work

• Confirm whether S3 data events are enabled on buckets holding regulated or customer data. If they are not, you cannot answer what was read after an incident. This is a configuration change, not a project.
• Query ninety days of CloudTrail and list the distinct API actions each high-privilege role actually used. The output is both a detection baseline and a permissions-trimming worklist.
• Write one detection for broad discovery behavior by a principal with no history of it.
• Verify your trail is multi-region, has log file validation enabled, and delivers to a separate account.
• Rehearse the query. Most teams find out during an incident that nobody knows how to search their own CloudTrail quickly.

Frequently asked questions

Is S3 object access logged by default in AWS?

No. S3 object-level reads and writes are data events and must be enabled explicitly on a trail. Management events such as bucket creation and policy changes are logged by default. This gap is the most common cause of an incomplete cloud investigation.

What permissions does an attacker need to enumerate S3 buckets?

Very few. Listing all buckets in an account and listing the objects inside one are separate permissions, and neither is usually treated as sensitive. Both are frequently granted by policies written for convenience rather than least privilege.

How would I detect this activity in my own AWS account?

Alert on discovery behavior from principals with no history of it, particularly broad listing across multiple services, and on access from unfamiliar source regions. Behavioral baselines outperform static rules here because the individual API calls are all legitimate on their own.

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 of running anything against your own infrastructure.

Which certification covers this in depth?

The Amazon Cloud Red Team Professional (ACRTP) covers AWS attack and detection paths in full, including CloudTrail analysis, IAM abuse and privilege escalation, and is assessed hands-on in a live AWS account.