Risky Sign-in with ElevateAccess

Hunt Hypothesis

Users who experience a risky sign-in event followed by an ElevateAccess action may indicate potential credential compromise or unauthorized elevation of privileges, as adversaries could exploit compromised credentials to gain higher access levels. SOC teams should proactively hunt for this behavior in Azure Sentinel to identify and mitigate potential lateral movement or privilege escalation attempts.

KQL Query

let riskySignInLookback = 3d;
let elevatedUsers =
( CloudAppEvents
| where Timestamp > ago(1d)
| where ApplicationId == 12260 // filter Azure Resource Manager events 
| where ActionType has "elevateAccess"
| project  elevatedOperationTimestamp = Timestamp, AccountObjectId);
let hasElevatedUsers = isnotempty(toscalar(elevatedUsers));
EntraIdSignInEvents
| where hasElevatedUsers
| where Timestamp > ago(riskySignInLookback)
| where ErrorCode == 0
| where RiskLevelDuringSignIn in (50, 100) //10 - low, 50 - medium, 100 - high)
| join elevatedUsers on AccountObjectId
| where elevatedOperationTimestamp > Timestamp
| project LoginTime = Timestamp, elevatedOperationTimestamp, AccountObjectId, AccountDisplayName, riskScore = RiskLevelDuringSignIn

Analytic Rule Definition

id: 158b565b-411b-4dec-81de-2d2bcaf0c34c
name: Risky Sign-in with ElevateAccess
description: |
  Looks for users who had a risky sign in (based on Entra ID Identity Protection risk score) and then performed and ElevateAccess action. ElevateAccess operations can be used by Global Admins to obtain permissions over Azure resources. 
requiredDataConnectors:
- connectorId: MicrosoftThreatProtection
  dataTypes:
  - CloudAppEvents
  - EntraIdSignInEvents
tactics:
- PrivilegeEscalation
query: |
  let riskySignInLookback = 3d;
  let elevatedUsers =
  ( CloudAppEvents
  | where Timestamp > ago(1d)
  | where ApplicationId == 12260 // filter Azure Resource Manager events 
  | where ActionType has "elevateAccess"
  | project  elevatedOperationTimestamp = Timestamp, AccountObjectId);
  let hasElevatedUsers = isnotempty(toscalar(elevatedUsers));
  EntraIdSignInEvents
  | where hasElevatedUsers
  | where Timestamp > ago(riskySignInLookback)
  | where ErrorCode == 0
  | where RiskLevelDuringSignIn in (50, 100) //10 - low, 50 - medium, 100 - high)
  | join elevatedUsers on AccountObjectId
  | where elevatedOperationTimestamp > Timestamp
  | project LoginTime = Timestamp, elevatedOperationTimestamp, AccountObjectId, AccountDisplayName, riskScore = RiskLevelDuringSignIn

Required Data Sources

MITRE ATT&CK Context

• Tactic: PrivilegeEscalation

References

• [Source Query](https://github.com/Azure/Azure-Sentinel/blob/main/Hunting Queries/Microsoft 365 Defender/Privilege escalation/riskySignInToElevateAccess.yaml)

False Positive Guidance

• Scenario: A Global Admin performs a scheduled maintenance task using PowerShell remoting to update a service account password.
  Filter/Exclusion: Exclude sign-ins where the user has the Global Admin role and the action is part of a known maintenance script or scheduled job (e.g., Update-ServiceAccountPassword.ps1).

• Scenario: A user with Privileged Role Administration (PRA) access uses ElevateAccess to temporarily elevate privileges to deploy a critical application update via Azure DevOps pipeline.
  Filter/Exclusion: Exclude actions initiated from Azure DevOps pipelines with known deployment scripts or tasks (e.g., Deploy-AppUpdate.ps1).

• Scenario: A System Administrator uses ElevateAccess to access a secure resource (e.g., Azure Key Vault) to retrieve a secret for a scheduled backup job.
  Filter/Exclusion: Exclude sign-ins where the user has System Administrator role and the action is related to backup jobs or secret retrieval (e.g., Retrieve-BackupSecret.ps1).

• Scenario: A Security Analyst uses ElevateAccess to investigate a potential security incident and access Microsoft Defender for Cloud logs.
  Filter/Exclusion: Exclude sign-ins where the user has Security Analyst role and the action is related to incident investigation or log analysis (e.g., Investigate-SecurityIncident.ps1).

• Scenario: A Service Principal (with ElevateAccess permissions) is used to run a PowerShell script that performs routine system health checks on a virtual machine.
  Filter/Exclusion: Exclude sign-ins where the user is a Service Principal and the action is associated with system health checks or **automated monitoring scripts