What's the difference between a brute force attack and password spraying in Azure AD logs?

Brute force targets one account with many password attempts — visible as many failure events against the same userPrincipalName. Password spraying targets many accounts with a small number of common passwords — the same source IP cycling through a large list of userPrincipalNames, each with only one or two attempts. Spraying is specifically designed to stay under per-account lockout thresholds.

Does Microsoft Entra ID's own risk detection make LogTriage redundant?

They're complementary. Entra ID's riskLevelAggregated and sign-in risk signals are incorporated directly into LogTriage's risk assessment — if Microsoft already suspected something and it wasn't acted on, that gap is visible in the report. LogTriage adds external threat intelligence (AbuseIPDB, OTX, GreyNoise, ThreatFox) that Entra doesn't include, and produces a structured incident report rather than just flagged sign-in events.

Can I detect attacks using legacy authentication protocols from sign-in logs?

Yes. The clientAppUsed field in Azure AD sign-in logs identifies the authentication protocol. Legacy protocols like IMAP, POP3, and older Exchange ActiveSync clients appear in this field and can't support modern Conditional Access MFA requirements — making them a common bypass path. LogTriage flags legacy protocol usage as a distinct risk factor.

Which export format does LogTriage expect for Azure AD sign-in logs?

Both formats work: the Graph API export ({"value": [...]}) and the bare array format from the Entra portal export. LogTriage auto-detects both automatically.

Detecting Credential Stuffing / Brute Force in Azure AD Sign-In Logs

Why this matters

Azure AD / Entra ID is the front door to almost everything in a modern Microsoft 365 environment — mail, files, Teams, and usually a dozen federated SaaS apps besides. A successful brute-force or credential-stuffing hit against it isn’t “one account compromised,” it’s “one identity that can now reach everything that identity was trusted with.”

Repeated status.errorCode values for invalid credentials against the same userPrincipalName, especially from a single IP or a small rotating pool
A burst of failures across many different userPrincipalName values from the same source — this is password spraying, the credential-stuffing variant that targets breadth over depth
A riskLevelAggregated of medium or high that wasn’t acted on before a later successful sign-in
Sign-in attempts using userAgent strings associated with known authentication-attack tooling rather than real browsers
IP addresses or ASNs already flagged by external threat intelligence as credential-stuffing infrastructure

How LogTriage detects this

LogTriage enriches every sign-in’s source IP against ASN reputation, AbuseIPDB, OTX, GreyNoise, and ThreatFox in addition to the rule-based credential-stuffing pattern detector. For Azure AD specifically, Microsoft’s own riskLevelAggregated field is folded directly into the event’s risk factors — so when Entra ID already suspected something and nothing was done about it, that gap is visible in the report instead of buried in a console nobody checked that day.

Detection / evidence checklist

Determine whether this is targeted (one account, many passwords) or spray (many accounts, few passwords)
Check if any of the targeted accounts have weak or reused passwords — that’s your real exposure
Confirm smart lockout / Conditional Access sign-in risk policies are actually enabled, not just available
Force MFA enrollment for any account without it, prioritizing accounts with elevated privileges
Block the source IP/ASN range at the Conditional Access named-locations level if the activity is ongoing

Frequently Asked Questions

What's the difference between a brute force attack and password spraying in Azure AD logs?: Brute force targets one account with many password attempts — visible as many failure events against the same userPrincipalName. Password spraying targets many accounts with a small number of common passwords — the same source IP cycling through a large list of userPrincipalNames, each with only one or two attempts. Spraying is specifically designed to stay under per-account lockout thresholds.
Does Microsoft Entra ID's own risk detection make LogTriage redundant?: They're complementary. Entra ID's riskLevelAggregated and sign-in risk signals are incorporated directly into LogTriage's risk assessment — if Microsoft already suspected something and it wasn't acted on, that gap is visible in the report. LogTriage adds external threat intelligence (AbuseIPDB, OTX, GreyNoise, ThreatFox) that Entra doesn't include, and produces a structured incident report rather than just flagged sign-in events.
Can I detect attacks using legacy authentication protocols from sign-in logs?: Yes. The clientAppUsed field in Azure AD sign-in logs identifies the authentication protocol. Legacy protocols like IMAP, POP3, and older Exchange ActiveSync clients appear in this field and can't support modern Conditional Access MFA requirements — making them a common bypass path. LogTriage flags legacy protocol usage as a distinct risk factor.
Which export format does LogTriage expect for Azure AD sign-in logs?: Both formats work: the Graph API export ({"value": [...]}) and the bare array format from the Entra portal export. LogTriage auto-detects both automatically.

See this detection run on a real report

Try the live demo with a pre-loaded malicious log set — no signup required — or upload your own log file and get a full AI-reviewed threat report in minutes.

Try Live Demo → Analyze Your Own Logs