Beginner Friendly 
Understand Authentication Mechanisms Using boto3
Explore how to interact with AWS services using Python3 and the boto3 module
Overview
Scenario
In the previous Python coding lesson, we showed how to use the Python requests library to enumerate unauthenticated S3 buckets and download files from them. In this lesson, we will use the Python library, Boto3, to authenticate to the AWS service and not only download files, but also make queries to the IAM, STS, and SecretsManager services.
Lab prerequisites
To generate a programmatic solution for the lesson, we need the following tools:
- Burp Suite (Community edition works fine here)
- AWS CLI installed
- Visual Studio Code with Python and Python Debugger extensions installed - see VS Code installation instructions here
- Have previously completed the “Create Custom Tooling to Explore AWS” lesson
Real-world context
When building infrastructure in AWS, running audits and creating incident response playbooks, and assessing the security of AWS environments, there are times when existing tools don't do exactly what we need. For these situations, being able to create your own tools and scripts will help you build, defend and attack more effectively.
KEY TAKEAWAY
Boto3 resolves credentials from a defined chain of sources before any request is made, and understanding that order explains most of the confusing authentication behavior people encounter in AWS, including why a script sometimes uses an identity nobody expected.
What this lab covers
You move from unauthenticated scripting to authenticated tooling, using Boto3 to interact with IAM, STS and Secrets Manager rather than only retrieving public objects.
It follows on from building custom tooling with the requests library, and the step up is authentication: signing requests, resolving credentials and handling the errors that come with permissions rather than with connectivity.
It suits anyone who has written a small script against a cloud API and wanted to make it do something that requires an identity.
How Boto3 authenticates
Boto3 looks for credentials in a defined order: explicitly passed parameters, environment variables, shared credential and configuration files, and finally the container or instance metadata service. The first source that yields credentials wins.
That order explains a great deal of real-world confusion. A script that works on a laptop and behaves differently on an instance is usually resolving a different identity, not encountering a permissions problem, and knowing the chain turns a puzzling failure into an obvious one.
Every request is then signed with those credentials, the request contents and a timestamp. The signature is what prevents replay and tampering, and it is also why credentials cannot simply be copied out of a request capture.
Understanding identity through STS
The simplest and most useful call in AWS is the one that asks who you are. It returns the account, the identity and its unique identifier, and it works with any valid credential, which makes it the first thing to run whenever you are unsure what you hold.
It is equally useful defensively. Establishing which identity a workload is actually running as, rather than which one it was configured with, resolves a large share of access problems and misconfigurations.
Role assumption builds on the same service. Understanding how temporary credentials are obtained and how long they last is what makes short-lived credentials practical to work with rather than an obstacle.
Automating security tasks with an identity
Authenticated tooling covers the work that matters most: listing which identities hold which permissions, checking secret rotation ages, finding roles trusted by external accounts, and reconciling resources against an expected inventory.
These are the checks that appear on audit checklists and get performed by hand once a year. A short authenticated script converts them into something scheduled that reports only what changed, which is the difference between an annual snapshot and a control.
Error handling is where useful tooling separates from a proof of concept. Access denied is information rather than failure, pagination silently truncates results if ignored, and rate limiting needs handling. Getting these right is what makes a script trustworthy enough to act on.
Applying this at work
- Run the identity call against every credential you use regularly and confirm each is the identity you expected.
- Write one authenticated script that answers a question about your own account, such as which secrets have not rotated recently.
- Check that your scripts handle pagination, since silently truncated results are worse than an error.
- Treat access denied responses as data in your tooling rather than as a reason to stop.
- Schedule one manual audit check as an automated script that reports only changes.
Frequently asked questions
How does Boto3 decide which credentials to use?
It resolves them in order: explicit parameters, environment variables, shared credential and configuration files, then container or instance metadata. The first source that provides credentials is used, which explains why the same script can run as different identities in different places.
Why does my script work locally but not on an instance?
Usually because it is resolving a different identity. Locally it may use your profile, while on an instance it uses the attached role. Checking which identity is actually in use resolves most of these cases immediately.
Why are AWS requests signed?
Signing binds the request to the credentials, the contents and a timestamp, which prevents replay and tampering. It is also why credentials cannot be lifted from a captured request and reused directly.
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.