security-tools/sigma-rules
1
0
Fork 0
Code Issues Pull Requests Actions 3 Packages Projects Releases Wiki Activity

[Rule Tuning] Entra ID OAuth Device Code Grant by Unusual User (#5791)

Browse Source 
* [Rule Tuning] Entra ID OAuth Device Code Grant by Unusual User
Fixes #5790

* updated description and investigation guide
This commit is contained in:
Terrance DeJesus
2026-03-10 10:37:38 -04:00
committed by GitHub
parent 0ae390ce6f
commit 1d3dad243c
1 changed files with 53 additions and 54 deletions
Download Patch File Download Diff File Expand all files Collapse all files
rules/integrations/azure/initial_access_entra_id_first_time_seen_device_code_auth.toml
+53 -54
View File
@@ -2,15 +2,15 @@
creation_date = "2024/10/14"
integration = ["azure"]
maturity = "production"
updated_date = "2025/12/10"
updated_date = "2026/02/26"
[rule]
author = ["Elastic", "Matteo Potito Giorgio"]
description = """
Identifies when a user is observed for the first time in the last 14 days 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.
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.
"""
from = "now-9m"
index = ["filebeat-*", "logs-azure.signinlogs-*", "logs-azure.activitylogs-*"]
@@ -21,73 +21,60 @@ note = """## 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 a **14-day 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.
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
### Possible investigation steps
#### Identify the User and Authentication Details
- **User Principal Name (UPN)**: Review `azure.signinlogs.properties.user_principal_name` to identify the user involved in the authentication event.
- **User ID**: Check `azure.signinlogs.properties.user_id` for a unique identifier of the affected account.
- **Authentication Protocol**: Confirm that `azure.signinlogs.properties.authentication_protocol` is set to `deviceCode`.
- **Application Used**: Verify the application through `azure.signinlogs.properties.app_display_name` and `azure.signinlogs.properties.app_id` to determine if it is an expected application.
- 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.
#### Review the Source IP and Geolocation
- **Source IP Address**: Check `source.ip` and compare it with previous authentication logs to determine whether the login originated from a trusted or expected location.
- **Geolocation Details**: Analyze `source.geo.city_name`, `source.geo.region_name`, and `source.geo.country_name` to confirm whether the login location is suspicious.
- **ASN / ISP Details**: Review `source.as.organization.name` to check if the IP is associated with a known organization or cloud provider.
### False positive analysis
#### Examine Multi-Factor Authentication (MFA) and Conditional Access
- **MFA Enforcement**: Review `azure.signinlogs.properties.applied_conditional_access_policies` to determine if MFA was enforced during the authentication.
- **Conditional Access Policies**: Check `azure.signinlogs.properties.conditional_access_status` to understand if conditional access policies were applied and if any controls were bypassed.
- **Authentication Method**: Look at `azure.signinlogs.properties.authentication_details` to confirm how authentication was satisfied (e.g., MFA via claim in token).
- 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.
#### Validate Device and Client Details
- **Device Information**: Review `azure.signinlogs.properties.device_detail.browser` to determine if the login aligns with the expected behavior of a device that lacks a keyboard.
- **User-Agent Analysis**: Inspect `user_agent.original` for anomalies, such as an unexpected operating system or browser.
- **Client Application**: Verify `azure.signinlogs.properties.client_app_used` to confirm whether the login was performed using a known client.
### Response and remediation
#### Investigate Related Activities
- **Correlate with Phishing Attempts**: Check if the user recently reported phishing attempts or suspicious emails.
- **Monitor for Anomalous Account Activity**: Look for recent changes in the user's account settings, including password resets, role changes, or delegation of access.
- **Check for Additional DeviceCode Logins**: Review if other users in the environment have triggered similar authentication events within the same timeframe.
## False Positive Analysis
- **Legitimate Device Enrollment**: If the user is setting up a new device (e.g., a smart TV or kiosk), this authentication may be expected.
- **Automation or Scripting**: Some legitimate applications or scripts may leverage the `DeviceCode` authentication protocol for non-interactive logins.
- **Shared Devices in Organizations**: In cases where shared workstations or conference room devices are in use, legitimate users may trigger alerts.
- **Travel and Remote Work**: If the user is traveling or accessing from a new location, confirm legitimacy before taking action.
## Response and Remediation
- **Revoke Suspicious Access Tokens**: Immediately revoke any access tokens associated with this authentication event.
- **Investigate the User’s Recent Activity**: Review additional authentication logs, application access, and recent permission changes for signs of compromise.
- **Reset Credentials and Enforce Stronger Authentication**:
- Reset the affected user’s credentials.
- Enforce stricter MFA policies for sensitive accounts.
- Restrict `DeviceCode` authentication to only required applications.
- **Monitor for Further Anomalies**:
- Enable additional logging and anomaly detection for DeviceCode logins.
- Set up alerts for unauthorized access attempts using this authentication method.
- **Educate Users on Phishing Risks**: If phishing is suspected, notify the affected user and provide security awareness training on how to recognize and report phishing attempts.
- **Review and Adjust Conditional Access Policies**:
- Limit `DeviceCode` authentication to approved users and applications.
- Implement stricter geolocation-based authentication restrictions.
- 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.
"""
references = [
"https://aadinternals.com/post/phishing/",
"https://www.blackhillsinfosec.com/dynamic-device-code-phishing/",
"https://www.volexity.com/blog/2025/02/13/multiple-russian-threat-actors-targeting-microsoft-device-code-authentication/",
"https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-authentication-flows",
"https://www.microsoft.com/en-us/security/blog/2025/02/13/storm-2372-conducts-device-code-phishing-campaign/"
]
risk_score = 47
rule_id = "af22d970-7106-45b4-b5e3-460d15333727"
setup = "This rule optionally requires Azure Sign-In logs from the Azure integration. Ensure that the Azure integration is correctly set up and that the required data is being collected.\n"
setup = """#### 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.
"""
severity = "medium"
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",
@@ -99,10 +86,22 @@ query = '''
event.dataset:(azure.activitylogs or azure.signinlogs)
and (
azure.signinlogs.properties.authentication_protocol:deviceCode or
azure.signinlogs.properties.original_transfer_method: "Device code flow" 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"
)
'''
@@ -137,4 +136,4 @@ field = "new_terms_fields"
value = ["azure.signinlogs.properties.user_principal_name"]
[[rule.new_terms.history_window_start]]
field = "history_window_start"
value = "now-14d"
value = "now-7d"