Okta Identity Cloud — CraftedSignal Threat Feed

Okta Policy Modification or Deletion Detected

hello@craftedsignal.io — Wed, 03 Jan 2024 12:00:00 +0000

This alert identifies modifications or deletions of Okta policies, which govern authentication, authorization, and access control within the Okta Identity Cloud platform. While legitimate administrators routinely update policies, unauthorized changes can weaken security postures and grant malicious actors elevated privileges or bypass security controls. The source event indicates a potential compromise or insider threat activity within the Okta environment. Because Okta serves as a critical identity provider for many organizations, any unauthorized change to its policies can have far-reaching consequences. Detecting policy changes is crucial for maintaining the integrity and security of the Okta environment and preventing potential breaches. The targeted scope includes all Okta-managed applications and resources protected by the modified or deleted policy.

Attack Chain

Initial Access: The attacker gains access to an Okta administrator account, either through compromised credentials (e.g., phishing, credential stuffing) or insider access.
Authentication: The attacker authenticates to the Okta admin console using the compromised or legitimate administrator account.
Policy Enumeration: The attacker identifies target Okta policies to modify or delete using the Okta admin console or API.
Policy Modification/Deletion: The attacker modifies or deletes the targeted Okta policy through the Okta admin console or API. This generates an policy.lifecycle.update or policy.lifecycle.delete event.
Privilege Escalation (Potential): By modifying policies, the attacker may escalate privileges, granting themselves or other unauthorized users access to sensitive applications and resources.
Lateral Movement (Potential): With escalated privileges, the attacker moves laterally within the Okta environment, accessing other applications and resources.
Data Exfiltration/Damage (Potential): The attacker leverages the compromised Okta environment to exfiltrate sensitive data or cause damage to connected systems.

Impact

A successful Okta policy modification or deletion can have significant consequences. Unauthorized policy changes can weaken security controls, allowing attackers to bypass authentication mechanisms, escalate privileges, and gain unauthorized access to sensitive applications and data. This could lead to data breaches, financial loss, and reputational damage. The impact depends on the scope of the affected policy and the applications it protects. The number of victims could range from a few individuals to the entire organization, depending on the scope of the compromised policy.

Recommendation

Deploy the provided Sigma rule to your SIEM to detect Okta policy modifications or deletions (policy.lifecycle.update, policy.lifecycle.delete event types).
Investigate any detected policy changes to verify their legitimacy and identify the user responsible.
Review Okta administrator account activity for any signs of compromise or unauthorized access.
Implement multi-factor authentication (MFA) for all Okta administrator accounts to prevent unauthorized access.
Regularly review and audit Okta policies to ensure they are configured securely and in accordance with security best practices.

Okta MFA Reset or Deactivation Attempt

hello@craftedsignal.io — Wed, 03 Jan 2024 12:00:00 +0000

Attackers may attempt to disable or reset MFA to bypass security controls and gain unauthorized access to user accounts. This activity is often part of a broader attack campaign, such as credential stuffing or account takeover. The Okta platform provides detailed logs of user authentication events, including MFA resets and deactivations. Monitoring these events is crucial for detecting and responding to potential account compromise attempts. These attempts can originate from various sources, including compromised administrator accounts or direct attacks on user accounts. The impact of successful MFA bypass can be significant, potentially leading to data breaches, financial loss, and reputational damage.

Attack Chain

The attacker gains initial access to a user’s Okta account, possibly through phishing or credential compromise.
The attacker authenticates to the Okta tenant using the compromised credentials.
The attacker initiates a request to reset or deactivate one or more of the user’s MFA factors through the Okta API or web interface.
Okta generates a system log event of type user.mfa.factor.deactivate or user.mfa.factor.reset_all.
If successful, the attacker can then authenticate without providing the MFA factor, bypassing a critical security control.
The attacker leverages the compromised account to access sensitive applications and data within the Okta environment.
The attacker may perform lateral movement to access other user accounts or systems.
The final objective may include data exfiltration, financial fraud, or other malicious activities.

Impact

Successful MFA deactivation or reset can lead to complete account takeover. Depending on the compromised user’s role and access permissions, this could result in significant data breaches, unauthorized access to sensitive systems, and financial losses. The impact scales with the number of compromised accounts and the sensitivity of the data they can access. This activity targets all sectors relying on Okta for identity and access management.

Recommendation

Deploy the provided Sigma rules to your SIEM to detect suspicious MFA reset or deactivation attempts in Okta logs.
Investigate any triggered alerts for user.mfa.factor.deactivate or user.mfa.factor.reset_all events, as described in the Sigma rule.
Review Okta system logs for unusual authentication patterns, focusing on users with recently deactivated MFA factors, as detailed in the Okta API documentation.
Implement strict access controls and monitoring for Okta administrator accounts to prevent unauthorized MFA modifications.
Educate users about phishing and credential security to reduce the risk of initial access compromise.

Okta API Token Creation

hello@craftedsignal.io — Wed, 03 Jan 2024 12:00:00 +0000

The creation of Okta API tokens is a legitimate administrative function, but can also be abused by malicious actors to establish persistence within an Okta environment. Monitoring for the creation of these tokens, especially when performed by unexpected users or under unusual circumstances, is crucial for identifying potential security breaches. Okta API tokens allow for programmatic access to Okta resources, making them a valuable asset for attackers seeking to maintain access or perform unauthorized actions. Defenders should prioritize monitoring for these events to quickly identify and respond to potentially malicious activity.

Attack Chain

An attacker gains unauthorized access to an Okta account with sufficient privileges (e.g., Super Administrator).
The attacker authenticates to the Okta Admin Console.
The attacker navigates to the Security > API > Tokens section of the Okta Admin Console.
The attacker creates a new API token with broad or specific permissions.
Okta logs the system.api_token.create event.
The attacker uses the newly created API token to programmatically access Okta resources.
The attacker may leverage the API token for various malicious activities, such as user enumeration, group manipulation, or application access.
The attacker maintains persistent access to the Okta environment even if their initial access is revoked.

Impact

Successful exploitation can lead to unauthorized access to sensitive data, modification of user accounts and permissions, and potentially complete control over the Okta environment. The impact can range from data breaches and service disruptions to complete compromise of identity management. The number of victims and sectors targeted depends on the scope of the compromised Okta environment.

Recommendation

Deploy the Sigma rule “Okta API Token Created” to your SIEM to detect API token creation events (logsource: okta, service: okta).
Investigate any detected system.api_token.create events to verify the legitimacy of the token creation.
Review Okta system logs for unusual administrative activity preceding the API token creation event (logsource: okta, service: okta).
Implement multi-factor authentication (MFA) for all Okta administrator accounts to reduce the risk of unauthorized access.