Why do failed sign-ins count here?

Because of what the failure codes mean. AADSTS50074 and AADSTS50076 are returned when the password was correct and Entra ID then required multifactor authentication, which a legacy protocol cannot complete. AADSTS53003 is returned when a Conditional Access policy blocked token issuance, and Conditional Access is evaluated after the first factor. So each of these failures tells you the attacker has the user's correct password. Wrong passwords produce AADSTS50126 instead, which this rule ignores.

Why is legacy authentication an MFA bypass?

Legacy protocols (basic authentication over IMAP, POP and SMTP, Exchange ActiveSync, and the catch-all 'Other clients') cannot present an MFA challenge. Where MFA is enforced for them, the sign-in fails with one of the codes above. Where it is not, for example a Conditional Access policy that only targets browsers and modern clients, the sign-in succeeds on the password alone; that is the success branch of this rule (errorCode 0).

Which fields does the rule use?

`clientAppUsed` and `status.errorCode` from the Microsoft Graph sign-in log schema. In Log Analytics (the SigninLogs table) the same values are in `ClientAppUsed` and `ResultType`, where ResultType is a string, so compare it with "50074" rather than a number.

What should I do when this fires?

Reset the user's password, because whoever signed in has it, and revoke the user's sessions. Then block legacy authentication with a Conditional Access policy (or Microsoft's security defaults), inventory anything that breaks and move it to modern authentication. A success over a legacy protocol also deserves a look at what the session accessed, usually the mailbox.

HIGH Azure AD Sign-In Logs MFA Bypass / Conditional Access Evasion LTR-0004 ✓ validated

Detect Legacy-Protocol Sign-Ins With a Correct Password in Entra ID Logs

Published June 23, 2026 · Updated October 20, 2026

MITRE ATT&CK: T1078.004

Sigma Rule

title: Entra ID Legacy-Protocol Sign-In With a Correct Password
id: 2f8c5d11-4a7e-4b90-9c33-7e1d6a2b4c04
status: experimental
description: >
  Detects a sign-in over a legacy protocol (Exchange ActiveSync, IMAP4, POP3,
  authenticated SMTP, MAPI over HTTP or "Other clients") where the password was
  accepted: the sign-in succeeded (errorCode 0), or it failed only because MFA
  was required (50074, 50076) or Conditional Access blocked token issuance
  (53003). Legacy protocols cannot complete MFA, so a success means MFA was not
  enforced for that path, and each failure code still proves the password works.
references:
  - https://learn.microsoft.com/en-us/entra/identity-platform/reference-error-codes
  - https://attack.mitre.org/techniques/T1078/004/
author: LogTriage
date: 2026/06/23
modified: 2026/10/20
logsource:
  product: azure
  service: signinlogs
detection:
  legacy_client:
    clientAppUsed:
      - 'Other clients'
      - 'Exchange ActiveSync'
      - 'IMAP4'
      - 'POP3'
      - 'Authenticated SMTP'
      - 'MAPI Over HTTP'
  password_accepted:
    status.errorCode:
      - 0
      - 50074
      - 50076
      - 53003
  condition: legacy_client and password_accepted
falsepositives:
  - Old mail clients or line-of-business apps still on basic authentication
  - Documented service accounts on legacy protocols
level: high
tags:
  - attack.initial_access
  - attack.t1078.004

What this rule detects

Legacy authentication is one of the most common ways attackers use a stolen Microsoft 365 or Entra ID password. This rule fires on a sign-in over a legacy protocol where the password was accepted:

A success (errorCode 0): MFA was not enforced for that protocol, so the password alone signed the attacker in.
AADSTS50074 or AADSTS50076: the password was correct and Entra ID required MFA, which the legacy client could not complete.
AADSTS53003: a Conditional Access policy blocked token issuance after the first factor.

Either way, someone other than the user has a working password.

Detection logic

Two selections, both required:

legacy_client: clientAppUsed is a legacy protocol: Other clients, Exchange ActiveSync, IMAP4, POP3, Authenticated SMTP or MAPI Over HTTP. Modern sign-ins report Browser or Mobile Apps and Desktop clients.
password_accepted: status.errorCode is 0, 50074, 50076 or 53003.

The condition is legacy_client and password_accepted. Wrong-password attempts (AADSTS50126) over legacy protocols are password spraying; they deserve a separate, count-based rule.

Validated against a real sample

Validated against azure_mfa_bypass.json (shipped with LogTriage), four legacy-protocol sign-ins made with python-requests/2.28.0 within 90 seconds:

[email protected] and [email protected] over Other clients from 91.107.192.50 (Germany), both failing with 50074
[email protected] over Exchange ActiveSync from the same address, blocked by Conditional Access with 53003
[email protected] again over Other clients, now from 194.165.16.100 (Russia), failing with 50076

The rule fires on all four: three accounts whose passwords are known to the attacker. It stays silent on the matching benign log, where every sign-in is a successful Browser sign-in.

False positives

A real legacy mail client or line-of-business app can trip this. That is a finding too, because it is an exposure to close: inventory the source, migrate it to modern authentication, and scope a documented exception only if it is truly unavoidable.

Frequently Asked Questions

Why do failed sign-ins count here?: Because of what the failure codes mean. AADSTS50074 and AADSTS50076 are returned when the password was correct and Entra ID then required multifactor authentication, which a legacy protocol cannot complete. AADSTS53003 is returned when a Conditional Access policy blocked token issuance, and Conditional Access is evaluated after the first factor. So each of these failures tells you the attacker has the user's correct password. Wrong passwords produce AADSTS50126 instead, which this rule ignores.
Why is legacy authentication an MFA bypass?: Legacy protocols (basic authentication over IMAP, POP and SMTP, Exchange ActiveSync, and the catch-all 'Other clients') cannot present an MFA challenge. Where MFA is enforced for them, the sign-in fails with one of the codes above. Where it is not, for example a Conditional Access policy that only targets browsers and modern clients, the sign-in succeeds on the password alone; that is the success branch of this rule (errorCode 0).
Which fields does the rule use?: `clientAppUsed` and `status.errorCode` from the Microsoft Graph sign-in log schema. In Log Analytics (the SigninLogs table) the same values are in `ClientAppUsed` and `ResultType`, where ResultType is a string, so compare it with "50074" rather than a number.
What should I do when this fires?: Reset the user's password, because whoever signed in has it, and revoke the user's sessions. Then block legacy authentication with a Conditional Access policy (or Microsoft's security defaults), inventory anything that breaks and move it to modern authentication. A success over a legacy protocol also deserves a look at what the session accessed, usually the mailbox.

Related Resources

Reference

Entra ID (Azure AD) Sign-In Log Fields: field reference → every field explained, with real sample records
AADSTS50074 — The password was correct and Entra ID asked for multifactor authentication, which this request did not complete. Followed by a success it is routine; alone, from an unfamiliar place, it means someone else knows the password.
AADSTS50076 — Entra ID accepted the username and password, then required multifactor authentication that this request did not provide. From scripts or legacy mail clients it is strong evidence that whoever sent it knows the password.
AADSTS50126 — Entra ID rejected the password (or the username) for this sign-in. One failure is a typo; the same failure across many accounts from one IP is password spraying.
AADSTS53003 — A Conditional Access policy blocked the sign-in. Conditional Access is enforced after first-factor authentication completes, so for an interactive sign-in an unexpected 53003 usually means the password was right.
Entra ID (AADSTS) sign-in error codes →
Look up any error code in these events → free, runs in your browser

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