During the last months, I have received many questions about the possibility to detect activity when Azure AD Global Admin elevates access his/her own account to Azure resources. This process grants permissions (User Access Administrator) to the Azure root scope. In practical to the Root Management Group and all Azure subscriptions.

The main reason to write this blog is to shed a light on the possibilities if there are any. The activity itself is not found from any built-in logs. The assumption is that these kinds of activities would be logged in Azure AD or Azure Activity logs.

Disclaimer: I did tests found in this blog only in two of my demo tenants but the assumption is that the same method works in all tenants.

Setting is found underneath Azure AD properties

Background – What’s Elevated Access

There are many articles on how to elevate the access itself and I’m not covering that section here. If you want to read the background information about the scenario I recommend starting from here.

By default, Global Admin doesn’t have access to Azure resources. Azure AD and Azure resources are secured independently from one another but there might be a reason when this operation needs to be done (if not an attack), use cases by Microsoft:

  • Regain access to an Azure subscription or management group when a user has lost access
  • Grant another user or yourself access to an Azure subscription or management group
  • See all Azure subscriptions or management groups in an organization
  • Allow an automation app (such as an invoicing or auditing app) to access all Azure subscriptions or management groups

Permission granted is the User Access Administrator role in Azure at the root scope (/).  With this role, you will receive access to any subscription or management group in the directory.

This sounds a bit scary in terms of security and I understand totally the concern about missing security monitoring. Imagine a scenario where there would be rogue admin playing around in the environment….

Worth to mention is that User Access Administrator role assignments can be removed using Azure PowerShell, Azure CLI, or the REST API. What’s interesting, when I removed permissions by toggle option to “no”, permissions were not removed from the account. I need to perform additional tests about this and will write a blog post after the summer vacation period about permission removal.

Built-in Logs

When Global Admin elevates itself to the User Access Administrator group the built-in Azure Activity logs are empty, nothing is logged about the activity. I granted the permissions on Saturday, May 30, 2020 7:33:44 PM.

Subscription Activity Log doesn’t have any event about the activity.

Tenant root group Activity Log doesn’t have any event about the activity either.

During the time of change there isn’t anything in Azure AD Audit Logs.

I checked Unified Audit Logs from the O365 side, just in case but no sign off any event related to the activity.

Possible Solution – Microsoft Cloud App Security?

I’m a huge fan of Microsoft Cloud App Security and it gives deep insight information from the integrated Apps through APIs. If Cloud App Security has Azure integration enabled it will receive activities from the Azure API (https://management.core.windows.net/).

When you receive the data, the next question is, does it contain any information about the elevated access? Yes, it does! I can see that there are two events:

  • ElevateAccess Microsoft.Authorization: resource /providers/Microsoft.Authorization- Started
  • ElevateAccess Microsoft.Authorization: resource /providers/Microsoft.Authorization- Succeeded

Raw data in JSON mode

Create Custom Alert

Update 08/18/2020

If the search below doesn’t work as expected and you are not able to find “ElevateAccess Microsoft.Authorization” when creating the policy you can use this search string which should do a trick (replace fetanet with own domain name)

https://fetanet.portal.cloudappsecurity.com/#/audits?service=eq(i:35851,i:12260)&activity.eventType=eq(12260:EVENT_AZURE_GENERIC:Microsoft.Authorization%2FelevateAccess%2Faction,)

There isn’t any built-in alert policy for the scenario and custom alert is needed for this case. To achieve desired outcome select Activity type as below:

  • Azure operation = ElevateAccess Microsoft.Authorization

At the end of the day, you will receive an alert every time someone with Global Admin permissions in the organization elevates access to Azure resources starts & succeed/fails.

What’s even better, if MCAS is integrated to Azure Sentinel the same alert is found from SIEM 🙂

I hope this helps! Removal of un-needed permissions from root management group is worth another blog post.