AWS - EC2 Privesc
Last updated
Last updated
Learn & practice AWS Hacking: Learn & practice GCP Hacking:
For more info about EC2 check:
iam:PassRole
, ec2:RunInstances
An attacker could create and instance attaching an IAM role and then access the instance to steal the IAM role credentials from the metadata endpoint.
Access via SSH
Run a new instance using a created ssh key (--key-name
) and then ssh into it (if you want to create a new one you might need to have the permission ec2:CreateKeyPair
).
Access via rev shell in user data
You can run a new instance using a user data (--user-data
) that will send you a rev shell. You don't need to specify security group this way.
Be careful with GuradDuty if you use the credentials of the IAM role outside of the instance:
Potential Impact: Direct privesc to a any EC2 role attached to existing instance profiles.
With this set of permissions you could also create an EC2 instance and register it inside an ECS cluster. This way, ECS services will be run in inside the EC2 instance where you have access and then you can penetrate those services (docker containers) and steal their ECS roles attached.
To learn how to force ECS services to be run in this new EC2 instance check:
If you cannot create a new instance but has the permission ecs:RegisterContainerInstance
you might be able to register the instance inside the cluster and perform the commented attack.
Potential Impact: Direct privesc to ECS roles attached to tasks.
iam:PassRole
, iam:AddRoleToInstanceProfile
Similar to the previous scenario, an attacker with these permissions could change the IAM role of a compromised instance so he could steal new credentials.
As an instance profile can only have 1 role, if the instance profile already has a role (common case), you will also need iam:RemoveRoleFromInstanceProfile
.
If the instance profile has a role and the attacker cannot remove it, there is another workaround. He could find an instance profile without a role or create a new one (iam:CreateInstanceProfile
), add the role to that instance profile (as previously discussed), and associate the instance profile compromised to a compromised instance:
If the instance doesn't have any instance profile (ec2:AssociateIamInstanceProfile
) *
Potential Impact: Direct privesc to a different EC2 role (you need to have compromised a AWS EC2 instance and some extra permission or specific instance profile status).
iam:PassRole
(( ec2:AssociateIamInstanceProfile
& ec2:DisassociateIamInstanceProfile
) || ec2:ReplaceIamInstanceProfileAssociation
)With these permissions it's possible to change the instance profile associated to an instance so if the attack had already access to an instance he will be able to steal credentials for more instance profile roles changing the one associated with it.
If it has an instance profile, you can remove the instance profile (ec2:DisassociateIamInstanceProfile
) and associate it *
or replace the instance profile of the compromised instance (ec2:ReplaceIamInstanceProfileAssociation
). *
Potential Impact: Direct privesc to a different EC2 role (you need to have compromised a AWS EC2 instance and some extra permission or specific instance profile status).
ec2:RequestSpotInstances
,iam:PassRole
An attacker with the permissions ec2:RequestSpotInstances
andiam:PassRole
can request a Spot Instance with an EC2 Role attached and a rev shell in the user data.
Once the instance is run, he can steal the IAM role.
ec2:ModifyInstanceAttribute
An attacker with the ec2:ModifyInstanceAttribute
can modify the instances attributes. Among them, he can change the user data, which implies that he can make the instance run arbitrary data. Which can be used to get a rev shell to the EC2 instance.
Note that the attributes can only be modified while the instance is stopped, so the permissions ec2:StopInstances
and ec2:StartInstances
.
Potential Impact: Direct privesc to any EC2 IAM Role attached to a created instance.
ec2:CreateLaunchTemplateVersion
,ec2:CreateLaunchTemplate
,ec2:ModifyLaunchTemplate
An attacker with the permissions ec2:CreateLaunchTemplateVersion
,ec2:CreateLaunchTemplate
and ec2:ModifyLaunchTemplate
can create a new Launch Template version with a rev shell in the user data and any EC2 IAM Role on it, change the default version, and any Autoscaler group using that Launch Template that is configured to use the latest or the default version will re-run the instances using that template and will execute the rev shell.
Potential Impact: Direct privesc to a different EC2 role.
autoscaling:CreateLaunchConfiguration
, autoscaling:CreateAutoScalingGroup
, iam:PassRole
An attacker with the permissions autoscaling:CreateLaunchConfiguration
,autoscaling:CreateAutoScalingGroup
,iam:PassRole
can create a Launch Configuration with an IAM Role and a rev shell inside the user data, then create an autoscaling group from that config and wait for the rev shell to steal the IAM Role.
Potential Impact: Direct privesc to a different EC2 role.
!autoscaling
The set of permissions ec2:CreateLaunchTemplate
and autoscaling:CreateAutoScalingGroup
aren't enough to escalate privileges to an IAM role because in order to attach the role specified in the Launch Configuration or in the Launch Template you need to permissions iam:PassRole
and ec2:RunInstances
(which is a known privesc).
ec2-instance-connect:SendSSHPublicKey
An attacker with the permission ec2-instance-connect:SendSSHPublicKey
can add an ssh key to a user and use it to access it (if he has ssh access to the instance) or to escalate privileges.
Potential Impact: Direct privesc to the EC2 IAM roles attached to running instances.
ec2-instance-connect:SendSerialConsoleSSHPublicKey
An attacker with the permission ec2-instance-connect:SendSerialConsoleSSHPublicKey
can add an ssh key to a serial connection. If the serial is not enable, the attacker needs the permission ec2:EnableSerialConsoleAccess
to enable it.
In order to connect to the serial port you also need to know the username and password of a user inside the machine.
This way isn't that useful to privesc as you need to know a username and password to exploit it.
Potential Impact: (Highly unprovable) Direct privesc to the EC2 IAM roles attached to running instances.
describe-launch-templates
,describe-launch-template-versions
Since launch templates have versioning, an attacker with ec2:describe-launch-templates
and ec2:describe-launch-template-versions
permissions could exploit these to discover sensitive information, such as credentials present in user data. To accomplish this, the following script loops through all versions of the available launch templates:
In the above commands, although we're specifying certain patterns (aws_|password|token|api
), you can use a different regex to search for other types of sensitive information.
Assuming we find aws_access_key_id
and aws_secret_access_key
, we can use these credentials to authenticate to AWS.
Potential Impact: Direct privilege escalation to IAM user(s).
Learn & practice AWS Hacking: Learn & practice GCP Hacking:
Check the !
Join the 💬 or the or follow us on Twitter 🐦 .
Share hacking tricks by submitting PRs to the and github repos.