This chapter covers two critical AWS attack vectors: IAM privilege escalation and S3 data exposure. These topics are heavily tested on the PT0-002 exam, appearing in approximately 15-20% of questions related to cloud penetration testing. Understanding how attackers abuse misconfigured IAM policies and S3 bucket permissions is essential for both the exam and real-world engagements. You will learn the exact mechanisms, common misconfigurations, and tools used to identify and exploit these vulnerabilities.
Jump to a section
Imagine a hotel where each employee has a key card that grants access to specific rooms. The front desk manager (Root user) can create and assign key cards. A housekeeper (attacker) has a card that opens only guest rooms. However, the housekeeper discovers that the key card programming terminal (IAM policy editor) is left unlocked in a storage closet. By accessing this terminal, the housekeeper can modify her own card to add master key privileges (escalate to administrator). Worse, she can create a duplicate card for an accomplice (backdoor user). The hotel's access control system logs every card swipe, but the housekeeper knows she can delete logs after modifying her privileges (cloud trail deletion). The hotel's security relies on the principle that only managers should access the programming terminal. In AWS, IAM policies define permissions, and if an attacker gains access to an IAM user with permission to change its own policies, they can escalate privileges just like the housekeeper. S3 buckets are like hotel safe deposit boxes: if the manager leaves a safe open (publicly accessible S3 bucket), anyone can take the contents. The analogy highlights that privilege escalation often stems from overly permissive IAM policies that allow users to modify their own permissions or create new users.
IAM Escalation: The Core Mechanism
AWS Identity and Access Management (IAM) is the service that controls access to AWS resources. IAM policies are JSON documents that define permissions. Privilege escalation occurs when an IAM user or role can modify its own permissions or create new identities with elevated privileges. The fundamental flaw is a violation of the principle of least privilege. The exam tests specific escalation paths, each with distinct conditions.
Common IAM Escalation Paths
CreateUserPolicy: A user with iam:CreateUser and iam:PutUserPolicy permissions can create a new user with an attached policy granting full administrator access. The attacker then logs in as that new user.
AttachUserPolicy: If a user has iam:AttachUserPolicy permission on their own user, they can attach the AWS-managed AdministratorAccess policy to themselves. This is a direct escalation.
CreatePolicyVersion: A user with iam:CreatePolicyVersion can create a new version of an existing policy (e.g., a policy attached to themselves) that allows all actions. If the policy's default version is set to the new permissive version, the user gains full access.
SetDefaultPolicyVersion: Similar to above, but the user can change the default version of an existing policy to a previously created permissive version.
PassRole: A user with iam:PassRole can pass a role to an EC2 instance or Lambda function. If the role has high privileges, the attacker can launch an instance with that role and access its credentials via the instance metadata service.
CreateAccessKey: A user with iam:CreateAccessKey on another user can create an access key for that user, potentially escalating if the target user has higher privileges.
UpdateAssumeRolePolicy: A user with iam:UpdateAssumeRolePolicy can modify the trust policy of a role to allow their own user to assume that role. If the role has admin privileges, escalation is achieved.
How IAM Escalation Works Internally
AWS IAM evaluates policies using a request context that includes the principal, action, resource, and conditions. When a user makes an API call, IAM checks all applicable policies (identity-based, resource-based, etc.). The default action is implicit deny — if no policy explicitly allows an action, it is denied. An explicit deny overrides any allow.
For escalation, the attacker must have permissions to perform IAM actions on themselves or other principals. The AWS API calls are logged in AWS CloudTrail, but attackers may attempt to disable logging or delete logs.
Key IAM Values and Defaults
IAM user: A permanent identity with long-term credentials (access key ID and secret access key).
IAM role: A temporary identity that can be assumed by trusted entities. Roles have a trust policy and a permissions policy.
IAM policy: A JSON document with statements containing Effect (Allow/Deny), Action, Resource, and Condition.
AWS-managed policies: Predefined policies like AdministratorAccess (full admin), PowerUserAccess (full except IAM), etc.
Customer managed policies: Policies created by the customer.
Inline policies: Policies embedded directly in a user, group, or role.
Default limit: An IAM user can have up to 10 inline policies and 10 managed policies attached. A policy can have up to 5 versions, with one being the default.
S3 Exposure: Core Concepts
Amazon Simple Storage Service (S3) is an object storage service. Each bucket has a unique global name. Objects are stored in buckets and accessed via URLs. S3 permissions can be configured at the bucket level (bucket policies) or object level (ACLs). Additionally, IAM policies can grant access to S3 resources.
Common S3 Misconfigurations Leading to Exposure
Publicly readable bucket: Bucket policy grants s3:GetObject to Principal: "*" (all users). This allows anyone on the internet to list and download objects.
Publicly writable bucket: Bucket policy grants s3:PutObject to Principal: "*". Attackers can upload malicious files, potentially leading to data corruption or hosting malware.
Authenticated users access: Bucket policy grants access to any authenticated AWS user, not just users in the same account. This exposes data to any AWS customer.
Misconfigured ACLs: Object ACLs set to public-read or public-read-write.
Missing bucket policy restrictions: No conditions on IP addresses, VPC endpoints, or MFA.
S3 Access Control Evaluation
When a request is made to an S3 bucket, AWS evaluates both IAM policies and bucket policies. The effective permissions are a union of all applicable policies, but an explicit deny in any policy overrides allows. For public access, AWS has a Block Public Access feature that can override bucket policies and ACLs to prevent public exposure.
Default Values for S3
By default, buckets and objects are private. Only the bucket owner and authorized IAM users can access them.
S3 Block Public Access settings: By default, these are not enabled at the account level, but AWS recommends enabling them.
Bucket policy size limit: 20 KB.
Object ACL: Each object has an ACL that can grant access to specific AWS accounts or groups (e.g., AllUsers group for public access).
Tools for Discovery and Exploitation
AWS CLI: Commands like aws s3 ls, aws s3 cp, aws iam list-users, aws iam list-attached-user-policies.
Pacu: An AWS exploitation framework with modules for IAM escalation and S3 enumeration.
ScoutSuite: A security auditing tool that identifies misconfigurations.
CloudSploit: Another scanner for cloud misconfigurations.
S3Scanner: A tool specifically for finding open S3 buckets.
Interplay Between IAM and S3
IAM policies can grant access to S3 buckets. For example, a user may have an IAM policy that allows s3:GetObject on a specific bucket. If the bucket policy also allows public access, the user can access it via IAM. Attackers often use IAM escalation to gain access to S3 buckets that contain sensitive data.
Exam-Relevant Details
The exam expects you to know the exact IAM actions that enable escalation (e.g., iam:AttachUserPolicy, iam:CreatePolicyVersion).
You must understand that S3 bucket names are globally unique and publicly resolvable via DNS.
Attackers use bucket enumeration by trying common bucket names (e.g., company-backups, company-data).
The exam may present a scenario where an attacker has limited IAM permissions and asks which escalation path is possible.
CloudTrail logs all IAM and S3 API calls. Attackers may attempt to stop CloudTrail logging (cloudtrail:StopLogging) or delete logs (s3:DeleteObject on the log bucket).
Mitigation Techniques
Implement least privilege IAM policies. Use IAM Access Analyzer to identify overly permissive policies.
Enable S3 Block Public Access at the account level.
Use bucket policies with conditions (e.g., aws:SourceIp, aws:SourceVpce).
Enable CloudTrail and S3 server access logs.
Regularly review IAM users and roles with IAM Credential Report.
Use AWS Config rules to detect non-compliant resources.
Enumerate IAM Users and Policies
Using the AWS CLI or tools like Pacu, the attacker lists all IAM users and their attached policies. The command `aws iam list-users` returns all users. Then `aws iam list-attached-user-policies --user-name <target>` shows managed policies, and `aws iam list-user-policies --user-name <target>` shows inline policies. The attacker looks for policies that grant IAM write permissions (e.g., `iam:AttachUserPolicy`, `iam:CreateUser`). This enumeration is the reconnaissance phase. The attacker must have at least `iam:ListUsers` permission, which is often included in read-only policies. If the attacker has no permissions, they might use a compromised access key or assume a role.
Identify Escalation Path
The attacker examines the policies to find one that allows modifying IAM resources. For example, if a policy grants `iam:AttachUserPolicy` on `arn:aws:iam::*:user/${aws:username}`, the attacker can attach the `AdministratorAccess` policy to themselves. The attacker uses `aws iam attach-user-policy --user-name <self> --policy-arn arn:aws:iam::aws:policy/AdministratorAccess`. AWS evaluates the policy and if the attacker's user is allowed, the policy is attached. The attacker now has full admin privileges. This step requires understanding the resource ARN in the policy; the attacker must be the target user.
Create a Backdoor User
With escalated privileges, the attacker creates a new IAM user with full admin access to maintain persistence. Using `aws iam create-user --user-name backdoor` and `aws iam attach-user-policy --user-name backdoor --policy-arn arn:aws:iam::aws:policy/AdministratorAccess`. The attacker also creates access keys for this user: `aws iam create-access-key --user-name backdoor`. These keys are saved and can be used later even if the original compromised user is detected and disabled. The attacker may also add the backdoor user to an existing admin group if possible.
Cover Tracks by Disabling Logging
The attacker attempts to disable CloudTrail to prevent logging of their actions. Using `aws cloudtrail stop-logging --name <trail-name>`. If the trail is multi-region, the attacker must stop logging in each region. The attacker may also delete CloudTrail log files from the S3 bucket: `aws s3 rm s3://<log-bucket>/AWSLogs/... --recursive`. However, if the trail has log file validation enabled, deletion may be detected. The attacker might also modify IAM policies to remove logging permissions from other users. This step is critical to avoid detection but may not always be possible if the attacker lacks the required permissions.
Enumerate S3 Buckets for Data Exfiltration
With admin access, the attacker lists all S3 buckets in the account: `aws s3 ls`. For each bucket, the attacker checks if it is public or if the attacker has read access. The attacker uses `aws s3api get-bucket-acl --bucket <name>` and `aws s3api get-bucket-policy --bucket <name>` to determine permissions. If a bucket allows public read or if the attacker's user has `s3:GetObject`, the attacker downloads objects: `aws s3 cp s3://<bucket>/<key> . --recursive`. The attacker searches for sensitive data like credentials, customer PII, or configuration files. Data exfiltration can be done directly via the CLI or by using S3 sync.
In a typical enterprise, AWS accounts are managed by a central cloud team. IAM users are created for developers, operations, and other roles. A common misconfiguration is granting developers iam:CreateUser and iam:PutUserPolicy permissions so they can create service accounts for their applications. However, this allows them to create an admin user. For example, a developer at a fintech company had permissions to create users and attach policies. They created a user with full admin access and used it to access an S3 bucket containing customer financial data, leading to a data breach. In another scenario, a company used S3 buckets for backup logs. They set the bucket policy to allow s3:PutObject and s3:GetObject from a specific VPC, but forgot to add a condition restricting access to the VPC endpoint. An attacker who compromised an EC2 instance in the same VPC could access the bucket. The attacker enumerated buckets using a script that checked common names and found the backup bucket. They downloaded sensitive log files containing database credentials. Performance considerations: IAM policy evaluation adds minimal latency, but S3 access can be slow for large objects. Companies often use S3 Transfer Acceleration for faster uploads. Misconfiguration often occurs due to lack of automated policy validation. Tools like AWS Config and IAM Access Analyzer can detect overly permissive policies, but many organizations fail to enable them. The most common mistake is granting * permissions in IAM policies or S3 bucket policies without proper review.
The PT0-002 exam tests IAM escalation and S3 exposure under Objective 3.5: 'Given a scenario, perform attacks and exploits.' Specific sub-objectives include: 'Exploit network-based vulnerabilities' (3.5) and 'Exploit application-based vulnerabilities' (3.5). The exam expects you to identify which IAM actions allow privilege escalation. Common wrong answers include: 'iam:CreateRole' (which does not directly escalate without PassRole), 'iam:ListUsers' (a read-only action), and 's3:ListBucket' (which only lists objects, not read them). Candidates often confuse 'AttachUserPolicy' with 'PutUserPolicy' — both can escalate, but AttachUserPolicy attaches a managed policy, while PutUserPolicy creates an inline policy. The exam loves to test the difference between 'CreatePolicyVersion' and 'SetDefaultPolicyVersion'. Another trap: assuming that S3 Block Public Access always prevents public exposure — but if Block Public Access is not enabled at the account level, bucket policies can still grant public access. Specific numbers: IAM policy size limit is 6144 characters for managed policies; S3 bucket policy max size is 20 KB. The exam may ask about the default action when no policy matches: implicit deny. Edge case: If a user has iam:PassRole but the role's trust policy does not allow the user to assume it, escalation fails. To eliminate wrong answers, always check if the action allows modifying permissions or creating new identities. For S3, look for Effect: Allow with Principal: "*" or Principal: "AWS": "*".
IAM privilege escalation requires permissions to modify IAM resources (e.g., `iam:AttachUserPolicy`, `iam:CreateUser`, `iam:CreatePolicyVersion`).
S3 bucket public exposure is often due to bucket policies with `Principal: "*"` or `Principal: "AWS": "*"`.
The default IAM action is implicit deny; an explicit deny overrides any allow.
S3 Block Public Access at the account level provides a safety net but can be bypassed if not fully enabled.
CloudTrail logs all API calls; attackers often disable CloudTrail or delete logs to cover tracks.
Tools like Pacu and ScoutSuite automate IAM escalation and S3 enumeration.
Always check for `iam:PassRole` combined with `ec2:RunInstances` for escalation via EC2.
These come up on the exam all the time. Here's how to tell them apart.
AttachUserPolicy
Attaches a managed policy (AWS or customer managed) to a user.
Requires `iam:AttachUserPolicy` on the user resource.
Managed policies are reusable across multiple users.
Cannot create an inline policy; only attaches existing policies.
Example: `aws iam attach-user-policy --user-name alice --policy-arn arn:aws:iam::aws:policy/AdministratorAccess`
PutUserPolicy
Creates an inline policy embedded directly in a user.
Requires `iam:PutUserPolicy` on the user resource.
Inline policies are unique to the user and not reusable.
Can define custom permissions in the policy document.
Example: `aws iam put-user-policy --user-name alice --policy-name admin --policy-document file://admin.json`
Mistake
Only the root user can create IAM users.
Correct
Any IAM user with the `iam:CreateUser` permission can create new IAM users. The root user is not required. This is a common escalation path.
Mistake
S3 Block Public Access completely prevents any public access.
Correct
Block Public Access settings can be overridden by bucket policies that explicitly allow public access if the block settings are not applied at the account level. Also, object ACLs can still allow public read if block public access is not enabled for ACLs.
Mistake
Attaching a policy to yourself always requires `iam:AttachUserPolicy` on your own user.
Correct
You also need `iam:PassRole` permission if the policy is a role? No, for users, you only need `iam:AttachUserPolicy` or `iam:PutUserPolicy`. `iam:PassRole` is for roles passed to services.
Mistake
CloudTrail logs cannot be deleted by IAM users.
Correct
If an IAM user has `cloudtrail:DeleteTrail` and `s3:DeleteObject` on the log bucket, they can delete CloudTrail trails and log files. This is a common post-exploitation step.
Mistake
S3 bucket names are case-sensitive.
Correct
S3 bucket names are globally unique and must be DNS-compliant. They are lowercase only and can contain periods and hyphens. They are not case-sensitive; AWS treats them as lowercase.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
The most common path is `iam:AttachUserPolicy` where a user attaches the `AdministratorAccess` policy to themselves. This is straightforward and often tested. Ensure you know the exact API call and the required permissions. Example: If a user has a policy allowing `iam:AttachUserPolicy` on their own user ARN, they can escalate to admin.
Use the AWS CLI: `aws s3api get-bucket-acl --bucket <name>` to check ACLs, and `aws s3api get-bucket-policy --bucket <name>` to check bucket policies. Look for `Effect: Allow` with `Principal: "*"` or `Principal: "AWS": "*"`. Also check the bucket's 'Block Public Access' settings via `aws s3api get-public-access-block --bucket <name>`. Tools like S3Scanner automate this.
No. `iam:ListUsers` is a read-only action that does not allow modifying any IAM resources. You need actions that create, modify, or attach policies/users. However, you might use `iam:ListUsers` to find a user with higher privileges to target for credential theft.
`CreatePolicyVersion` creates a new version of a managed policy. `SetDefaultPolicyVersion` sets an existing version as the default version (the one that is applied). To escalate, an attacker might create a permissive version and then set it as default. Both actions require the `iam:CreatePolicyVersion` and `iam:SetDefaultPolicyVersion` permissions respectively.
If a user has `iam:PassRole` and `ec2:RunInstances`, they can launch an EC2 instance with a high-privilege role. The instance metadata service provides credentials for that role. The attacker can SSH into the instance and retrieve the role's temporary credentials via `curl http://169.254.169.254/latest/meta-data/iam/security-credentials/<role-name>`. Then they can use those credentials to perform actions as the role.
Attackers enumerate S3 buckets by guessing common names (e.g., company-backups, logs, data). Since bucket names are globally unique and DNS-resolvable, they can check if a bucket exists by attempting to access it. Tools like S3Scanner automate this. Once a bucket is found, the attacker checks if it's publicly readable. This is a common initial access vector.
IAM Access Analyzer helps identify overly permissive policies but does not prevent escalation. It generates findings for policies that grant access to external principals. To prevent escalation, implement least privilege policies, use conditions, and regularly audit permissions. Enable AWS Config rules to detect changes.
You've just covered AWS Pentesting: IAM Escalation, S3 Exposure — now see how well it sticks with free PT0-002 practice questions. Full explanations included, no account needed.
Done with this chapter?