Identifying Suspicious Successful Sign-Ins In Entra ID With Sentinel & Defender XDR

Password-based attacks remain one of the most effective ways for attackers to gain access to cloud environments. Despite widespread MFA adoption and improved identity protections, brute force and password spraying campaigns continue to succeed. This is especially true when attackers abuse less monitored authentication paths such as legacy protocols, SMTP, or non-interactive sign-ins.

For security teams, the challenge is no longer limited to detecting failed login attempts. The real risk appears when attackers eventually succeed, often after multiple failures, account lockouts, or activity originating from suspicious infrastructure. A correct password used under the wrong conditions can be the difference between a contained incident and a full account takeover.

This blog focuses on identifying potential successful brute force activity by combining Entra ID telemetry, historical baselines, and behavioral indicators. The objective is to surface high-risk authentication events that warrant immediate analyst attention, even when the sign-in itself appears legitimate.

Technical Details

Threat Overview

From an identity security perspective, brute force attacks have evolved beyond noisy and obvious failure patterns. Modern attackers operate patiently, rotate infrastructure, abuse legacy authentication flows, and attempt to blend into normal sign-in behavior to avoid detection.

Microsoft Entra ID provides rich authentication telemetry, but attackers often exploit monitoring gaps. Non-interactive sign-ins, SMTP authentication, and protocol-based access can bypass modern client protections. In many investigations, defenders only see suspicious behavior after access has already been obtained.

The highest-risk scenarios typically include:

  • A password being entered correctly
  • The sign-in originating from an unfamiliar or malicious IP address
  • An account that was recently locked due to repeated failures

These conditions strongly indicate a brute force campaign that has moved from attempted access to potential compromise.

Detection Logic Explained

Intent

The detection logic is designed to:

  • Identify authentication attempts where a correct password is used under suspicious conditions
  • Detect early indicators of successful brute force activity before attackers exploit access
  • Reduce reliance on alerts driven solely by failed sign-ins

Signal Selection

The detection leverages Entra ID sign-in telemetry from both interactive and non-interactive logs. It focuses on authentication events associated with risk indicators such as malicious IP classifications, account lockouts, and legacy authentication protocols. Recent activity is evaluated in the context of historical behavior.

Allow-List and Baseline Design

A historical baseline of IP addresses that successfully authenticated over the past 14 days is established. When a sign-in originates from an IP address not observed during that period, it is treated as higher risk if additional suspicious indicators are present.

This approach allows the detection to adapt naturally to normal user behavior while still highlighting meaningful anomalies.

Behavioral Rationale

Instead of alerting on every authentication failure, this logic looks for signs of success occurring in the wrong context, including:

  • Correct passwords originating from malicious or unfamiliar infrastructure
  • Successful authentication attempts against accounts already under attack or locked
  • SMTP or legacy protocol access following repeated authentication failures

In practice, this behavior-focused approach produces higher-quality signals and improves analyst confidence during triage.

KQL Query Used

The query analyzes recent authentication activity and identifies several high-risk scenarios:

  • Correct password usage from IPs flagged as malicious.
  • Successful authentication attempts against locked accounts.
  • Possible successful brute force attempts using SMTP or legacy authentication flows.
  • All results are filtered to exclude IP addresses previously observed in successful sign-ins.

The output is a consolidated view of potentially compromised authentication events that warrant immediate investigation.

let PreviouslyUsedIP = SigninLogs 
    | union AADNonInteractiveUserSignInLogs 
    | where TimeGenerated between (ago(14d) .. ago(1h)) 
    | where ResultType == 0 
    | distinct IPAddress; 

let MaliciousIPSignin = SigninLogs 
    | union AADNonInteractiveUserSignInLogs 
    | where TimeGenerated > ago(1h) // Rule Frequency 
    | where ResultType == 50053 
    | where ResultDescription contains "malicious activity" 
    | extend PasswordStatus = tostring(parse_json(AuthenticationDetails)[0].authenticationStepResultDetail)  
    | extend PasswordEnteredCorrectly = tostring(parse_json(AuthenticationDetails)[0].succeeded) 
    | where PasswordStatus == "Correct password" or PasswordEnteredCorrectly contains "true" 
    | extend Case = "Malicious IP Address" 
    | project 
        Case, 
        PasswordStatus, 
        PasswordEnteredCorrectly, 
        TimeGenerated, 
        UserPrincipalName, 
        IPAddress, 
        Location, 
        AppDisplayName, 
        ResultType, 
        ResultDescription, 
        Status_dynamic, 
        Status_string, 
        AuthenticationDetails, 
        RiskEventTypes, 
        RiskEventTypes_V2, 
        ClientAppUsed, 
        AuthenticationProtocol, 
        UserAgent, 
        DeviceDetail_dynamic, 
        DeviceDetail_string 
    | join kind=leftanti PreviouslyUsedIP on IPAddress; 

let CorrectPasswordLockedAccount = SigninLogs 
    | union AADNonInteractiveUserSignInLogs 
    | where TimeGenerated > ago(1h) // Rule Frequency 
    | where ResultType == 50053 
    | where ResultDescription contains "Account is locked" 
    | extend PasswordStatus = tostring(parse_json(AuthenticationDetails)[0].authenticationStepResultDetail)  
    | extend PasswordEnteredCorrectly = tostring(parse_json(AuthenticationDetails)[0].succeeded) 
    | where PasswordStatus == "Correct password" or PasswordEnteredCorrectly contains "true" 
    | extend Case = "Successful Password on a Locked Account" 
    | project 
        Case, 
        PasswordStatus, 
        PasswordEnteredCorrectly, 
        TimeGenerated, 
        UserPrincipalName, 
        IPAddress, 
        Location, 
        AppDisplayName, 
        ResultType, 
        ResultDescription, 
        Status_dynamic, 
        Status_string, 
        AuthenticationDetails, 
        RiskEventTypes, 
        RiskEventTypes_V2, 
        ClientAppUsed, 
        AuthenticationProtocol, 
        UserAgent, 
        DeviceDetail_dynamic, 
        DeviceDetail_string 
    | join kind=leftanti PreviouslyUsedIP on IPAddress; 

let SMTPBruteForceUsers = SigninLogs 
    | union AADNonInteractiveUserSignInLogs 
    | where TimeGenerated > ago(1h) // Rule Frequency 
    | where ResultType in (50053, 50126) 
    | where ClientAppUsed == "Authenticated SMTP" 
        or AuthenticationProtocol == "ropc" 
        or UserAgent == "BAV2ROPC"  
    | summarize FailureCount = count() by UserPrincipalName 
    | where FailureCount > 2; // Change value to tune 

let PossibleSuccessSMTPBruteForce = SigninLogs 
    | union AADNonInteractiveUserSignInLogs 
    | where TimeGenerated > ago(1h) // Rule Frequency 
    | join kind=inner SMTPBruteForceUsers on UserPrincipalName 
    | extend PasswordStatus = tostring(parse_json(AuthenticationDetails)[0].authenticationStepResultDetail)  
    | extend PasswordEnteredCorrectly = tostring(parse_json(AuthenticationDetails)[0].succeeded) 
    | where (PasswordStatus == "Correct password" or PasswordEnteredCorrectly contains "true") 
        or (ResultType notin (50126, 50053)) 
    | where ClientAppUsed == "Authenticated SMTP" 
        or AuthenticationProtocol == "ropc" 
        or UserAgent == "BAV2ROPC" 
    | extend Case = "Possible Successful SMTP Brute Force" 
    | project 
        Case, 
        TimeGenerated, 
        UserPrincipalName, 
        IPAddress, 
        Location, 
        AppDisplayName, 
        ResultType, 
        ResultDescription, 
        Status_dynamic, 
        Status_string, 
        AuthenticationDetails, 
        RiskEventTypes, 
        RiskEventTypes_V2, 
        ClientAppUsed, 
        AuthenticationProtocol, 
        UserAgent, 
        DeviceDetail_dynamic, 
        DeviceDetail_string 
    | join kind=leftanti PreviouslyUsedIP on IPAddress; 

PossibleSuccessSMTPBruteForce 
| union MaliciousIPSignin 
| union CorrectPasswordLockedAccount 
| extend DeviceOS = tostring(parse_json(DeviceDetail_dynamic).operatingSystem) 

Expected Results

When this detection triggers, analysts can expect to see:

  • Authentication events where a correct password was used under suspicious circumstances.
  • Sign-ins originating from IP addresses the organization has never seen before.
  • Indicators of brute force activity that may have transitioned into successful access.
  • Context such as user identity, application accessed, location, and authentication method.

These signals represent high-confidence identity risk, not routine login noise.

How the Detection Logic Works

The detection uses a simple but effective model:

  1. Establish what “normal” successful authentication looks like by reviewing recent historical sign-ins.
  2. Focus on the most recent authentication activity.
  3. Highlight events where success occurs alongside warning signs, malicious IPs, locked accounts, or brute force patterns.
  4. Exclude known and previously trusted infrastructure to reduce false positives.

This approach prioritizes early visibility into identity compromise while maintaining manageable alert volume.

Limitations:

The detection cannot prove intent on its own. A successful login from a new IP may occasionally be legitimate. Analyst validation and user verification remain essential steps before remediation.

MITRE ATT&CK Mapping

This detection aligns with the following techniques:

  • T1110 – Brute Force
    Attackers attempt repeated authentication attempts until valid credentials are discovered.
  • T1078 – Valid Accounts
    Stolen or brute-forced credentials are used to access cloud services.
  • T1556 – Modify Authentication Process (related behaviors)
    Abuse of legacy or less-secured authentication flows to bypass modern controls.

Prevention

  • Enforce phishing-resistant MFA across all users.
  • Disable legacy authentication protocols where possible.
  • Restrict SMTP authentication to approved service accounts only.
  • Monitor and review risky sign-in events regularly.
  • Apply Conditional Access policies based on risk and location.

Detection

This detection can be further strengthened by:

  • Correlating sign-in activity with Defender XDR alerts.
  • Linking identity events to endpoint behavior following authentication.
  • Monitoring mailbox rules, token usage, and lateral movement indicators.
  • Enriching IP addresses with threat intelligence sources.
  • Using ASIM to normalize identity telemetry for broader correlation.

Remediation

When a potential successful brute force event is detected:

  1. Confirm whether the authentication was expected.
  2. Reset credentials and revoke sessions if suspicious.
  3. Investigate post-authentication activity.
  4. Block malicious IPs and tighten Conditional Access.
  5. Educate the user if password hygiene or reuse is suspected.

Trends & Impact

Attackers continue to focus on identities because credentials remain the fastest path to access. As email and endpoint defenses improve, identity attacks increasingly exploit protocol gaps and behavioral blind spots.

Detecting when brute force attempts succeed allows security teams to intervene before attackers establish persistence, exfiltrate data, or escalate privileges.

Impacted Technologies

  • Microsoft Entra ID (Azure AD):
    Primary source of authentication telemetry and risk indicators.
  • Microsoft Sentinel:
    Enables correlation, baselining, and analytics-driven detection.
  • Microsoft Defender XDR:
    Enriches identity events with endpoint and post-compromise signals.
Example Case:

Brute Force via SMTP Leading to Account Takeover

In a real-world incident, an attacker launched a brute force campaign against multiple users using SMTP authentication. After repeated failures, one account successfully authenticated from a previously unseen IP address.

Because the access relied on legacy authentication, MFA was bypassed. Within minutes, the attacker created inbox rules, accessed cloud files, and attempted internal phishing.

The earliest warning signal was a successful authentication under suspicious conditions, exactly the type of activity this detection is designed to surface.

Why This Is Important

Successful brute force attacks rarely draw immediate attention. By the time traditional alerts fire, damage is often already underway.

This detection shifts focus away from noisy failures and toward meaningful success signals. It improves visibility, reduces alert fatigue, and enables faster response when identity is abused.

How Wizard Cyber Can Help

Wizard Cyber specializes in identity-focused detection engineering across Microsoft cloud environments. We help organizations move beyond basic alerts by designing high-confidence detections that focus on attacker behavior, not just individual events.

Our capabilities include:

  • Custom Sentinel analytics for identity threats.
  • Managed detection using Defender XDR telemetry.
  • Behavioral baselining for authentication activity.
  • Proactive threat hunting and CTEM alignment.
  • Incident response support for identity-driven attacks.

By focusing on signal quality and early detection, we help organizations stop identity attacks before they become breaches.

CYBERSECURITY READINESS

Strengthen Your Cyber Defences Today

As cyber threats grow more complex, proactive detection is no longer optional.

With Wizard Cyber’s Microsoft expertise, organizations can transform their security posture and gain real-time visibility across all endpoints.

Start your journey to smarter, faster cybersecurity today.

EXPLORE MORE

Related Blogs & Insights

Discover blogs that deepen your knowledge and accelerate your security strategy.

ABOUT THE AUTHOR
Heider Albadawi
Senior SOC Analyst

Heider leads Detection Engineering, specialising in Microsoft Sentinel analytics, KQL development, detection engineering, and security architecture. His expertise spans SIEM optimisation, analytics rule development, and Microsoft security technologies, supported by SC-100 (Cybersecurity Architect), SC-400 (Information Protection Administrator), SC-200, SC-300, and AZ-500 certifications

 

Certifications: SC-200, AZ-500, SC-300, SC-100, SC-400

Detection Engineering Team

WIZARD CYBER
Headquarters
Providing enterprises with bespoke & powerful managed solutions to protect against all forms of cybercrime
OUR LOCATIONS
Where to find us?
world map
GET IN TOUCH
Latest Updates
Stay up to date with the latest news from Wizard Cyber and the cybersecurity industry
https://wizardcyber.com/wp-content/uploads/2026/04/ISO-QSL-Cert-ISO-27001-scaled.png
https://wizardcyber.com/wp-content/uploads/2026/04/ISO-QSL-Cert-ISO-9001-scaled.png
WIZARD CYBER
Headquarters
Providing enterprises with bespoke & powerful managed solutions to protect against all forms of cybercrime
OUR LOCATIONS
Where to find us?
world map
GET IN TOUCH
Latest Updates
Stay up to date with the latest news from Wizard Cyber and the cybersecurity industry

Copyright by Wizard Cyber. All rights reserved.

Copyright by Wizard Cyber. All rights reserved.

Contact Us
×
Contact Us
Need Cybersecurity Guidance? Get in touch with us!

Our experts are ready to help with your cybersecurity questions—book a conversation with us by clicking the button.

Book a Meeting
Funded Workshops
×
Funded Workshops
Explore Our Funded Microsoft Security Workshops

Click to learn more about each Microsoft-supported engagement

Book a Consultation