Unauthorized Scope for Public App OAuth2 Token Grant with Client Credentials
Identifies a failed OAuth 2.0 token grant attempt for a public client app using client credentials. This event is
generated when a public client app attempts to exchange a client credentials grant for an OAuth 2.0 access token, but
the request is denied due to the lack of required scopes. This could indicate compromised client credentials in which an
adversary is attempting to obtain an access token for unauthorized scopes. This is a New
Terms rule where the
okta.actor.display_name
field value has not been seen in the last 14 days regarding this event.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2024/09/11"
3integration = ["okta"]
4maturity = "production"
5updated_date = "2025/07/02"
6
7[rule]
8author = ["Elastic"]
9description = """
10Identifies a failed OAuth 2.0 token grant attempt for a public client app using client credentials. This event is
11generated when a public client app attempts to exchange a client credentials grant for an OAuth 2.0 access token, but
12the request is denied due to the lack of required scopes. This could indicate compromised client credentials in which an
13adversary is attempting to obtain an access token for unauthorized scopes. This is a [New
14Terms](https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-new-terms-rule) rule where the
15`okta.actor.display_name` field value has not been seen in the last 14 days regarding this event.
16"""
17from = "now-9m"
18index = ["filebeat-*", "logs-okta*"]
19language = "kuery"
20license = "Elastic License v2"
21name = "Unauthorized Scope for Public App OAuth2 Token Grant with Client Credentials"
22note = """## Triage and analysis
23
24> **Disclaimer**:
25> 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.
26
27### Investigating Unauthorized Scope for Public App OAuth2 Token Grant with Client Credentials
28
29OAuth 2.0 is a protocol for authorization, allowing apps to access resources on behalf of users. Public client apps, lacking secure storage, use client credentials for token grants. Adversaries may exploit compromised credentials to request unauthorized scopes. The detection rule identifies failed token grants due to scope mismatches, signaling potential misuse of client credentials.
30
31### Possible investigation steps
32
33- Review the `okta.actor.display_name` field to identify the public client app involved in the failed token grant attempt and determine if it is a known or expected application.
34- Examine the `okta.debug_context.debug_data.flattened.requestedScopes` field to understand which unauthorized scopes were requested and assess their potential impact if accessed.
35- Investigate the `okta.actor.type` field to confirm that the actor is indeed a public client app, which lacks secure storage, and evaluate the risk of compromised credentials.
36- Check the `okta.outcome.reason` field for "no_matching_scope" to verify that the failure was due to a scope mismatch, indicating an attempt to access unauthorized resources.
37- Analyze the `okta.client.user_agent.raw_user_agent` field to ensure the request did not originate from known Okta integrations, which are excluded from the rule, to rule out false positives.
38- Correlate the event with other security logs or alerts to identify any patterns or additional suspicious activities related to the same client credentials or IP address.
39
40### False positive analysis
41
42- Frequent legitimate access attempts by known public client apps may trigger false positives. To manage this, consider creating exceptions for specific `okta.actor.display_name` values that are known to frequently request scopes without malicious intent.
43- Automated processes or integrations that use client credentials might occasionally request scopes not typically associated with their function. Review these processes and, if deemed non-threatening, exclude their `okta.client.user_agent.raw_user_agent` from triggering the rule.
44- Development or testing environments often simulate various OAuth 2.0 token grant scenarios, which can result in false positives. Identify and exclude these environments by their `okta.actor.display_name` or other distinguishing attributes.
45- Regularly review and update the list of non-threatening scopes in `okta.debug_context.debug_data.flattened.requestedScopes` to ensure that legitimate scope requests are not flagged as unauthorized.
46
47### Response and remediation
48
49- Immediately revoke the compromised client credentials to prevent further unauthorized access attempts.
50- Conduct a thorough review of the affected public client app's access logs to identify any successful unauthorized access or data exfiltration attempts.
51- Notify the application owner and relevant security teams about the incident to ensure coordinated response efforts.
52- Implement additional monitoring on the affected app and associated user accounts to detect any further suspicious activities.
53- Update and enforce stricter access controls and scope permissions for public client apps to minimize the risk of unauthorized scope requests.
54- Consider implementing multi-factor authentication (MFA) for accessing sensitive resources to add an additional layer of security.
55- Escalate the incident to the security operations center (SOC) for further investigation and to determine if broader organizational impacts exist."""
56references = [
57 "https://github.blog/news-insights/company-news/security-alert-stolen-oauth-user-tokens/",
58 "https://developer.okta.com/docs/reference/api/event-types/",
59 "https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security",
60 "https://www.elastic.co/security-labs/starter-guide-to-understanding-okta",
61]
62risk_score = 47
63rule_id = "6649e656-6f85-11ef-8876-f661ea17fbcc"
64severity = "medium"
65tags = [
66 "Domain: SaaS",
67 "Data Source: Okta",
68 "Use Case: Threat Detection",
69 "Use Case: Identity and Access Audit",
70 "Tactic: Defense Evasion",
71 "Resources: Investigation Guide",
72]
73timestamp_override = "event.ingested"
74type = "new_terms"
75
76query = '''
77event.dataset: okta.system
78 and event.action: "app.oauth2.as.token.grant"
79 and okta.actor.type: "PublicClientApp"
80 and okta.debug_context.debug_data.flattened.grantType: "client_credentials"
81 and okta.outcome.result: "FAILURE"
82 and not okta.client.user_agent.raw_user_agent: "Okta-Integrations"
83 and not okta.actor.display_name: (Okta* or Datadog)
84 and not okta.debug_context.debug_data.flattened.requestedScopes: ("okta.logs.read" or "okta.eventHooks.read" or "okta.inlineHooks.read")
85 and okta.outcome.reason: "no_matching_scope"
86'''
87
88
89[[rule.threat]]
90framework = "MITRE ATT&CK"
91[[rule.threat.technique]]
92id = "T1550"
93name = "Use Alternate Authentication Material"
94reference = "https://attack.mitre.org/techniques/T1550/"
95[[rule.threat.technique.subtechnique]]
96id = "T1550.001"
97name = "Application Access Token"
98reference = "https://attack.mitre.org/techniques/T1550/001/"
99
100
101
102[rule.threat.tactic]
103id = "TA0005"
104name = "Defense Evasion"
105reference = "https://attack.mitre.org/tactics/TA0005/"
106
107[rule.new_terms]
108field = "new_terms_fields"
109value = ["okta.actor.display_name"]
110[[rule.new_terms.history_window_start]]
111field = "history_window_start"
112value = "now-14d"
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 Unauthorized Scope for Public App OAuth2 Token Grant with Client Credentials
OAuth 2.0 is a protocol for authorization, allowing apps to access resources on behalf of users. Public client apps, lacking secure storage, use client credentials for token grants. Adversaries may exploit compromised credentials to request unauthorized scopes. The detection rule identifies failed token grants due to scope mismatches, signaling potential misuse of client credentials.
Possible investigation steps
- Review the
okta.actor.display_name
field to identify the public client app involved in the failed token grant attempt and determine if it is a known or expected application. - Examine the
okta.debug_context.debug_data.flattened.requestedScopes
field to understand which unauthorized scopes were requested and assess their potential impact if accessed. - Investigate the
okta.actor.type
field to confirm that the actor is indeed a public client app, which lacks secure storage, and evaluate the risk of compromised credentials. - Check the
okta.outcome.reason
field for "no_matching_scope" to verify that the failure was due to a scope mismatch, indicating an attempt to access unauthorized resources. - Analyze the
okta.client.user_agent.raw_user_agent
field to ensure the request did not originate from known Okta integrations, which are excluded from the rule, to rule out false positives. - Correlate the event with other security logs or alerts to identify any patterns or additional suspicious activities related to the same client credentials or IP address.
False positive analysis
- Frequent legitimate access attempts by known public client apps may trigger false positives. To manage this, consider creating exceptions for specific
okta.actor.display_name
values that are known to frequently request scopes without malicious intent. - Automated processes or integrations that use client credentials might occasionally request scopes not typically associated with their function. Review these processes and, if deemed non-threatening, exclude their
okta.client.user_agent.raw_user_agent
from triggering the rule. - Development or testing environments often simulate various OAuth 2.0 token grant scenarios, which can result in false positives. Identify and exclude these environments by their
okta.actor.display_name
or other distinguishing attributes. - Regularly review and update the list of non-threatening scopes in
okta.debug_context.debug_data.flattened.requestedScopes
to ensure that legitimate scope requests are not flagged as unauthorized.
Response and remediation
- Immediately revoke the compromised client credentials to prevent further unauthorized access attempts.
- Conduct a thorough review of the affected public client app's access logs to identify any successful unauthorized access or data exfiltration attempts.
- Notify the application owner and relevant security teams about the incident to ensure coordinated response efforts.
- Implement additional monitoring on the affected app and associated user accounts to detect any further suspicious activities.
- Update and enforce stricter access controls and scope permissions for public client apps to minimize the risk of unauthorized scope requests.
- Consider implementing multi-factor authentication (MFA) for accessing sensitive resources to add an additional layer of security.
- Escalate the incident to the security operations center (SOC) for further investigation and to determine if broader organizational impacts exist.
References
Related rules
- Successful Application SSO from Rare Unknown Client Device
- Attempt to Deactivate an Okta Network Zone
- Attempt to Deactivate an Okta Policy
- Attempt to Deactivate an Okta Policy Rule
- Attempt to Delete an Okta Network Zone