What is AWS Post exploitation?

Post exploitation is required when you’ve successfully compromised a particular target. The purpose of the AWS Post Exploitation phase is to determine the value of the account compromised and to maintain control of the account for later use. The value of the account is determined by the sensitivity of the data stored in it, permissions that the compromised access keys have and the account usefulness in further compromising the network sometimes can create a reverse shell from the on-prem compromised machine if there’s a VPN/DirectConnect connection. However, AWS post exploitation for network or system based applications is different from that of the traditional on-prem post exploitation. In this blog post, we will mainly focus on the post-exploitation of Amazon AWS which is a cloud platform that provides on-demand cloud computing platforms to individuals, companies, and governments, on a paid subscription basis.

  1. AWS CLI: The AWS Command Line Interface (CLI) is a unified tool to manage your AWS services. With just one tool to download and configure, you can control multiple AWS services from the command line and automate them through scripts. Follow the detailed step in the AWS documentation to install and configure your AWS CLI on your system by referring here.
  2. Jq: jq is like sed for JSON data – you can use it to slice and filter and map and transform structured data with the same ease that sed, awk, grep and friends let you play with text. Follow the detailed installation steps and set up jq on your preferred operating system by referring here.

Getting your hands dirty:

So the first thing that comes to your mind once you’ve got a command shell anywhere is to check which user has been compromised. The old whoami command serves the purpose. Luckily AWS has an equivalent command get-caller-identity. Although it won’t give you much except the Account number, User Id, and Arn, it is enough to give you a feel for your access.

[email protected]:~# aws sts get-caller-identity

AWS Direct Connect makes it easy to establish a dedicated network connection from your premises to AWS. Organisations that utilize AWS generally connect their data centers and offices directly to Amazon using the Direct Connect service. AWS Direct Connect lets you establish a dedicated network connection between your network and one of the AWS Direct Connect locations.  It links your internal network to an AWS Direct Connect location. With this connection in place, you can create virtual interfaces directly to the AWS cloud. AWS has an API to interact with which provides us with a decent amount of information. Describing locations will display metadata about any connections.

A successful execution will result in a list of aliases and physical facility locations.

[email protected]:~# aws directconnect describe-locations | jq '.locations [] | .locationCode + " " + .locationName'


“EqSe2 Equinix SE2, Seattle, WA”

“SNAP Switch SUPERNAP 8, Las Vegas, NV”

“ECPO1 EdgeConnex, Hillsboro, OR”

“TPS19 TierPoint, Seattle, WA”

“PEH51 Pittock Block, Portland, OR”

“CSDE1 CoreSite DE1, Denver, CO”

Upon querying the EC2 API, we can obtain the following information that would allow you to match locations with the returned IP ranges and later use the matches to tunnel back into data centers or corporate networks. You could further filter out the noise using jq.

[email protected]:~# aws ec2 describe-route-tables | \jq '.RouteTables | .[] | .Routes [] | .GatewayId + " " +  .DestinationCidrBlock'




A network access control list (ACL) is an optional layer of security for your VPC that acts as a firewall for controlling traffic in and out of one or more subnets. Virtual gateways are associated with virtual private clouds (VPCs), which are the network containers used to group resources like EC2 instances and Lambda functions. If you can compromise such a resource or create one in the right VPC, you should be able to route normally through those gateways unless network ACLs prevent it. Listing NACLs is also an EC2 call.

[email protected]:~# aws ec2 describe-network-acls | jq '.NetworkAcls [] .Entries [] | .Protocol + " " + .RuleAction + " " + .CidrBlock' | sort | uniq
Enumerating Identity and Access Management (IAM)

AWS Identity and Access Management (IAM) enables you to manage access to AWS services and resources securely. Using IAM, you can create and manage AWS users and groups, and use permissions to allow and deny their access to AWS resources.

User: An IAM user is an entity that you create in AWS to represent the person or service that uses it to interact with AWS. A user in AWS consists of a name and credentials.

To enumerate IAM users present in the account that has been compromised we use another subcommand of aws cli.

[email protected]:~# aws iam list-users | jq '.Users [] .Arn'

Some organizations keep their list of users by providing federated authentication via a SAML provider. The following command will provide you with the list of users if there’s any. Currently, my list is empty though.

[email protected]:~# aws iam list-saml-providers

IAM Roles: An IAM role is similar to a user, in that it is an AWS identity with permission policies that determine what the identity can and cannot do in AWS. Roles are assumed by users authenticating via SAML. Roles are how Amazon recommends you start your EC2 instances and how it forces you to work in newer services like Lambda. You can enumerate IAM roles using the following command:

[email protected]:~# aws iam list-roles | jq '.Roles [] .Arn'



If you want to go through all user, role, and policy data there’s an API to retrieve all the details at once.

[email protected]:~# aws iam get-account-authorization-details

You could further retrieve EC2 key-pairs with the following command:

[email protected]:~# aws ec2 describe-key-pairs | jq '.[][] .KeyName'

AWS Escalation

After getting access to a user’s aws credentials, it is likely that a user would attempt privilege escalation techniques that would expand the attack surface.

i) Creating a new policy version

An attacker can create a new version of an IAM policy that they have access to. This allows him to assign his own permissions. When creating a new policy version, it needs to be set as the default version to take effect, it is possible to include a flag (–set-as-default) that will automatically create it as the new default version.

[email protected]:~#aws iam create-policy-version –policy-arn target_policy_arn –policy-document {path to file} –set-as-default

Here the policy.json file would include a policy document that allows any action against any resource in the account.

ii) Setting the default policy version to an existing version

An attacker with the iam:SetDefaultPolicyVersion permission may be able to escalate privileges through existing policy versions that are currently dormant. If a policy that they have access to has versions that are not the default, they would be able to change the default version to any other existing version. The impact could range from no privilege escalation at all to gaining full administrator access to the AWS account.

[email protected]:~#aws iam set-default-policy-version –policy-arn target_policy_arn –version-id v2

Here “v2” is the policy version with the most privileges available.

iii) Creating an EC2 instance with an existing instance profile

If the attacker has access to the iam:PassRole and ec2:RunInstances permissions he can create a new EC2 instance and pass an existing EC2 instance profile/service role to it. He can then login to the instance and request the associated AWS keys from the EC2 instance meta data, which gives them access to all the permissions that the associated instance profile/service role has.

The attacker can gain access to the instance in a by to creating or importing an SSH key and associate it with the instance on creation and after that he can SSH into it. This would give him access to the set of permissions that the instance profile/role has, which again could range from no privilege escalation to full administrator access of the AWS account.

[email protected]:~#aws ec2 run-instances –image-id ami-a4dc46db –instance-type t2.small –iam-instance-profile Name=iam-unauthorized-access –key-name ssh_key –security-group-ids sg-111111

Here the attacker has access to the victim’s ssh_key and the security group sg-11111 allows SSH access.

iv) Creating a new user access key

An attacker with the iam:CreateAccessKey permission on other users can create an access key ID and secret access key belonging to another user in the AWS environment. This would give an attacker the same level of permissions as any user they were able to create an access key for.

[email protected]:~#aws iam create-access-key –user-name victim-user

Here victim_user has an extended set of permissions compared to the current user.

v) Creating a new login profile

Creation of a login profile is possible if an attacker has the iam:CreateLoginProfile permission. He can create a password to login to the AWS console on any user that does not already have a login profile setup.

[email protected]:~#aws iam create-login-profile –user-name victim_user –password ‘XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX’ –no-password-reset-required
vi) Updating an existing login profile

Manipulation of a login profile is possible if an attacker has the iam:UpdateLoginProfile permission. He can change the password used to login to the AWS console on any user that already has a login profile setup.

[email protected]:~#aws iam update-login-profile –user-name victim_user –password XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX –no-password-reset-required

 vii) Attaching a policy to a resource

An attacker with the iam:AttachUserPolicy, iam:AttachGroupPolicy, or iam:AttachRolePolicy permissions can escalate privileges by attaching a policy to a user, group, or role that they have access to, adding the permissions of that policy to the attacker.

[email protected]:~#aws iam attach-user-policy –user-name some_username –policy-arn arn:aws:iam::aws:policy/AdministratorAccess

[email protected]:~#aws iam attach-group-policy –group-name some_group –policy-arn arn:aws:iam::aws:policy/AdministratorAccess

[email protected]:~#aws iam attach-role-policy –role-name some_role –policy-arn arn:aws:iam::aws:policy/AdministratorAccess
viii) Updating an inline policy for a resource

An attacker with the iam:PutUserPolicy, iam:PutGroupPolicy, or iam:PutRolePolicy permissions can escalate privileges by updating an existing inline policy for a user, group, or role that they have access to, adding the permissions of the updated policy to the attacker.

[email protected]:~#aws iam put-user-policy –user-name my_username –policy-name my_inline_policy –policy-document file://path/to/administrator/policy.json


[email protected]:~#aws iam put-group-policy –group-name group_i_am_in –policy-name group_inline_policy –policy-document file://path/to/administrator/policy.json


[email protected]:~#aws iam put-role-policy –role-name role_i_can_assume –policy-name role_inline_policy –policy-document file://path/to/administrator/policy.json


Where the username is the current user, the group is a group the current user is in, or the role is a role that the current user can temporarily assume with sts:AssumeRole.

Potential Impact: Due to the ability to specify an arbitrary policy document with this method, the attacker could specify a policy that gives permission to perform any action on any resource, ultimately escalating to full administrator privileges in the AWS environment.

ix) Adding a user to a group

The iam:AddUserToGroup permission can be used to add a user to an existing IAM Group in the AWS account. Attackers can misuse this by gaining privileged access to an existing group in the account.

[email protected]:~#aws iam add-user-to-group –group-name victim_group –user-name some_username

Here victim_group has different privileges than the attacker’s user account.

x) Updating the AssumeRolePolicyDocument of a role

If an attacker has access to the iam:UpdateAssumeRolePolicy and sts:AssumeRole permissions, he would be able to change the assume role policy document of any existing role to allow them to assume that role. This would give the attacker the privileges that are attached to any role in the account.

[email protected]:~#aws iam update-assume-role-policy –role-name my_role –policy-document my_policy.json

Here the policy looks like the following, which gives the user permission to assume the role.


AWS post exploitation is definitely not limited to what we have discussed today. These could be the initial steps after a successful exploitation to enumerate more details form the compromised account. You can refer to a previous blog post on how to leverage Nimbostratus to perform post exploitation.

Thank you for reading! – Setu Parimi, Steve George & Indranil Roy

Sign up for the blog directly here.

Check out our professional services here.

Feedback is welcome! For professional services, fan mail, hate mail, or whatever else, contact [email protected]

Leave a Reply

Your email address will not be published. Required fields are marked *

%d bloggers like this: