The three most effective and dangerous cyberattacks to Azure and countermeasures (part 3 – The privilege escalation)

In my previous two articles I examined two different areas, the network and the storage, I am going now to speak about Azure AD (active directory) and RBAC (role-based access control). In my opinion, the privilege escalation is the most dangerous and effective attack on the cloud, and for many reasons.

The cloud architecture is designed to be easily accessible and manageable for people, this is the main concept created by the new business mindset. Make it easier as possible for people to use the resources, this is the easiest and fastest way to achieve high productivity and usage.

Below a picture representing how Azure AD and RBAC works in Azure.

I don’t want to spend too much time explaining the basics of roles and so on, and you can find a good article to read here: https://docs.microsoft.com/en-us/azure/role-based-access-control/rbac-and-directory-admin-roles

I want to elaborate on a simple concept of it, privacy and delegation, authentication and authorization.

The relation between Azure AD and RBAC is very simple:

  • the account in Azure AD is an account with AD roles and no access to any Azure Resources;
  • We use Azure AD to authenticate and the account must be subscribed to an Azure resource in order to have the authorization to use it. Then, the Azure resource can be a management group, a subscription, a resource group and so on.
  • When the user has been subscribed, we use RBAC in order to manage the authorization, it means what the user can do in Azure.

As you can see in the picture it is a hierarchical structure, the roles assigned to the user at the top have effect in all the subdirectories, unless we specifically set a deny role.

There is one account that is able to do almost everything and anything, the Global Admin. The Global Admin is able to do anything he wants, for that reason, it is considered a very dangerous account.

Microsoft introduced a new Azure feature called: Azure Privilege Identity Management aka Azure PIM. See more about it here:

A Global Admin can provide to any account the possibility to elevate his account as Global Admin for a specific time window, the account decides that, below how to activate.

When the account has been elevated he is able to perform any type of operation at this role level. Behind the hood, the account keeps the same RBAC policies and a top elevated Azure AD role. The account is able to operate as Global Admin in the Azure resources authorized by RBAC.

However, something that many people ignore is that as Global Admin the account is also able to work with any Azure AD setting.

The account can enable the possibility to his account to enable Access management for Azure Resources, this is a setting in Azure AD and properties.

This is a setting that the Global Admin can only activate but, because the user is now global admin, he can do that.

Enabling this setting the user is authorizing himself to access to any azure resources tied to the main tenant, it means any subscription in any Azure Enterprise Agreement and in any resource. It means everywhere, anywhere, in any Azure resource tied to the tenant around the globe, this is a very dangerous operation.

There is also another important thing to consider after the setting has been enabled, it is not going to expire with the azure PIM time windows. When the Azure PIM expires this setting will stay enabled and the user will still have ownership access, this is a by-design feature.

If a hacker can perform a privilege escalation to the Global Admin account, it can be devastating for the company, the hacker can get access to the entire company.
Below a diagram showing you the potential exposure of a privilege escalation.

How a hacker can achieve a privileged escalation?

Well, unfortunately, there are many ways and the most used is an attack from the internal.
A hacker can persuade an employee convincing him/her to be another person, today it is very easy to find any information we need in the socials, people share their entire life.
A password on a piece of paper, or a password list in a lost phone, or even a lost phone with the Azure app installed and passwords cached in the browser.

Those are just a few examples but, trust me, the list is very long.

Companies are very focused on protecting from external, this is perfectly understandable, you are in your home, you close the door to keep you in safety. Even considering that a new guest in our home can be a potential threat, we also need to consider that a company is not exactly a home containing a family.
A company is full of different people with different life and interests, it is very complicated to control, especially from the internal.

If a professional cyber-criminal decides to attack a global company, he will attack from the internal, maybe the company will hire him.

A brute force attack and a privilege escalation is also another possibility. A hacker could access a VM exposed on the internet via RDP and, if the VM is joining the tenant, then we have a massive problem.

When I speak with my teams about security, I like to remember them, don’t trust anyone, especially yourself. The problem of being a global Admin cannot be solved by the “circle of trust”, this is not an acceptable option.

We need to implement the proper countermeasures in order to avoid or, at least, limit and control this threat. Logging is not the solution, we need to prevent that, the logging is perfect for forensic activities on post-attack.

The best prevention is offered by Azure Policies, using Azure policies we can control and even block the usage of those features.

Alerting and Auditing is also another thing to do, Azure log anything on Activity Log, we can alert for any possible authorized escalation in our infrastructure.

Azure Sentinel is another great option for working as an internal SIEM. See more about it here: https://azure.microsoft.com/en-gb/services/azure-sentinel/

There are also other ways and types of privilege escalations but the scope and the end are always the same.

Azure RBAC structure is very simple, three main roles:

  • Owner
    • It can do anything plus assigning security roles if a subscription level it can even delete the subscription.
  • Contributor
    • It can anything but assigning security roles
  • Reader
    • Just read the resources

An attack at the Owner level can be also extremely effective, especially if the hacker, instead of destroying, he is going to create backdoors and organizing for other things.

The cloud infrastructures are very suitable for large scale attacks, for that reason hacker can decide to use our infrastructure for a future massive attack to another target.

In this article, I was shown to you the most dangerous form of privilege escalation in Azure. Don’t underestimate the possibility of this attack, and if you are not sure about your internal security infrastructure, better you contact an expert and ask him for a security assessment.

What people underestimate?

the global Admin.

 

Related blog posts