Dormant privileged identities with no recent sign-ins

Hunt Hypothesis

This hunt detects adversaries leveraging compromised dormant privileged identities (T1078.004) that have retained elevated permissions despite lacking recent authentication activity for over 90 days. Proactive hunting is essential to identify and remediate these “sleeper” accounts before attackers can exploit their persistent access rights to establish a foothold or escalate privileges within the Azure Sentinel environment.

KQL Query

let lookback = 90d;
IdentityInfo
| summarize arg_max(Timestamp, *) by AccountObjectId
| where IsAccountEnabled == true
| where isnotempty(AssignedRoles) or isnotempty(PrivilegedEntraPimRoles)
| join kind=leftanti (
    SigninLogs
    | where TimeGenerated > ago(lookback)
    | where ResultType == "0"
    | project AccountObjectId = UserId
) on AccountObjectId
| extend
    AccountName = tostring(split(AccountUpn, "@")[0]),
    AccountUPNSuffix = tostring(split(AccountUpn, "@")[1])
| project
    AccountObjectId, AccountUpn, AccountName, AccountUPNSuffix, AccountDisplayName,
    BlastRadius, AssignedRoles, PrivilegedEntraPimRoles,
    Department, JobTitle
| sort by BlastRadius desc

Analytic Rule Definition

id: 0a70fd03-6f58-4df3-ab39-f9d123d538cd
name: Dormant privileged identities with no recent sign-ins
description: |
  Finds enabled identities with assigned directory or Entra PIM roles that
  have no successful sign-in in the last 90 days. These dormant privileged
  accounts retain access and can become takeover targets if credentials are
  obtained or reused.
description-detailed: |
  Leverages the Microsoft 365 Defender IdentityInfo table, which exposes
  assigned and PIM-eligible roles, BlastRadius and account enablement
  state, correlated against SigninLogs to surface identities with zero
  successful logons within the lookback. Review whether each account is
  still required, rotate credentials for any that remain, and consider
  removing unneeded role assignments or triggering just-in-time access.
  References:
  - https://learn.microsoft.com/entra/identity/role-based-access-control/groups-concept
  - https://attack.mitre.org/techniques/T1078/004/
requiredDataConnectors:
  - connectorId: MicrosoftThreatProtection
    dataTypes:
      - IdentityInfo
  - connectorId: AzureActiveDirectory
    dataTypes:
      - SigninLogs
tactics:
  - Persistence
  - PrivilegeEscalation
relevantTechniques:
  - T1078.004
query: |
  let lookback = 90d;
  IdentityInfo
  | summarize arg_max(Timestamp, *) by AccountObjectId
  | where IsAccountEnabled == true
  | where isnotempty(AssignedRoles) or isnotempty(PrivilegedEntraPimRoles)
  | join kind=leftanti (
      SigninLogs
      | where TimeGenerated > ago(lookback)
      | where ResultType == "0"
      | project AccountObjectId = UserId
  ) on AccountObjectId
  | extend
      AccountName = tostring(split(AccountUpn, "@")[0]),
      AccountUPNSuffix = tostring(split(AccountUpn, "@")[1])
  | project
      AccountObjectId, AccountUpn, AccountName, AccountUPNSuffix, AccountDisplayName,
      BlastRadius, AssignedRoles, PrivilegedEntraPimRoles,
      Department, JobTitle
  | sort by BlastRadius desc
entityMappings:
  - entityType: Account
    fieldMappings:
      - identifier: FullName
        columnName: AccountUpn
      - identifier: Name
        columnName: AccountName
      - identifier: UPNSuffix
        columnName: AccountUPNSuffix
      - identifier: AadUserId
        columnName: AccountObjectId
version: 1.0.3
metadata:
  source:
    kind: Community
  author:
    name: d4rk-pri0r
  support:
    tier: Community
  categories:
    domains: [ "Security - Threat Protection", "Identity" ]

Required Data Sources

MITRE ATT&CK Context

• Tactic: Persistence
• Tactic: PrivilegeEscalation
• Technique: T1078.004 — T1078.004

References

• [Source Query](https://github.com/Azure/Azure-Sentinel/blob/main/Hunting Queries/SigninLogs/DormantPrivilegedIdentities.yaml)

False Positive Guidance

Here are 5 specific false positive scenarios for the “Dormant privileged identities with no recent sign-ins” rule, along with suggested filters or exclusions:

• Scheduled Service Accounts for Automated Backups

  • Scenario: A dedicated service account (e.g., svc-backup-azure) assigned a high-level role like Backup Administrator in Azure Entra ID is used exclusively by an automated backup job running via Azure Automation or Veeam. The job executes daily but authenticates via Managed Identity or certificate-based authentication rather than interactive user sign-ins, causing the rule to flag it as dormant despite active usage.
  • Filter/Exclusion: Exclude accounts where AccountType equals “Service” and AuthenticationMethod includes “Certificate” or “ManagedIdentity”. Additionally, filter out any account with a naming convention prefix of svc- if the last successful interactive sign-in is older than 90 days but the associated automation runbook has executed successfully within that window.

• Break-Glass Emergency Accounts

  • Scenario: “Break-glass” or emergency administrator accounts (e.g., adm-emergency-01) are provisioned with Global Administrator roles in Microsoft Entra ID specifically for disaster recovery scenarios. These accounts are intentionally kept dormant to prevent them from being targeted by routine phishing campaigns and are only activated during actual incidents, which may occur less frequently than every 90 days.
  • Filter/Exclusion: Create a tag-based exclusion where accounts tagged with Purpose:BreakGlass or Category:Emergency are ignored by this rule regardless of their last sign-in date. Alternatively, extend the detection window for these specific tags from 90 to 365 days.

• Third-Party Integration Accounts

  • Scenario: A privileged identity (e.g., app-integration-sap) holds a role