Entra ID Illicit Consent Grant via Registered Application
Identifies an illicit consent grant request on-behalf-of a registered Entra ID application. Adversaries may create and register an application in Microsoft Entra ID for the purpose of requesting user consent to access resources. This is accomplished by tricking a user into granting consent to the application, typically via a pre-made phishing URL. This establishes an OAuth grant that allows the malicious client applocation to access resources on-behalf-of the user.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2020/09/01"
3integration = ["azure"]
4maturity = "production"
5updated_date = "2026/09/18"
6
7[rule]
8author = ["Elastic"]
9description = """
10Identifies an illicit consent grant request on-behalf-of a registered Entra ID application. Adversaries may create and
11register an application in Microsoft Entra ID for the purpose of requesting user consent to access resources. This is
12accomplished by tricking a user into granting consent to the application, typically via a pre-made phishing URL. This
13establishes an OAuth grant that allows the malicious client applocation to access resources on-behalf-of the user.
14"""
15from = "now-7d"
16interval = "8m"
17language = "esql"
18license = "Elastic License v2"
19name = "Entra ID Illicit Consent Grant via Registered Application"
20note = """## Triage and analysis
21
22### Investigating Entra ID Illicit Consent Grant via Registered Application
23
24Adversaries may register a malicious application in Microsoft Entra ID and trick users into granting excessive permissions via OAuth consent. These applications can access sensitive data—such as mail, profiles, or files—on behalf of the user once consent is granted. This is commonly delivered via spearphishing links that prompt users to approve permissions for seemingly legitimate applications.
25
26This rule identifies a new consent grant event based on Azure audit logs where a user or admin granted consent to an application.
27
28This rule uses ES|QL aggregation-based new terms logic with a 7-day history window. It extracts the AppId from the multi-valued additional_details array using MV_EXPAND and UUID regex filtering, then alerts when the user-application pair is first seen within the last 9 minutes. Alerts are suppressed by AppId and user principal name for 6 hours. Each distinct user-application pair therefore produces a single alert, preserving per-victim visibility: an application consented to by multiple users raises one alert per user, so the spread of a consent phishing campaign remains visible in the alert list.
29
30#### Possible investigation steps
31
32- Review `azure.auditlogs.properties.additional_details.value` to identify the AppId and User-Agent values to determine which application was granted access and how the request was initiated. Pivot on the AppId in the Azure portal under Enterprise Applications to investigate further.
33- Review `azure.auditlogs.properties.initiated_by.user.userPrincipalName` to identify the user who approved the application. Investigate their recent activity for signs of phishing, account compromise, or anomalous behavior during the timeframe of the consent.
34- Review `azure.auditlogs.properties.initiated_by.user.ipAddress` to assess the geographic source of the consent action. Unexpected locations or IP ranges may indicate adversary-controlled infrastructure.
35- Review `azure.auditlogs.properties.target_resources.display_name` to evaluate whether the application name is familiar, expected, or potentially spoofing a known service.
36- Review `azure.auditlogs.properties.target_resources.modified_properties.display_name` to inspect key indicators of elevated privilege or risk, including:
37 - ConsentContext.IsAdminConsent to determine if the application was granted tenant-wide admin access.
38 - ConsentContext.OnBehalfOfAll to identify whether the app was granted permissions on behalf of all users in the tenant.
39 - ConsentAction.Permissions to evaluate the specific scopes and data access the application requested. Scope combinations such as `offline_access` with `Mail.ReadWrite`, `Files.ReadWrite.All`, or `Chat.Read` are characteristic of mailbox and file exfiltration.
40 - ConsentAction.Reason to determine whether Microsoft's own risk heuristics flagged the application. A value of `Risky application detected` means Microsoft scored the app as suspicious at the time consent was granted and should raise the priority of the review. Note this reason is only populated on admin-consent events, and its absence does not clear the application; a flagged app is also not necessarily malicious, since Microsoft's heuristic can flag legitimate apps.
41 - TargetId.ServicePrincipalNames to confirm the service principal associated with the granted permissions.
42- Review `azure.tenant_id` to confirm the activity originated from your tenant and is not related to a cross-tenant application.
43- Review `@timestamp` and `azure.auditlogs.properties.correlation_id` to pivot into related sign-in, token usage, or application activity for further context.
44
45### False positive analysis
46
47- Some applications may request high-privilege scopes for legitimate purposes. Validate whether the application is verified, developed by Microsoft, or approved internally by your organization.
48- Review publisher verification, app ownership, and scope alignment with the intended business use case.
49- A `ConsentAction.Reason` of `Risky application detected` raises confidence that the consent is worth investigating, but Microsoft's risk heuristic is advisory and can flag legitimate applications (including internal line-of-business apps and newly registered tenant applications). Conversely, the absence of the flag does not make the consent benign, so weigh it alongside the requested scopes, admin-consent context, and the application's home tenant rather than in isolation.
50
51### Response and remediation
52
53- Revoke the application’s OAuth grant using Graph API or PowerShell. Use the Remove-AzureADOAuth2PermissionGrant cmdlet.
54- Remove the associated service principal from Azure AD.
55- Reset credentials or revoke tokens for affected users.
56- Block the application via Conditional Access or Defender for Cloud Apps policies.
57- Enable the Admin Consent Workflow in Azure AD to prevent unsanctioned user approvals in the future.
58- Report any malicious applications to Microsoft to protect other tenants.
59"""
60references = [
61 "https://www.wiz.io/blog/midnight-blizzard-microsoft-breach-analysis-and-best-practices",
62 "https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/detect-and-remediate-illicit-consent-grants?view=o365-worldwide",
63 "https://www.cloud-architekt.net/detection-and-mitigation-consent-grant-attacks-azuread/",
64 "https://docs.microsoft.com/en-us/defender-cloud-apps/investigate-risky-oauth#how-to-detect-risky-oauth-apps",
65]
66risk_score = 47
67rule_id = "1c6a8c7a-5cb6-4a82-ba27-d5a5b8a40a38"
68severity = "medium"
69tags = [
70 "Domain: Cloud",
71 "Domain: Identity",
72 "Data Source: Azure",
73 "Data Source: Microsoft Entra ID",
74 "Data Source: Microsoft Entra ID Audit Logs",
75 "Use Case: Identity and Access Audit",
76 "Resources: Investigation Guide",
77 "Tactic: Initial Access",
78 "Tactic: Credential Access",
79 "Noise: Medium",
80 "Performance: Fast",
81 "Profile: Recommended",
82 "Threat: OAuth App Consent",
83 "Rule Type: ES|QL",
84 "Platform: Entra ID",
85]
86type = "esql"
87
88query = '''
89FROM logs-azure.auditlogs-* metadata _id, _version, _index
90| WHERE (azure.auditlogs.operation_name == "Consent to application"
91 OR event.action == "Consent to application")
92 AND event.outcome == "success"
93
94| MV_EXPAND azure.auditlogs.properties.additional_details.value
95| WHERE azure.auditlogs.properties.additional_details.value
96 RLIKE "[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}"
97| RENAME azure.auditlogs.properties.additional_details.value AS Esql.app_id
98
99| STATS
100 Esql.timestamp_first_seen = MIN(@timestamp),
101 Esql.timestamp_last_seen = MAX(@timestamp),
102 Esql.app_display_name_values = VALUES(`azure.auditlogs.properties.target_resources.0.display_name`),
103 Esql.service_principal_id_values = VALUES(`azure.auditlogs.properties.target_resources.0.id`),
104 Esql.is_admin_consent_values = VALUES(`azure.auditlogs.properties.target_resources.0.modified_properties.0.new_value`),
105 Esql.is_app_only_values = VALUES(`azure.auditlogs.properties.target_resources.0.modified_properties.1.new_value`),
106 Esql.on_behalf_of_all_values = VALUES(`azure.auditlogs.properties.target_resources.0.modified_properties.2.new_value`),
107 Esql.consent_context_tags_values = VALUES(`azure.auditlogs.properties.target_resources.0.modified_properties.3.new_value`),
108 Esql.consent_permissions_values = VALUES(`azure.auditlogs.properties.target_resources.0.modified_properties.4.new_value`),
109 Esql.consent_reason_values = VALUES(`azure.auditlogs.properties.target_resources.0.modified_properties.5.new_value`),
110 Esql.user_id_values = VALUES(azure.auditlogs.properties.initiated_by.user.id),
111 Esql.ip_address_values = VALUES(azure.auditlogs.properties.initiated_by.user.ipAddress),
112 Esql.tenant_id_values = VALUES(azure.tenant_id),
113 Esql.correlation_id_values = VALUES(azure.auditlogs.properties.correlation_id),
114 Esql.event_count = COUNT(*)
115 BY azure.auditlogs.properties.initiated_by.user.userPrincipalName, Esql.app_id
116
117| WHERE Esql.timestamp_first_seen >= NOW() - 9 minutes
118| KEEP Esql.*, azure.*
119'''
120
121[rule.alert_suppression]
122group_by = ["azure.auditlogs.properties.initiated_by.user.userPrincipalName"]
123duration = {value = 6, unit = "h"}
124missing_fields_strategy = "suppress"
125
126
127[[rule.threat]]
128framework = "MITRE ATT&CK"
129
130[[rule.threat.technique]]
131id = "T1566"
132name = "Phishing"
133reference = "https://attack.mitre.org/techniques/T1566/"
134
135[[rule.threat.technique.subtechnique]]
136id = "T1566.002"
137name = "Spearphishing Link"
138reference = "https://attack.mitre.org/techniques/T1566/002/"
139
140[[rule.threat.technique]]
141id = "T1199"
142name = "Trusted Relationship"
143reference = "https://attack.mitre.org/techniques/T1199/"
144
145[rule.threat.tactic]
146id = "TA0001"
147name = "Initial Access"
148reference = "https://attack.mitre.org/tactics/TA0001/"
149[[rule.threat]]
150framework = "MITRE ATT&CK"
151[[rule.threat.technique]]
152id = "T1528"
153name = "Steal Application Access Token"
154reference = "https://attack.mitre.org/techniques/T1528/"
155
156
157[rule.threat.tactic]
158id = "TA0006"
159name = "Credential Access"
160reference = "https://attack.mitre.org/tactics/TA0006/"
Triage and analysis
Investigating Entra ID Illicit Consent Grant via Registered Application
Adversaries may register a malicious application in Microsoft Entra ID and trick users into granting excessive permissions via OAuth consent. These applications can access sensitive data—such as mail, profiles, or files—on behalf of the user once consent is granted. This is commonly delivered via spearphishing links that prompt users to approve permissions for seemingly legitimate applications.
This rule identifies a new consent grant event based on Azure audit logs where a user or admin granted consent to an application.
This rule uses ES|QL aggregation-based new terms logic with a 7-day history window. It extracts the AppId from the multi-valued additional_details array using MV_EXPAND and UUID regex filtering, then alerts when the user-application pair is first seen within the last 9 minutes. Alerts are suppressed by AppId and user principal name for 6 hours. Each distinct user-application pair therefore produces a single alert, preserving per-victim visibility: an application consented to by multiple users raises one alert per user, so the spread of a consent phishing campaign remains visible in the alert list.
Possible investigation steps
- Review
azure.auditlogs.properties.additional_details.valueto identify the AppId and User-Agent values to determine which application was granted access and how the request was initiated. Pivot on the AppId in the Azure portal under Enterprise Applications to investigate further. - Review
azure.auditlogs.properties.initiated_by.user.userPrincipalNameto identify the user who approved the application. Investigate their recent activity for signs of phishing, account compromise, or anomalous behavior during the timeframe of the consent. - Review
azure.auditlogs.properties.initiated_by.user.ipAddressto assess the geographic source of the consent action. Unexpected locations or IP ranges may indicate adversary-controlled infrastructure. - Review
azure.auditlogs.properties.target_resources.display_nameto evaluate whether the application name is familiar, expected, or potentially spoofing a known service. - Review
azure.auditlogs.properties.target_resources.modified_properties.display_nameto inspect key indicators of elevated privilege or risk, including:- ConsentContext.IsAdminConsent to determine if the application was granted tenant-wide admin access.
- ConsentContext.OnBehalfOfAll to identify whether the app was granted permissions on behalf of all users in the tenant.
- ConsentAction.Permissions to evaluate the specific scopes and data access the application requested. Scope combinations such as
offline_accesswithMail.ReadWrite,Files.ReadWrite.All, orChat.Readare characteristic of mailbox and file exfiltration. - ConsentAction.Reason to determine whether Microsoft's own risk heuristics flagged the application. A value of
Risky application detectedmeans Microsoft scored the app as suspicious at the time consent was granted and should raise the priority of the review. Note this reason is only populated on admin-consent events, and its absence does not clear the application; a flagged app is also not necessarily malicious, since Microsoft's heuristic can flag legitimate apps. - TargetId.ServicePrincipalNames to confirm the service principal associated with the granted permissions.
- Review
azure.tenant_idto confirm the activity originated from your tenant and is not related to a cross-tenant application. - Review
@timestampandazure.auditlogs.properties.correlation_idto pivot into related sign-in, token usage, or application activity for further context.
False positive analysis
- Some applications may request high-privilege scopes for legitimate purposes. Validate whether the application is verified, developed by Microsoft, or approved internally by your organization.
- Review publisher verification, app ownership, and scope alignment with the intended business use case.
- A
ConsentAction.ReasonofRisky application detectedraises confidence that the consent is worth investigating, but Microsoft's risk heuristic is advisory and can flag legitimate applications (including internal line-of-business apps and newly registered tenant applications). Conversely, the absence of the flag does not make the consent benign, so weigh it alongside the requested scopes, admin-consent context, and the application's home tenant rather than in isolation.
Response and remediation
- Revoke the application’s OAuth grant using Graph API or PowerShell. Use the Remove-AzureADOAuth2PermissionGrant cmdlet.
- Remove the associated service principal from Azure AD.
- Reset credentials or revoke tokens for affected users.
- Block the application via Conditional Access or Defender for Cloud Apps policies.
- Enable the Admin Consent Workflow in Azure AD to prevent unsanctioned user approvals in the future.
- Report any malicious applications to Microsoft to protect other tenants.
References
Related rules
- Microsoft Entra ID Impossible Travel Sign-in
- Entra ID Kali365 Default User-Agent Detected
- Entra ID Multiple Device Registrations by a Single User
- Entra ID OAuth Device Code Sign-in to Azure AD Graph Enumeration
- Entra ID OAuth Phishing via First-Party Microsoft Application