« Microsoft Build Engine Using an Alternate Name Microsoft Entra ID Conditional Access Policy (CAP) Modified »
Elastic Docs ›Elastic Security Solution [8.18] ›Detections and alerts ›Prebuilt rule reference

Microsoft Entra ID Concurrent Sign-Ins with Suspicious Properties

edit
A newer version is available. Check out the latest documentation.

Microsoft Entra ID Concurrent Sign-Ins with Suspicious Properties

edit

Identifies concurrent azure signin events for the same user and from multiple sources, and where one of the authentication event has some suspicious properties often associated to DeviceCode and OAuth phishing. Adversaries may steal Refresh Tokens (RTs) via phishing to bypass multi-factor authentication (MFA) and gain unauthorized access to Azure resources.

Rule type: esql

Rule indices: None

Severity: high

Risk score: 73

Runs every: 5m

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

Maximum alerts per execution: 100

References:

Tags:

  • Domain: Cloud
  • Domain: SaaS
  • Data Source: Azure
  • Data Source: Entra ID
  • Data Source: Entra ID Sign-in
  • Use Case: Identity and Access Audit
  • Use Case: Threat Detection
  • Tactic: Credential Access
  • Resources: Investigation Guide

Version: 1

Rule authors:

  • Elastic

Rule license: Elastic License v2

Investigation guide

edit

Triage and analysis

Investigating Microsoft Entra ID Concurrent Sign-Ins with Suspicious Properties

Possible investigation steps

  • Review the sign-in logs to assess the context and reputation of the source.ip address.
  • Investigate the user account associated with the successful sign-in to determine if the activity aligns with expected behavior or if it appears suspicious.
  • Check for any recent changes or anomalies in the user’s account settings or permissions that could indicate compromise.
  • Review the history of sign-ins for the user to identify any patterns or unusual access times that could suggest unauthorized access.
  • Assess the device from which the sign-in was attempted to ensure it is a recognized and authorized device for the user.

Response and remediation

  • Immediately revoke the compromised Primary Refresh Tokens (PRTs) to prevent further unauthorized access. This can be done through the Azure portal by navigating to the user’s account and invalidating all active sessions.
  • Enforce a password reset for the affected user accounts to ensure that any credentials potentially compromised during the attack are no longer valid.
  • Implement additional Conditional Access policies that require device compliance checks and restrict access to trusted locations or devices only, to mitigate the risk of future PRT abuse.
  • Conduct a thorough review of the affected accounts' recent activity logs to identify any unauthorized actions or data access that may have occurred during the compromise.
  • Escalate the incident to the security operations team for further investigation and to determine if there are any broader implications or additional compromised accounts.
  • Enhance monitoring by configuring alerts for unusual sign-in patterns or device code authentication attempts from unexpected locations or devices, to improve early detection of similar threats.
  • Coordinate with the incident response team to perform a post-incident analysis and update the incident response plan with lessons learned from this event.

Setup

edit

Required Azure Entra Sign-In Logs

This rule requires the Azure logs integration be enabled and configured to collect all logs, including sign-in logs from Entra. In Entra, sign-in logs must be enabled and streaming to the Event Hub used for the Azure logs integration.

Rule query

edit
FROM logs-azure.signinlogs* metadata _id, _version, _index
// the rule is scheduled to run every hour and looks for events occured during last 1 hour.
| where @timestamp > NOW() - 1 hours
| where event.dataset == "azure.signinlogs" and source.ip is not null and azure.signinlogs.identity is not null and to_lower(event.outcome) == "success"
| keep @timestamp, azure.signinlogs.identity, source.ip, azure.signinlogs.properties.authentication_requirement, azure.signinlogs.properties.app_id, azure.signinlogs.properties.resource_display_name, azure.signinlogs.properties.authentication_protocol, azure.signinlogs.properties.app_display_name
// devicecode authentication no MFA
| eval device_code = case(azure.signinlogs.properties.authentication_protocol == "deviceCode" and azure.signinlogs.properties.authentication_requirement != "multiFactorAuthentication", azure.signinlogs.identity, null),
// potential Visual Studio Code OAuth code phish - sign-in events with client set to Visual Studio Code
 visual_studio = case(azure.signinlogs.properties.app_id == "aebc6443-996d-45c2-90f0-388ff96faa56" and azure.signinlogs.properties.resource_display_name == "Microsoft Graph", azure.signinlogs.identity, null),
// Other sign-in events
 other = case(azure.signinlogs.properties.authentication_protocol != "deviceCode" and azure.signinlogs.properties.app_id != "aebc6443-996d-45c2-90f0-388ff96faa56", azure.signinlogs.identity, null)
| stats total = COUNT(*), device_code_count = COUNT_DISTINCT(device_code), vsc = count_distinct(visual_studio), other_count = COUNT_DISTINCT(other), src_ip = COUNT_DISTINCT(source.ip), ips = values(source.ip), clients = values(azure.signinlogs.properties.app_display_name), resources = VALUES(azure.signinlogs.properties.resource_display_name), auth_requirement = VALUES(azure.signinlogs.properties.authentication_requirement) by azure.signinlogs.identity
// 2 unique source.ip for same account - which may indicate the presence 2 sign-ins one by the adversary and the other by the victim
| where src_ip >= 2 and (device_code_count > 0 or vsc >0)

Framework: MITRE ATT&CKTM

« Microsoft Build Engine Using an Alternate Name Microsoft Entra ID Conditional Access Policy (CAP) Modified »