Detecting Unauthorized Privilege Escalation in Microsoft 365 Using KQL and Azure Alerts – CloudSecOp.com : Real-World Tech Insights

In modern cloud environments, identity is the new security perimeter. As organizations increasingly rely on Microsoft 365 for identity, collaboration, and administration, monitoring privileged access becomes a critical component of any security strategy. Unauthorized privilege escalation, whether caused by compromised accounts, insider threats, or configuration abuse, can lead to catastrophic consequences such as data exfiltration, persistence, or widespread compromise.

This article explains the importance of a targeted KQL (Kusto Query Language) query designed to detect role assignments and privilege changes in Microsoft 365, and how integrating this detection into Azure Alerts strengthens the overall security posture. A refined version of the query is also provided.

1 – Why Monitoring Privilege Escalation in M365 Matters

A – Privilege Escalation Is a Primary Attack Vector

Adversaries seeking access to sensitive data or administrative capabilities often aim to elevate their permissions. In M365, roles such as Global Administrator, Exchange Administrator, or Privileged Role Administrator provide powerful access to cloud resources.
If an attacker gains access to an identity and assigns additional roles either directly or by adding the compromised user to privileged groups they can rapidly expand their foothold.

B – Built-In Audit Logs Provide the Visibility You Need

Microsoft 365 generates extensive logs for Directory Role changes. These logs include:

Who initiated the action
Which roles or accounts were modified
When and where the action occurred
The operational context (IP address, device, identity provider)

Leveraging these logs through Microsoft Sentinel or the Azure Monitor Log Analytics workspace is a best practice for SIEM-driven detection.

C – Proactive Detection Prevents Breaches

Privilege escalation should be considered a high-severity event. Detecting it early allows a security team to:

Identify compromised administrator accounts
Prevent lateral movement
Respond before attackers exfiltrate data
Satisfy compliance requirements for access transparency

Setting up an alert based on this query ensures real-time visibility into security-critical events that could otherwise go unnoticed.

Create/modify Log Analytics Space

I explained in a previous article the steps to follow to create a Log Analytics Workspace. You can refer to that article for more details.

Proactive M365 Threat Detection : Live Detection of Sign-In Attempts from Unusual Locations – CloudSecOp.com : Real-World Tech Insights

Steps :

Go to the Entra ID admin Center : https://entra.microsoft.com/
Select Monitoring & Health menu
Select Diagnostic settings
If you dont have Log Analytics Workspace then click on “Add diagnostic settings“.
if you already have Log Analytics Workspace just Edit settings.

Select the “AuditLogs” table to be added to your Log Analytics Workspace. We need only this table.
Click Save

Keep in mind the AuditLogs table can take up to 24 hours to appear in your Log Analytics Workspace.

The KQL Query

Find out the KQL query used to capture role changes from my Github Repository :

https://github.com/aymenjaz/KQL/blob/main/KQL%20queries/Detecting%20Unauthorized%20Privilege%20Escalation%20in%20Microsoft%20365.KQL

Executing the KQL Query

So, to be able to execute the query :

Go to your Log Analytics workspace in the top navigation bar.
Select “Logs” from the left-hand menu.
Close the Queries hub by clicking the ‘X’ in the top right corner of that section.

Select KQL mode in your Log Analytics workspace.
Copy/Paste the KQL query to filter sign-in attempts from locations outside Canada (CA) and the United States (US).
Click “Run” to execute the query.

Review the results in the table below, which includes details like :

Saving as KQL Query

Always in the log Analitycs Workspace.
Click on Save then select “Save as query“

Enter a Query Name : Example : "Escalation Attempts". This is the title under which your query will be saved for future use.
Add a Description : Example : "Detecting Unauthorized Privilege Escalation in Microsoft 365". Helps explain the purpose of the query to other users or future you.
Resource Type: Select "Log Analytics workspaces"
Category: Choose a relevant category like "Audit"
Label : Optionally, select or create a label to organize your queries.
Click “Save”.

This saves the query with all the metadata so it can be reused or referenced later.

Keep the query name in Notepad because we’ll use it later (Escalation Attempts).

Create new Alert

Always in the log Analitycs Workspace.
On the top right, click on “…” (three points), then select “New Alert Rule“.

In the Condition section:

Set the Signal name to “Custom log search”.
Choose the appropriate Query type (e.g., Aggregated logs, Single log, or Multiple logs).
Paste your KQL query in the text box to define the condition that will trigger the alert.

In the Measurement section:

Set Measure to “Table rows”.
Choose “Count” as the Aggregation type.
Set the Aggregation granularity to “10 minutes” (or another interval depending on your needs).

Aggregation granularity Defines the time window over which the data is aggregated. Azure will evaluate the query every 10 minutes and count how many matching rows appear in that period.

Click “Next: Actions” to configure what happens when the alert is triggered (e.g., email, webhook, automation).

Define Alert Logic

Set the operator to “Greater than” to define the condition.
Enter the threshold value (0) that will trigger the alert if the KQL query rows are greater than 0.
Choose the time aggregation (e.g., 10 minutes) to specify how data is grouped over time.
Override query time range : 30 min (or change it as your company needs)
Click “Next Action” to continue.

In the “Action” section :

Select Quick Actions (Preview) : Choose the “Use quick actions (preview)” option to simplify the setup of notification actions.
Configure Action Group Details
- Action Group Name : Set a name like "Send Escalation Alert" to identify the group.
- Display Name: Provide a short label like "Escalation" for easier reference.
- Notification Emails : Add email addresses that should receive the alert (e.g., helpdesk@globalitnow.com, admin@globalitnow.com).
- Optionally, enable:
  - Email Azure Resource Manager Role
  - Azure mobile app notifications
Click the “Save” button to confirm and apply the notification settings.
Customize the subject line for alert emails, e.g., "Alert - M365 Escalation right".
Use “Next: Details >” to proceed with alert rule configuration.

Choose the Azure subscription under which the alert will be created (e.g., Azure subscription 1).
Select the resource group
Set the severity level (e.g., 2 – Critical) to indicate the importance of the alert.
Provide a descriptive name (e.g., Sign-in Attempts from Unusual Locations).
Add a brief explanation of the alert’s purpose.
Choose the region where the alert will be deployed (Keep in mind all resources should be in same location)
Click “Review + create”.