deardaniel/secdata-raw huggingface dataset:
Elastic SIEM Detection Rules: initial access impossible travel sign on

# Successful Impossible Travel Sign-On Events

---

## Metadata

- **Author:** Elastic
- **Description:** This hunting query identifies when a user successfully signs on from more than one country in a 15 minute interval. Adversaries may compromise authentication credentials for users or clients and attempt to authenticate from a separate country that the user has not previously authenticated from.

- **UUID:** `31585786-71f4-11ef-9e99-f661ea17fbcc`
- **Integration:** [okta](https://docs.elastic.co/integrations/okta)
- **Language:** `[ES|QL]`
- **Source File:** [Successful Impossible Travel Sign-On Events](../queries/initial_access_impossible_travel_sign_on.toml)

## Query

```sql
from logs-okta.system*
| where @timestamp > NOW() - 7 day
| where event.dataset == "okta.system"

    // filter on successful sign-on events only
    and okta.event_type == "policy.evaluate_sign_on"
    and okta.outcome.result in ("ALLOW", "SUCCESS")

// Truncate the timestamp to 1 hour intervals
| eval time_window = DATE_TRUNC(1 hours, @timestamp)

// Count the number of successful sign-on events for each user every 15 minutes
| stats country_count = count_distinct(client.geo.country_name) by okta.actor.alternate_id, time_window

// Filter for users who sign on from more than one country in a 15 minute interval
| where country_count >= 2
```

## Notes

- `okta.actor.alternate_id` would be target of the threat adversary
- Pivoting into a potential compromise requires an additional search for `okta.outcome.result` being `SUCCESS` for any `user.authentication*` value for `okta.event_type`
- Pivot to any additional Okta logs after authentication to determine if activity is still being reported by separate countries.

## MITRE ATT&CK Techniques

- [T1078.004](https://attack.mitre.org/techniques/T1078/004)

## License

- `Elastic License v2`
Elastic SIEM Detection Rules: initial access higher than average failed authentication

# Identify High Average of Failed Daily Authentication Attempts

---

## Metadata

- **Author:** Elastic
- **Description:** This hunting query identifies when the average number of failed daily authentication attempts is higher than normal in Okta. Adversaries may attempt to brute force user credentials to gain unauthorized access to accounts. This query calculates the average number of daily failed authentication attempts for each user and identifies when the average is higher than normal.

- **UUID:** `c8a35a26-71f1-11ef-9c4e-f661ea17fbcc`
- **Integration:** [okta](https://docs.elastic.co/integrations/okta)
- **Language:** `[ES|QL]`
- **Source File:** [Identify High Average of Failed Daily Authentication Attempts](../queries/initial_access_higher_than_average_failed_authentication.toml)

## Query

```sql
from logs-okta*
| where @timestamp > NOW() - 7 day

// truncate the timestamp to daily intervals
| eval target_time_window = DATE_TRUNC(1 days, @timestamp)
| where

    // filter for invalid credential authentication events
    event.action == "user.session.start"
    and okta.outcome.result == "FAILURE"
    and okta.outcome.reason == "INVALID_CREDENTIALS"
    and okta.actor.type == "User"

| stats
    // count the number of daily failed logins for each day and user
    failed_daily_logins = count(*) by target_time_window, okta.actor.alternate_id

| stats
    // calculate the average number of daily failed logins for each day
    avg_daily_logins = avg(failed_daily_logins) by target_time_window

// sort the results by the average number of daily failed logins in descending order
| sort avg_daily_logins desc
```

## Notes

- Pivot to users by only keeping the first stats statement where `okta.actor.alternate_id` is the targeted accounts.
- Pivot for successful logins from the same source IP by searching for `event.action` equal to `user.session.start` or `user.authentication.verify` where the outcome is `SUCCESS`.
- User agents can be used to identify anomalous behavior, such as a user agent that is not associated with a known application or user.
- Another `WHERE` count can be added to the query if activity has been baseline to filter out known behavior.

## MITRE ATT&CK Techniques

- [T1078.004](https://attack.mitre.org/techniques/T1078/004)

## License

- `Elastic License v2`
Elastic SIEM Detection Rules: persistence multi factor push notification bombing

# Multi-Factor Authentication (MFA) Push Notification Bombing

---

## Metadata

- **Author:** Elastic
- **Description:** This hunting query identifies when a user denies multiple push notifications for multi-factor authentication (MFA) in rapid succession. Adversaries may attempt to deny push notifications to flood the target user's device with notifications, causing the user to ignore legitimate notifications or potentially disable MFA. This query identifies when a user denies more than 5 push notifications in a single hour.

- **UUID:** `7c51fe3e-6ae9-11ef-919d-f661ea17fbcc`
- **Integration:** [okta](https://docs.elastic.co/integrations/okta)
- **Language:** `[ES|QL]`
- **Source File:** [Multi-Factor Authentication (MFA) Push Notification Bombing](../queries/persistence_multi_factor_push_notification_bombing.toml)

## Query

```sql
from logs-okta.system*
| where @timestamp > NOW() - 7 day

// Filter for deny push notifications for multi-factor authentication
| where event.dataset == "okta.system" and event.action == "user.mfa.okta_verify.deny_push"

// Truncate the timestamp to hourly intervals
| eval hourly_count = date_trunc(1 hour, event.ingested)

// Count the number of deny push notifications for each user every hour
| stats hourly_denies = count(*) by okta.actor.alternate_id, hourly_count

// Filter for users who deny more than 5 push notifications in a single hour
| where hourly_denies > 5
```

## Notes

- `okta.actor.alternate_id` would be target of the threat adversary
- Pivoting into a potential compromise requires an additional search for `okta.outcome.result` being `SUCCESS` for any `user.authentication*` value for `okta.event_type`
- For a smaller window (rapid denies), reduce from 1 hour to 30 minutes or lower

## MITRE ATT&CK Techniques

- [T1556.006](https://attack.mitre.org/techniques/T1556/006)

## License

- `Elastic License v2`
Elastic SIEM Detection Rules: credential access mfa bombing push notifications

# Rapid MFA Deny Push Notifications (MFA Bombing)

---

## Metadata

- **Author:** Elastic
- **Description:** This hunting query identifies MFA bombing attacks in Okta. Adversaries may attempt to flood a user with multiple MFA push notifications to disrupt operations or gain unauthorized access to accounts. This query identifies when a user has more than 5 MFA deny push notifications in a 10 minute window.

- **UUID:** `223451b0-6eca-11ef-a070-f661ea17fbcc`
- **Integration:** [okta](https://docs.elastic.co/integrations/okta)
- **Language:** `[ES|QL]`
- **Source File:** [Rapid MFA Deny Push Notifications (MFA Bombing)](../queries/credential_access_mfa_bombing_push_notifications.toml)

## Query

```sql
from logs-okta*
| where @timestamp > NOW() - 7 day

// Truncate the timestamp to 10 minute windows
| eval target_time_window = DATE_TRUNC(10 minutes, @timestamp)

// Filter for MFA deny push notifications
| where event.action == "user.mfa.okta_verify.deny_push"

// Count the number of MFA deny push notifications for each user in each 10 minute window
| stats deny_push_count = count(*) by target_time_window, okta.actor.alternate_id

// Filter for users with more than 5 MFA deny push notifications
| where deny_push_count >= 5
```

## Notes

- `okta.actor.alternate_id` is the targeted user account.
- Pivot and search for `event.action` is `user.authentication.auth_via_mfa` to determine if the target user accepted the MFA push notification.
- If a MFA bombing attack is suspected, both username and password are required prior to MFA push notifications. Thus the credentials are likely compromised.

## MITRE ATT&CK Techniques

- [T1621](https://attack.mitre.org/techniques/T1621)

## License

- `Elastic License v2`
Elastic SIEM Detection Rules: defense evasion rare oauth access token granted by application

# Rare Occurrence of OAuth Access Token Granted to Public Client App

---

## Metadata

- **Author:** Elastic
- **Description:** This hunting query identifies a rare occurrence of a public client app successfully retrieves an OAuth access token using client credentials as the grant type within the last 14 days. Public client applications in Okta that leverage OAuth, client credentials can be used to retrieve access tokens without user consent. Unsecured credentials may be compromised by an adversary whom may use them to request an access token on behalf of the public client app.

- **UUID:** `11666aa0-71d9-11ef-a9be-f661ea17fbcc`
- **Integration:** [okta](https://docs.elastic.co/integrations/okta)
- **Language:** `[ES|QL]`
- **Source File:** [Rare Occurrence of OAuth Access Token Granted to Public Client App](../queries/defense_evasion_rare_oauth_access_token_granted_by_application.toml)

## Query

```sql
from logs-okta.system*
| where @timestamp > NOW() - 14 day
| where

    // filter for successful OAuth access token grant requests
    event.action == "app.oauth2.as.token.grant.access_token"
    and event.outcome == "success"
    and event.dataset == "okta.system"

    // filter for public client apps
    and okta.actor.type == "PublicClientApp"

    // ignore Elastic Okta integration and DataDog actors
    and not okta.client.user_agent.raw_user_agent == "Okta-Integrations"
    and not (okta.actor.display_name LIKE "Okta%" or okta.actor.display_name LIKE "Datadog%")

// count the number of access tokens granted by the same public client app
| stats token_granted_count = count(*) by okta.actor.display_name

// filter where the public client app has only been granted an access token once in the last 14 days
| where token_granted_count == 1
```

## Notes

- Review `okta.debug_context.debug_data.flattened.grantType` to identify if the grant type is `client_credentials`
- Ignore `okta.debug_context.debug_data.flattened.requestedScopes` values that indicate read-only access
- Review `okta.actor.display_name` to identify the public client app that attempted to retrieve the access token. This may help identify the compromised client credentials.
- False-positives may exist if the public client app is new or has not been used in the last 14 days.

## MITRE ATT&CK Techniques

- [T1550.001](https://attack.mitre.org/techniques/T1550/001)

## License

- `Elastic License v2`
Elastic SIEM Detection Rules: initial access password spraying from repeat source

# Password Spraying from Repeat Source

---

## Metadata

- **Author:** Elastic
- **Description:** This hunting query identifies password spraying attacks in Okta where the same source IP attempts to authenticate to multiple accounts with invalid credentials. Adversaries may attempt to use a single source IP to avoid detection and bypass account lockout policies.

- **UUID:** `1c2d2b08-71ee-11ef-952e-f661ea17fbcc`
- **Integration:** [okta](https://docs.elastic.co/integrations/okta)
- **Language:** `[ES|QL]`
- **Source File:** [Password Spraying from Repeat Source](../queries/initial_access_password_spraying_from_repeat_source.toml)

## Query

```sql
from logs-okta*
| where @timestamp > NOW() - 7 day

// truncate the timestamp to daily intervals
| eval target_time_window = DATE_TRUNC(1 days, @timestamp)
| where

// filter for invalid credential events
    event.action == "user.session.start"
    and okta.outcome.result == "FAILURE"
    and okta.outcome.reason == "INVALID_CREDENTIALS"
| stats
    // count the distinct number of targeted accounts
    target_count = count_distinct(okta.actor.alternate_id),

    // count the number of invalid credential events for each source IP
    source_count = count(*) by target_time_window, okta.client.ip

// filter for source IPs with more than 5 invalid credential events
| where target_count >= 10
```

## Notes

- `okta.actor.alternate_id` are the targeted accounts.
- Pivot for successful logins from the same source IP by searching for `event.action` equal to `user.session.start` or `user.authentication.verify` where the outcome is `SUCCESS`.
- User agents can be used to identify anomalous behavior, such as a user agent that is not associated with a known application or user.
- The `target_count` can be adjusted depending on the organization's account lockout policy or baselined behavior.

## MITRE ATT&CK Techniques

- [T1078.004](https://attack.mitre.org/techniques/T1078/004)

## License

- `Elastic License v2`
Elastic SIEM Detection Rules: defense evasion multiple client sources reported for oauth access tokens granted

# OAuth Access Token Granted for Public Client App from Multiple Client Addresses

---

## Metadata

- **Author:** Elastic
- **Description:** This hunting query identifies when a public client app successfully retrieves an OAuth access token using client credentials from multiple client addresses. For public client applications in Okta that leverage OAuth, client credentials can be used to retrieve access tokens without user consent. Unsecured credentials may be compromised by an adversary who may use them to request an access token on behalf of the public client app.

- **UUID:** `38d82c2c-71d9-11ef-a9be-f661ea17fbcc`
- **Integration:** [okta](https://docs.elastic.co/integrations/okta)
- **Language:** `[ES|QL]`
- **Source File:** [OAuth Access Token Granted for Public Client App from Multiple Client Addresses](../queries/defense_evasion_multiple_client_sources_reported_for_oauth_access_tokens_granted.toml)

## Query

```sql
from logs-okta.system*
| where @timestamp > NOW() - 21 day

// truncate the timestamp to 1 day
| eval target_time_window = DATE_TRUNC(1 days, @timestamp)
| where

    // filter for successful OAuth access token grant requests
    event.action == "app.oauth2.as.token.grant.access_token"
    and event.outcome == "success"
    and event.dataset == "okta.system"

    // filter for public client apps
    and okta.actor.type == "PublicClientApp"

    // ignore Elastic Okta integration and DataDog actors
    and not (okta.actor.display_name LIKE "Okta*" or okta.actor.display_name LIKE "Datadog*")

// count the number of access tokens granted by the same public client app in a day
| stats token_granted_count = count(*), unique_client_ip = count_distinct(okta.client.ip) by target_time_window, okta.actor.display_name

// filter where access tokens were granted on the same day but client addresses are different
| where unique_client_ip >= 2 and token_granted_count >= 2
```

## Notes

- Review `okta.debug_context.debug_data.flattened.grantType` to identify if the grant type is `client_credentials`
- Ignore `okta.debug_context.debug_data.flattened.requestedScopes` values that indicate read-only access
- Review `okta.actor.display_name` to identify the public client app that attempted to retrieve the access token. This may help identify the compromised client credentials.
- Filter on the public client app and aggregate by `event.action` to determine what actions were taken by the public client app after the access token was granted.

## MITRE ATT&CK Techniques

- [T1550.001](https://attack.mitre.org/techniques/T1550/001)

## License

- `Elastic License v2`
Elastic SIEM Detection Rules: defense evasion failed oauth access token retrieval via public client app

# Failed OAuth Access Token Retrieval via Public Client App

---

## Metadata

- **Author:** Elastic
- **Description:** This hunting query identifies when a public client app fails to retrieve an OAuth access token using client credentials because of an uauthorized scope. Adversaries may attempt to retrieve access tokens using client credentials to bypass user authentication and access resources. This query identifies when a public client app fails to retrieve an access token using client credentials and scopes that are not implicitly granted.

- **UUID:** `0b936024-71d9-11ef-a9be-f661ea17fbcc`
- **Integration:** [okta](https://docs.elastic.co/integrations/okta)
- **Language:** `[ES|QL]`
- **Source File:** [Failed OAuth Access Token Retrieval via Public Client App](../queries/defense_evasion_failed_oauth_access_token_retrieval_via_public_client_app.toml)

## Query

```sql
from logs-okta.system*
| where @timestamp > NOW() - 7 day
| where
    event.dataset == "okta.system"

    // filter on failed access token grant requests where source is a public client app
    and event.action == "app.oauth2.as.token.grant"
    and okta.actor.type == "PublicClientApp"
    and okta.outcome.result == "FAILURE"

    // filter out known Okta and Datadog actors
    and not (
        okta.actor.display_name LIKE "Okta%"
        or okta.actor.display_name LIKE "Datadog%"
    )

    // filter for scopes that are not implicitly granted
    and okta.outcome.reason == "no_matching_scope"

| keep @timestamp, event.action, okta.actor.type, okta.outcome.result, okta.outcome.reason, okta.actor.display_name
```

## Notes

- Review `okta.debug_context.debug_data.flattened.grantType` to identify if the grant type is `client_credentials`
- Ignore `okta.debug_context.debug_data.flattened.requestedScopes` values that indicate read-only access
- Review `okta.actor.display_name` to identify the public client app that attempted to retrieve the access token. This may help identify the compromised client credentials.
- Pivot for successful access token retrieval by the same public client app by searching `event.action` equal to `app.oauth2.as.token.grant.access_token` where the display name is the same.

## MITRE ATT&CK Techniques

- [T1550.001](https://attack.mitre.org/techniques/T1550/001)

## License

- `Elastic License v2`
Elastic SIEM Detection Rules: credential access rapid reset password requests for different users

# Rapid Reset Password Requests for Different Users

---

## Metadata

- **Author:** Elastic
- **Description:** This hunting query identifies rapid reset password requests for different users in Okta. Adversaries may attempt to reset passwords for multiple users in rapid succession to gain unauthorized access to accounts or disrupt operations. This query identifies when the source user is different from the target user in reset password events and filters for users with more than 15 reset password attempts.

- **UUID:** `c784106e-6ae8-11ef-919d-f661ea17fbcc`
- **Integration:** [okta](https://docs.elastic.co/integrations/okta)
- **Language:** `[ES|QL]`
- **Source File:** [Rapid Reset Password Requests for Different Users](../queries/credential_access_rapid_reset_password_requests_for_different_users.toml)

## Query

```sql
from logs-okta.system*
| where @timestamp > NOW() - 7 day

// Filter for reset password events where the source user is different from the target user
| where event.dataset == "okta.system" and event.action == "user.account.reset_password" and source.user.full_name != user.target.full_name

// Extract relevant fields
| keep @timestamp, okta.actor.alternate_id, okta.debug_context.debug_data.dt_hash, user.target.full_name, okta.outcome.result

// Count the number of reset password attempts for each user
| stats
    user_count = count_distinct(user.target.full_name),
    reset_counts = by okta.actor.alternate_id, source.user.full_name, okta.debug_context.debug_data.dt_hash

// Filter for more than 10 unique users and more than 15 reset password attempts by the source
| where user_count > 10 and reset_counts > 15
```

## Notes

- `okta.actor.alternate_id` is the potentially compromised account
- An API access token may have been compromised, where okta.actor.alternate_id reflects the owner
- To identify a list of tokens this user created, search for the `okta.actor.alternate_id` where `event.action` is `system.api_token*` which may require a larger time window

## MITRE ATT&CK Techniques

- [T1098.001](https://attack.mitre.org/techniques/T1098/001)

## License

- `Elastic License v2`
Elastic SIEM Detection Rules: persistence rare domain with user authentication

# Rare Occurrence of Domain with User Authentication Events

---

## Metadata

- **Author:** Elastic
- **Description:** This hunting query identifies rare occurrences of user authentication events for an Okta user whose registered user account email address has a domain that is not commonly seen in the organization. Adversaries may use compromised credentials or tokens to create a new user account with a domain that is not commonly seen in the organization because they do not have access to a valid email address within that domain.

- **UUID:** `f3bc68f4-71e9-11ef-952e-f661ea17fbcc`
- **Integration:** [okta](https://docs.elastic.co/integrations/okta)
- **Language:** `[ES|QL]`
- **Source File:** [Rare Occurrence of Domain with User Authentication Events](../queries/persistence_rare_domain_with_user_authentication.toml)

## Query

```sql
from logs-okta*
| where @timestamp > NOW() - 7 day
| where
    // Filter for user authentication events
    okta.actor.alternate_id is not null
    and event.action LIKE "user.authentication*"

// Extract the top-level domain (TLD) from the user's email address
| dissect okta.actor.alternate_id "%{}@%{tld}"

// Count the number of user authentication events for each TLD
| stats tld_auth_counts = count(*) by tld

// Filter for TLDs with less than or equal to 5 user authentication events
| where tld_auth_counts <= 5

// Sort the results by the number of user authentication events in ascending order
| sort tld_auth_counts asc
```

## Notes

- Pivot into potential compromised accounts by searching for the `okta.actor.alternate_id` in `okta.target` where `event.action` is `user.lifecycle.create`. This would identify when the user account was created. The `okta.actor.alternate_id` of this event will also be the potential compromised account.

## MITRE ATT&CK Techniques

- [T1078.004](https://attack.mitre.org/techniques/T1078/004)

## License

- `Elastic License v2`