Real Life Examples of Privilege Escalation in AWS and Azure

Privilege escalation attacks are one of the many dangers of managing identities in the cloud. Identity is the new stepping stone for bad-actors to exploit and use to move throughout your environment. We’ve explained some tactics bad-actors use to escalate their privileges in both AWS and Azure so you can recognize the pitfalls and get ahead of them.

The 5 Types of Privilege Escalation

Through our research we’ve identified five patterns of privilege escalation in the public cloud. Let’s review them below:

  1. Direct Self Escalation

This is when an Identity can modify its own rights. It has all the permissions it needs to move throughout your environment e.g. make itself an administrator.

  1. Indirect Escalation

This is where one identity can modify another identity’s credentials to impersonate it. For example, an identity has the permission to modify roles in AWS. While this identity is unable to read sensitive data itself, it can modify other roles so that they can read that data, and then jump into this new role and reach their goal ultimately.

  1. Unintended Inheritance

This is often the result of the complexity in your cloud, including a web of rules, policies, trust relationships and permissions that give access at an unintended level. For example in Azure, a security team using a VM may have that identity at least privilege, but then higher up in the RBAC model, at the management group level, it was set that all devs in the application group have permission to read across the tenant. The result is a VM having unintended inheritance to read data across the environment.

  1. Confused Deputy

An identity with a low set of permission gets access to a resource or a service with a higher level of permission and then uses that to perform actions on its behalf. For example, an EC2 instance has an instance profile with access to read sensitive data. The low level identity uses the EC2 to read all of the sensitive data on its behalf.

  1. Resource Permissions Escalations

An identity has the permissions to change the configuration settings on a resource to allow the identity to perform unintended actions on that resource. For example, this identity is at least privileged itself, but it somehow has the permissions to change the configurations of a datastore that normally it only has read access to, but now they want the ability to delete it all.

Now that we’ve reviewed the common patterns of privilege escalation, let’s review some examples from AWS and Azure that exemplify these patterns.

Real Life Examples of Privilege Escalation in AWS

Self-Assigning privileges with new IAM policies [Direct Escalation]

All a bad actor needs to execute this exploit is access to an identity (user account) with the permission iam:CreatePolicyVersion. This enables them to create a new version of an IAM policy, which allows them to simply grant themselves the access privileges they need to execute their plan. By enabling them to define their own custom permissions, this vulnerability allows a bad actor to wreak irreparable damage in your environment.

When you create a new version of an IAM Policy, you must set it as the default in order for it to take effect on the system, and that’s where the fatal misconception comes into play. In reality, being able to set a policy as default does not require a user (non-person identity) to have the iam:SetDefaultPolicyVersion permission, although most assume that it does. Rather, when creating a new permission, a user simply needs to flag it with “set-as-default” and AWS will automatically make the new default version when it’s created.

Modify the Policy on an AWS Role and then use it [Indirect Escalation]

Oftentimes an AWS User seems pretty locked down to what they can do but looks can be deceiving.  If that AWS User has the ability to assume a specific AWS Role and perform some basic AWS IAM commands, say to list Managed Policies that are attached to the Role, list the Policy Versions of the Managed Policies and then set the Default Policy to one that is more privileged, then they can escallate the permissions of the role and then use it for their own purposes. From there, the User is no longer acting under their Identity but instead as the newly escalated AWS Role.

Creating access keys for a privileged user [Confused Deputy]

Starting with a very limited set of permissions, the attacker is able to leverage the instance-profile-attachment permissions to create a new EC2 instance with significantly greater privileges than their own. With access to this new EC2 instance, the attacker gains full administrative powers within the target account and is able to accomplish the scenario’s goal – deleting the cg-super-critical-security-server and paving the way for further nefarious actions.

Attaching new policies to roles, users, and groups [Resource Permissions Escalations]

By gaining the iam:AttachUserPolicy permission, a bad actor is able to escalate their privileges by attaching an IAM policy to any identity they have access to. What’s most concerning about this method and the similar examples to follow, is that it provides a direct pathway to administrator privileges, as the bad actor simply needs to attach the AdministratorAccess AWS managed policy to a user they have access to, and they’ll suddenly have full access to your AWS environment. Similar to the above, the iam:AttachGroupPolicy permission enables a bad actor to escalate their privileges by giving a group that they’re a member of a new policy with escalated access to the environment. Like the above method, the bad actor could attach the AdministratorAccess AWS managed policy to their user group, which would give them full access to your environment.The iam:AttachRolePolicy permission is another commonly exploited privilege that allows a bad actor to escalate their permissions by attaching a policy, including the AdministratorAccess AWS managed policy, to a role they are assigned to. The user is able to assume the role temporarily using sts:AssumeRole.

Real Life Examples of Privilege Escalation in Azure

Managed identities become a subscription owner [Indirect Escalation]

Another common and straightforward escalation tactic is for a bad actor to gain access through an Azure ‘Subscription Owner’. Typically a bad actor will add a “guest” to their subscription. Once the guest is added, it is elevated to an ‘Owner’. If the identity is given a role (Contributor, Owner, etc.) or the privileges are higher than those granted to the guest they will gain access to virtual machine escalating privileges beyond the VM.

Add a guest account to the subscription [Direct Self Escalation]

Similar to the above, adding a guest account to a ‘subscription’ enables a bad actor to escalate their privileges by executing commands on other VMs via Azure CLI or APIs with escalated access to the environment. Like the above method, the bad actor could pivot to other data sets and evaluate permissions which would give them full access to your environment.

Managed identities gain access to Key Vaults [Resource Permissions Escalations]

The bad actor will target a managed identity that has the most permissions. Once the keys are created, they’ll use them to access your environment. The result is that the bad actor will have the same permissions levels as the managed identity.  They will be able to create keys, overwrite or delete secrets stored, which could result in anything from no privilege escalation to full administrative access.

Privilege Escalation via Cloud Shell [Resource Permissions Escalation]

By default, Azure Subscription Contributors have access to all storage accounts in a subscription. These storage accounts can contain Azure Cloud Shell storage files (Linux home directories) that can contain sensitive information. By modifying these Cloud Shell files, a bad actor can execute commands in the Cloud Shell sessions of other identities. This can lead to cross-account command execution and privilege escalation.

Secondary Access [Unintended Inheritance]

Subscriptions where an identity does not have contributor rights on a VM, but they have Runbook creation and run rights on an Automation account means the automation account has subscription contributor rights. These rights allow the lesser privileged identity to run commands on the VM through the Runbook. While this in itself is a privilege inheritance and entitlement issue, it can be abused by the previously outlined process to escalate privileges on an Azure subscription.

Solutions for Preventing Privilege Escalation: CIEM

Privilege escalation is a sinister tactic as it often happens right under your nose. Sometimes your security team may have locked down a workload at least privilege, but not realized that non-person identity actually has a permission allowing it to manipulate another role. Suddenly, even though the workload at hand is at least privilege, it can actually still help execute a malicious act through manipulating another identity to work on its behalf. If your security team has done all it can to make sure a workload is at least privilege yet bad actors can still find ways to accomplish their goals, how do you truly protect your environment?

Where manual and human efforts reach their threshold, solutions and tools can step in. Cloud Infrastructure Entitlements Management (CIEM) is the answer to your privilege escalation troubles. A strong CIEM solution can detect every single pathway between every single identity and data, permissions, roles and more, across different accounts and environments. This means every covert way a bad-actor could manipulate your configurations is revealed. 

CIEM platforms will inventory every identity, person and non-person, reveal their effective permissions and allow your team to note the excessive permissions or possible dangers like toxic combinations or privilege escalation. A CIEM platform is a sure way to help your cloud reach least privilege and make sure you stay there.

Sonrai CIEM Capabilities

Sonrai Dig harnesses graphing technologies that tackle all the benefits of a CIEM solution, but offers even more. Dig can separate groups and environments into different ‘swimlanes’, allowing your organization to set unique security targets and security maturity assessment scores. When security concerns are detected, our intelligent workflows make sure the correct team is notified to reduce alert overwhelm and fatigue and address the issue – if a bot hasn’t already handled that for you.

To see Dig in action, request a demo.

The post Real Life Examples of Privilege Escalation in AWS and Azure appeared first on Sonrai Security.

*** This is a Security Bloggers Network syndicated blog from Blog – Sonrai Security authored by Eric Kedrosky. Read the original post at:

Real Life Examples of Privilege Escalation in AWS and Azure

Leave a Reply