Sign-ins from IPs that attempt sign-ins to disabled accounts (Uses Authentication Normalization)

Hunt Hypothesis

Adversaries may be using compromised credentials from disabled accounts to pivot within the network by attempting sign-ins from IPs that successfully accessed other accounts. SOC teams should proactively hunt for this behavior to identify potential credential reuse and lateral movement tactics in their Azure Sentinel environment.

KQL Query

imAuthentication
| where EventResult =='Failure'
| where EventResultDetails == 'User disabled'
| summarize StartTime=min(EventStartTime), EndTime=max(EventEndTime), disabledAccountLoginAttempts = count()
      , disabledAccountsTargeted = dcount(TargetUsername), disabledAccountSet = make_set(TargetUsername)
      , applicationsTargeted = dcount(TargetAppName)
      , applicationSet = make_set(TargetAppName) 
      by SrcDvcIpAddr, Type
| order by disabledAccountLoginAttempts desc
| join kind=leftouter 
    (
    // Consider these IPs suspicious - and alert any related  successful sign-ins
    imAuthentication
    | where EventResult=='Success'
    | summarize successfulAccountSigninCount = dcount(TargetUsername), successfulAccountSigninSet = makeset(TargetUsername, 15) by SrcDvcIpAddr, Type
    // Assume IPs associated with sign-ins from 100+ distinct user accounts are safe
    | where successfulAccountSigninCount < 100
    )
    on SrcDvcIpAddr
| where isnotempty(successfulAccountSigninCount)
| project StartTime, EndTime, SrcDvcIpAddr, disabledAccountLoginAttempts, disabledAccountsTargeted, disabledAccountSet, applicationSet, 
successfulAccountSigninCount, successfulAccountSigninSet, Type
| order by disabledAccountLoginAttempts

Analytic Rule Definition

id: 95002681-4ecb-4da3-9ece-26d7e5feaa33
name: Sign-ins from IPs that attempt sign-ins to disabled accounts (Uses Authentication Normalization)
description: |
  'Identifies IPs with failed attempts to sign in to one or more disabled accounts signed in successfully to another account.
  To use this analytics rule, make sure you have deployed the [ASIM normalization parsers](https://aka.ms/ASimAuthentication)'
severity: Medium
requiredDataConnectors: []
queryFrequency: 1d
queryPeriod: 1d
triggerOperator: gt
triggerThreshold: 0
tactics:
  - InitialAccess
  - Persistence
relevantTechniques:
  - T1078
  - T1098
tags:
  - Id: 500c103a-0319-4d56-8e99-3cec8d860757
    version: 1.0.0
query: |
  imAuthentication
  | where EventResult =='Failure'
  | where EventResultDetails == 'User disabled'
  | summarize StartTime=min(EventStartTime), EndTime=max(EventEndTime), disabledAccountLoginAttempts = count()
        , disabledAccountsTargeted = dcount(TargetUsername), disabledAccountSet = make_set(TargetUsername)
        , applicationsTargeted = dcount(TargetAppName)
        , applicationSet = make_set(TargetAppName) 
        by SrcDvcIpAddr, Type
  | order by disabledAccountLoginAttempts desc
  | join kind=leftouter 
      (
      // Consider these IPs suspicious - and alert any related  successful sign-ins
      imAuthentication
      | where EventResult=='Success'
      | summarize successfulAccountSigninCount = dcount(TargetUsername), successfulAccountSigninSet = makeset(TargetUsername, 15) by SrcDvcIpAddr, Type
      // Assume IPs associated with sign-ins from 100+ distinct user accounts are safe
      | where successfulAccountSigninCount < 100
      )
      on SrcDvcIpAddr
  | where isnotempty(successfulAccountSigninCount)
  | project StartTime, EndTime, SrcDvcIpAddr, disabledAccountLoginAttempts, disabledAccountsTargeted, disabledAccountSet, applicationSet, 
  successfulAccountSigninCount, successfulAccountSigninSet, Type
  | order by disabledAccountLoginAttempts

entityMappings:
  - entityType: IP
    fieldMappings:
      - identifier: Address
        columnName: SrcDvcIpAddr
version: 1.0.3
kind: Scheduled
metadata:
  source:
    kind: Community

Required Data Sources

MITRE ATT&CK Context

• Tactic: InitialAccess
• Tactic: Persistence
• Tactic: Defense Evasion
• Tactic: Privilege Escalation
• Tactic: Initial Access
• Technique: T1078 — Valid Accounts

  Adversaries may obtain and abuse credentials of existing accounts as a means of gaining Initial Access, Persistence, Privilege Escalation, or Defense Evasion. Compromised credentials may be used to by

• Technique: T1098 — Account Manipulation

  Adversaries may manipulate accounts to maintain and/or elevate access to victim systems. Account manipulation may consist of any action that preserves or modifies adversary access to a compromised acc

Validation (Atomic Red Team)

• T1098 — Account Manipulation

References

• Source Query

False Positive Guidance

• Scenario: A system administrator uses a disabled account to perform a scheduled job or maintenance task, and the same IP address is used to sign in to a valid admin account.
  Filter/Exclusion: Exclude IP addresses associated with known admin accounts or use a filter like ip.src == <admin_ip> or user == "admin_account".

• Scenario: A user with a disabled account is part of a legacy system that is still referenced by a script or application, which occasionally attempts to authenticate using that account.
  Filter/Exclusion: Exclude accounts marked as “legacy” or “disabled” using a filter like account_status == "disabled" or account_type == "legacy".

• Scenario: A security tool or SIEM agent (e.g., Splunk, ELK) attempts to authenticate to a disabled account during a configuration check or health scan.
  Filter/Exclusion: Exclude IPs associated with security tools using a filter like ip.src == <security_tool_ip> or tool == "Splunk", or use a custom field like tool_type.

• Scenario: A user’s account was temporarily disabled during a password reset, and the same IP address is used to sign in to a different account.
  Filter/Exclusion: Exclude accounts that were recently disabled or use a filter like account_status == "disabled", or include a time-based exclusion for accounts disabled within the last 24 hours.

• Scenario: A third-party service (e.g., Azure DevOps, GitHub Actions) attempts to authenticate to a disabled account during a CI/CD pipeline run, but successfully authenticates to a valid service account using the same IP.
  Filter/Exclusion: Exclude IPs associated with CI/CD services using a filter like ip.src == <ci_cd_ip> or service == "GitHub Actions", or use a custom field like `ci_cd