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

[Rule Tuning] Okta User Sessions Started from Different Geolocations (#3799)

Browse Source 
* tuning 'Okta User Sessions Started from Different Geolocations'

* TOML linting

* updated min-stack comments

* added setup

* Removed some blank spaces
This commit is contained in:
Terrance DeJesus
2024-06-20 16:52:26 -04:00
committed by GitHub
parent e9d7ddfa35
commit 11aab028dc
1 changed files with 63 additions and 23 deletions
Download Patch File Download Diff File Expand all files Collapse all files
rules/integrations/okta/initial_access_okta_user_sessions_started_from_different_geolocations.toml
+63 -23
View File
@@ -2,51 +2,99 @@
creation_date = "2023/11/18"
integration = ["okta"]
maturity = "production"
min_stack_comments = "Breaking change in Okta integration bumping version to ^2.0.0"
min_stack_version = "8.10.0"
updated_date = "2023/11/18"
min_stack_comments = "ES|QL rule type becomes available in 8.13.0 as technical preview."
min_stack_version = "8.13.0"
updated_date = "2024/06/20"
[rule]
author = ["Elastic"]
description = """
Detects when a specific Okta actor has multiple sessions started from different geolocations.
Detects when a specific Okta actor has multiple sessions started from different geolocations. Adversaries may attempt to
launch an attack by using a list of known usernames and passwords to gain unauthorized access to user accounts from
different locations.
"""
from = "now-30m"
interval = "15m"
index = ["filebeat-*", "logs-okta*"]
language = "kuery"
language = "esql"
license = "Elastic License v2"
name = "Okta User Sessions Started from Different Geolocations"
note = """## Setup
note = """
The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
## Triage and analysis
### Investigating Okta User Sessions Started from Different Geolocations
This rule detects when a specific Okta actor has multiple sessions started from different geolocations. Adversaries may attempt to launch an attack by using a list of known usernames and passwords to gain unauthorized access to user accounts from different locations.
#### Possible investigation steps:
- Since this is an ES|QL rule, the `okta.actor.alternate_id` and `okta.client.id` values can be used to pivot into the raw authentication events related to this alert.
- Identify the users involved in this action by examining the `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, and `okta.actor.display_name` fields.
- Determine the device client used for these actions by analyzing `okta.client.ip`, `okta.client.user_agent.raw_user_agent`, `okta.client.zone`, `okta.client.device`, and `okta.client.id` fields.
- With Okta end users identified, review the `okta.debug_context.debug_data.dt_hash` field.
- Historical analysis should indicate if this device token hash is commonly associated with the user.
- Review the `okta.event_type` field to determine the type of authentication event that occurred.
- If the event type is `user.authentication.sso`, the user may have legitimately started a session via a proxy for security or privacy reasons.
- If the event type is `user.authentication.password`, the user may be using a proxy to access multiple accounts for password spraying.
- If the event type is `user.session.start`, the source may have attempted to establish a session via the Okta authentication API.
- Review the past activities of the actor(s) involved in this action by checking their previous actions.
- Evaluate the actions that happened just before and after this event in the `okta.event_type` field to help understand the full context of the activity.
- This may help determine the authentication and authorization actions that occurred between the user, Okta and application.
### False positive analysis:
- It is very rare that a legitimate user would have multiple sessions started from different geo-located countries in a short time frame.
### Response and remediation:
- If the user is legitimate and the authentication behavior is not suspicious based on device analysis, no action is required.
- If the user is legitimate but the authentication behavior is suspicious, consider resetting passwords for the users involves and enabling multi-factor authentication (MFA).
- If MFA is already enabled, consider resetting MFA for the users.
- If any of the users are not legitimate, consider deactivating the user's account.
- Conduct a review of Okta policies and ensure they are in accordance with security best practices.
- Check with internal IT teams to determine if the accounts involved recently had MFA reset at the request of the user.
- If so, confirm with the user this was a legitimate request.
- If so and this was not a legitimate request, consider deactivating the user's account temporarily.
- Reset passwords and reset MFA for the user.
- If this is a false positive, consider adding the `okta.debug_context.debug_data.dt_hash` field to the `exceptions` list in the rule.
- This will prevent future occurrences of this event for this device from triggering the rule.
- Alternatively adding `okta.client.ip` or a CIDR range to the `exceptions` list can prevent future occurrences of this event from triggering the rule.
- This should be done with caution as it may prevent legitimate alerts from being generated.
"""
references = [
"https://developer.okta.com/docs/reference/api/system-log/",
"https://developer.okta.com/docs/reference/api/event-types/",
"https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy",
"https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection",
"https://www.rezonate.io/blog/okta-logs-decoded-unveiling-identity-threats-through-threat-hunting/"
"https://www.rezonate.io/blog/okta-logs-decoded-unveiling-identity-threats-through-threat-hunting/",
]
risk_score = 47
rule_id = "2e56e1bc-867a-11ee-b13e-f661ea17fbcd"
setup = """
The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
"""
severity = "medium"
tags = ["Use Case: Identity and Access Audit", "Data Source: Okta", "Tactic: Initial Access"]
timestamp_override = "event.ingested"
type = "threshold"
type = "esql"
query = '''
event.dataset:okta.system and okta.event_type:user.session.start and not okta.security_context.is_proxy:true
and okta.actor.id:* and client.geo.country_name:*
FROM logs-okta*
| WHERE
event.dataset == "okta.system"
AND (event.action RLIKE "user\\.authentication(.*)" OR event.action == "user.session.start")
AND okta.security_context.is_proxy != true and okta.actor.id != "unknown"
AND event.outcome == "success"
| STATS
geo_auth_counts = COUNT_DISTINCT(client.geo.country_name)
BY okta.actor.id, okta.actor.alternate_id
| WHERE
geo_auth_counts >= 2
'''
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1078"
name = "Valid Accounts"
reference = "https://attack.mitre.org/techniques/T1078/"
[[rule.threat.technique.subtechnique]]
id = "T1078.004"
name = "Cloud Accounts"
@@ -56,11 +104,3 @@ reference = "https://attack.mitre.org/techniques/T1078/004/"
id = "TA0001"
name = "Initial Access"
reference = "https://attack.mitre.org/tactics/TA0001/"
[rule.threshold]
field = ["okta.actor.id"]
value = 1
[[rule.threshold.cardinality]]
field = "client.geo.country_name"
value = 2