« Unusual Azure VM Extension Detected Azure AKS API Server Proxying Request to Kubelet »
Elastic Docs ›Elastic Security [8.19] ›Downloadable rule update v8.19.28

Entra ID User Sign-In via Unusual Legacy Authentication Client

edit
IMPORTANT: This documentation is no longer updated. Refer to Elastic's version policy and the latest documentation.

Entra ID User Sign-In via Unusual Legacy Authentication Client

edit

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.

Rule type: new_terms

Rule indices:

  • logs-azure.signinlogs-*

Severity: medium

Risk score: 47

Runs every: 5m

Searches indices from: now-9m (Date Math format, see also Additional look-back time)

Maximum alerts per execution: 100

References:

Tags:

  • Domain: Cloud
  • Domain: Identity
  • Data Source: Azure
  • Data Source: Microsoft Entra ID
  • Data Source: Microsoft Entra ID Sign-In Logs
  • Use Case: Identity and Access Audit
  • Tactic: Initial Access
  • Tactic: Defense Evasion
  • Resources: Investigation Guide

Version: 1

Rule authors:

  • Elastic

Rule license: Elastic License v2

Investigation guide

edit

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.

Rule query

edit
data_stream.dataset: "azure.signinlogs" and
    event.action: "Sign-in activity" and
    event.outcome: "success" and
    azure.signinlogs.properties.user_type: "Member" and
    azure.signinlogs.properties.client_app_used: (
        "Authenticated SMTP" or
        "Autodiscover" or
        "Exchange ActiveSync" or
        "Exchange Online PowerShell" or
        "Exchange Web Services" or
        "IMAP4" or
        "MAPI Over HTTP" or
        "Offline Address Book" or
        "Outlook Anywhere" or
        "Outlook Service" or
        "POP3" or
        "Reporting Web Services" or
        "Other clients"
    )

Framework: MITRE ATT&CKTM

« Unusual Azure VM Extension Detected Azure AKS API Server Proxying Request to Kubelet »