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.
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.
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
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)
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.
unfortunately I can’t see Azure operation = ElevateAccess Microsoft.Authorization in my drop down list. double checked I have the same screen/options as you. any idea why?
I’m aware of the issue. Due to the recent changes in the MCAS platform, the presented solution doesn’t work at the moment (filtering doesn’t work as presented in the blog). I have been on vacation the whole summer but I will take a look is there a workaround available. I used a similar method in one of my earlier blogs related to O365 ATP & MCAS. I just updated the blog and now it contains a workaround but I haven’t had time to test that one with Azure API events.
Here is a link to O365 ATP & MCAS blog
I found out today that the activity log filtering works in my MCAS instance. Could you please try in your tenant as well? The guidance I created earlier should work. If not, try this one by replacing fetanet with you own domain name.
Thanks for the update and the link. I was able to create the alert based off that search string URL. still couldn’t see it if creating manually though for some reason.
not seeing any alerts fire yet but we’ll see.
Great to hear that it worked! It should immediately show results if there are any. I tested search string URL in 2 tenants and it worked as expected. Reach me out if you have any additional questions.
Comments are closed.