In this project, I worked on an AWS IAM enumeration case study, simulating a real-world security consulting scenario. The objective was to perform enumeration on an IAM user account and map out its privileges, attached policies, and potentially accessible resources. The goal was to better understand how attackers might exploit misconfigurations, and how defenders can analyze permission boundaries.
Scenario
I was hired as a security consultant by a logistics company named Huge Logistics. After suspicious activity was reported, I was tasked with enumerating the IAM user account dev01 and identifying any resources that may have been exposed or compromised.
Learning Objectives
Through this project, I aimed to:
- Gain hands-on experience with the AWS CLI
- Understand IAM roles, policies, and permissions
- Learn how to enumerate AWS IAM components systematically
Tools Used
- AWS Management Console
- AWS CLI (Command Line Interface)
- Linux terminal
Initial Setup
I started by accessing the AWS Management Console via the provided IAM user credentials. After logging in successfully, I explored the various services available through the AWS web interface. This was my initial entry point into the environment.
After familiarizing myself with the console, I moved to the AWS CLI to conduct a more thorough enumeration. I installed the AWS CLI on my system using:
apt install awscli
Once installed, I configured the CLI with the provided AWS access key ID and secret access key:
aws configure
Confirming User Identity
To verify that I was authenticated properly, I ran:
aws sts get-caller-identity
This confirmed that I was operating as the IAM user dev01 within the correct AWS account.
I also retrieved more information about the IAM user:
aws iam get-user
Group Membership Check
Next, I checked if this user belonged to any groups:
aws iam list-groups-for-user --user-name dev01
The output showed that dev01 was not part of any IAM groups.
Enumerating User Policies
I proceeded to list any attached user policies:
aws iam list-attached-user-policies --user-name dev01
Two policies were attached:
AmazonGuardDutyReadOnlyAccess(AWS Managed Policy)dev01(Customer Managed Policy)
I also checked for inline policies:
aws iam list-user-policies --user-name dev01
An inline policy named S3_Access was found.
Policy Deep Dive
Amazon Managed Policy: GuardDuty ReadOnly
First, I examined the AWS managed policy AmazonGuardDutyReadOnlyAccess. I listed its versions:
aws iam list-policy-versions --policy-arn arn:aws:iam::aws:policy/AmazonGuardDutyReadOnlyAccess
The latest version was v4. I retrieved its policy document:
aws iam get-policy-version --policy-arn arn:aws:iam::aws:policy/AmazonGuardDutyReadOnlyAccess --version-id v4
The permissions allowed various read-only actions such as Describe*, Get*, and List* for GuardDuty and some Organization services.
[Screenshot placeholder: get-policy-version output for GuardDuty]
Customer Managed Policy: dev01
I also examined the customer managed policy dev01. First, I listed its versions:
aws iam list-policy-versions --policy-arn arn:aws:iam::79492**57501:policy/dev01
The latest version was v7. I retrieved its document using:
aws iam get-policy-version --policy-arn arn:aws:iam::79492**57501:policy/dev01 --version-id v7
This policy granted permissions to retrieve information about the IAM user, roles, and other policies including:
- GetUser, ListGroupsForUser, ListAttachedUserPolicies
- GetRole, GetRolePolicy, ListAttachedRolePolicies
- GetPolicy, GetPolicyVersion, ListPolicyVersions
Investigating IAM Role: BackendDev
One of the roles referenced in the customer managed policy was BackendDev. I enumerated its attached policies:
aws iam list-attached-role-policies --role-name BackendDev
It was confirmed that BackendDevPolicy was attached.
I then retrieved information about the role itself:
aws iam get-role --role-name BackendDev
The trust relationship showed that the IAM user dev01 was allowed to assume this role via sts:AssumeRole.
Investigating BackendDevPolicy
I retrieved the policy information for BackendDevPolicy:
aws iam get-policy --policy-arn arn:aws:iam::7949**857501:policy/BackendDevPolicy
The version in use was v1. I extracted the policy version details:
aws iam get-policy-version --policy-arn arn:aws:iam::7949**857501:policy/BackendDevPolicy --version-id v1
This policy allowed:
ec2:DescribeInstancessecretsmanager:ListSecretssecretsmanager:GetSecretValueforprod/Customerssecretsmanager:DescribeSecretforprod/Customers
[Screenshot placeholder: get-policy-version output for BackendDevPolicy]
If I assumed this role, I would gain temporary access to list all EC2 instances, list all secrets, and retrieve the secret value of prod/Customers.
Investigating Inline Policy: S3_Access
Lastly, I examined the inline policy attached to the user:
aws iam get-user-policy --user-name dev01 --policy-name S3_Access
The policy granted access to list and retrieve objects from the S3 bucket hl-dev-artifacts.
Summary of Findings
After completing the enumeration, I discovered:
- The user
dev01has both AWS managed and customer managed policies attached. - The customer managed policy allows the user to enumerate various IAM roles, policies, and their own permissions.
- The
BackendDevrole allows privilege escalation throughsts:AssumeRole, giving access to EC2 instance information and sensitive secrets. - An inline policy grants access to an S3 bucket where potentially sensitive artifacts are stored.
Privilege Escalation Simulation
To simulate what an attacker could do, I used:
aws s3 ls s3://hl-dev-artifacts
aws s3 cp s3://hl-dev-artifacts/flag.txt .
I successfully retrieved the flag, demonstrating how an attacker might pivot after initial access.
Conclusion
This project highlighted how critical IAM misconfigurations can expose sensitive resources. With just limited permissions, I was able to enumerate roles, escalate privileges, and access confidential data stored in both S3 and Secrets Manager. In real-world scenarios, proper IAM auditing, least privilege enforcement, and constant monitoring can significantly reduce such risks.