> For the complete documentation index, see [llms.txt](https://docs.oort.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.oort.io/understanding-check-failures/oort-insights/identity-threat-detection-insights/azure-admin-activity-anomaly.md).
# Microsoft Entra ID Admin Activity Anomaly
Detects unusual administrative activity in Microsoft Entra ID by flagging accounts that either perform an action type for the first time, or apply changes to 10 or more targets within 10 minutes, measured against a 90-day behavioral baseline. If needed, exclude specific activity categories or adjust event or timeframe thresholds in Custom Detection Settings to reduce alerts from known high-volume administrative workflows in your environment.
Adversaries may create or modify an account to maintain access to victim systems or modify the configuration settings to evade defenses or escalate the privileges of the compromised account.
**Recommended Actions**
Verify with the account holder whether the flagged actions were intentional, as these alerts can sometimes reflect normal business lifecycle events such as bulk onboarding, offboarding, and scheduled migrations, or can highlight unexpected results of a desired configuration change.
If the activity is unrecognized or was not clearly authorized, suspend the account immediately and end all active sessions. Review the full list of affected targets (users, groups, apps, roles and policies), prioritizing changes that expand access or weaken controls, to determine the impact and whether any changes need to be reversed or escalated to affected business owners.
Refer to the [Admin Activity Anomaly Insights Explained](#admin-activity-anomaly-insights-explained) section below for more detailed information and remediation recommendations for this check.
**Default Check Settings**
Number Of Distinct Targets: 10
Timeframe in minutes: 10
Ignore List: Blank
#### **Compatibility**
[Microsoft Entra ID](/integrations/azure-active-directory-integration.md)
#### **Use Cases**
* An identity engineer performs a large remediation or migration, updating many users, groups, applications, or policies in a short period as part of legitimate business work.
* A compromised administrator account begins changing roles, memberships, applications, or policies across several targets, creating persistent backdoor access that survives a forced password reset of the original compromised account.
* A support or security administrator successfully performs a category of Microsoft Entra administrative action for the first time, making the behavior unusual enough to warrant business review.
* An automated provisioning script running under a user account rather than a designated service account exceeds the target threshold, generating a false positive that still warrants security team review and documentation.
#### **Real-World Incidents**
**Scattered Spider / MGM Resorts — September 2023**\
Attackers social-engineered IT help desks into resetting MFA on privileged admin accounts, then immediately made bulk changes to disable authentication requirements for targeted accounts and register fraudulent Identity Providers granting broad impersonation access across all connected applications.\
[BleepingComputer, Sep 2023](https://www.bleepingcomputer.com/news/security/mgm-resorts-cyberattack-MGM-Resorts-confirms-cyberattack-impacting-hotel-systems/)
**APT29 Device Code Phishing — Microsoft 365 / Entra ID, September 2025**\
Russia's APT29 used malicious OAuth device code flows to obtain persistent admin-scoped tokens for victim Microsoft 365 tenants, then performed first-time administrative actions including application registration and permission scope modifications that no legitimate user had ever previously executed in those environments.\
[BleepingComputer, Sep 2025](https://www.bleepingcomputer.com/news/security/microsoft-says-apt29-used-device-code-phishing-to-hack-azure/)
## Admin Activity Anomaly Insights Explained
### Overview
Identity Intelligence provides insights into anomalous user behavior for both Azure AD and Okta platforms. The intention is to highlight unusual activity that may be indicators of either privilege escalation or other invasive/evasive tactics used by threat actors within an environment.
The anomalous behavior can include a variety of different actions. This articles provides an understanding of the different categories. The core criteria to trigger this insight is the following:
* A user performing an administrative action (defined below) that they have not previously done over the past 90 days
* A user taking a high velocity of administrative actions in a short period of time (configurable, see below)
### Configuration
For high velocity admin actions, the default configuration is 10 targets or objects (users, groups, devices) in 10 minutes, as mentioned above under "Default Check Settings". This is configurable via the [Check Settings](/understanding-check-failures/customizing-checks.md#custom-detection-settings).
For Entra ID environments, the check is based on events collected from Entra ID [Directory Audits.](https://learn.microsoft.com/en-us/graph/api/resources/directoryaudit?view=graph-rest-1.0) Identity Intelligence specifically references and presents events and notifications for this check based on the `category` field from the [directoryAudit resource type](https://learn.microsoft.com/en-us/graph/api/resources/directoryaudit?view=graph-rest-1.0), which indicates the resource category that is targeted by the activity.\
\
**For example:** UserManagement, GroupManagement, ApplicationManagement, RoleManagement.
### Recommendations for User Activity Anomaly Events
From a security and governance perspective, anomalous admin actions and activity - both rare actions or bulk actions taken against a large number of objects - should be reviewed and confirmed with either:
1. Known normal behavior for that end user within the platform
2. A service ticket, request, or temporary privilege escalation that explains and justified the actions taken
Check failure events can be [marked as Suspicious or Normal Behavior](/understanding-your-users/remediation-actions.md#mark-as-suspicious-mark-as-normal-behavior) to log the result of an investigation within the Identity Intelligence platform either on the Failing Check page or on a given user's Checks tab in the User 360. These two feedback options are also available directly in your messaging system, if you have [configured the check to send alerts to tools such as Slack, Teams or Webex](/integrations.md#notification-targets), and your selected response will be sent back to the Identity Intelligence platform.\
\
These triage responses not only [mitigate the user so that they are no longer failing the check ](/understanding-check-failures/reviewing-check-results.md#available-actions)but also provide the Data team for Identity Intelligence with valuable insight to enhance the accuracy of the platform and it's detections.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://docs.oort.io/understanding-check-failures/oort-insights/identity-threat-detection-insights/azure-admin-activity-anomaly.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.