Brute force attack against user credentials (Uses Authentication Normalization)

Hunt Hypothesis

Adversaries may be attempting to brute force user credentials by generating multiple authentication failures followed by a successful login, indicating a potential credential compromise. SOC teams should proactively hunt for this behavior in Azure Sentinel to identify and mitigate credential theft attempts before they lead to broader network compromise.

KQL Query

let failureCountThreshold = 10;
let successCountThreshold = 1;
// let authenticationWindow = 20m; // Implicit in the analytic rule query period 
imAuthentication
| where TargetUserType != "NonInteractive"
| summarize 
      StartTime = min(TimeGenerated), 
      EndTime = max(TimeGenerated), 
      IpAddresses = make_set (SrcDvcIpAddr, 100),
      ReportedBy = make_set (strcat (EventVendor, "/", EventProduct), 100),
      FailureCount = countif(EventResult=='Failure'),
      SuccessCount = countif(EventResult=='Success')
  by 
      TargetUserId, TargetUsername, TargetUserType 
| where FailureCount >= failureCountThreshold and SuccessCount >= successCountThreshold
| extend
      IpAddresses = strcat_array(IpAddresses, ", "), 
      ReportedBy = strcat_array(ReportedBy, ", ")
| extend
  Name = iif(
      TargetUsername contains "@"
          , tostring(split(TargetUsername, '@', 0)[0])
          , TargetUsername
      ),
  UPNSuffix = iif(
      TargetUsername contains "@"
      , tostring(split(TargetUsername, '@', 1)[0])
      , ""
  )

Analytic Rule Definition

id: a6c435a2-b1a0-466d-b730-9f8af69262e8
name: Brute force attack against user credentials (Uses Authentication Normalization)
description: |
  'Identifies evidence of brute force activity against a user based on multiple authentication failures and at least one successful authentication within a given time window.
  Note that the query does not enforce any sequence, and does not require the successful authentication to occur last.
  The default failure threshold is 10, success threshold is 1, and the default time window is 20 minutes.
  To use this analytics rule, make sure you have deployed the [ASIM normalization parsers](https://aka.ms/ASimAuthentication)'
severity: Medium
requiredDataConnectors: []
queryFrequency: 20m
queryPeriod: 20m
triggerOperator: gt
triggerThreshold: 0
tactics:
  - CredentialAccess
relevantTechniques:
  - T1110
tags:
  - Id: 28b42356-45af-40a6-a0b4-a554cdfd5d8a
    version: 1.0.0
  - Schema: ASIMAuthentication
    SchemaVersion: 0.1.0
query: |
  let failureCountThreshold = 10;
  let successCountThreshold = 1;
  // let authenticationWindow = 20m; // Implicit in the analytic rule query period 
  imAuthentication
  | where TargetUserType != "NonInteractive"
  | summarize 
        StartTime = min(TimeGenerated), 
        EndTime = max(TimeGenerated), 
        IpAddresses = make_set (SrcDvcIpAddr, 100),
        ReportedBy = make_set (strcat (EventVendor, "/", EventProduct), 100),
        FailureCount = countif(EventResult=='Failure'),
        SuccessCount = countif(EventResult=='Success')
    by 
        TargetUserId, TargetUsername, TargetUserType 
  | where FailureCount >= failureCountThreshold and SuccessCount >= successCountThreshold
  | extend
        IpAddresses = strcat_array(IpAddresses, ", "), 
        ReportedBy = strcat_array(ReportedBy, ", ")
  | extend
    Name = iif(
        TargetUsername contains "@"
            , tostring(split(TargetUsername, '@', 0)[0])
            , TargetUsername
        ),
    UPNSuffix = iif(
        TargetUsername contains "@"
        , tostring(split(TargetUsername, '@', 1)[0])
        , ""
    )

entityMappings:
  - entityType: Account
    fieldMappings:
      - identifier: FullName
        columnName: TargetUserName
      - identifier: Name
        columnName: Name
      - identifier: UPNSuffix
        columnName: UPNSuffix

customDetails:
  IpAddresses: IpAddresses
  ReportedBy: ReportedBy
version: 1.2.5
kind: Scheduled
metadata:
    source:
        kind: Community
    author:
        name: Ofer Shezaf
    support:
        tier: Community
    categories:
        domains: [ "Security - Others", "Identity" ]

Required Data Sources

MITRE ATT&CK Context

• Tactic: CredentialAccess
• Tactic: Credential Access
• Technique: T1110 — Brute Force

  Adversaries may use brute force techniques to gain access to accounts when passwords are unknown or when password hashes are obtained.(Citation: TrendMicro Pawn Storm Dec 2020) Without knowledge of th

References

• Source Query

False Positive Guidance

• Scenario: Scheduled System Maintenance or Backup Job
  Description: A legitimate scheduled job (e.g., rsync, cron, or PowerShell script) attempts to authenticate to a server to perform backups or maintenance.
  Filter/Exclusion: Exclude events where the source IP is known to be part of the internal network or where the username is a service account (e.g., backup_user, sysadmin).

• Scenario: User Testing or Password Reset Attempt
  Description: An admin or user is testing a password or attempting to reset their own password, leading to multiple failed attempts followed by a successful login.
  Filter/Exclusion: Exclude events where the username matches a known admin or support account (e.g., admin, [email protected]), or where the event occurred during a known password reset window.

• Scenario: Automated Configuration Management Tool (e.g., Ansible, Puppet)
  Description: A configuration management tool (e.g., Ansible) attempts to authenticate to multiple systems during a deployment, leading to multiple failed logins followed by a successful connection.
  Filter/Exclusion: Exclude events where the username is a service account (e.g., ansible, puppet) or where the source IP is associated with the configuration management server.

• Scenario: User Lockout Recovery Process
  Description: A user is locked out of their account and an admin or helpdesk attempts to reset the password, resulting in multiple failed attempts followed by a successful login.
  Filter/Exclusion: Exclude events where the username is associated with the helpdesk or admin team, or where the event occurred during a known lockout recovery window.

• Scenario: Internal Monitoring or Logging Tool Authentication
  Description: A monitoring tool (e.g., Prometheus, Zabbix, or Splunk) authenticates to