Cloud Credential Attack: From a Leaked Access Key to Blast Radius

Overview

A single leaked credential is often the whole way into a cloud account. In this activity you work a realistic engagement: you have recovered an access key that a developer left in a code repository, and you use the Amazon Web Services command line interface to find out exactly what that one key can reach.

Work the lesson top to bottom. Each Try it box gives you a command to run in the terminal; when you run it, the box marks itself done. When you have worked through the sections, the Challenge at the end asks you to use the same commands to answer graded questions and produce a score report.

How the terminal works

• Click in the terminal, type a command, and press Enter.
• Press Tab to autocomplete commands, services, and resource names.
• Press the up and down arrows to reuse earlier commands.
• Type help for the list of commands, or use Terminal help above the terminal.

The AWS CLI and how access keys authenticate

The Amazon Web Services command line interface (AWS CLI) is a program that sends requests to Amazon Web Services (AWS) from a terminal. Every request it sends has to be signed with credentials so that AWS knows who is asking and what they are allowed to do.

For a human or automation account, those credentials are an access key, which has two parts:

• An access key ID, which identifies the key. It starts with AKIA and is not secret on its own.
• A secret access key, the long secret value used to sign requests. Anyone who holds both parts can act as that identity until the key is disabled.

This is why a key committed to a code repository is so dangerous: the two strings are the entire credential. There is no password prompt and no second factor to stop someone who copies them.

You recovered a credentials file during reconnaissance. Read it first, then load the key into the CLI with aws configure. That command stores the key ID, the secret, a default region, and an output format so that later commands can use them.

Finding out what the key is allowed to do

Knowing whose key you hold is only the start. In the cloud there is no trusted internal network, only identities and the permissions attached to them. Identity and Access Management (IAM) is the AWS service that defines those permissions through policies.

Permissions reach a user two ways. Attached policies are managed documents linked to the user. Inline policies are written directly on the user. A key can have an empty attached list and still be powerful through an inline policy, so check both.

1. List attached managed policies.
2. List inline policy names.
3. Read an inline policy to see the exact actions and resources it allows.

Reaching the data: the blast radius

The policy said this key can read storage and secrets. Now you confirm what that means in practice by reaching the actual resources. The damage a key can do is called its blast radius: the full set of data and actions its permissions expose.

Storage

Amazon Simple Storage Service (S3) stores files in containers called buckets. List the buckets, then list the objects inside one, then copy an object out.

Secrets

AWS Secrets Manager stores values such as database passwords and application programming interface (API) keys. If the leaked key can read a secret, it can often reach whatever that secret protects.

Possession is not administrator access

A key is not automatically powerful. Its policy sets a hard boundary, and AWS refuses anything outside it. Try to escalate and watch the request fail.

What this tells you as a tester, and as a defender

You moved from one recovered string to the company's production data in a handful of commands, and every step depended on the permissions attached to that one identity. Three findings come out of this, and each has a direct defense:

• Least privilege limits the damage. This key read storage and secrets but could not create users or launch servers, so the breach stayed read-only. A key scoped to only what its job needs turns a total compromise into a contained one.
• Long-lived keys age badly. A static access key works until someone disables it, and the one you used had clearly outlived the commit that leaked it. Short-lived credentials and regular rotation shrink the window a leaked key stays useful.
• Secrets and backups are high-value targets. A readable backup bucket and a readable secret each exposed production data without touching the live systems. Access to those resources deserves the tightest controls and the closest monitoring.

When you have finished the Try it boxes above, open the Challenge below.

Challenge: Report the Blast Radius

This challenge has two parts. Challenge 1 revisits the Verdant Cart key from the lesson. Challenge 2 is a fresh engagement with a new client and a new, more powerful key that you recover, configure, and escalate yourself; it unlocks once you finish Challenge 1. Use the terminal to answer each question. Questions open one at a time: answer one correctly and the next unlocks. Each question has a hint. The escalation steps in Challenge 2 were not covered in the lesson, so those questions include the exact command to run. When you finish both parts, enter your name to generate a score report to submit.