Create Custom Tooling to Explore AWS

What this lab covers

You route AWS command line traffic through an intercepting proxy to see exactly what the API calls look like, then write Python tooling that performs enumeration and retrieval on your terms rather than a tool author's.

The lab is about capability rather than a single technique. It assumes basic Python familiarity and no prior AWS experience, and the skills it builds apply to every other AWS lab you do afterwards.

It suits anyone who has hit the limits of an existing tool and wanted to change how it behaved, on either the offensive or defensive side.

How AWS tooling actually works

The AWS CLI and every SDK are clients for a signed HTTPS API. Requests carry a signature derived from the credentials, the request contents and the time, which is why credentials cannot simply be replayed and why understanding the request structure is useful.

Proxying the CLI makes this concrete. Watching the requests and responses for a familiar command shows the endpoints, parameters and pagination behavior, and turns documentation into something you have observed directly.

Boto3 then gives programmatic access to the same operations, with the important additions of pagination and error handling. Enumeration at scale is mostly about paginating correctly and interpreting access denied responses, both of which carry more information than they appear to, because a denial confirms a resource exists and a boundary applies.

Understanding the platform properly

Reading the API directly is the fastest way to actually learn a cloud platform. A tool's output is someone else's summary of what the API returned, and working with the API yourself removes that layer of interpretation along with whatever the tool author decided was unimportant.

It also makes you considerably better at using other people's tools. When a tool returns nothing, you can tell whether the permission was missing, the pagination stopped early, or the resource genuinely does not exist, which is usually the difference between an hour of confusion and a quick answer.

The understanding transfers. Azure and Google Cloud expose the same shape of interface, so the habit of reading requests rather than memorising commands is what makes the second and third platform much faster to pick up than the first.

Automating security tasks

Most cloud security work is repetitive and well suited to a script: checking which buckets are public across every account and region, listing role trust policies with external principals, finding access keys older than a threshold, or reconciling resources against an inventory.

These are the tasks that get done once during an audit and then not again for a year, because doing them by hand is tedious. A short script converts an annual exercise into something that runs on a schedule and reports only what changed.

The same applies to evidence gathering. Compliance work consumes enormous time in screenshots and manual collection, and much of it is a handful of API calls that can be run repeatedly and consistently.

Covering what existing tools miss

Off-the-shelf tooling reflects its author's priorities. It covers the services they cared about, checks the conditions they thought of, and outputs what suited their workflow, which is why teams frequently find that no available tool answers their actual question.

Environment-specific questions are the clearest example. Whether resources follow your tagging standard, whether a naming convention is applied consistently, whether a specific internal policy is honored across accounts, none of these appear in a general purpose tool because they are particular to you.

New and less common services are the other gap. Tool coverage follows popularity, so the service your team adopted recently is frequently the one nothing checks, and a short script closes that gap immediately rather than waiting for someone else to add support.

Applying this at work

• Write one script that checks a condition specific to your environment, such as your tagging standard or naming convention, across every account.
• Automate a check you currently perform manually during audits, and put it on a schedule that reports only changes.
• Proxy the CLI while running a command you use often, and read the requests. It is a short exercise that pays back repeatedly.
• Identify a service your organization uses that your current tooling does not cover, and write a minimal check for it.
• Replace a manual compliance evidence step with a script that produces the same output consistently.

Frequently asked questions

Why proxy the AWS CLI through Burp Suite?

To see the actual HTTPS requests the CLI makes, including endpoints, parameters and pagination. It turns the API from documentation into something observed, which is what makes writing your own tooling straightforward.

Why write custom tooling when good tools already exist?

Because existing tools reflect their author's priorities and coverage. Environment-specific questions such as tagging standards or internal policies, and newer services with no tool support yet, generally require something you write yourself.

Do I need to be a strong programmer to do this?

No. Most useful cloud security tooling is short, using an SDK to make API calls and handle pagination. Basic Python is enough to automate checks that would otherwise be done by hand once a year.

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 to 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 IAM abuse and privilege escalation, and is assessed hands-on in a live AWS account.