Detecting Brute Force Attacks Followed by Successful Logon in Microsoft Sentinel

Correlate failed sign-ins followed by a successful authentication within a short time window to immediately flag compromised user accounts.

Dikshant Lather
2 min read ·
Detecting Brute Force Attacks Followed by Successful Logon in Microsoft Sentinel

Detecting Brute Force Attacks Followed by Successful Logon in Microsoft Sentinel

High-volume password guessing generates dozens of failed sign-in events. While individual failed logins are commonplace, a cluster of repeated failures from a specific IP followed by an immediate successful login indicates that an adversary successfully guessed or cracked the password.

Here is an optimized correlation query using the SigninLogs table.


Correlation KQL Query

// Flag When 5+ Failed Logins are Followed by a Successful Login within 20 Minutes
let lookback = 4h;
let correlationWindow = 20m;
let failureThreshold = 5;
let failedLogins = 
    SigninLogs
    | where TimeGenerated >= ago(lookback)
    | where ResultType != 0
    | summarize 
        FailureCount = count(),
        FirstFailure = min(TimeGenerated),
        LastFailure = max(TimeGenerated)
        by UserPrincipalName, IPAddress, Location
    | where FailureCount >= failureThreshold;
let successfulLogins = 
    SigninLogs
    | where TimeGenerated >= ago(lookback)
    | where ResultType == 0
    | project SuccessTime = TimeGenerated, UserPrincipalName, IPAddress, AppDisplayName, UserAgent;
failedLogins
| join kind=inner (successfulLogins) on UserPrincipalName, IPAddress
| where SuccessTime between (LastFailure .. (LastFailure + correlationWindow))
| extend TimeToCompromiseMinutes = datetime_diff('minute', SuccessTime, FirstFailure)
| project UserPrincipalName, IPAddress, Location, FailureCount, FirstFailure, LastFailure, SuccessTime, TimeToCompromiseMinutes, AppDisplayName, UserAgent
| order by SuccessTime desc

Operational Advantages of This Rule

  • High Signal-to-Noise Ratio: Raw failed logins produce unmanageable alert volumes. Requiring a subsequent success isolates actionable compromises.
  • IP-to-IP Binding: By joining on both UserPrincipalName and IPAddress, we ensure that the success originated from the very entity conducting the password guessing.

Triage Actions

  1. Verify if the user remembers mistyping their password or if they were traveling.
  2. If confirmed malicious, perform immediate password reset and revoke all active refresh tokens.
  3. Review subsequent activity logs (AzureActivity, OfficeActivity) for the compromised account.

MITRE ATT&CK Mapping

  • Tactic: Credential Access (TA0006), Initial Access (TA0001)
  • Technique: Brute Force: Password Guessing (T1110.001)
Dikshant Lather
Written by

Dikshant Lather

Cyber Security & AI Architect

Responses (0)

Join the technical conversation or share implementation thoughts.

What are your thoughts?

Sign in to join the technical discussion or share feedback.

There are currently no responses for this story. Be the first to respond.