Break-glass account sign-in detected

Hunt Hypothesis

This hypothesis detects adversaries attempting to compromise or impersonate privileged break-glass accounts by initiating unscheduled sign-ins that deviate from their expected dormant state. Proactive hunting for this behavior is critical in Azure Sentinel to ensure these high-privilege emergency access points remain secure and are not exploited as a foothold for lateral movement or persistence during an incident response scenario.

KQL Query

let starttime = todatetime('{{StartTimeISO}}');
let endtime = todatetime('{{EndTimeISO}}');
let BreakGlassAccounts = (
    _GetWatchlist('BreakGlassAccounts')
    | project AccountUPN = tolower(tostring(SearchKey))
);
SigninLogs
| where TimeGenerated between (starttime .. endtime)
| where tolower(UserPrincipalName) in (BreakGlassAccounts)
| extend City = tostring(LocationDetails.city)
| extend Country = tostring(LocationDetails.countryOrRegion)
| extend AccountName      = tostring(split(UserPrincipalName, "@")[0])
| extend AccountUPNSuffix = tostring(split(UserPrincipalName, "@")[1])
| project
    TimeGenerated,
    UserPrincipalName,
    AccountName,
    AccountUPNSuffix,
    UserId,
    IPAddress,
    City,
    Country,
    AppDisplayName,
    ResourceDisplayName,
    ResultType,
    ResultDescription,
    ConditionalAccessStatus,
    AuthenticationRequirement,
    CorrelationId
| sort by TimeGenerated desc

Analytic Rule Definition

id: 1685c69b-d03b-4e71-8171-879d6fefad2d
name: Break-glass account sign-in detected
description: |
  Identifies any sign-in from an account designated as an emergency break-glass account. These
  accounts exist purely as a last-resort fallback and should show no sign-in activity outside a
  scheduled quarterly test or a genuine tenant-wide lockout.
description-detailed: |
  Break-glass (emergency access) accounts are cloud-only, highly privileged accounts that
  organizations deliberately exclude from Conditional Access policies and day-to-day MFA
  enforcement so they remain usable if every other authentication path fails. Because of that
  exclusion, a successful sign-in to one of these accounts bypasses the same controls that
  protect every other identity in the tenant, and Microsoft's own guidance is that sign-in and
  credential-change activity on them should be monitored continuously.
  This query depends on a watchlist named `BreakGlassAccounts` whose `SearchKey` column holds
  the user principal names of the tenant's designated emergency access accounts. Populate it
  once from the tenant's documented break-glass account inventory; there is no reliable way to
  infer these accounts from sign-in data alone.
  Any match here should be validated against the change calendar for a planned access-recovery
  test. Sign-ins that fall outside a documented test window, that originate from an unexpected
  IP address or country, or that are closely followed by a credential change or a privilege
  change on the same account (see the two companion hunting queries in this pack, covering
  credential and security-info modifications and role or group membership changes) warrant
  immediate escalation.
  References:
  - https://learn.microsoft.com/entra/identity/role-based-access-control/security-emergency-access
  - https://attack.mitre.org/techniques/T1078/004/
requiredDataConnectors:
  - connectorId: AzureActiveDirectory
    dataTypes:
      - SigninLogs
tactics:
  - InitialAccess
  - Persistence
relevantTechniques:
  - T1078.004
query: |
  let starttime = todatetime('{{StartTimeISO}}');
  let endtime = todatetime('{{EndTimeISO}}');
  let BreakGlassAccounts = (
      _GetWatchlist('BreakGlassAccounts')
      | project AccountUPN = tolower(tostring(SearchKey))
  );
  SigninLogs
  | where TimeGenerated between (starttime .. endtime)
  | where tolower(UserPrincipalName) in (BreakGlassAccounts)
  | extend City = tostring(LocationDetails.city)
  | extend Country = tostring(LocationDetails.countryOrRegion)
  | extend AccountName      = tostring(split(UserPrincipalName, "@")[0])
  | extend AccountUPNSuffix = tostring(split(UserPrincipalName, "@")[1])
  | project
      TimeGenerated,
      UserPrincipalName,
      AccountName,
      AccountUPNSuffix,
      UserId,
      IPAddress,
      City,
      Country,
      AppDisplayName,
      ResourceDisplayName,
      ResultType,
      ResultDescription,
      ConditionalAccessStatus,
      AuthenticationRequirement,

Required Data Sources

MITRE ATT&CK Context

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

References

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

False Positive Guidance

Here are 5 specific false positive scenarios for the “Break-glass account sign-in detected” rule, including suggested filters and exclusions:

• Scheduled Automated Health Checks

  • Scenario: The enterprise’s IT Operations team utilizes a nightly maintenance window where an automated script (e.g., running via Azure Automation Account or Ansible Tower) logs into the break-glass account to verify Active Directory replication status and license compliance. This triggers the rule despite being a planned, non-human event.
  • Filter/Exclusion: Exclude sign-ins originating from specific trusted IP ranges (e.g., the internal jump box subnet 10.20.45.0/24) or filter by user agent strings containing “Automation” or “ServiceAccount”. Additionally, suppress alerts during the defined maintenance window (e.g., Sundays 02:00–04:00 UTC).

• Emergency Access for Critical Patch Deployment

  • Scenario: During a critical security patch rollout using Microsoft Endpoint Configuration Manager (MECM) or WSUS, the System Administrator team temporarily activates the break-glass account to push high-priority updates that require elevated privileges not available in standard admin accounts. This is a planned, time-bound operational task rather than an unexpected emergency.
  • Filter/Exclusion: Create a suppression rule based on a “Pre-Approved Change Request” ID. If the sign-in occurs within 1 hour of a ticket created in ServiceNow or Jira tagged with Change-ID: PATCH-CRITICAL, the alert should be auto-resolved as a false positive.

• Third-Party Backup Solution Authentication

  • Scenario: The organization’s backup solution (e.g., Veeam Backup & Replication or Rubrik) is configured to use the break-glass account credentials for its initial