DIY: Hunting Azure Shadow Admins Like Never Before

TL;DR

Cloud technologies are ubiquitous and most organizations rely on cloud vendors to provide them with critical services and computing workloads. This ecosystem makes organizations deeply dependent on their cloud infrastructure with the most popular cloud providers being AWS and Azure. In correlation to the increased importance of cloud environments, the opportunities for security threats in these environments have increased dramatically. For this reason, cloud security has become a crucial part of any organization’s security strategy.

Azure cloud, specifically, has experienced a recent spike in popularity as it’s adopted by organizations across all industries and segments. In this blog, we are going to discuss the threat of “Shadow Admins” – or hidden admin users – in Azure environments and how they can be used by attackers to perform privilege escalation and cause serious damage to an organization’s network. We’ll review the concept of Shadow Admins and how attackers can use them to their advantage and also introduce an open source tool, CyberArk SkyArk.

SkyArk is designed to help organizations combat Shadow Admins by targeting and securing the most privileged entities in both Azure and AWS environments.

Shadow Admins Concept

Shadow Admins are stealthy user entities that have specifically sensitive permissions granting them the ability to escalate privileges in cloud environments. These entities, which often arise from misconfigurations or lack of awareness, can be targeted by attackers, putting the entire environment at risk.

While organizations may be familiar with their list of straightforward admin accounts, Shadow Admins are much more difficult to discover due to the thousands of permissions that exist in standard cloud environments. (AWS and Azure each have more than 5,000 different permissions.) As a result, there are many cases where Shadow Admins can be created.
Despite the appearance of limited permissions, a Shadow Admin with just a single permission has the ability to gain the equivalent power of a full admin.

We’ve spent quite a significant amount of time researching the threat of Shadow Admins in the cloud as well as across on-prem networks.

Three years ago, we published our first research blog on the risk of Shadow Admin accounts in on-prem Active Directory networks and described how attackers can abuse them for malicious actions. On-premises Shadow Admin accounts have sensitive privileges and are typically overlooked as they are not members of a privileged Active Directory (AD) group. Instead, they’re granted privileges through the direct assignment of permissions (using ACLs on AD objects).

A year later, we then shifted our focus to cloud environments – looking at AWS. In this blog post you can read the full details of our discovery of stealthy admin users in AWS and how attackers find them and use them to take control of the entire AWS environment.

Along with our research, the threat of stealthy admins got the attention of more security researchers. For the on-prem networks, ACLs analysis of the Active Directory objects became an integrated part of the security tool BloodHound (thanks to @_wald0, @CptJesus and @harmj0y). Regarding AWS, a list of privilege escalation methods was published on GitHub (by @RhinoSecurity and @SpenGietz).

Azure Background

From a permissions assignment perspective, we can divide the Azure environment into two main layers. The first layer is the Directory layer and the second is the Subscription layer. The Directory layer is the Azure Active Directory (AAD); from here, you define and manage all the available Azure identities in your environment. The AAD is the identity source of all the Azure entities, including: Azure users, groups and applications. The Subscription layer includes the Azure resources. Azure resources are the things you run and host in your Azure environment. There are many types of resources: Azure VMs, DBs, Blob storages, Serverless functions, and many more.

These two different layers also have two different permission architectures. To be able to perform actions in the Directory layer, an entity should be assigned one of the AAD Administrator Roles. Figure 2 shows the Azure screen with the list of available AAD roles.

With the Subscription layer and the resources, you’re dealing with different permission assignments. You need to be defined as a Classic Administrator to be able to perform actions on Azure resources or to get permissions through the useful RBAC mechanism (Azure’s Role Based Access Control (RBAC)).

Azure Shadow Admin in Subscription layer

Now, let’s deal with the question of who the most privileged users in the Subscription layer are. In the Subscription layer, there are the obvious admin types, Classic Administrators, who are full subscription admins with essentially unrestricted power. There are three types of Classic Administrators: Account Administrator, Service Administrator and Co-Administrator.

Beyond these users, there are three straightforward full subscription admins through the RBAC Permissions Mechanism: Owner, Contributor and User Access Administrator.

A user who has a User Access Administrator RBAC role could be perceived as a Shadow Admin because, at first, this user cannot take any direct action on the subscription resources (i.e. they can’t create VM, delete DBs, etc.), but they can add new RBAC permissions as they see fit and then perform any action on resources. So, while the role User Access Administrator starts out without all the RBAC permissions, they can obtain them in a roundabout way.

Another interesting method for privilege escalation can be achieved through the “ownership” of a group or application. Azure Groups and Applications can be configured with an owner. If an attacker succeeds in compromising the owner of a privileged group or app, that could be an easy way to add himself to that privileged group or use the application identity for his own malicious intentions.

This, of course, is only privilege escalation, if the owner doesn’t start out with the same level of permissions that the group or the app had. We were surprised to see so many use cases for these unbalanced permissions. In the cloud world, there are so many places that organizations can make these kinds of mistakes and these misconfigurations can make an organization vulnerable to an attack.

Additionally, there is a whole new area for Shadow Admin creation in the custom RBAC roles. Organizations can create their own custom roles for their subscription, which is a very useful capability, but they must be careful not to make assignment mistakes.

Let’s examine an example:

In figure 5, you can see the permission assignment for a team leader in one of the organization’s storage teams.

This is a perfect (but unfortunate) example of a Shadow Admin user; this Storage Team Leader is actually a full Subscription Admin. At first glance, the user has only five lines of allowed permission – definitely not all the 5,000 permissions that are available in Azure, right?

However, one of the permissions allowed is “Microsoft.Authorization/roleAssignments/*” and this is the escalation vulnerability. This permission line gives users the ability to assign themselves to any other additional permission they seek to. So, it would be terrible if this team leader account fell into an attacker’s hands.

The absurd thing is that this permission line was given to the team leader intentionally (but without full awareness of the consequences). The organization has a business need for which the team leader has to be able to manage the permissions of his team members. For example, if new employees join, the team leader gives them the required DB permissions and, when they leave, the team leader is responsible for revoking and removing those permissions. Moreover, if the storage team creates a new DB, the team leader should be able to assign and manage the permissions on this newly created Azure DB.

The security issue was created when this organization defined the scope of the team leader’s permissions as “/subscription/6ec6070a-ded3-41bc-9541-14954bd22c3a”, which enabled the team leader’s permissions to apply across the entire subscription scope and not only to the scope of the storage team’s DBs. A correct permission assignment should be like Figure 6, wherein the AssignableScopes has an exact list of the needed DB resources.

Here is a summary table for the super sensitive subscription admins:

Azure Shadow Admins in the Directory Layer

Not long ago, when you wanted to create a new user in Azure, you had three options for roles to choose from and assign – as shown in Figure 8.

The new user could be a “User,” meaning a regular user without an AAD admin role,”Global administrator” with all the Azure Directory permissions – making it as powerful as a Domain admin in an on-prem Domain network—or “Limited Administrator.” Here is the full list of all the available AAD roles in the past.

The term “limited” here is extremely ironic as this is exactly where, if permission management was misused, Shadow Admins were being created. This could be the reason the word “limited” was removed from the current creation flow of new Azure users. However, the removal of that word didn’t resolve the risk of some AAD roles being able to perform privilege escalation and gain more permissions than they possessed at the start.

Here are a few examples of how a “limited” admin user can become a full admin – classic Shadow Admin scenarios:

1. Privileged Role Administrator – This is one of the “limited” roles, yet we can all agree that it isn’t limited at all. Users with this role can assign themselves any additional privileges they’d like and even become a Global Administrator.
2. Application Administrator and Cloud Application Administrator – The level of danger for both of these depends on the Azure applications in the environments. This type of admin can control privileged applications and, through them, can achieve more privileges than they had at the start. Many organizations have sensitive apps that can be leveraged, such as the ones used for backups, sync, SSO, DevOps, etc.
3. Helpdesk Administrator – This one is a straightforward Shadow Admin. A user with this role can reset the passwords of other targeted Azure users. This opens an easy privilege escalation scenario. If that “limited” admin user falls to an attacker, the attacker can target and impersonate other subscription admins and perform all of their malicious actions on their desired Azure subscription.
4. User Administrator – Here is another AAD role that can easily be used for privilege escalation. One of the scenarios here is to change membership in a privileged group and most organizations will already have an admin group that can be abused. With a compromised user in the role of User Administrator, the attackers can easily add themselves to this admin group and become a Subscription Admin as well. Another possible escalation scenario is to configure new users controlled by the attacker to be owners of those groups, i.e. writing group owner is possible with the permission “microsoft.directory/groups/owners/update.”

Microsoft has tried to put a limitation on some of the built-in admin roles so that they cannot perform sensitive actions on more powerful AAD admins. For example, a Helpdesk Administrator cannot reset the password of a Global Administrator, but they still can reset the passwords of other very sensitive admins like Subscription Owners. So, they can still easily escalate their permissions and be an admin for any targeted subscription in that Azure environment. A malicious user can also reset the passwords of the CEO, CISO and more – which is why we consider users with these AAD roles as TIER 0 and they must be discovered and protected carefully.

Scanning Your Cloud Environment with SkyArk

As part of the research we did on tricky permission assignments, we developed and published open source scanning tools to help mitigate these threats. For hunting Cloud Shadow Admins – we have SkyArk.

SkyArk’s goal is to help in the assessment and discovery of your most privileged entities in Azure and AWS. The tool is built from two main scanning modules:

1. AzureStealth – scans Azure environments
2. AWStealth – scans AWS environments

All the SkyArk details and a Quick Start Guide are written in the tool’s GitHub readme pages: SkyArk readme, AzureStealth and AWStealth. We invite you to try them out.

SkyArk is a quick and easy scan that only requires read-only permissions as it just queries the cloud entities and their assigned permissions and then performs the analysis and provides the results. You can watch SkyArk’s AzureStealth demo in Figure 10:

Figure 10. SkyArk’s AzureStealth demo – discovering Azure admins.

SkyArk Usage

1. Starting point:
   1. To scan Azure: you can perform the scan with any Azure user.
      • By default, any Azure user has read permissions over its Directory, so SkyArk can scan the directory’s admins. In addition, if that user also has read permissions on some subscriptions, the scan will also discover the admins in these subscriptions.
   2. To scan AWS: you need an access key or STS token with read permissions on the IAM service.
2. Starting the scan – see the exact commands in GitHub readme.
3. After a few minutes, the results will be presented to you and saved as csv results files.
4. With the results:
   1. Red Teamers:
      1. Take a look at the list of discovered cloud admins. SkyArk discovers the most privileged users in the target cloud environment, including the straightforward admins and the more hidden Shadow Admins.
      2. Try targeting one of the admins on the list. This can be accomplished by trying password matching, spear phishing on the user’s mail or a targeted attack on the endpoints of the employees with discovered admin rights (or shadow rights) on the organization’s cloud. Getting to that endpoint can be accomplished through the regular lateral movement attack phase in the targeted organization.
      3. Use the compromised admin user. If you get access to a Shadow Admin user, like our example of the Storage Team Leader, you can perform the privilege escalation trick related to this kind of Shadow Admin, and gain more permissions.
      4. Of course, report your findings to the organization’s security team for an urgent fix.
   2. Blue Teamers:
      1. SkyArk detects your most privileged users in Azure and AWS. The first step is to go over each of the users and identify them. Make sure that none of the users you discovered are already part of an ongoing attack and added as a backdoored admin user to your environment.
      2. For the second step, try to eliminate the unintended admins and remove unnecessary permissions from Shadow Admins. Manage your environment following the least privilege principle. Then, if one of the users is compromised, the malicious impact will be more limited.
      3. Finally, thoroughly secure the admins you discovered they are the beating heart of your cloud. Follow best practices for securing privileged users. Admins should have strong and automatically rotated passwords and their usage is be audited and monitored. Also, enforce their activity with MFA, etc.
      4. Nice tip: I’ve heard of companies who run a SkyArk scan on a periodic basis, then automatically alert if there is a deviation in the number of discovered admins. If, for some reason, a new Shadow Admin was created in your environment, you would be notified and able to handle it.

Wrapping Up

Attackers are increasingly targeting cloud environments and Shadow Admins are becoming a primary way for them to gain a foothold, escalate privileges and ultimately to do some serious damage. So, while securing admin users is the first key element in securing cloud environments, it’s impossible to secure these admins if you don’t know they exist – and that’s the true problem with Shadow Admins. SkyArk was developed to help make the challenge of finding and securing all your most privileged users (including Shadow Admins) easier and to make your cloud environments more secure.

The bottom line: It’s critical to discover your cloud admins before the bad guys do!

Thanks for reading, if you have any questions or want to share feedback – feel free to contact me: @Hechtov.