IMPORTANT: No additional bug fixes or documentation updates will be released for this version. For the latest information, see the current release documentation.
« Attempts to Brute Force a Microsoft 365 User Account Authentication via Unusual PAM Grantor »
Elastic Docs ›Elastic Security Solution [8.14] ›Detections and alerts ›Prebuilt rule reference

Attempts to Brute Force an Okta User Account

edit

Attempts to Brute Force an Okta User Account

edit

Identifies when an Okta user account is locked out 3 times within a 3 hour window. An adversary may attempt a brute force or password spraying attack to obtain unauthorized access to user accounts. The default Okta authentication policy ensures that a user account is locked out after 10 failed authentication attempts.

Rule type: threshold

Rule indices:

  • filebeat-*
  • logs-okta*

Severity: medium

Risk score: 47

Runs every: 5m

Searches indices from: now-180m (Date Math format, see also Additional look-back time)

Maximum alerts per execution: 100

References:

Tags:

  • Use Case: Identity and Access Audit
  • Tactic: Credential Access
  • Data Source: Okta

Version: 312

Rule authors:

  • Elastic
  • @BenB196
  • Austin Songer

Rule license: Elastic License v2

Investigation guide

edit

Triage and analysis

Investigating Attempts to Brute Force an Okta User Account

Brute force attacks aim to guess user credentials through exhaustive trial-and-error attempts. In this context, Okta accounts are targeted.

This rule fires when an Okta user account has been locked out 3 times within a 3-hour window. This could indicate an attempted brute force or password spraying attack to gain unauthorized access to the user account. Okta’s default authentication policy locks a user account after 10 failed authentication attempts.

Possible investigation steps:

  • Identify the actor related to the alert by reviewing okta.actor.alternate_id field in the alert. This should give the username of the account being targeted.
  • Review the okta.event_type field to understand the nature of the events that led to the account lockout.
  • Check the okta.severity and okta.display_message fields for more context around the lockout events.
  • Look for correlation of events from the same IP address. Multiple lockouts from the same IP address might indicate a single source for the attack.
  • If the IP is not familiar, investigate it. The IP could be a proxy, VPN, Tor node, cloud datacenter, or a legitimate IP turned malicious.
  • Determine if the lockout events occurred during the user’s regular activity hours. Unusual timing may indicate malicious activity.
  • Examine the authentication methods used during the lockout events by checking the okta.authentication_context.credential_type field.

False positive analysis:

  • Determine whether the account owner or an internal user made repeated mistakes in entering their credentials, leading to the account lockout.
  • Ensure there are no known network or application issues that might cause these events.

Response and remediation:

  • Alert the user and your IT department immediately.
  • If unauthorized access is confirmed, initiate your incident response process.
  • Investigate the source of the attack. If a specific machine or network is compromised, additional steps may need to be taken to address the issue.
  • Require the affected user to change their password.
  • If the attack is ongoing, consider blocking the IP address initiating the brute force attack.
  • Implement account lockout policies to limit the impact of brute force attacks.
  • Encourage users to use complex, unique passwords and consider implementing multi-factor authentication.
  • Check if the compromised account was used to access or alter any sensitive data or systems.

Setup

edit

The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.

Rule query

edit
event.dataset:okta.system and event.action:user.account.lock

Framework: MITRE ATT&CKTM

« Attempts to Brute Force a Microsoft 365 User Account Authentication via Unusual PAM Grantor »