LOG-05: Admin Activity Anomaly Detection

Overview

This guide walks you through detecting anomalous behavior by admin accounts using Microsoft Entra ID Identity Protection and Log Analytics. At Level 2, the focus is specifically on admin accounts: unusual sign-in locations, bulk operations performed in a short window, and activity outside normal working hours. These are the signals most commonly associated with compromised administrator accounts.

Control ID: LOG-05 Category: Logging Severity: High Minimum Level: 2 License Required: Microsoft Entra ID P2

Why This Matters

Compromised admin accounts often exhibit unusual patterns: signing in from new locations, performing bulk operations, or working at unusual hours. Detecting these anomalies enables early response to account compromise.

Advisory: TrueConfig detects whether admin anomaly monitoring is configured. Remediation is manual and requires configuring Identity Protection, Diagnostic Settings, and Log Analytics or Microsoft Sentinel in your environment.

Prerequisites

Required Roles

You need one of the following roles:

• Security Administrator
• Global Administrator
• Security Reader (for viewing reports only)

For Log Analytics and Sentinel rule configuration:

• Contributor on the Azure subscription

Required Licenses

Pre-Configuration Requirements

• Entra ID P2 licenses assigned to all admin accounts
• Entra ID Diagnostic Settings configured to stream AuditLogs and SignInLogs (see LOG-02)
• Log Analytics workspace receiving Entra ID logs
• Admin account naming convention or security group defined so queries can filter to admin accounts

Time Estimate

Step-by-Step Instructions

Step 1: Access Identity Protection and Review Admin Account Risks

Identity Protection is the primary source for sign-in anomaly signals on admin accounts.

1. Navigate to Microsoft Entra admin center
2. Go to Protection > Identity Protection
3. Click Risk detections
4. Filter the list to admin accounts:
   • Use the User filter to search for admin UPNs or use your admin naming convention
5. Review detections for the following signals, which are highest priority for admin accounts:

1. Click individual detections to review IP address, location, device, and sign-in details

Step 2: Configure Admin-Specific Identity Protection Notifications

Set up immediate email alerts when admin accounts are flagged as risky.

1. Navigate to Protection > Identity Protection
2. Click Notifications

Users at Risk Detected Alerts

1. Under Users at risk detected alerts:
   • Click Add recipient
   • Add the security team distribution list and any on-call contact
   • Set frequency to Immediate for high-risk detections
2. Click Save

Weekly Digest

1. Under Weekly digest, add recipients for a summary of:
   • Admin accounts newly flagged as risky
   • Dismissed or resolved risks from the prior week
   • Risk trend changes
2. Click Save

Step 3: Configure Log Analytics Queries for Admin Anomalies

These KQL queries detect the three core anomaly patterns for admin accounts directly from the sign-in and audit log data. Run them in your Log Analytics workspace or deploy them as Sentinel analytics rules.

Prerequisites: Entra ID Diagnostic Settings must be streaming AuditLogs and SignInLogs to this workspace. See LOG-02 for setup.

Query 1: New Sign-In Location for an Admin Account

Detects admin accounts signing in from a country not seen in the prior 30 days.

let AdminAccounts =
    AuditLogs
    | where TimeGenerated > ago(30d)
    | where OperationName == "Add member to role"
    | extend AssignedUser = tostring(TargetResources[0].userPrincipalName)
    | where isnotempty(AssignedUser)
    | summarize by AssignedUser;
let HistoricalLocations =
    SigninLogs
    | where TimeGenerated between (ago(30d) .. ago(1h))
    | join kind=inner AdminAccounts on $left.UserPrincipalName == $right.AssignedUser
    | summarize HistoricalCountries = make_set(Location) by UserPrincipalName;
SigninLogs
| where TimeGenerated > ago(1h)
| where ResultType == 0
// Adjust the UPN filter to match your admin naming convention if role-based lookup is not practical
| where UserPrincipalName has_any ("admin", "ga-", "-adm")
| join kind=leftouter HistoricalLocations on UserPrincipalName
| where isempty(HistoricalCountries) or not(Location in (HistoricalCountries))
| project TimeGenerated, UserPrincipalName, Location, IPAddress, AppDisplayName

Query 2: Bulk Operations by a Single Admin (15-Minute Window)

Detects an admin performing more than 20 directory or policy operations within 15 minutes, which may indicate automated abuse of a compromised session.

AuditLogs
| where TimeGenerated > ago(1h)
| where Category in ("RoleManagement", "Policy", "ApplicationManagement", "GroupManagement", "UserManagement")
| extend Actor = tostring(InitiatedBy.user.userPrincipalName)
| where isnotempty(Actor)
| summarize OperationCount = count(), Operations = make_set(OperationName) by Actor, bin(TimeGenerated, 15m)
| where OperationCount > 20
| project TimeGenerated, Actor, OperationCount, Operations

Query 3: Off-Hours Admin Activity

Detects directory changes by admin accounts outside normal business hours. Adjust the UTC window to match your organization's timezone and working hours.

AuditLogs
| where TimeGenerated > ago(24h)
| extend HourOfDay = hourofday(TimeGenerated)
// Flags activity outside 07:00-20:00 UTC; adjust for your organization's timezone
| where HourOfDay < 7 or HourOfDay > 20
| where Category in ("RoleManagement", "Policy", "UserManagement", "ApplicationManagement")
| extend Actor = tostring(InitiatedBy.user.userPrincipalName)
| where isnotempty(Actor)
| project TimeGenerated, HourOfDay, Actor, OperationName, Category, Result
| order by TimeGenerated desc

Query 4: Admin Sign-In from Anonymous IP

Detects successful admin sign-ins from anonymizing infrastructure (Tor, VPNs, hosting providers).

SigninLogs
| where TimeGenerated > ago(24h)
| where ResultType == 0
| where RiskEventTypes_V2 has_any ("anonymizedIPAddress", "maliciousIPAddress")
    or NetworkLocationDetails has "anonymousProxy"
| where UserPrincipalName has_any ("admin", "ga-", "-adm")
| project TimeGenerated, UserPrincipalName, IPAddress, Location, RiskEventTypes_V2, AppDisplayName

Step 4: Deploy Queries as Sentinel Analytics Rules

Deploy the queries above as scheduled analytics rules for continuous automated detection.

1. In your Sentinel workspace, go to Configuration > Analytics
2. Click + Create > Scheduled query rule
3. For each query:
   • Name: Use the query name (for example, Admin: New Sign-In Location Detected)
   • Tactics: Credential Access, Lateral Movement (as applicable)
   • Severity: High for new location and anonymous IP; Medium for bulk operations and off-hours
4. Paste the query
5. Set Run query every: 5 minutes
6. Set Lookup data from last: 1 hour (or 24h for off-hours query)
7. Under Incident settings, enable incident creation
8. Click Save and enable

Step 5: Configure Named Locations to Reduce False Positives

Define known office IP ranges and countries so that sign-ins from expected locations do not trigger alerts.

1. Navigate to Protection > Conditional Access > Named locations
2. Click + IP ranges location
3. Add your office IP ranges with Mark as trusted location checked
4. Add a second named location for expected countries if your admin team operates across multiple regions
5. Update the detection queries to exclude these named locations:

// Add to the top of new-location queries:
let TrustedRanges = dynamic(["203.0.113.0/24", "198.51.100.0/24"]); // replace with your office CIDRs

Verification Checklist

After configuring admin anomaly detection:

• Unusual admin behaviors trigger alerts in Identity Protection or Sentinel
• New sign-in locations for admin accounts are flagged
• Bulk operations by admins are monitored (query deployed and tested)
• Off-hours admin activity is tracked (query deployed and tested)
• Identity Protection notifications are configured for the security team
• Log Analytics or Sentinel analytics rules are in Enabled state
• Named locations are configured to reduce false positives from known office locations
• A test admin action was performed and confirmed visible in query results
• Escalation procedures document what to do when an admin anomaly fires

Troubleshooting

Issue: No Admin Risk Detections Appearing in Identity Protection

Cause: Entra ID P2 licenses not assigned or no sign-in activity on admin accounts.

Solution:

1. Verify Entra ID P2 licenses are assigned to admin accounts
2. Wait 24-48 hours after license assignment for risk scoring to activate
3. Confirm that admin accounts are actively signing in (not service accounts with no interactive sign-ins)

Issue: Off-Hours Query Returns Too Many False Positives

Cause: UTC time window does not match your organization's local working hours, or admin accounts legitimately span multiple time zones.

Solution:

1. Adjust the HourOfDay filter in Query 3 to reflect your actual UTC business hours
2. Add a named-location filter to exclude expected remote work locations
3. Add known service account UPNs to an exclusion list at the top of the query

Issue: Bulk Operations Query Fires on Automated Provisioning Jobs

Cause: A legitimate service principal or provisioning account performs bulk operations during scheduled runs.

Solution:

1. Identify the service account or managed identity UPN responsible
2. Add an exclusion at the top of Query 2:

| where Actor !in ("provisioning-svc@yourdomain.com", "sync-account@yourdomain.com")

Issue: Sentinel Analytics Rule Never Creates an Incident

Cause: Incident settings are off, or query returns no results because the time range does not overlap with activity.

Solution:

1. Edit the rule and confirm Create incidents from alerts triggered by this analytics rule is enabled
2. Run the query manually in Logs with a wider time range to verify it can return results
3. Check that the Log Analytics workspace is receiving Entra ID data (run SigninLogs | take 5)

Issue: New Sign-In Location Query Returns No Results for Known Admin Accounts

Cause: Admin account UPN does not match the filter pattern, or the account has never signed in interactively.

Solution:

1. Run SigninLogs | where UserPrincipalName == "specific-admin@yourdomain.com" | take 5 to verify the account appears in logs
2. Update the UPN filter pattern to match your actual admin naming convention
3. For accounts in a security group, consider using a group-membership lookup instead of a UPN pattern filter

Related Controls

• LOG-03: Stream All Security Events to SIEM in Real-Time - Level 3 real-time streaming that builds on this control
• LOG-04: Configure Privileged Operation Alerts - Complements anomaly detection with rule-based alerting on specific operations
• CA-03: Sign-In Risk Policy - Conditional Access enforcement when Identity Protection detects a risky sign-in
• CA-04: User Risk Policy - Conditional Access requiring password change when an admin account is flagged as high-risk user

Additional Resources

• Microsoft Learn: What is Identity Protection?
• Microsoft Learn: Risk detection types
• Microsoft Learn: Investigate risky users
• Microsoft Sentinel: Create scheduled analytics rules
• Microsoft Learn: Named locations in Conditional Access