Monitoring the ‘Elevate Access Activity’ by Global Admin is a bit tricky operation and so far I have only found it possible with the Microsoft Cloud App Security (MCAS). Last year, I wrote about how you can do it with MCAS. The ultimate solution would be to monitor the activity in Azure Sentinel and, in this blog post, I’m showing how to achieve this by integrating MCAS and Azure Sentinel with Azure Logic Apps.

Special thanks to Ville Mäkelä & Christopher Brumm (@cbrhh) sparring with the topic.

Disclaimer – the scenario is tested in my two demo environments and more proper planning in Azure Logic Apps might be needed in the production environment. In the future, there might be a more robust way to establish the integration. A hint of it is seen in Azure Sentinel ‘M365 Defender’ data connector settings.

Background

There are many articles around how Azure AD Global Admin can elevate access to Azure Root Management Group (User Access Administrator) and I’m not covering the elevation process here. If you want to get familiar with the concept 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 part of the attack), according to Microsoft (docs.microsoft.com):

• 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, the user will get access to any subscription or management group in the directory.

Worth mentioning is that User Access Administrator role assignments can be removed using Azure PowerShell, Azure CLI, or the REST API. In general, the removal part has been updated since last summer. The permissions cannot be removed from the portal but when the admin changes the toggle option to “no”, permissions are removed from the root management group.

Send MCAS Activity Log Data to Azure Sentinel

Native Azure Sentinel ‘Cloud App Security’ data connector does include the following data sources:

• Alerts
• Cloud Discovery Logs

It means that the ‘Activity Log’, which contains the raw data from the apps connected (API connections) to MCAS is not included in the connector. To integrate ‘Activity Log’ with Azure Sentinel there are a couple of options to send the MCAS Activity Log data to the underlying Azure Log Analytics repository. For this blog I tested two approaches:

• Log Collector with MCAS SIEM agent
• Service to Service integration with Azure Logic Apps

Both solutions naturally have pros and cons. A modern way to establish the integration is to use cloud-native solutions instead of SIEM agent. If the SIEM agent is already running in the environment it might be more efficient to leverage that one.

Cloud App Security

I started the research by comparing data in the MCAS portal and data from the activity API to verify that I’m able to get and send the needed data to Azure Sentinel.

SIEM Agent aka Log Collector

I used the Windows server as a log collector and installed SIEM agent & Log Analytics agent to the server. Instructions on how to configure are found from here. When the SIEM agent is configured and receives the data add the folder as a custom log source on Log Analytics advanced configuration.

I found that all events from the MCAS Activity log were not ingested through the SIEM agent, such as the activity I was looking for in my use case. This is still under investigation and I will update the content if I found the root cause. If someone has more information about this and can shed a light on it, I’m more than happy to have a call around the topic through Teams.

Azure Logic Apps

Microsoft published guidance on how to establish service to service integration (send MCAS Activity Log data to Azure Sentinel) with Azure Logic Apps a while ago, a great blog that I suggest reading. I used this as a guide to starting building the integration.

Kudos to Ville Mäkelä, Azure wizard from Finland, who helped me to parse the MCAS activity data in the Azure Logic Apps to have it in Azure Sentinel more structured. In the Logic Apps, the following sections were configured:

• Reoccurrence
  • Once a day
• Initialize a variable for MCAS API Token
  • Type – String
  • Value – contains MCAS API token. The modern way would be to store a token to Azure Key Vault which I would recommend in the production instance
• HTTP – MCAS Activities API
  • Method – GET
  • URI – https://tenantname.cloudappsecurity.com/api/v1/activities/ (replace tenantname with your tenant name)
  • Headers – Authorization & MCAS_API_Token variable created in an earlier phase
• Parse JSON – Content: @{body(‘HTTP_-_MCAS_Activities_API’)} – see MS blog for reference
• Add For each control to iterate MCAS Activities parsed items
  • Select an output from previous steps (data) – @body(‘Parse_JSON’)?[‘data’]
  • Send Data (JSON request body – current item): @{items(‘For_each’)}
  • Custom Log Name: MCAS_Activity_Log_Data

By doing so, all activities are saved to separate rows which helps a lot (at least me) with KQL.

• On the left – data ingested with Azure Logic Apps
• On the right – data ingested with SIEM agent aka Log Collector

Expression Evaluation Failed

In case you face an error below verify that your data variable is defined like in the pictures below. You can configure it manually from the “expression” tab if needed.

Azure Sentinel

When data arrives in Azure Log Analytics I can leverage Azure Sentinel Analytics rules and create incidents based on the data. Even though, MCAS already creates alerts based on this activity, with Azure Sentinel there is more granularity for rule creation and possibilities to investigate (+hunt) the activities performed by the actor from a varied range of services.

If everything works as expected, when Global Admin elevates access to Azure Root Management Group and all subscriptions underneath it, MCAS will receive the data from Azure Management API and logs the activity to the Activity Log. From here there are two approaches:

• If you are not sending MCAS Actvity Log data to Azure Sentinel – Create an alert on MCAS and raise it up in Azure Sentinel based on Microsoft security rule – “Create incidents based on Microsoft Cloud App Security alerts“
• Create a custom analytics rule on Azure Sentinel based on the ingested MCAS activity log data

Analytics Rules in Azure Sentinel – Built-in Rule

The built-in rule based on MCAS alerts is not enabled by default. When enabled and if you have MCAS integration in place all alerts created by MCAS are found at the end of the day from Azure Sentinel.

Analytics Rules in Azure Sentinel – Custom Rule

In the custom rule, which is based on the activity log data ingestion through Logic Apps, I search for Microsoft.Authorization/elevateAccess/action activity where roleAssignmentScope == “/”.

The KQL query below should do a trick. I added username & client IP to the query to get more relevant data to the incident for the investigation.

MCAS_Activity_Log_Data_CL
| where rawDataJson_operationName_s contains "Microsoft.Authorization/elevateAccess/action"
| where parse_json(tostring(parse_json(rawDataJson_authorization_s).evidence)).roleAssignmentScope == "/"
| extend AccountCustomEntity = user_userName_s
| extend IPCustomEntity = device_clientIP_s

At the end of the day there are incident based on the activity.

Considerations

• Take into account MCAS API limits
• If a large number of events is received from the API you need to handle those ones in the Logic Apps that you don’t miss activities
• More info about MCAS API & Log Analytics Data Collector API

Summary

If you have read this far you might ask yourself, do I use MCAS or Azure Sentinel to create rules for this scenario?

As always, it depends on many different factors such as the organization’s needs, used solutions, security monitoring design, log architecture, and last but not least, roles and responsibilities. By sending MCAS Activity Log to Azure Sentinel you get more granularity for creating analytics rules and options to perform a deeper investigation of what has been happening after access has been elevated.

Hope this helps in cloud monitoring journey! Until next time!

This blog is part of Azure Week. Check it out for more great content!

About the Author:

Lead Consultant at NixuTigerTeam and an Azure MVP

Reference:

Lamppu, S. (2021). Monitor Elevate Access Activity in Azure with Azure Sentinel. Available at: https://samilamppu.com/2021/02/09/monitor-elevate-access-activity-in-azure-with-azure-sentinel/ [Accessed: 8th July 2021].