M365 Identity OAuth Illicit Consent Grant by Rare Client and User
Identifies an Microsoft 365 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 in Microsoft 365. 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 in Microsoft 365 on-behalf-of the user.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2025/03/24"
3integration = ["o365"]
4maturity = "production"
5updated_date = "2026/09/18"
6
7[rule]
8author = ["Elastic"]
9description = """
10Identifies an Microsoft 365 illicit consent grant request on-behalf-of a registered Entra ID application. Adversaries
11may create and register an application in Microsoft Entra ID for the purpose of requesting user consent to access
12resources in Microsoft 365. This is accomplished by tricking a user into granting consent to the application, typically
13via a pre-made phishing URL. This establishes an OAuth grant that allows the malicious client applocation to access
14resources in Microsoft 365 on-behalf-of the user.
15"""
16from = "now-9m"
17index = ["logs-o365.audit-*"]
18language = "kuery"
19license = "Elastic License v2"
20name = "M365 Identity OAuth Illicit Consent Grant by Rare Client and User"
21note = """## Triage and analysis
22
23### Investigating M365 Identity OAuth Illicit Consent Grant by Rare Client and User
24
25Adversaries may register a malicious application in Microsoft Entra ID and trick users into granting excessive permissions via OAuth consent. These apps can access sensitive Microsoft 365 data—such as mail, profiles, and files—on behalf of the user once consent is granted. This activity is often initiated through spearphishing campaigns that direct the user to a pre-crafted OAuth consent URL.
26
27This rule identifies a new consent grant to an application using Microsoft 365 audit logs. Additionally, this is a New Terms rule that will only trigger if the user and client ID have not been seen doing this activity in the last 14 days.
28
29#### Possible investigation steps
30
31- **Review the app in Entra ID**:
32 - Go to **Enterprise Applications** in the Azure portal.
33 - Search for the `AppId` or name from `o365.audit.ObjectId`.
34 - Review granted API permissions and whether admin consent was required.
35 - Check the `Publisher` and `Verified` status.
36
37- **Assess the user who granted consent**:
38 - Investigate `o365.audit.UserId` (e.g., `terrance.dejesus@...`) for signs of phishing or account compromise.
39 - Check if the user was targeted in recent phishing simulations or campaigns.
40 - Review the user’s sign-in logs for suspicious geolocation, IP, or device changes.
41
42- **Determine scope and risk**:
43 - Check `o365.audit.ModifiedProperties.ConsentAction_Reason.NewValue` 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. 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.
44 - Use the `ConsentContext_IsAdminConsent` and `ConsentContext_OnBehalfOfAll` flags to assess privilege level.
45 - Review `o365.audit.ModifiedProperties.ConsentAction_Permissions.NewValue` for the granted scopes. Combinations such as `offline_access` with `Mail.ReadWrite`, `Files.ReadWrite.All`, or `Chat.Read` are characteristic of mailbox and file exfiltration and indicate potential data exposure.
46 - Cross-reference affected `Target` objects with known business-critical assets or data owners.
47
48- **Correlate additional telemetry**:
49 - Review logs from Defender for Cloud Apps (MCAS), Microsoft Purview, or other DLP tooling for unusual access patterns.
50 - Search for `AppId` across your tenant to determine how widely it's used.
51
52### False positive analysis
53
54- Not all consent grants are malicious. Verify if the app is business-approved, listed in your app catalog, or commonly used by users in that role or department.
55- Consent reasons like `WindowsAzureActiveDirectoryIntegratedApp` could relate to integrated services, though these still require verification.
56- 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). Its absence does not make the consent benign, so weigh it alongside the requested scopes, admin-consent context, and the application's publisher.
57
58### Response and remediation
59
60- **If the app is confirmed malicious**:
61 - Revoke OAuth consent using the [Microsoft Graph API](https://learn.microsoft.com/en-us/graph/api/oauth2permissiongrant-delete).
62 - Remove any related service principals from Entra ID.
63 - Block the app via the Conditional Access "Grant" control or Defender for Cloud Apps policies.
64 - Revoke refresh tokens and require reauthentication for affected users.
65 - Notify end-users and IT of the potential exposure.
66 - Activate your phishing or OAuth abuse response playbook.
67
68- **Prevent future misuse**:
69 - Enable the [Admin consent workflow](https://learn.microsoft.com/en-us/azure/active-directory/manage-apps/configure-admin-consent-workflow) to restrict user-granted consent.
70 - Audit and reduce overprivileged applications in your environment.
71 - Consider using Defender for Cloud Apps OAuth app governance.
72
73"""
74references = [
75 "https://www.wiz.io/blog/midnight-blizzard-microsoft-breach-analysis-and-best-practices",
76 "https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/detect-and-remediate-illicit-consent-grants?view=o365-worldwide",
77 "https://www.cloud-architekt.net/detection-and-mitigation-consent-grant-attacks-azuread/",
78 "https://docs.microsoft.com/en-us/defender-cloud-apps/investigate-risky-oauth#how-to-detect-risky-oauth-apps",
79 "https://learn.microsoft.com/en-us/office/office-365-management-api/office-365-management-activity-api-schema",
80]
81risk_score = 47
82rule_id = "0c3c80de-08c2-11f0-bd11-f661ea17fbcc"
83severity = "medium"
84tags = [
85 "Domain: Cloud",
86 "Data Source: Microsoft 365",
87 "Data Source: Microsoft 365 Audit Logs",
88 "Use Case: Identity and Access Audit",
89 "Resources: Investigation Guide",
90 "Tactic: Initial Access",
91 "Tactic: Credential Access",
92 "Noise: Medium",
93 "Performance: Normal",
94 "Profile: Recommended",
95 "Threat: OAuth App Consent",
96 "Rule Type: New Terms",
97 "Platform: Microsoft 365",
98 "Domain: SaaS",
99 "Domain: Email",
100]
101timestamp_override = "event.ingested"
102type = "new_terms"
103
104query = '''
105data_stream.dataset: "o365.audit"
106 and o365.audit.Actor.Type: 5
107 and event.action: "Consent to application."
108 and event.outcome: "success"
109 and o365.audit.Target.Type: (0 or 2 or 3 or 9 or 10)
110 and o365.audit.UserId: *
111 and o365.audit.ObjectId: *
112'''
113
114
115[[rule.threat]]
116framework = "MITRE ATT&CK"
117
118[[rule.threat.technique]]
119id = "T1566"
120name = "Phishing"
121reference = "https://attack.mitre.org/techniques/T1566/"
122
123[[rule.threat.technique.subtechnique]]
124id = "T1566.002"
125name = "Spearphishing Link"
126reference = "https://attack.mitre.org/techniques/T1566/002/"
127
128[rule.threat.tactic]
129id = "TA0001"
130name = "Initial Access"
131reference = "https://attack.mitre.org/tactics/TA0001/"
132
133[[rule.threat]]
134framework = "MITRE ATT&CK"
135
136[[rule.threat.technique]]
137id = "T1528"
138name = "Steal Application Access Token"
139reference = "https://attack.mitre.org/techniques/T1528/"
140
141[rule.threat.tactic]
142id = "TA0006"
143name = "Credential Access"
144reference = "https://attack.mitre.org/tactics/TA0006/"
145
146[[rule.threat]]
147framework = "MITRE ATT&CK"
148
149[[rule.threat.technique]]
150id = "T1098"
151name = "Account Manipulation"
152reference = "https://attack.mitre.org/techniques/T1098/"
153
154[rule.threat.tactic]
155id = "TA0003"
156name = "Persistence"
157reference = "https://attack.mitre.org/tactics/TA0003/"
158[rule.investigation_fields]
159field_names = [
160 "@timestamp",
161 "event.action",
162 "event.outcome",
163 "o365.audit.UserId",
164 "o365.audit.ObjectId",
165 "o365.audit.Actor.Type",
166 "o365.audit.Target.Type",
167 "o365.audit.ModifiedProperties.ConsentAction_Reason.NewValue",
168 "o365.audit.ExtendedProperties.additionalDetails",
169 "cloud.region"
170]
171
172[rule.new_terms]
173field = "new_terms_fields"
174value = ["o365.audit.UserId", "o365.audit.ObjectId"]
175[[rule.new_terms.history_window_start]]
176field = "history_window_start"
177value = "now-10d"
Triage and analysis
Investigating M365 Identity OAuth Illicit Consent Grant by Rare Client and User
Adversaries may register a malicious application in Microsoft Entra ID and trick users into granting excessive permissions via OAuth consent. These apps can access sensitive Microsoft 365 data—such as mail, profiles, and files—on behalf of the user once consent is granted. This activity is often initiated through spearphishing campaigns that direct the user to a pre-crafted OAuth consent URL.
This rule identifies a new consent grant to an application using Microsoft 365 audit logs. Additionally, this is a New Terms rule that will only trigger if the user and client ID have not been seen doing this activity in the last 14 days.
Possible investigation steps
-
Review the app in Entra ID:
- Go to Enterprise Applications in the Azure portal.
- Search for the
AppIdor name fromo365.audit.ObjectId. - Review granted API permissions and whether admin consent was required.
- Check the
PublisherandVerifiedstatus.
-
Assess the user who granted consent:
- Investigate
o365.audit.UserId(e.g.,terrance.dejesus@...) for signs of phishing or account compromise. - Check if the user was targeted in recent phishing simulations or campaigns.
- Review the user’s sign-in logs for suspicious geolocation, IP, or device changes.
- Investigate
-
Determine scope and risk:
- Check
o365.audit.ModifiedProperties.ConsentAction_Reason.NewValueto determine whether Microsoft's own risk heuristics flagged the application. A value ofRisky application detectedmeans Microsoft scored the app as suspicious at the time consent was granted and should raise the priority of the review. 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. - Use the
ConsentContext_IsAdminConsentandConsentContext_OnBehalfOfAllflags to assess privilege level. - Review
o365.audit.ModifiedProperties.ConsentAction_Permissions.NewValuefor the granted scopes. Combinations such asoffline_accesswithMail.ReadWrite,Files.ReadWrite.All, orChat.Readare characteristic of mailbox and file exfiltration and indicate potential data exposure. - Cross-reference affected
Targetobjects with known business-critical assets or data owners.
- Check
-
Correlate additional telemetry:
- Review logs from Defender for Cloud Apps (MCAS), Microsoft Purview, or other DLP tooling for unusual access patterns.
- Search for
AppIdacross your tenant to determine how widely it's used.
False positive analysis
- Not all consent grants are malicious. Verify if the app is business-approved, listed in your app catalog, or commonly used by users in that role or department.
- Consent reasons like
WindowsAzureActiveDirectoryIntegratedAppcould relate to integrated services, though these still require verification. - 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). Its absence does not make the consent benign, so weigh it alongside the requested scopes, admin-consent context, and the application's publisher.
Response and remediation
-
If the app is confirmed malicious:
- Revoke OAuth consent using the Microsoft Graph API.
- Remove any related service principals from Entra ID.
- Block the app via the Conditional Access "Grant" control or Defender for Cloud Apps policies.
- Revoke refresh tokens and require reauthentication for affected users.
- Notify end-users and IT of the potential exposure.
- Activate your phishing or OAuth abuse response playbook.
-
Prevent future misuse:
- Enable the Admin consent workflow to restrict user-granted consent.
- Audit and reduce overprivileged applications in your environment.
- Consider using Defender for Cloud Apps OAuth app governance.
References
Related rules
- M365 Identity Device Code Grant by an Unusual User (Non-Compliant Device)
- Entra ID Kali365 Default User-Agent Detected
- M365 Identity Device Code Grant with Unusual User and ASN
- M365 Identity Login from Atypical Region
- M365 Identity OAuth Flow by User Sign-in to Device Registration