Entra ID Device Code Auth with Broker Client
Identifies device code authentication with an Azure broker client for Entra ID. Adversaries abuse Primary Refresh Tokens (PRTs) to bypass multi-factor authentication (MFA) and gain unauthorized access to Azure resources. PRTs are used in Conditional Access policies to enforce device-based controls. Compromising PRTs allows attackers to bypass these policies and gain unauthorized access. This rule detects successful sign-ins using device code authentication with the Entra ID broker client application ID (29d9ed98-a469-4536-ade2-f981bc1d605e).
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2024/06/24"
3integration = ["azure"]
4maturity = "production"
5updated_date = "2025/01/15"
6
7[rule]
8author = ["Elastic"]
9description = """
10Identifies device code authentication with an Azure broker client for Entra ID. Adversaries abuse Primary Refresh Tokens (PRTs) to bypass multi-factor authentication (MFA) and gain unauthorized access to Azure resources. PRTs are used in Conditional Access policies to enforce device-based controls. Compromising PRTs allows attackers to bypass these policies and gain unauthorized access. This rule detects successful sign-ins using device code authentication with the Entra ID broker client application ID (29d9ed98-a469-4536-ade2-f981bc1d605e).
11"""
12from = "now-9m"
13index = ["filebeat-*", "logs-azure.signinlogs-*", "logs-azure.activitylogs-*"]
14language = "kuery"
15license = "Elastic License v2"
16name = "Entra ID Device Code Auth with Broker Client"
17references =[
18 "https://dirkjanm.io/assets/raw/Phishing%20the%20Phishing%20Resistant.pdf",
19 "https://learn.microsoft.com/en-us/troubleshoot/azure/entra/entra-id/governance/verify-first-party-apps-sign-in",
20 "https://learn.microsoft.com/en-us/azure/azure-monitor/reference/tables/signinlogs"
21]
22risk_score = 47
23rule_id = "a83b3dac-325a-11ef-b3e6-f661ea17fbce"
24setup = """
25This 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.
26"""
27severity = "medium"
28tags = [
29 "Domain: Cloud",
30 "Data Source: Azure",
31 "Data Source: Microsoft Entra ID",
32 "Use Case: Identity and Access Audit",
33 "Tactic: Credential Access",
34 "Resources: Investigation Guide",
35]
36timestamp_override = "event.ingested"
37type = "query"
38
39query = '''
40 event.dataset:(azure.activitylogs or azure.signinlogs)
41 and azure.signinlogs.properties.authentication_protocol:deviceCode
42 and azure.signinlogs.properties.conditional_access_audiences.application_id:29d9ed98-a469-4536-ade2-f981bc1d605e
43 and event.outcome:success or (
44 azure.activitylogs.properties.appId:29d9ed98-a469-4536-ade2-f981bc1d605e
45 and azure.activitylogs.properties.authentication_protocol:deviceCode)
46'''
47note = """## Triage and analysis
48
49> **Disclaimer**:
50> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
51
52### Investigating Entra ID Device Code Auth with Broker Client
53
54Entra ID Device Code Authentication allows users to authenticate devices using a code, facilitating seamless access to Azure resources. Adversaries exploit this by compromising Primary Refresh Tokens (PRTs) to bypass multi-factor authentication and Conditional Access policies. The detection rule identifies unauthorized access attempts by monitoring successful sign-ins using device code authentication linked to a specific broker client application ID, flagging potential misuse.
55
56### Possible investigation steps
57
58- Review the sign-in logs to confirm the use of device code authentication by checking the field azure.signinlogs.properties.authentication_protocol for the value deviceCode.
59- Verify the application ID involved in the sign-in attempt by examining azure.signinlogs.properties.conditional_access_audiences.application_id and ensure it matches 29d9ed98-a469-4536-ade2-f981bc1d605e.
60- Investigate the user account associated with the successful sign-in to determine if the activity aligns with expected behavior or if it appears suspicious.
61- Check for any recent changes or anomalies in the user's account settings or permissions that could indicate compromise.
62- Review the history of sign-ins for the user to identify any patterns or unusual access times that could suggest unauthorized access.
63- Assess the device from which the sign-in was attempted to ensure it is a recognized and authorized device for the user.
64
65### False positive analysis
66
67- Legitimate device code authentication by trusted applications or users may trigger the rule. Review the application ID and user context to confirm legitimacy.
68- Frequent access by automated scripts or services using device code authentication can be mistaken for unauthorized access. Identify and document these services, then create exceptions for known application IDs.
69- Shared devices in environments with multiple users may cause false positives if device code authentication is used regularly. Implement user-specific logging to differentiate between legitimate and suspicious activities.
70- Regular maintenance or updates by IT teams using device code authentication might be flagged. Coordinate with IT to schedule these activities and temporarily adjust monitoring rules if necessary.
71- Ensure that any exceptions or exclusions are regularly reviewed and updated to reflect changes in the environment or application usage patterns.
72
73### Response and remediation
74
75- 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.
76- Enforce a password reset for the affected user accounts to ensure that any credentials potentially compromised during the attack are no longer valid.
77- 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.
78- 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.
79- Escalate the incident to the security operations team for further investigation and to determine if there are any broader implications or additional compromised accounts.
80- 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.
81- Coordinate with the incident response team to perform a post-incident analysis and update the incident response plan with lessons learned from this event."""
82
83
84[[rule.threat]]
85framework = "MITRE ATT&CK"
86[[rule.threat.technique]]
87id = "T1528"
88name = "Steal Application Access Token"
89reference = "https://attack.mitre.org/techniques/T1528/"
90
91
92[rule.threat.tactic]
93id = "TA0006"
94name = "Credential Access"
95reference = "https://attack.mitre.org/tactics/TA0006/"
Triage and analysis
Disclaimer: This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
Investigating Entra ID Device Code Auth with Broker Client
Entra ID Device Code Authentication allows users to authenticate devices using a code, facilitating seamless access to Azure resources. Adversaries exploit this by compromising Primary Refresh Tokens (PRTs) to bypass multi-factor authentication and Conditional Access policies. The detection rule identifies unauthorized access attempts by monitoring successful sign-ins using device code authentication linked to a specific broker client application ID, flagging potential misuse.
Possible investigation steps
- Review the sign-in logs to confirm the use of device code authentication by checking the field azure.signinlogs.properties.authentication_protocol for the value deviceCode.
- Verify the application ID involved in the sign-in attempt by examining azure.signinlogs.properties.conditional_access_audiences.application_id and ensure it matches 29d9ed98-a469-4536-ade2-f981bc1d605e.
- 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.
False positive analysis
- Legitimate device code authentication by trusted applications or users may trigger the rule. Review the application ID and user context to confirm legitimacy.
- Frequent access by automated scripts or services using device code authentication can be mistaken for unauthorized access. Identify and document these services, then create exceptions for known application IDs.
- Shared devices in environments with multiple users may cause false positives if device code authentication is used regularly. Implement user-specific logging to differentiate between legitimate and suspicious activities.
- Regular maintenance or updates by IT teams using device code authentication might be flagged. Coordinate with IT to schedule these activities and temporarily adjust monitoring rules if necessary.
- Ensure that any exceptions or exclusions are regularly reviewed and updated to reflect changes in the environment or application usage patterns.
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.
References
Related rules
- Azure Storage Account Key Regenerated
- AWS EC2 Admin Credential Fetch via Assumed Role
- AWS EC2 Instance Console Login via Assumed Role
- AWS IAM CompromisedKeyQuarantine Policy Attached to User
- AWS Management Console Brute Force of Root User Identity