Detection rules › Kusto
Authentications of Privileged Accounts Outside of Expected Controls
'Detects when a privileged user account successfully authenticates from a location, device or ASN that another admin has not logged in from in the last 7 days. Privileged accounts are a key target for threat actors, monitoring for logins from these accounts that deviate from normal activity can help identify compromised accounts. Authentication attempts should be investigated to ensure the activity was legitimate and if there is other similar activity. Ref: https://docs.microsoft.com/azure/active-directory/fundamentals/security-operations-user-accounts#monitoring-for-successful-unusual-sign-ins'
MITRE ATT&CK coverage
| Tactic | Techniques |
|---|---|
| Initial Access | T1078.004 Valid Accounts: Cloud Accounts |
Rules detecting the same action
Other rules on this platform that filter on the same API call or operation.
- Anomalous sign-in location by user account and authenticating application (Kusto)
- Anomalous Single Factor Signin (Kusto)
- Azure Many Failed SignIns (Panther)
- Azure Portal sign in from another Azure Tenant (Kusto)
- Azure Service Principal Sign-In Followed by Arc Cluster Credential Access (Elastic)
- Azure SignIn via Legacy Authentication Protocol (Panther)
- Detect non-admin requesting token for admin applications (Kusto)
- Discovery Using AzureHound (Sigma)
Rule body kusto
id: af435ca1-fb70-4de1-92c1-7435c48482a9
name: Authentications of Privileged Accounts Outside of Expected Controls
description: |
'Detects when a privileged user account successfully authenticates from a location, device or ASN that another admin has not logged in from in the last 7 days.
Privileged accounts are a key target for threat actors, monitoring for logins from these accounts that deviate from normal activity can help identify compromised accounts.
Authentication attempts should be investigated to ensure the activity was legitimate and if there is other similar activity.
Ref: https://docs.microsoft.com/azure/active-directory/fundamentals/security-operations-user-accounts#monitoring-for-successful-unusual-sign-ins'
severity: Medium
requiredDataConnectors:
- connectorId: AzureActiveDirectory
dataTypes:
- SigninLogs
- connectorId: BehaviorAnalytics
dataTypes:
- BehaviorAnalytics
- connectorId: BehaviorAnalytics
dataTypes:
- IdentityInfo
queryFrequency: 1d
queryPeriod: 7d
triggerOperator: gt
triggerThreshold: 0
tactics:
- InitialAccess
relevantTechniques:
- T1078.004
tags:
- AADSecOpsGuide
query: |
let admin_users = (IdentityInfo
| summarize arg_max(TimeGenerated, *) by AccountUPN
| where AssignedRoles contains "admin"
| summarize by tolower(AccountUPN));
let admin_asn = (SigninLogs
| where TimeGenerated between (ago(7d)..ago(1d))
| where tolower(UserPrincipalName) in (admin_users)
| summarize by AutonomousSystemNumber);
let admin_locations = (SigninLogs
| where TimeGenerated between (ago(7d)..ago(1d))
| where tolower(UserPrincipalName) in (admin_users)
| summarize by Location);
let admin_devices = (SigninLogs
| where TimeGenerated between (ago(7d)..ago(1d))
| where tolower(UserPrincipalName) in (admin_users)
| extend deviceId = tostring(DeviceDetail.deviceId)
| where isnotempty(deviceId)
| summarize by deviceId);
SigninLogs
| where TimeGenerated > ago(1d)
| where ResultType == 0
| where tolower(UserPrincipalName) in (admin_users)
| extend deviceId = tostring(DeviceDetail.deviceId)
| where AutonomousSystemNumber !in (admin_asn) and deviceId !in (admin_devices) and Location !in (admin_locations)
entityMappings:
- entityType: Account
fieldMappings:
- identifier: FullName
columnName: UserPrincipalName
version: 1.0.2
kind: Scheduled
metadata:
source:
kind: Community
author:
name: Pete Bryan
support:
tier: Community
categories:
domains: [ "Security - Others", "Identity" ]
Stages and Predicates
Let binding: admin_users
let admin_users = (IdentityInfo
| summarize arg_max(TimeGenerated, *) by AccountUPN
| where AssignedRoles contains "admin"
| summarize by tolower(AccountUPN));
Let binding: admin_asn
let admin_asn = (SigninLogs
| where TimeGenerated between (ago(7d)..ago(1d))
| where tolower(UserPrincipalName) in (admin_users)
| summarize by AutonomousSystemNumber);
Derived from admin_users.
Let binding: admin_locations
let admin_locations = (SigninLogs
| where TimeGenerated between (ago(7d)..ago(1d))
| where tolower(UserPrincipalName) in (admin_users)
| summarize by Location);
Derived from admin_users.
Let binding: admin_devices
let admin_devices = (SigninLogs
| where TimeGenerated between (ago(7d)..ago(1d))
| where tolower(UserPrincipalName) in (admin_users)
| extend deviceId = tostring(DeviceDetail.deviceId)
| where isnotempty(deviceId)
| summarize by deviceId);
Derived from admin_users.
Stage 1: source
SigninLogs
Stage 2: where
| where TimeGenerated > ago(1d)
Stage 3: where
| where ResultType == 0
Stage 4: where
| where tolower(UserPrincipalName) in (admin_users)
References admin_users (defined above).
Stage 5: extend
| extend deviceId = tostring(DeviceDetail.deviceId)
Stage 6: where
| where AutonomousSystemNumber !in (admin_asn) and deviceId !in (admin_devices) and Location !in (admin_locations)
References admin_asn, admin_devices, admin_locations (defined above).
Exclusions
Top-level NOT(...) conjuncts: predicates this rule actively suppresses.
| Field | Kind | Excluded values |
|---|---|---|
AutonomousSystemNumber | eq | admin_asn |
Location | eq | admin_locations |
deviceId | eq | admin_devices |
Indicators
Each row is a field, operator, and value that the rule matches. The corpus column counts how many other rules in the catalog look for the same combination: high numbers point to widely-used, community-vetted indicators. Blank or 1 shows that the indicator is specific to this rule.
| Field | Kind | Values |
|---|---|---|
ResultType | eq |
|
UserPrincipalName | in |
|
Output fields
Fields the rule emits when it matches. Chronicle authors list these in the outcome block; they appear on the detection and $risk_score drives alerting. Sentinel / Defender XDR rules build them up through project / summarize / extend stages. Sentinel maps these into alert fields via entityMappings and customDetails; Defender XDR custom detections surface them as alert fields directly.
| Field | Source |
|---|---|
deviceId | extend |