Entra ID User Sign-In via Unusual Legacy Authentication Client

Detects a successful sign-in by a Member user principal through a legacy authentication client (such as Authenticated SMTP, IMAP4, POP3, Exchange ActiveSync, Exchange Web Services, or other basic-authentication clients) in Microsoft Entra ID, where the user principal has not been seen using a legacy client in the last 7 days. Legacy authentication clients rely on basic authentication, do not support modern authentication or interactive multi-factor authentication, and are frequently abused by adversaries for password spraying and account takeover because they translate into single-factor Resource Owner Password Credentials (ROPC) grants. This is a New Terms rule that surfaces the first occurrence of legacy client authentication for a given user, which is unusual in most modern environments.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2026/07/02"
  3integration = ["azure"]
  4maturity = "production"
  5updated_date = "2026/07/02"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Detects a successful sign-in by a Member user principal through a legacy authentication client (such as Authenticated
 11SMTP, IMAP4, POP3, Exchange ActiveSync, Exchange Web Services, or other basic-authentication clients) in Microsoft Entra
 12ID, where the user principal has not been seen using a legacy client in the last 7 days. Legacy authentication clients
 13rely on basic authentication, do not support modern authentication or interactive multi-factor authentication, and are
 14frequently abused by adversaries for password spraying and account takeover because they translate into single-factor
 15Resource Owner Password Credentials (ROPC) grants. This is a New Terms rule that surfaces the first occurrence of legacy
 16client authentication for a given user, which is unusual in most modern environments.
 17"""
 18from = "now-9m"
 19index = ["logs-azure.signinlogs-*"]
 20language = "kuery"
 21license = "Elastic License v2"
 22name = "Entra ID User Sign-In via Unusual Legacy Authentication Client"
 23note = """## Triage and analysis
 24
 25### Investigating Entra ID User Sign-In via Unusual Legacy Authentication Client
 26
 27Legacy authentication clients use basic authentication and do not support modern authentication or interactive multi-factor authentication. Microsoft Entra ID classifies these clients under `client_app_used` values such as Authenticated SMTP, IMAP4, POP3, Exchange ActiveSync, Exchange Web Services, MAPI Over HTTP, Outlook Anywhere, and Other clients (as opposed to the modern values Browser and Mobile Apps and Desktop clients). Adversaries prefer these clients because they translate into single-factor ROPC grants that bypass interactive MFA, making them effective for password spraying and account takeover.
 28
 29This rule is a New Terms detection that fires when a Member user principal is first seen authenticating with a legacy client in the last 7 days. In environments that have largely moved to modern authentication, a new legacy-client sign-in for a user is unusual and warrants review. It is a broader companion to the targeted ROPC detections and catches legacy protocols beyond Authenticated SMTP.
 30
 31### Possible investigation steps
 32- Review `azure.signinlogs.properties.client_app_used` to identify which legacy protocol was used and whether the user is expected to use it.
 33- Review `azure.signinlogs.properties.user_principal_name` to determine whether the account is a human user, a service account, or a shared mailbox, and whether legacy authentication is part of its normal behavior.
 34- Review `azure.signinlogs.properties.client_ip` / `source.ip`, geolocation, and ASN to determine whether the source is expected. Correlate with known-malicious infrastructure.
 35- Inspect `user_agent.original`. Values such as `BAV2ROPC`, `python-requests`, `curl`, or other scripting-tool agents are highly suspicious.
 36- Check `azure.signinlogs.properties.applied_conditional_access_policies` to determine whether legacy-authentication blocking was expected to apply and why it did not.
 37- Look for a preceding burst of failed authentications (password spraying) from the same source or against the same account, and for post-authentication actions such as mailbox rule creation, mail forwarding, or OAuth consent.
 38
 39### False positive analysis
 40- Legitimate legacy applications, service accounts, multifunction printers, scan-to-email appliances, and monitoring tools may still use legacy authentication clients such as Authenticated SMTP. These are typically stable in source IP and account and can be excluded once verified.
 41- Migrations, onboarding of older mail clients, or line-of-business applications that have not yet moved to modern authentication can generate first-occurrence sign-ins. Validate the business context and exclude confirmed benign accounts.
 42
 43### Response and remediation
 44- If the sign-in is confirmed malicious, disable the account, revoke active sessions and refresh tokens, and reset the password.
 45- Disable the specific legacy protocol for the affected mailbox (for example `Set-CASMailbox -SmtpClientAuthenticationDisabled $true`) and, where feasible, block legacy authentication tenant-wide with Conditional Access.
 46- Enforce MFA for the affected user and investigate the source IP and any preceding failed-authentication activity to scope a potential password-spray campaign.
 47- Review the account's activity after the sign-in (mailbox rules, forwarding, delegate changes, OAuth grants) and remediate any unauthorized changes.
 48"""
 49references = [
 50    "https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-block-legacy-authentication",
 51    "https://learn.microsoft.com/en-us/entra/identity-platform/v2-oauth-ropc",
 52    "https://www.proofpoint.com/us/blog/threat-insight/attackers-unleash-teamfiltration-account-takeover-campaign",
 53    "https://redcanary.com/blog/threat-detection/bav2ropc/",
 54]
 55risk_score = 47
 56rule_id = "0b7dbb27-29f8-4219-bcf1-7b82c6dd0bdc"
 57severity = "medium"
 58tags = [
 59    "Domain: Cloud",
 60    "Domain: Identity",
 61    "Data Source: Azure",
 62    "Data Source: Microsoft Entra ID",
 63    "Data Source: Microsoft Entra ID Sign-In Logs",
 64    "Use Case: Identity and Access Audit",
 65    "Tactic: Initial Access",
 66    "Tactic: Defense Evasion",
 67    "Resources: Investigation Guide",
 68]
 69timestamp_override = "event.ingested"
 70type = "new_terms"
 71
 72query = '''
 73data_stream.dataset: "azure.signinlogs" and
 74    event.action: "Sign-in activity" and
 75    event.outcome: "success" and
 76    azure.signinlogs.properties.user_type: "Member" and
 77    azure.signinlogs.properties.client_app_used: (
 78        "Authenticated SMTP" or
 79        "Autodiscover" or
 80        "Exchange ActiveSync" or
 81        "Exchange Online PowerShell" or
 82        "Exchange Web Services" or
 83        "IMAP4" or
 84        "MAPI Over HTTP" or
 85        "Offline Address Book" or
 86        "Outlook Anywhere" or
 87        "Outlook Service" or
 88        "POP3" or
 89        "Reporting Web Services" or
 90        "Other clients"
 91    )
 92'''
 93
 94
 95[[rule.threat]]
 96framework = "MITRE ATT&CK"
 97[[rule.threat.technique]]
 98id = "T1078"
 99name = "Valid Accounts"
100reference = "https://attack.mitre.org/techniques/T1078/"
101[[rule.threat.technique.subtechnique]]
102id = "T1078.004"
103name = "Cloud Accounts"
104reference = "https://attack.mitre.org/techniques/T1078/004/"
105
106
107
108[rule.threat.tactic]
109id = "TA0001"
110name = "Initial Access"
111reference = "https://attack.mitre.org/tactics/TA0001/"
112[[rule.threat]]
113framework = "MITRE ATT&CK"
114[[rule.threat.technique]]
115id = "T1078"
116name = "Valid Accounts"
117reference = "https://attack.mitre.org/techniques/T1078/"
118[[rule.threat.technique.subtechnique]]
119id = "T1078.004"
120name = "Cloud Accounts"
121reference = "https://attack.mitre.org/techniques/T1078/004/"
122
123
124
125[rule.threat.tactic]
126id = "TA0005"
127name = "Defense Evasion"
128reference = "https://attack.mitre.org/tactics/TA0005/"
129
130[rule.new_terms]
131field = "new_terms_fields"
132value = ["azure.signinlogs.properties.user_principal_name"]
133[[rule.new_terms.history_window_start]]
134field = "history_window_start"
135value = "now-7d"

Triage and analysis

Investigating Entra ID User Sign-In via Unusual Legacy Authentication Client

Legacy authentication clients use basic authentication and do not support modern authentication or interactive multi-factor authentication. Microsoft Entra ID classifies these clients under client_app_used values such as Authenticated SMTP, IMAP4, POP3, Exchange ActiveSync, Exchange Web Services, MAPI Over HTTP, Outlook Anywhere, and Other clients (as opposed to the modern values Browser and Mobile Apps and Desktop clients). Adversaries prefer these clients because they translate into single-factor ROPC grants that bypass interactive MFA, making them effective for password spraying and account takeover.

This rule is a New Terms detection that fires when a Member user principal is first seen authenticating with a legacy client in the last 7 days. In environments that have largely moved to modern authentication, a new legacy-client sign-in for a user is unusual and warrants review. It is a broader companion to the targeted ROPC detections and catches legacy protocols beyond Authenticated SMTP.

Possible investigation steps

  • Review azure.signinlogs.properties.client_app_used to identify which legacy protocol was used and whether the user is expected to use it.
  • Review azure.signinlogs.properties.user_principal_name to determine whether the account is a human user, a service account, or a shared mailbox, and whether legacy authentication is part of its normal behavior.
  • Review azure.signinlogs.properties.client_ip / source.ip, geolocation, and ASN to determine whether the source is expected. Correlate with known-malicious infrastructure.
  • Inspect user_agent.original. Values such as BAV2ROPC, python-requests, curl, or other scripting-tool agents are highly suspicious.
  • Check azure.signinlogs.properties.applied_conditional_access_policies to determine whether legacy-authentication blocking was expected to apply and why it did not.
  • Look for a preceding burst of failed authentications (password spraying) from the same source or against the same account, and for post-authentication actions such as mailbox rule creation, mail forwarding, or OAuth consent.

False positive analysis

  • Legitimate legacy applications, service accounts, multifunction printers, scan-to-email appliances, and monitoring tools may still use legacy authentication clients such as Authenticated SMTP. These are typically stable in source IP and account and can be excluded once verified.
  • Migrations, onboarding of older mail clients, or line-of-business applications that have not yet moved to modern authentication can generate first-occurrence sign-ins. Validate the business context and exclude confirmed benign accounts.

Response and remediation

  • If the sign-in is confirmed malicious, disable the account, revoke active sessions and refresh tokens, and reset the password.
  • Disable the specific legacy protocol for the affected mailbox (for example Set-CASMailbox -SmtpClientAuthenticationDisabled $true) and, where feasible, block legacy authentication tenant-wide with Conditional Access.
  • Enforce MFA for the affected user and investigate the source IP and any preceding failed-authentication activity to scope a potential password-spray campaign.
  • Review the account's activity after the sign-in (mailbox rules, forwarding, delegate changes, OAuth grants) and remediate any unauthorized changes.

References

Related rules

to-top