AWS Pentesting for Beginners: Think Like a Cloud Attacker
Let’s be honest: most cloud security writing is either boring or dangerously naive. Firewalls and network ports aren’t the threat anymore…
Let’s be honest: most cloud security writing is either boring or dangerously naive. Firewalls and network ports aren’t the threat anymore ,in AWS pentesting, the real weakness is logic and permissions.
Cloud breaches happen because someone configured roles badly and never checked the policy JSONs.
Identity Is the New Perimeter
In traditional environments, we’d worry about exposed servers and open ports. In AWS, identity and access management (IAM) is everything. If permissions are sloppy, attackers don’t need to break anything , they just assume a higher-privilege role. That’s how real breaches escalate.
efore you can break a system, you must understand its rules. We begin by dissecting the four pillars of AWS IAM:
- Users: The entities (people or services) interacting with AWS.
- Groups: Collections of users (e.g., “Developers,” “Admins”) used to manage permissions efficiently.
- Roles: The most critical component for hackers. A role is a temporary identity that a user can “assume” to gain new permissions.
- Policies: The JSON documents that actually define what is allowed or denied (e.g.,
Allow S3:ListBucket).
The danger lies in the relationship between these entities. If a low-level user has a policy that allows them to AssumeRole for a high-level role, the game is effectively over.
The Classic AWS Attack Chain
A compromised set of keys + a few AWS CLI commands = an escalation path that should have been blocked at design time.
Phase 1: Reconnaissance
Attackers start by figuring out who they are in the system. The AWS command aws sts get-caller-identity is the cloud equivalent of whoami. And if they already have credentials, that first bit of info tells them everything.
Phase 2: Enumeration
Once identity is known, attackers enumerate what they can do. This means reading IAM policies , both inline and attached , to find permissions that shouldn’t exist.
Phase 3: Privilege Escalation
If a user has sts:AssumeRole permissions, they just assume a more powerful role and walk in like they belong.
Phase 4: Exfiltration
Once at a higher privilege level, listing and downloading sensitive S3 data is trivial. Just cloud API calls that your own admin accidentally allowed.
AWS Isn’t Hard
The worst problem with cloud security writing is false comfort. People hear “cloud is secure by design” and think that’s all the security they need. Reality check: cloud providers assume you will configure permissions correctly and most orgs don’t.
Pentesting AWS is about thinking like someone who already has a foothold and trying to escalate. That insight alone changes the game.
The AWS Hacker’s Cheatsheet
Here are the essential AWS CLI commands extracted from the workflow. These are useful for both Red Teamers (simulating attacks) and Blue Teamers (auditing permissions).
1. Identity & Enumeration
# Verify your current identity
aws sts get-caller-identity# List all users in the account
aws iam list-users# List inline policies for a specific user
aws iam list-user-policies --user-name <username># List attached (managed) policies for a user
aws iam list-attached-user-policies --user-name <username>
2. Policy Inspection
# View the actual JSON content of a user policy
aws iam get-user-policy --policy-name <policy_name> --user-name <username># List all available roles
aws iam list-roles# View inline policies attached to a role
aws iam list-role-policies --role-name <role_name>
3. Privilege Escalation (Assuming a Role)
# Request temporary credentials for a target role
aws sts assume-role --role-arn <role_arn> --role-session-name <session_name># After running the above, you must export the output keys to your environment:
export AWS_ACCESS_KEY_ID=<New_Access_Key>
export AWS_SECRET_ACCESS_KEY=<New_Secret_Key>
export AWS_SESSION_TOKEN=<New_Session_Token>
4. S3 Data Exfiltration
# List all S3 buckets
aws s3api list-buckets# List files (objects) inside a specific bucket
aws s3api list-objects --bucket <bucket_name># Download a specific file
aws s3api get-object --bucket <bucket_name> --key <file_name> <output_file_name>
The AssumeRole Trap
From a personal perspective, this guide highlights exactly why AWS security is so difficult. The vulnerability wasn’t a “hack” in the traditional sense, no code was broken, no buffer was overflowed. The system worked exactly as designed. The administrator explicitly granted the sts:AssumeRole permission.
In 2026, as we move toward more automated infrastructure, these logic bugs are becoming the primary vector of compromise. An automated script might need temporary access to a bucket, so a developer creates a broad role and allows a user to assume it. Five months later, that user’s key leaks, and suddenly the attacker has the keys to the kingdom.
My Advice: If you are auditing an AWS environment, hunt for sts:AssumeRole like your life depends on it. It is the bridge between a low-level nuisance and a headline-grabbing breach. If a user doesn’t absolutely need to change their identity, strip that permission away immediately.