Entra ID OAuth Device Code Grant by Unusual User

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

Entra ID OAuth Device Code Grant by Unusual User

edit

Identifies when a user is observed for the first time authenticating using the device code authentication workflow. This authentication workflow can be abused by attackers to phish users and steal access tokens to impersonate the victim. By its very nature, device code should only be used when logging in to devices without keyboards, where it is difficult to enter emails and passwords. This rule only applies to Entra ID user types and detects new users leveraging this flow.

Rule type: new_terms

Rule indices:

  • filebeat-*
  • logs-azure.signinlogs-*
  • logs-azure.activitylogs-*

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
  • Resources: Investigation Guide

Version: 8

Rule authors:

  • Elastic
  • Matteo Potito Giorgio

Rule license: Elastic License v2

Investigation guide

edit

Triage and analysis

Investigating Entra ID OAuth Device Code Grant by Unusual User

This rule detects the first instance of a user authenticating via the DeviceCode authentication protocol within the historical window. The DeviceCode authentication workflow is designed for devices that lack keyboards, such as IoT devices and smart TVs. However, adversaries can abuse this mechanism by phishing users and stealing authentication tokens, leading to unauthorized access.

Possible investigation steps

  • Review azure.signinlogs.properties.user_principal_name and azure.signinlogs.properties.user_id to identify the user involved.
  • Confirm that azure.signinlogs.properties.authentication_protocol is set to deviceCode.
  • Verify the application through azure.signinlogs.properties.app_display_name and azure.signinlogs.properties.app_id to determine if it is expected.
  • Check source.ip and compare it with previous authentication logs to determine whether the login originated from a trusted location.
  • Analyze source.geo.city_name, source.geo.region_name, and source.geo.country_name to confirm whether the login location is suspicious.
  • Review source.as.organization.name to check if the IP is associated with a known organization or cloud provider.
  • Review azure.signinlogs.properties.applied_conditional_access_policies and azure.signinlogs.properties.conditional_access_status to determine if MFA or conditional access policies were enforced or bypassed.
  • Look at azure.signinlogs.properties.authentication_details to confirm how authentication was satisfied.
  • Review azure.signinlogs.properties.device_detail.browser and user_agent.original to determine if the login aligns with expected device behavior.
  • Verify azure.signinlogs.properties.client_app_used to confirm whether the login was performed using a known client.
  • Check if the user recently reported phishing attempts or suspicious emails.
  • Look for recent changes in the user’s account settings, including password resets, role changes, or delegation of access.
  • Review if other users in the environment have triggered similar DeviceCode authentication events within the same timeframe.

False positive analysis

  • If the user is setting up a new device (e.g., a smart TV or kiosk), this authentication may be expected.
  • Some legitimate applications or scripts may leverage the DeviceCode authentication protocol for non-interactive logins.
  • In cases where shared workstations or conference room devices are in use, legitimate users may trigger alerts.
  • If the user is traveling or accessing from a new location, confirm legitimacy before taking action.

Response and remediation

  • Immediately revoke any access tokens associated with this authentication event.
  • Review additional authentication logs, application access, and recent permission changes for signs of compromise.
  • Reset the affected user’s credentials and enforce stricter MFA policies for sensitive accounts.
  • Restrict DeviceCode authentication to only required applications.
  • Enable additional logging and anomaly detection for DeviceCode logins.
  • If phishing is suspected, notify the affected user and provide security awareness training on how to recognize and report phishing attempts.
  • Limit DeviceCode authentication to approved users and applications via conditional access policies.

Setup

edit

Required Microsoft Entra ID Sign-In Logs

This rule requires the Azure integration with Microsoft Entra ID Sign-In logs to be enabled and configured to collect audit and activity logs via Azure Event Hub.

Rule query

edit
event.dataset:(azure.activitylogs or azure.signinlogs)
    and (
            azure.signinlogs.properties.authentication_protocol:deviceCode or
            azure.signinlogs.properties.original_transfer_method:deviceCodeFlow or
            azure.activitylogs.properties.authentication_protocol:deviceCode
        )
    and event.outcome:success
    and azure.signinlogs.properties.user_type:*
    and not azure.signinlogs.properties.app_id:(
        "29d9ed98-a469-4536-ade2-f981bc1d605e" or
        "d5a56ea4-7369-46b8-a538-c370805301bf" or
        "80faf920-1908-4b52-b5ef-a8e7bedfc67a" or
        "97877f11-0fc6-4aee-b1ff-febb0519dd00" or
        "245e1dee-74ef-4257-a8c8-8208296e1dfd" or
        "9ba1a5c7-f17a-4de9-a1f1-6178c8d51223" or
        "74bcdadc-2fdc-4bb3-8459-76d06952a0e9" or
        "4813382a-8fa7-425e-ab75-3b753aab3abb" or
        "a850aaae-d5a5-4e82-877c-ce54ff916282"
    )

Framework: MITRE ATT&CKTM