{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata — refreshed continuously.","feed_url":"https://feed.craftedsignal.io/tags/okta/","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["low"],"_cs_tags":["privileged-access","okta","user-lifecycle"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis alert detects potential privileged access activity within an Okta environment. The detection is triggered by a machine learning job that identifies anomalous spikes in user lifecycle management change events. Threat actors may target user accounts to escalate their privileges or to establish persistence within the environment. This is achieved by manipulating user accounts, such as modifying roles, permissions, or other attributes. The prebuilt ML job \u0026ldquo;pad_okta_spike_in_user_lifecycle_management_changes_ea\u0026rdquo; is used to detect these anomalies. The rule requires the Privileged Access Detection integration assets to be installed, as well as Okta logs collected by integrations such as Okta. The rule looks for activity within a 3-hour window, checking every 15 minutes.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to an Okta account, possibly through compromised credentials or other means. (T1078)\u003c/li\u003e\n\u003cli\u003eThe attacker begins enumerating user accounts and their associated roles and permissions within the Okta environment.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies a target user account with elevated privileges or a role that would grant them desired access.\u003c/li\u003e\n\u003cli\u003eThe attacker modifies the target user account\u0026rsquo;s attributes, such as adding the attacker\u0026rsquo;s account to a privileged group or changing the user\u0026rsquo;s role. (T1098)\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the newly acquired privileges to access sensitive resources or perform unauthorized actions.\u003c/li\u003e\n\u003cli\u003eThe attacker may create new user accounts with elevated privileges to maintain persistent access to the environment. (T1098)\u003c/li\u003e\n\u003cli\u003eThe attacker covers their tracks by deleting logs or modifying audit trails to conceal their activity.\u003c/li\u003e\n\u003cli\u003eThe attacker achieves their objective, such as data exfiltration or system compromise.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful attack can result in privilege escalation, allowing unauthorized access to sensitive data and systems. Depending on the level of access gained, attackers may be able to compromise critical infrastructure, steal confidential information, or disrupt business operations. The impact can range from minor data breaches to significant financial losses and reputational damage. Early detection of anomalous user lifecycle changes is crucial to mitigating these risks.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnsure the Privileged Access Detection integration is installed and properly configured, including the preconfigured anomaly detection job \u0026ldquo;pad_okta_spike_in_user_lifecycle_management_changes_ea\u0026rdquo;.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by this rule by following the investigation steps outlined in the rule\u0026rsquo;s note section within the Kibana UI.\u003c/li\u003e\n\u003cli\u003eReview and update access management policies and procedures to prevent similar incidents in the future, ensuring that changes to user accounts are logged and regularly reviewed as described in the rule\u0026rsquo;s documentation.\u003c/li\u003e\n\u003cli\u003eMonitor Okta logs for any unusual or unauthorized activity, focusing on user account changes, as described in the setup documentation.\u003c/li\u003e\n\u003cli\u003eImplement additional monitoring on the affected accounts and related systems to detect any further suspicious activity or attempts to regain unauthorized access as mentioned in the response and remediation guidelines.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-11-02T12:00:00Z","date_published":"2024-11-02T12:00:00Z","id":"/briefs/2024-11-okta-user-lifecycle-spike/","summary":"A machine learning job has identified an unusual spike in Okta user lifecycle management change events, indicating potential privileged access activity where threat actors may manipulate user accounts to gain higher access rights or persist within the environment.","title":"Unusual Spike in Okta User Lifecycle Management Change Events","url":"https://feed.craftedsignal.io/briefs/2024-11-okta-user-lifecycle-spike/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Okta Identity Engine"],"_cs_severities":["high"],"_cs_tags":["okta","identity","privilege-escalation","persistence","defense-evasion","initial-access"],"_cs_type":"advisory","_cs_vendors":["Okta"],"content_html":"\u003cp\u003eThis threat brief focuses on detecting unusual behaviors within the Okta Admin Console, as identified by Okta\u0026rsquo;s heuristics. While the specific campaign details are unknown, identifying anomalous access patterns to the Admin Console is crucial for detecting various malicious activities. This includes potential privilege escalation by compromised accounts or insider threats attempting to gain elevated permissions, establishing persistence through unauthorized modifications, evading existing security controls, or gaining initial access through account compromise. The detection relies on Okta\u0026rsquo;s system logs which can signal unusual administrative activity. Defenders should prioritize monitoring and alerting on these events to quickly identify and respond to potential security breaches.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to an Okta account, possibly through credential phishing or brute-force attacks.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to log in to the Okta Admin Console.\u003c/li\u003e\n\u003cli\u003eOkta\u0026rsquo;s behavior detection engine analyzes the login attempt, considering factors like the user\u0026rsquo;s location, device, and time of day.\u003c/li\u003e\n\u003cli\u003eThe system logs record a \u003ccode\u003epolicy.evaluate_sign_on\u003c/code\u003e event when a sign-on policy is evaluated.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003etarget.displayName\u003c/code\u003e field within the log specifies \u0026ldquo;Okta Admin Console\u0026rdquo; indicating the user is attempting to access the administrative interface.\u003c/li\u003e\n\u003cli\u003eIf Okta identifies the behavior as unusual, the \u003ccode\u003edebugContext.debugData.behaviors\u003c/code\u003e or \u003ccode\u003edebugContext.debugData.logOnlySecurityData\u003c/code\u003e fields will contain \u0026ldquo;POSITIVE\u0026rdquo;.\u003c/li\u003e\n\u003cli\u003eAn alert is triggered based on the identified unusual behavior.\u003c/li\u003e\n\u003cli\u003eThe attacker, if successful in bypassing initial checks, may proceed to create new admin accounts, modify existing policies, or exfiltrate sensitive data.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eCompromise of the Okta Admin Console can lead to significant damage, including unauthorized access to sensitive data, modification of security policies, creation of rogue administrator accounts, and ultimately, a complete takeover of the Okta environment. This can impact all applications and services integrated with Okta, potentially affecting thousands of users and causing significant financial and reputational damage. Early detection is crucial to limiting the scope and impact of such attacks.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule \u003ccode\u003eOkta Admin Console Unusual Behavior\u003c/code\u003e to your SIEM to detect suspicious Okta Admin Console access based on Okta\u0026rsquo;s internal behavior analysis.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule to determine if the unusual behavior is legitimate or indicative of malicious activity.\u003c/li\u003e\n\u003cli\u003eReview Okta\u0026rsquo;s System Log API documentation to understand the various event types and data fields available for monitoring and detection.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all Okta accounts, especially administrator accounts, to mitigate the risk of account compromise (related to initial access).\u003c/li\u003e\n\u003cli\u003eMonitor Okta\u0026rsquo;s security advisories and announcements for updates on emerging threats and recommended security practices (references).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-05-02T10:00:00Z","date_published":"2024-05-02T10:00:00Z","id":"/briefs/2024-05-okta-admin-console-behaviors/","summary":"This brief details detection of anomalous activity within the Okta Admin Console, potentially indicating privilege escalation, persistence, defense evasion, or initial access attempts by malicious actors.","title":"Okta Admin Console Unusual Behavior Detection","url":"https://feed.craftedsignal.io/briefs/2024-05-okta-admin-console-behaviors/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Okta Identity Engine"],"_cs_severities":["high"],"_cs_tags":["attack.credential-access","attack.t1552","okta","password-leak"],"_cs_type":"advisory","_cs_vendors":["Okta"],"content_html":"\u003cp\u003eOkta, a leading identity and access management provider, retains login attempt data in its system logs. This data can be valuable for security monitoring and incident response. However, a misconfiguration or user error can lead to sensitive information, such as passwords, being inadvertently captured within these logs. Specifically, if a user mistakenly enters their password in the username field (referred to as \u0026lsquo;alternateId\u0026rsquo; in Okta logs) during a failed login attempt, the password may be stored in plain text within the log entry. This exposes the password to anyone with access to Okta system logs. This issue was highlighted in a Mitiga blog post, underscoring the risk to user data. Defenders must implement measures to detect and prevent such occurrences to maintain the confidentiality of user credentials and the overall security posture.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eUser attempts to log in to an Okta-protected application.\u003c/li\u003e\n\u003cli\u003eThe user mistakenly enters their password in the username (alternateId) field.\u003c/li\u003e\n\u003cli\u003eThe Okta authentication process fails due to incorrect credentials.\u003c/li\u003e\n\u003cli\u003eOkta logs the failed login attempt, including the \u0026lsquo;core.user_auth.login_failed\u0026rsquo; event.\u003c/li\u003e\n\u003cli\u003eThe password, entered in the alternateId field, is recorded in the Okta system log.\u003c/li\u003e\n\u003cli\u003eAn attacker gains unauthorized access to Okta system logs, potentially through compromised credentials or a misconfigured integration.\u003c/li\u003e\n\u003cli\u003eThe attacker searches for \u0026lsquo;core.user_auth.login_failed\u0026rsquo; events and examines the \u0026lsquo;actor.alternateId\u0026rsquo; field.\u003c/li\u003e\n\u003cli\u003eThe attacker discovers exposed passwords within the \u0026lsquo;actor.alternateId\u0026rsquo; field, potentially enabling account takeover or further lateral movement.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful attack exploiting this vulnerability could lead to widespread credential compromise. The number of potentially affected users depends on how frequently users make this mistake and the duration for which logs are retained. Sectors heavily reliant on Okta for authentication, such as technology, finance, and healthcare, are particularly at risk. If passwords are leaked, attackers can gain unauthorized access to sensitive data, applications, and systems, leading to data breaches, financial loss, and reputational damage.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule \u0026ldquo;Okta Password Entered in AlternateID Field\u0026rdquo; to your SIEM to detect instances of passwords potentially being logged in the \u003ccode\u003eactor.alternateId\u003c/code\u003e field.\u003c/li\u003e\n\u003cli\u003eReview and adjust the regular expression in the Sigma rule\u0026rsquo;s \u003ccode\u003efilter_main\u003c/code\u003e section to align with the specific character restrictions in your Okta username configuration.\u003c/li\u003e\n\u003cli\u003eImplement stricter input validation on Okta login pages to prevent users from entering passwords in the username field.\u003c/li\u003e\n\u003cli\u003eRegularly audit Okta system logs for sensitive information and enforce least privilege access to log data.\u003c/li\u003e\n\u003cli\u003eEducate users about the proper use of login forms to reduce the likelihood of entering passwords in the username field.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) to mitigate the impact of compromised passwords, as referenced in security best practices.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-02-29T12:00:00Z","date_published":"2024-02-29T12:00:00Z","id":"/briefs/2024-02-okta-password-alternateid/","summary":"Okta logs may contain user passwords if a user mistakenly enters their password into the username field during login, potentially exposing credentials in logs.","title":"Okta Password Entered in AlternateID Field","url":"https://feed.craftedsignal.io/briefs/2024-02-okta-password-alternateid/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["medium"],"_cs_tags":["okta","identity","policy","attack.impact"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eOkta is a widely used identity and access management platform. Threat actors may target Okta configurations to weaken an organization\u0026rsquo;s security posture. This activity involves modifications or deletions of policy rules within Okta. Such changes can reduce the effectiveness of multi-factor authentication (MFA) requirements, bypass access controls, or disable security logging. Detection of these changes is crucial to maintaining a strong security baseline and preventing unauthorized access to sensitive resources. Defenders should monitor Okta logs for unexpected or unauthorized policy rule modifications or deletions.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eInitial Access: The attacker gains unauthorized access to an Okta administrator account, possibly through credential theft or phishing.\u003c/li\u003e\n\u003cli\u003eAuthentication: The attacker authenticates to the Okta admin dashboard using the compromised credentials.\u003c/li\u003e\n\u003cli\u003eDiscovery: The attacker enumerates existing policy rules to understand the current security configuration.\u003c/li\u003e\n\u003cli\u003eModification: The attacker modifies an existing policy rule to weaken its security controls. This could involve disabling MFA, bypassing location restrictions, or altering group membership requirements.\u003c/li\u003e\n\u003cli\u003eDeletion: Alternatively, the attacker deletes a policy rule entirely, effectively removing a layer of security.\u003c/li\u003e\n\u003cli\u003ePrivilege Escalation: With weakened or removed policy rules, the attacker escalates privileges, gaining access to sensitive applications or data.\u003c/li\u003e\n\u003cli\u003eLateral Movement: The attacker leverages the compromised Okta environment to move laterally within the organization\u0026rsquo;s network, accessing additional systems and resources.\u003c/li\u003e\n\u003cli\u003eImpact: The attacker achieves their final objective, such as data exfiltration, financial fraud, or system disruption, due to the weakened security posture.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful modification or deletion of Okta policy rules can severely compromise an organization\u0026rsquo;s security. Consequences include unauthorized access to sensitive data, privilege escalation, lateral movement, and ultimately, data breaches or financial loss. The number of affected users and systems depends on the scope of the compromised policy rules and the attacker\u0026rsquo;s subsequent actions. Organizations in all sectors that rely on Okta for identity management are vulnerable.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the \u0026ldquo;Okta Policy Rule Modified or Deleted\u0026rdquo; Sigma rule to your SIEM to detect unauthorized changes (rule reference).\u003c/li\u003e\n\u003cli\u003eReview Okta system logs regularly for policy rule modifications or deletions, focusing on unusual source IPs or user agents.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all Okta administrator accounts to prevent unauthorized access (reference: Okta documentation).\u003c/li\u003e\n\u003cli\u003eEnforce the principle of least privilege for Okta administrator roles, limiting the number of users who can modify policy rules.\u003c/li\u003e\n\u003cli\u003eAlert on eventType \u003ccode\u003epolicy.rule.update\u003c/code\u003e or \u003ccode\u003epolicy.rule.delete\u003c/code\u003e in Okta logs using the provided Sigma rule (rule reference).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-29T12:00:00Z","date_published":"2024-01-29T12:00:00Z","id":"/briefs/2024-01-29-okta-policy-rule-modification/","summary":"An Okta policy rule was modified or deleted, potentially weakening security controls.","title":"Okta Policy Rule Modification or Deletion","url":"https://feed.craftedsignal.io/briefs/2024-01-29-okta-policy-rule-modification/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Okta Identity Engine"],"_cs_severities":["medium"],"_cs_tags":["okta","network-zone","impact"],"_cs_type":"advisory","_cs_vendors":["Okta"],"content_html":"\u003cp\u003eOkta network zones define trusted network boundaries for user access. These zones are configured with specific IP address ranges and can be used to restrict access to applications and resources. When an Okta network zone is deactivated or deleted, it can indicate a malicious actor attempting to weaken security policies, potentially allowing unauthorized access from untrusted locations. This activity is relevant for defenders because it may signal a breach in progress or preparation for future attacks. Compromised administrator accounts are often used to make unauthorized configuration changes in SaaS platforms. This alert focuses on activity within the Okta platform itself.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains unauthorized access to an Okta administrator account, potentially through credential theft or phishing.\u003c/li\u003e\n\u003cli\u003eThe attacker authenticates to the Okta administrative console.\u003c/li\u003e\n\u003cli\u003eThe attacker navigates to the network zone configuration within the Okta admin console.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies a target network zone that restricts access to critical resources.\u003c/li\u003e\n\u003cli\u003eThe attacker deactivates the target network zone, effectively disabling its restrictions. Alternatively, the attacker deletes the network zone.\u003c/li\u003e\n\u003cli\u003eThe attacker may modify other security settings, such as MFA policies, to further weaken the security posture.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the relaxed network restrictions to access sensitive applications or data from previously unauthorized locations.\u003c/li\u003e\n\u003cli\u003eThe attacker performs malicious actions, such as data exfiltration or lateral movement, using the compromised Okta session.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eThe deactivation or deletion of an Okta network zone can have serious consequences. It can lead to unauthorized access to sensitive applications and data, potentially resulting in data breaches, financial loss, and reputational damage. The impact is especially high if the affected network zone was protecting critical infrastructure or sensitive customer data. Depending on the scope of access granted, a single deactivated zone could expose data belonging to thousands of users.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the \u0026ldquo;Okta Network Zone Deactivated or Deleted\u0026rdquo; Sigma rule to your SIEM to detect this activity (logsource: okta, service: okta, eventType: zone.deactivate/zone.delete).\u003c/li\u003e\n\u003cli\u003eInvestigate any detected instances of network zone deactivation or deletion to determine if they were authorized changes.\u003c/li\u003e\n\u003cli\u003eReview Okta administrator account activity for signs of compromise, such as login attempts from unusual locations.\u003c/li\u003e\n\u003cli\u003eEnforce multi-factor authentication (MFA) for all Okta administrator accounts to prevent unauthorized access.\u003c/li\u003e\n\u003cli\u003eMonitor the Okta system logs for other suspicious configuration changes, such as modifications to MFA policies or application assignments.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-26T18:22:00Z","date_published":"2024-01-26T18:22:00Z","id":"/briefs/2024-01-26-okta-network-zone-changes/","summary":"An Okta network zone was deactivated or deleted, potentially indicating malicious activity aimed at bypassing security controls.","title":"Okta Network Zone Deactivation or Deletion","url":"https://feed.craftedsignal.io/briefs/2024-01-26-okta-network-zone-changes/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Okta"],"_cs_severities":["medium"],"_cs_tags":["identityprovider","okta","persistence"],"_cs_type":"advisory","_cs_vendors":["Okta"],"content_html":"\u003cp\u003eThe creation of a new identity provider (IdP) in Okta is a sensitive action that should be closely monitored. While legitimate administrators may create IdPs for federation purposes, adversaries can abuse this functionality to establish persistence or escalate privileges within an Okta environment. This involves creating a malicious IdP that they control and configuring it to authenticate users, potentially bypassing existing security controls such as multi-factor authentication (MFA) or implementing cross-tenant impersonation. The creation of a rogue IdP within Okta can be an indicator of compromise, potentially leading to unauthorized access to applications and data protected by Okta. Defenders should monitor Okta system logs for the creation of new identity providers and validate their legitimacy.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to an Okta tenant with sufficient administrative privileges, either through compromised credentials or by exploiting a vulnerability.\u003c/li\u003e\n\u003cli\u003eThe attacker navigates to the Okta admin console.\u003c/li\u003e\n\u003cli\u003eThe attacker creates a new identity provider (IdP) within the Okta tenant (system.idp.lifecycle.create).\u003c/li\u003e\n\u003cli\u003eThe attacker configures the rogue IdP with attacker-controlled settings, such as SAML endpoints or OIDC configurations, potentially pointing to an attacker-controlled server.\u003c/li\u003e\n\u003cli\u003eThe attacker configures routing rules within Okta to direct specific users or groups to authenticate through the newly created, malicious IdP.\u003c/li\u003e\n\u003cli\u003eUsers attempting to access Okta-protected applications are redirected to the attacker-controlled IdP for authentication.\u003c/li\u003e\n\u003cli\u003eThe attacker\u0026rsquo;s IdP captures user credentials or issues fraudulent authentication tokens, allowing the attacker to impersonate legitimate users.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the stolen credentials or fraudulent tokens to access sensitive applications and data protected by Okta, achieving their objective of data theft or service disruption.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful attack involving the creation of a rogue Okta identity provider can lead to significant consequences. Attackers can gain persistent access to the Okta environment, bypass multi-factor authentication, and impersonate legitimate users. This can result in unauthorized access to sensitive applications and data, data breaches, financial loss, and reputational damage. The scope of the impact depends on the privileges of the compromised accounts and the sensitivity of the data accessed.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Okta Identity Provider Created\u0026rdquo; to your SIEM to detect the creation of new identity providers and tune it for your environment.\u003c/li\u003e\n\u003cli\u003eRegularly review and validate all configured identity providers within your Okta tenant to ensure their legitimacy.\u003c/li\u003e\n\u003cli\u003eImplement strong access controls and multi-factor authentication for all Okta administrative accounts to prevent unauthorized creation of identity providers.\u003c/li\u003e\n\u003cli\u003eMonitor Okta system logs for suspicious activity related to identity provider configuration and authentication.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts triggered by the \u0026ldquo;Okta Identity Provider Created\u0026rdquo; Sigma rule to determine the legitimacy of the IdP creation event.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-25T12:00:00Z","date_published":"2024-01-25T12:00:00Z","id":"/briefs/2024-01-okta-idp-created/","summary":"An adversary may create a rogue identity provider within Okta to establish persistence and potentially escalate privileges by impersonating legitimate users or bypassing multi-factor authentication.","title":"Okta Identity Provider Creation Detected","url":"https://feed.craftedsignal.io/briefs/2024-01-okta-idp-created/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Okta"],"_cs_severities":["low"],"_cs_tags":["okta","identity","user-creation","credential-access"],"_cs_type":"advisory","_cs_vendors":["Okta"],"content_html":"\u003cp\u003eThis alert detects the creation of new user accounts within an Okta environment. While legitimate user creation is common, malicious actors may create accounts to gain unauthorized access to resources, escalate privileges, or establish persistence within the network. Monitoring for anomalous user creation activity, such as accounts created outside of normal business hours or with suspicious naming conventions, is crucial for identifying potential security breaches. Reviewing the source IP and administrator account used for the user creation can also provide valuable context.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to an Okta administrator account, potentially through phishing, credential stuffing, or exploiting a vulnerability.\u003c/li\u003e\n\u003cli\u003eThe attacker authenticates to the Okta admin portal.\u003c/li\u003e\n\u003cli\u003eThe attacker navigates to the user management section within the Okta admin console.\u003c/li\u003e\n\u003cli\u003eThe attacker creates a new user account, potentially mimicking an existing user or using a generic naming convention.\u003c/li\u003e\n\u003cli\u003eThe attacker assigns the new user account specific roles and permissions, potentially granting elevated privileges.\u003c/li\u003e\n\u003cli\u003eThe attacker may use the newly created account to access sensitive applications and data within the Okta-protected environment.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the compromised or newly created account to maintain persistence within the Okta environment.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful attack leading to unauthorized user creation can result in significant data breaches, privilege escalation, and unauthorized access to sensitive applications and resources. This could lead to financial loss, reputational damage, and compliance violations. The impact depends on the permissions granted to the created user and the applications they can access.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;New Okta User Created\u0026rdquo; to your SIEM to detect user creation events and tune for your environment.\u003c/li\u003e\n\u003cli\u003eInvestigate any detected user creation events for legitimacy, focusing on the source IP address and the administrator account used.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all Okta administrator accounts to mitigate the risk of credential compromise.\u003c/li\u003e\n\u003cli\u003eReview Okta event logs regularly for suspicious activity, including user creation, permission changes, and application access.\u003c/li\u003e\n\u003cli\u003eEstablish baseline user creation patterns to identify anomalous behavior, such as accounts created outside of normal business hours.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-23T12:00:00Z","date_published":"2024-01-23T12:00:00Z","id":"/briefs/2024-01-23-okta-user-created/","summary":"Detection of new user account creation in Okta, which could indicate malicious activity related to credential access.","title":"Okta User Account Created","url":"https://feed.craftedsignal.io/briefs/2024-01-23-okta-user-created/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Okta"],"_cs_severities":["medium"],"_cs_tags":["identity","okta","threat-detection","attack.command-and-control"],"_cs_type":"advisory","_cs_vendors":["Okta"],"content_html":"\u003cp\u003eThis alert focuses on identifying security threats detected by Okta\u0026rsquo;s ThreatInsight. Okta ThreatInsight analyzes traffic patterns and user behavior to identify and block malicious login attempts, brute-force attacks, and other suspicious activities. When ThreatInsight identifies a security threat, it generates a system log event with the eventType \u003ccode\u003esecurity.threat.detected\u003c/code\u003e. This event serves as a high-level indicator of potential command and control activity within the Okta environment. Defenders should investigate these alerts promptly to determine the nature and scope of the threat and take appropriate remediation steps. This detection leverages Okta system logs and is relevant for organizations using Okta as their identity provider.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker attempts to gain unauthorized access to an Okta account, possibly through credential stuffing or brute-force attacks.\u003c/li\u003e\n\u003cli\u003eOkta\u0026rsquo;s ThreatInsight analyzes the login attempt, evaluating factors such as IP address reputation, geographical location, and login frequency.\u003c/li\u003e\n\u003cli\u003eThreatInsight identifies the login attempt as a security threat based on predefined risk factors.\u003c/li\u003e\n\u003cli\u003eOkta generates a system log event with eventType \u003ccode\u003esecurity.threat.detected\u003c/code\u003e, recording details of the suspicious activity.\u003c/li\u003e\n\u003cli\u003eThe security team receives an alert based on the Sigma rule detecting the \u003ccode\u003esecurity.threat.detected\u003c/code\u003e event.\u003c/li\u003e\n\u003cli\u003eThe security team investigates the alert, examining the associated IP address, user account, and other relevant log data.\u003c/li\u003e\n\u003cli\u003eBased on the investigation, the security team takes appropriate remediation steps, such as blocking the IP address, resetting the user\u0026rsquo;s password, or enabling multi-factor authentication.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful attack targeting Okta could lead to unauthorized access to sensitive data, account takeover, and disruption of services. The impact of such an attack depends on the level of access granted to the compromised account and the sensitivity of the data accessible through Okta. Successful exploitation can lead to lateral movement within an organization\u0026rsquo;s cloud infrastructure and potentially compromise other critical systems.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule to your SIEM to detect \u003ccode\u003esecurity.threat.detected\u003c/code\u003e events in Okta system logs.\u003c/li\u003e\n\u003cli\u003eInvestigate all triggered alerts to determine the nature and scope of the threat.\u003c/li\u003e\n\u003cli\u003eReview Okta\u0026rsquo;s ThreatInsight configuration to ensure it is properly configured and tuned for your environment (references: Okta ThreatInsight documentation).\u003c/li\u003e\n\u003cli\u003eMonitor Okta system logs for suspicious activity, such as unusual login patterns, account lockouts, and password resets (references: Okta system log documentation).\u003c/li\u003e\n\u003cli\u003eEnforce strong password policies and multi-factor authentication to reduce the risk of unauthorized access.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-23T12:00:00Z","date_published":"2024-01-23T12:00:00Z","id":"/briefs/2024-01-okta-security-threat/","summary":"This alert detects when Okta's ThreatInsight identifies a security threat within an Okta environment, potentially indicating command and control activity.","title":"Okta Security Threat Detected","url":"https://feed.craftedsignal.io/briefs/2024-01-okta-security-threat/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Okta"],"_cs_severities":["medium"],"_cs_tags":["identity","okta","privilege-escalation","persistence"],"_cs_type":"advisory","_cs_vendors":["Okta"],"content_html":"\u003cp\u003eOkta is a widely used identity and access management (IAM) platform, making it a prime target for malicious actors seeking to gain unauthorized access to sensitive resources. This threat focuses on the creation of new admin role assignments within Okta. An attacker who successfully compromises an Okta account with sufficient privileges, or bypasses security controls, may attempt to escalate their privileges or establish persistence by creating new admin role assignments for themselves or other accounts they control. This activity can go unnoticed if not actively monitored, granting the attacker extended access and control over the Okta environment and connected applications. Monitoring for anomalous admin role assignments is crucial for early detection and prevention of potential breaches.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eInitial Access:\u003c/strong\u003e Attacker gains unauthorized access to an Okta account, possibly through credential phishing, brute-force attacks, or exploitation of vulnerabilities.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePrivilege Check:\u003c/strong\u003e The attacker verifies the privileges of the compromised account to determine if it has sufficient permissions to create new admin role assignments.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAccount Impersonation:\u003c/strong\u003e The attacker uses the compromised account to access the Okta admin dashboard.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eRole Assignment Creation:\u003c/strong\u003e The attacker navigates to the role assignment section and initiates the creation of a new admin role assignment.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eConfiguration:\u003c/strong\u003e The attacker specifies the target user or group for the new admin role assignment.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAudit Logging:\u003c/strong\u003e Okta logs the event \u0026lsquo;iam.resourceset.bindings.add\u0026rsquo; indicating the creation of a new admin role assignment.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePersistence:\u003c/strong\u003e The attacker uses the newly created admin role assignment to maintain persistent access to the Okta environment even if the initial compromised account is detected and remediated.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation could lead to complete control over the Okta environment, affecting all connected applications and services. An attacker with admin privileges can modify user accounts, reset passwords, access sensitive data, and potentially compromise the entire organization. The number of affected users and systems depends on the scope of the Okta deployment, but the impact can be significant, potentially affecting thousands of users and critical business operations.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eOkta Admin Role Assignment Created\u003c/code\u003e to your SIEM and tune it for your environment to detect suspicious admin role creation activity in Okta logs.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the \u003ccode\u003eOkta Admin Role Assignment Created\u003c/code\u003e rule to determine if the role assignment was legitimate and authorized.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all Okta accounts, especially those with administrative privileges, to mitigate the risk of credential compromise.\u003c/li\u003e\n\u003cli\u003eRegularly review and audit Okta admin role assignments to identify and remove any unnecessary or unauthorized privileges.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-23T12:00:00Z","date_published":"2024-01-23T12:00:00Z","id":"/briefs/2024-01-okta-admin-role/","summary":"Detection of new admin role assignments in Okta, potentially indicating privilege escalation or persistence attempts by malicious actors.","title":"Okta Admin Role Assignment Creation","url":"https://feed.craftedsignal.io/briefs/2024-01-okta-admin-role/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Okta"],"_cs_severities":["medium"],"_cs_tags":["identity","okta","suspicious-activity"],"_cs_type":"advisory","_cs_vendors":["Okta"],"content_html":"\u003cp\u003eThis alert focuses on detecting when an end-user within an Okta environment reports suspicious activity related to their account. This is a critical indicator that the account may be compromised, or that unauthorized access has occurred. The activity is reported directly by the end-user. While this alert does not directly reveal the method of compromise, it serves as an important signal for security teams to investigate potentially malicious activity. This event triggers from an Okta system log event generated when an end-user utilizes the \u0026ldquo;report suspicious activity\u0026rdquo; feature, available in many Okta deployments. Early detection allows security teams to rapidly respond, contain potential damage, and investigate the source of the suspicious activity. This type of self-reporting by end-users can be an invaluable source of threat intelligence within an organization.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains unauthorized access to an end-user\u0026rsquo;s Okta account, possibly via credential phishing or password reuse.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to perform actions such as accessing applications, changing profile details, or initiating password resets.\u003c/li\u003e\n\u003cli\u003eThe legitimate end-user observes suspicious activity in their Okta account, such as unfamiliar login locations, unauthorized application access, or unexpected password reset requests.\u003c/li\u003e\n\u003cli\u003eThe end-user utilizes the \u0026ldquo;report suspicious activity\u0026rdquo; feature within their Okta account portal.\u003c/li\u003e\n\u003cli\u003eThis action generates an Okta system log event with the eventType \u003ccode\u003euser.account.report_suspicious_activity_by_enduser\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe detection rule triggers based on this specific Okta log event.\u003c/li\u003e\n\u003cli\u003eSecurity analysts investigate the reported activity, examining Okta logs and other relevant data sources.\u003c/li\u003e\n\u003cli\u003eBased on the investigation, appropriate remediation steps are taken, such as resetting the user\u0026rsquo;s password, revoking active sessions, and blocking any identified malicious IP addresses.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful account compromise can lead to unauthorized access to sensitive applications and data within the organization. The number of affected users and the impact will depend on the permissions and access granted to the compromised Okta account. This can result in data breaches, financial loss, and reputational damage. Prompt detection of end-user reported suspicious activity allows for rapid incident response, minimizing potential damage.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Okta Suspicious Activity Reported by End-user\u0026rdquo; to your SIEM to detect when users report suspicious activity, using \u003ccode\u003eeventType: 'user.account.report_suspicious_activity_by_enduser'\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eReview Okta system logs for further details surrounding the events that prompted the user report (see references for log details).\u003c/li\u003e\n\u003cli\u003eImplement end-user training programs to educate users on how to identify and report suspicious activity.\u003c/li\u003e\n\u003cli\u003eInvestigate all triggered alerts to determine the root cause of the reported suspicious activity.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-17T12:00:00Z","date_published":"2024-01-17T12:00:00Z","id":"/briefs/2024-01-17-okta-suspicious-activity/","summary":"An Okta end-user reports potentially suspicious activity on their account, indicating possible compromise or unauthorized access.","title":"Okta End-User Reports Suspicious Account Activity","url":"https://feed.craftedsignal.io/briefs/2024-01-17-okta-suspicious-activity/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["low"],"_cs_tags":["privileged-access","okta","group-lifecycle"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis alert identifies potential privileged access activity within Okta environments by detecting unusual spikes in group lifecycle change events. The activity is detected using Elastic\u0026rsquo;s Anomaly Detection feature. Adversaries may manipulate group structures to achieve privilege escalation, establish persistence, or move laterally within an organization. The anomaly detection job, \u003ccode\u003epad_okta_spike_in_group_lifecycle_changes_ea\u003c/code\u003e, monitors these changes. This activity matters because unauthorized group modifications can grant attackers elevated permissions, compromise sensitive data, and disrupt normal business operations. The detection is based on machine learning analysis of Okta logs collected via an integration.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eInitial Compromise:\u003c/strong\u003e An attacker gains initial access to a user account, possibly through credential theft or phishing (not directly observed, but a common precursor).\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAccount Enumeration:\u003c/strong\u003e The attacker enumerates existing groups and their memberships within the Okta environment.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eGroup Manipulation:\u003c/strong\u003e The attacker initiates unauthorized group lifecycle changes, such as adding or removing members, to escalate privileges.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePrivilege Escalation:\u003c/strong\u003e By adding their compromised account to a privileged group (e.g., Okta administrators, application owners), the attacker gains elevated access.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eLateral Movement:\u003c/strong\u003e The attacker leverages their newly acquired privileges to access other systems or applications within the organization\u0026rsquo;s network.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePersistence:\u003c/strong\u003e The attacker modifies group memberships to maintain persistent access even if their initial access is revoked (T1098.007).\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eData Access/Exfiltration:\u003c/strong\u003e The attacker accesses sensitive data or resources that were previously inaccessible due to insufficient privileges.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful attack can lead to unauthorized access to sensitive data, compromise of critical systems, and disruption of business operations. The number of victims and the scope of the impact depend on the level of access achieved by the attacker and the sensitivity of the compromised data. While the alert is low severity, the potential consequences of privilege escalation are significant, requiring prompt investigation and remediation.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eInvestigate triggered alerts by reviewing the specific group lifecycle change events that triggered the alert in Okta logs to identify which groups were altered and the nature of the changes.\u003c/li\u003e\n\u003cli\u003eExamine the user accounts associated with the changes to determine if they have a history of suspicious activity or if they have recently been granted elevated privileges using the provided investigation steps.\u003c/li\u003e\n\u003cli\u003eTune the machine learning job anomaly threshold \u003ccode\u003eanomaly_threshold\u003c/code\u003e in the rule configuration to reduce false positives based on your environment\u0026rsquo;s baseline.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-09T12:00:00Z","date_published":"2024-01-09T12:00:00Z","id":"/briefs/2024-01-okta-group-lifecycle-spike/","summary":"A machine learning job has identified an unusual spike in Okta group lifecycle change events, indicating potential privilege escalation activity, where adversaries may be altering group structures to escalate privileges, maintain persistence, or facilitate lateral movement within an organization’s identity management system.","title":"Okta Group Lifecycle Change Spike Indicating Privilege Escalation","url":"https://feed.craftedsignal.io/briefs/2024-01-okta-group-lifecycle-spike/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["low"],"_cs_tags":["privileged-access","okta","machine-learning"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis alert leverages machine learning to identify deviations in IP usage patterns associated with privileged Okta operations, flagging unusual access attempts that could signify privilege escalation or account compromise. It identifies a user performing privileged operations in Okta from an uncommon source IP, potentially indicating account compromise, misuse of administrative privileges, or an attacker leveraging a new network location. The detection rule analyzes Okta logs, specifically focusing on events related to privileged operations and source IP addresses, to establish baseline behavior and detect anomalies. This detection is important because Okta controls access to many downstream applications, and any compromise of Okta privileges can lead to widespread data breaches. The rule requires the Privileged Access Detection integration assets to be installed, as well as Okta logs collected by integrations such as Okta. The minimum stack version is 9.4.0\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAdversary gains initial access to a valid user account through phishing, credential stuffing, or other means (T1078, T1078.004).\u003c/li\u003e\n\u003cli\u003eThe adversary leverages the compromised account to authenticate to Okta, potentially bypassing or circumventing MFA.\u003c/li\u003e\n\u003cli\u003eThe adversary attempts to perform privileged operations within Okta, such as modifying user permissions, accessing sensitive applications, or changing security settings.\u003c/li\u003e\n\u003cli\u003eOkta logs record the privileged operation attempt, including the source IP address of the request.\u003c/li\u003e\n\u003cli\u003eThe machine learning job analyzes the source IP address and compares it to the user\u0026rsquo;s historical access patterns.\u003c/li\u003e\n\u003cli\u003eIf the source IP address is determined to be unusual or rare for the user, the machine learning job generates an anomaly.\u003c/li\u003e\n\u003cli\u003eThe \u0026ldquo;Unusual Source IP for Okta Privileged Operations Detected\u0026rdquo; rule triggers based on the anomaly score exceeding a predefined threshold (anomaly_threshold = 75).\u003c/li\u003e\n\u003cli\u003eThe alert triggers, potentially leading to account takeover, data exfiltration, or further privilege escalation.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful attack can lead to unauthorized access to sensitive applications and data managed by Okta. This can result in data breaches, financial loss, reputational damage, and legal liabilities. Since Okta is a widely used identity management service, a compromise can impact numerous downstream applications and services that rely on Okta for authentication and authorization. The number of affected users and systems can vary depending on the scope of the privileged access and the attacker\u0026rsquo;s objectives.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eInstall the Privileged Access Detection integration assets, as well as Okta logs collected by integrations such as Okta, as described in the \u0026ldquo;Setup\u0026rdquo; section of the rule to enable the machine learning job.\u003c/li\u003e\n\u003cli\u003eReview the source IP address flagged by the alert to determine its geolocation and assess if it aligns with the user\u0026rsquo;s typical access patterns or known locations, as described in the rule\u0026rsquo;s \u0026ldquo;Triage and analysis\u0026rdquo; section.\u003c/li\u003e\n\u003cli\u003eTune the \u003ccode\u003eanomaly_threshold\u003c/code\u003e parameter in the machine learning job based on your environment to reduce false positives.\u003c/li\u003e\n\u003cli\u003eCorrelate the flagged IP address with any known threat intelligence feeds to check for any history of malicious activity associated with it, as described in the rule\u0026rsquo;s \u0026ldquo;Triage and analysis\u0026rdquo; section.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-09T10:00:00Z","date_published":"2024-01-09T10:00:00Z","id":"/briefs/2024-01-okta-unusual-ip/","summary":"A machine learning job has identified a user performing privileged operations in Okta from an uncommon source IP, indicating potential privileged access activity indicative of account compromise or privilege escalation.","title":"Unusual Source IP for Okta Privileged Operations Detected","url":"https://feed.craftedsignal.io/briefs/2024-01-okta-unusual-ip/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["medium"],"_cs_tags":["okta","session-hijacking","credential-access"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis threat brief addresses the risk of Okta session hijacking, where adversaries may steal session cookies or tokens to gain unauthorized access to Okta resources. The alert focuses on detecting anomalous Okta sessions characterized by multiple device token hashes and source IP addresses associated with a single authenticated user. This activity may indicate that an authenticated session has been compromised and is being replayed from different devices or networks. Defenders should be aware of the potential for attackers to leverage stolen sessions to access the Okta admin console, applications, tenants, and other sensitive resources. Elastic has published a rule to detect this behavior, last updated on April 13, 2026, which can be used to proactively identify potentially compromised Okta sessions within the environment.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eInitial Access:\u003c/strong\u003e An attacker gains access to a valid Okta session token or cookie through methods such as phishing or malware.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSession Token Theft:\u003c/strong\u003e The attacker steals a valid Okta session token/cookie from a compromised endpoint.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSession Replay:\u003c/strong\u003e The attacker replays the stolen session token/cookie from a different device and network location than the original user.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eOkta Authentication:\u003c/strong\u003e The replayed session token authenticates to Okta, creating a new session instance.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eMultiple Device Hashes:\u003c/strong\u003e Because the session is accessed from a different device, a new device token hash is generated. The attacker may also use proxy services from different locations.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eUnauthorized Access:\u003c/strong\u003e The attacker uses the hijacked session to access Okta resources, such as the admin console or applications.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePrivilege Escalation (Optional):\u003c/strong\u003e If the hijacked session belongs to a privileged user, the attacker may escalate privileges within the Okta environment.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eData Exfiltration/Manipulation:\u003c/strong\u003e The attacker exfiltrates sensitive data or modifies Okta configurations to establish persistence or further compromise the environment.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful Okta session hijacking attack can lead to unauthorized access to sensitive applications and data, privilege escalation, and disruption of business operations. The impact can range from data breaches and financial loss to reputational damage and regulatory fines. Attackers can potentially access and modify user accounts, security policies, and application integrations. The number of potential victims depends on the scope of the attacker\u0026rsquo;s access and the sensitivity of the data they can access.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule to your SIEM to detect multiple device token hashes and source IPs for single Okta sessions and tune for your environment.\u003c/li\u003e\n\u003cli\u003eInvestigate alerts generated by the Sigma rule by pivoting into Okta system logs using the \u003ccode\u003eokta.actor.alternate_id\u003c/code\u003e and \u003ccode\u003eokta.authentication_context.external_session_id\u003c/code\u003e fields.\u003c/li\u003e\n\u003cli\u003eMonitor Okta system logs for suspicious post-authentication activity, such as admin console access, policy changes, or application assignment modifications as described in the rule\u0026rsquo;s triage steps.\u003c/li\u003e\n\u003cli\u003eEnforce MFA enrollment for all Okta users to mitigate the risk of session hijacking and credential theft, as recommended in the investigation guide.\u003c/li\u003e\n\u003cli\u003eRevoke active sessions and reset passwords for affected users exhibiting suspicious activity as mentioned in the false positive analysis.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T18:41:22Z","date_published":"2024-01-03T18:41:22Z","id":"/briefs/2024-01-03-okta-session-hijacking/","summary":"Detection of multiple device token hashes and source IPs for a single Okta session, indicating potential session hijacking and unauthorized access to Okta resources.","title":"Okta Session Hijacking via Multiple Device Token Hashes","url":"https://feed.craftedsignal.io/briefs/2024-01-03-okta-session-hijacking/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Okta"],"_cs_severities":["high"],"_cs_tags":["identity","cloud","okta","initial-access"],"_cs_type":"advisory","_cs_vendors":["Okta"],"content_html":"\u003cp\u003eAttackers frequently use proxy infrastructure (VPNs, Tor, residential proxies) to mask their origin when using stolen credentials. This behavior often triggers additional detection rules after the initial authentication. By correlating the first instance of Okta user authentication via a proxy with subsequent Okta security alerts for the same user, this rule aims to identify potentially compromised accounts. This correlation focuses on activity within a 30-minute window following the initial proxy authentication, helping to pinpoint users whose proxy-based authentication was followed by suspicious activity. The rule leverages Okta system logs and alerts to identify these patterns. This is important for defenders to quickly identify compromised accounts and prevent further damage.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker obtains valid Okta credentials through phishing, credential stuffing, or other means. (T1078)\u003c/li\u003e\n\u003cli\u003eThe attacker initiates an Okta user session from behind a proxy (VPN, Tor, etc.) to mask their origin.\u003c/li\u003e\n\u003cli\u003eOkta classifies the connection as originating from a proxy.\u003c/li\u003e\n\u003cli\u003eThe user successfully authenticates and starts a session.\u003c/li\u003e\n\u003cli\u003ePost-authentication, the attacker attempts to access sensitive applications or data. (T1078.004)\u003c/li\u003e\n\u003cli\u003eThe attacker\u0026rsquo;s activity triggers an Okta security alert, such as unusual access patterns or MFA bypass attempts.\u003c/li\u003e\n\u003cli\u003eThe detection rule correlates the proxy authentication event with the subsequent security alert.\u003c/li\u003e\n\u003cli\u003eSecurity team investigates and responds to the potential account compromise.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful attack can lead to unauthorized access to sensitive data, privilege escalation, and lateral movement within the organization\u0026rsquo;s cloud environment. Multiple alerts, coupled with proxy authentication, indicate a higher likelihood of account compromise. If successful, attackers could exfiltrate sensitive data, modify configurations, or disrupt services.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Okta Alerts Following Unusual Proxy Authentication\u0026rdquo; to your SIEM and tune for your environment to detect suspicious activity after proxy authentication.\u003c/li\u003e\n\u003cli\u003eInvestigate correlated security alerts triggered after proxy authentication events for affected users, as highlighted by the Sigma rule.\u003c/li\u003e\n\u003cli\u003eMonitor Okta system logs for authentication events originating from known malicious proxy IP addresses and block them at the network perimeter.\u003c/li\u003e\n\u003cli\u003eReview user\u0026rsquo;s Okta activity for signs of account takeover (MFA changes, new devices, unusual app access) after proxy authentication.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) to reduce the risk of account compromise via stolen credentials, as this attack relies on valid accounts.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T15:00:00Z","date_published":"2024-01-03T15:00:00Z","id":"/briefs/2024-01-okta-proxy-auth-alerts/","summary":"Attackers use proxy infrastructure to mask their origin when using stolen Okta credentials, and this rule correlates the first occurrence of an Okta user session started via a proxy with subsequent Okta security alerts for the same user.","title":"Okta Alerts Following Unusual Proxy Authentication","url":"https://feed.craftedsignal.io/briefs/2024-01-okta-proxy-auth-alerts/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Okta Identity Cloud"],"_cs_severities":["low"],"_cs_tags":["identity","okta","policy","attack.impact"],"_cs_type":"advisory","_cs_vendors":["Okta"],"content_html":"\u003cp\u003eThis 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eInitial Access:\u003c/strong\u003e The attacker gains access to an Okta administrator account, either through compromised credentials (e.g., phishing, credential stuffing) or insider access.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAuthentication:\u003c/strong\u003e The attacker authenticates to the Okta admin console using the compromised or legitimate administrator account.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePolicy Enumeration:\u003c/strong\u003e The attacker identifies target Okta policies to modify or delete using the Okta admin console or API.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePolicy Modification/Deletion:\u003c/strong\u003e The attacker modifies or deletes the targeted Okta policy through the Okta admin console or API. This generates an \u003ccode\u003epolicy.lifecycle.update\u003c/code\u003e or \u003ccode\u003epolicy.lifecycle.delete\u003c/code\u003e event.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePrivilege Escalation (Potential):\u003c/strong\u003e By modifying policies, the attacker may escalate privileges, granting themselves or other unauthorized users access to sensitive applications and resources.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eLateral Movement (Potential):\u003c/strong\u003e With escalated privileges, the attacker moves laterally within the Okta environment, accessing other applications and resources.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eData Exfiltration/Damage (Potential):\u003c/strong\u003e The attacker leverages the compromised Okta environment to exfiltrate sensitive data or cause damage to connected systems.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule to your SIEM to detect Okta policy modifications or deletions (\u003ccode\u003epolicy.lifecycle.update\u003c/code\u003e, \u003ccode\u003epolicy.lifecycle.delete\u003c/code\u003e event types).\u003c/li\u003e\n\u003cli\u003eInvestigate any detected policy changes to verify their legitimacy and identify the user responsible.\u003c/li\u003e\n\u003cli\u003eReview Okta administrator account activity for any signs of compromise or unauthorized access.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all Okta administrator accounts to prevent unauthorized access.\u003c/li\u003e\n\u003cli\u003eRegularly review and audit Okta policies to ensure they are configured securely and in accordance with security best practices.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T12:00:00Z","date_published":"2024-01-03T12:00:00Z","id":"/briefs/2024-01-okta-policy-change/","summary":"An Okta policy was modified or deleted, potentially indicating unauthorized changes to security configurations within the Okta identity management platform by a malicious actor or insider.","title":"Okta Policy Modification or Deletion Detected","url":"https://feed.craftedsignal.io/briefs/2024-01-okta-policy-change/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Okta Identity Cloud"],"_cs_severities":["medium"],"_cs_tags":["okta","mfa","credential-access","persistence"],"_cs_type":"advisory","_cs_vendors":["Okta"],"content_html":"\u003cp\u003eAttackers 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker gains initial access to a user\u0026rsquo;s Okta account, possibly through phishing or credential compromise.\u003c/li\u003e\n\u003cli\u003eThe attacker authenticates to the Okta tenant using the compromised credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker initiates a request to reset or deactivate one or more of the user\u0026rsquo;s MFA factors through the Okta API or web interface.\u003c/li\u003e\n\u003cli\u003eOkta generates a system log event of type \u003ccode\u003euser.mfa.factor.deactivate\u003c/code\u003e or \u003ccode\u003euser.mfa.factor.reset_all\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eIf successful, the attacker can then authenticate without providing the MFA factor, bypassing a critical security control.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the compromised account to access sensitive applications and data within the Okta environment.\u003c/li\u003e\n\u003cli\u003eThe attacker may perform lateral movement to access other user accounts or systems.\u003c/li\u003e\n\u003cli\u003eThe final objective may include data exfiltration, financial fraud, or other malicious activities.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful MFA deactivation or reset can lead to complete account takeover. Depending on the compromised user\u0026rsquo;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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rules to your SIEM to detect suspicious MFA reset or deactivation attempts in Okta logs.\u003c/li\u003e\n\u003cli\u003eInvestigate any triggered alerts for \u003ccode\u003euser.mfa.factor.deactivate\u003c/code\u003e or \u003ccode\u003euser.mfa.factor.reset_all\u003c/code\u003e events, as described in the Sigma rule.\u003c/li\u003e\n\u003cli\u003eReview Okta system logs for unusual authentication patterns, focusing on users with recently deactivated MFA factors, as detailed in the Okta API documentation.\u003c/li\u003e\n\u003cli\u003eImplement strict access controls and monitoring for Okta administrator accounts to prevent unauthorized MFA modifications.\u003c/li\u003e\n\u003cli\u003eEducate users about phishing and credential security to reduce the risk of initial access compromise.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T12:00:00Z","date_published":"2024-01-03T12:00:00Z","id":"/briefs/2024-01-okta-mfa-reset/","summary":"An attacker attempts to disable or reset multi-factor authentication (MFA) for a user account in Okta, potentially leading to unauthorized access and account compromise.","title":"Okta MFA Reset or Deactivation Attempt","url":"https://feed.craftedsignal.io/briefs/2024-01-okta-mfa-reset/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["medium"],"_cs_tags":["okta","privilege-escalation","machine-learning"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis alert focuses on detecting potential privilege escalation attempts within Okta environments. The Elastic Security prebuilt machine learning job \u003ccode\u003epad_okta_spike_in_group_privilege_changes_ea\u003c/code\u003e identifies unusual spikes in Okta group privilege change events. Attackers may add themselves or compromised accounts to high-privilege groups to gain unauthorized access and persist within the environment. This activity can lead to significant data breaches, system compromise, and long-term persistence. The rule leverages Elastic\u0026rsquo;s Anomaly Detection feature. This detection is particularly relevant for organizations heavily reliant on Okta for identity and access management, especially those with sensitive data or critical infrastructure.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker compromises a low-privilege user account through phishing or credential stuffing.\u003c/li\u003e\n\u003cli\u003eThe attacker logs into Okta using the compromised credentials, bypassing MFA if possible.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to add the compromised account to a high-privilege Okta group, such as \u0026ldquo;Administrators\u0026rdquo; or \u0026ldquo;Security Admins.\u0026rdquo;\u003c/li\u003e\n\u003cli\u003eOkta logs an event indicating a group privilege change for the compromised account.\u003c/li\u003e\n\u003cli\u003eThe machine learning job \u003ccode\u003epad_okta_spike_in_group_privilege_changes_ea\u003c/code\u003e detects a statistically significant spike in these group privilege change events.\u003c/li\u003e\n\u003cli\u003eThe attacker gains elevated privileges within Okta and connected applications.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the newly acquired privileges to access sensitive data or modify critical system configurations.\u003c/li\u003e\n\u003cli\u003eThe attacker establishes persistence by creating new administrative accounts or modifying existing account permissions, ensuring continued access even if the initial compromised account is discovered.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful privilege escalation attack in Okta can have severe consequences. Attackers can gain complete control over the Okta environment, leading to unauthorized access to all connected applications and systems. This can result in data breaches, financial losses, and reputational damage. The number of affected users and systems depends on the scope of the attacker\u0026rsquo;s access and the sensitivity of the data stored within the connected applications.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the \u0026ldquo;Spike in Group Privilege Change Events\u0026rdquo; machine learning job in your Elastic Security environment and tune the \u003ccode\u003eanomaly_threshold\u003c/code\u003e for your specific Okta usage patterns (references: \u003ca href=\"https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html\"\u003eElastic ML Jobs\u003c/a\u003e, \u003ca href=\"https://docs.elastic.co/en/integrations/pad\"\u003ePrivileged Access Detection Setup\u003c/a\u003e).\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the machine learning job, focusing on identifying the accounts involved in the privilege changes, the source IP addresses, and the affected groups (reference: Investigation Guide section in the content).\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all Okta users, especially those with administrative privileges, to prevent account compromise (reference: remediation steps in the content).\u003c/li\u003e\n\u003cli\u003eReview and update access control policies to ensure that only authorized personnel can modify group memberships, reducing the risk of future privilege escalation (reference: remediation steps in the content).\u003c/li\u003e\n\u003cli\u003eEnable Okta integration and collect Okta logs in Elastic Agent policy (reference: \u003ca href=\"https://docs.elastic.co/en/integrations/okta\"\u003eOkta integration\u003c/a\u003e).\u003c/li\u003e\n\u003cli\u003eImplement the Sigma rule \u0026ldquo;Okta Suspicious Group Membership Changes\u0026rdquo; to detect specific patterns of malicious group modifications, and tune for your environment.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T12:00:00Z","date_published":"2024-01-03T12:00:00Z","id":"/briefs/2024-01-okta-group-privilege-spike/","summary":"A machine learning job has identified an unusual spike in Okta group privilege change events, indicating potential privileged access activity where attackers might be elevating privileges by adding themselves or compromised accounts to high-privilege groups, enabling further access or persistence.","title":"Okta Group Privilege Change Spike via ML Detection","url":"https://feed.craftedsignal.io/briefs/2024-01-okta-group-privilege-spike/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["low"],"_cs_tags":["privileged-access","privilege-escalation","okta"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eA machine learning job, \u003ccode\u003epad_okta_spike_in_group_application_assignment_changes_ea\u003c/code\u003e, has detected an unusual spike in Okta group application assignment change events. This activity, monitored by the Privileged Access Detection integration, suggests potential malicious activity where threat actors may be assigning applications to groups to escalate access, maintain persistence, or facilitate lateral movement. This is particularly relevant for organizations using Okta for identity and access management, as attackers targeting this platform could gain significant control over user access and sensitive resources. The detection is based on identifying anomalies in Okta events and requires the Privileged Access Detection integration to be installed and configured properly, along with the Okta integration. This detection has been in production since February 2025, and updated in April 2026, requiring Elastic Stack version 9.4.0 or later to function correctly due to its reliance on Entity Analytics fields.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eInitial Compromise:\u003c/strong\u003e An attacker compromises a user account with some level of administrative privileges within the Okta environment (T1078).\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePrivilege Escalation:\u003c/strong\u003e The attacker leverages the compromised account to modify group application assignments, granting unauthorized access to sensitive applications (T1098).\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eGroup Modification:\u003c/strong\u003e The attacker assigns applications to groups that the compromised user has access to modify. This allows the attacker to extend their reach within the organization.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eApplication Assignment:\u003c/strong\u003e The attacker assigns applications to a group, potentially giving all members of that group access to the applications without proper authorization.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eLateral Movement:\u003c/strong\u003e With access to new applications, the attacker uses the newly gained privileges to access other systems and resources within the network (T1078).\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePersistence:\u003c/strong\u003e The attacker may create or modify additional group application assignments to ensure continued access, even if the initial compromised account is detected and remediated (T1098).\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eData Access/Exfiltration:\u003c/strong\u003e The attacker leverages the escalated privileges to access and potentially exfiltrate sensitive data from the applications they now have access to.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful attack could lead to widespread unauthorized access to critical applications and data within the organization. The number of affected users and the extent of data breaches depend on the sensitivity of the applications accessed and the scope of the group membership changes. Consequences range from compliance violations and financial losses to reputational damage and operational disruption.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnsure the Privileged Access Detection integration is installed and properly configured in your Elastic Stack environment as described in the \u003ca href=\"https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html\"\u003esetup guide\u003c/a\u003e.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the \u003ccode\u003epad_okta_spike_in_group_application_assignment_changes_ea\u003c/code\u003e machine learning job, prioritizing those involving sensitive applications or high-privilege groups.\u003c/li\u003e\n\u003cli\u003eReview and update access controls and group assignment policies within Okta, as the advisory recommends to prevent similar unauthorized changes in the future.\u003c/li\u003e\n\u003cli\u003eImplement the following Sigma rule to detect suspicious Okta group application assignment changes and tune it for your environment.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T12:00:00Z","date_published":"2024-01-03T12:00:00Z","id":"/briefs/2024-01-okta-group-app-assignment-spike/","summary":"A machine learning job identified a spike in Okta group application assignment changes, potentially indicating threat actors escalating privileges, maintaining persistence, or moving laterally by assigning applications to groups.","title":"Okta Group Application Assignment Spike Indicates Privilege Escalation","url":"https://feed.craftedsignal.io/briefs/2024-01-okta-group-app-assignment-spike/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Okta"],"_cs_severities":["high"],"_cs_tags":["phishing","okta","fastpass"],"_cs_type":"advisory","_cs_vendors":["Okta"],"content_html":"\u003cp\u003eThis alert identifies instances where Okta FastPass successfully blocked a user authentication attempt due to a detected phishing attack. This is based on Okta system logs that record when FastPass declines an authentication because the user was attempting to log in to a known phishing site. The event indicates that a user was likely targeted via phishing, potentially through email or other means, and entered their Okta credentials into a fraudulent site. While the authentication was blocked, the event warrants investigation to determine the scope of the phishing campaign and whether the user may have entered credentials elsewhere.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker crafts a phishing email or message mimicking a legitimate Okta login page.\u003c/li\u003e\n\u003cli\u003eThe user receives the phishing message and clicks the embedded link.\u003c/li\u003e\n\u003cli\u003eThe user is directed to a fake Okta login page that is designed to steal credentials.\u003c/li\u003e\n\u003cli\u003eThe user enters their Okta username and password on the phishing site.\u003c/li\u003e\n\u003cli\u003eThe phishing site attempts to authenticate the user to Okta using the stolen credentials.\u003c/li\u003e\n\u003cli\u003eOkta FastPass detects that the authentication attempt is originating from a known phishing site.\u003c/li\u003e\n\u003cli\u003eOkta FastPass declines the authentication request, preventing access.\u003c/li\u003e\n\u003cli\u003eThe Okta system logs record the event \u0026ldquo;user.authentication.auth_via_mfa\u0026rdquo; with outcome \u0026ldquo;FAILURE\u0026rdquo; and reason \u0026ldquo;FastPass declined phishing attempt\u0026rdquo;.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eWhile Okta FastPass successfully prevented the immediate breach, the incident confirms that a user was targeted by a phishing campaign. This could lead to the compromise of other accounts if the user reuses the same password. Furthermore, successful phishing attacks can lead to data breaches, financial loss, and reputational damage. The number of affected users depends on the scale of the phishing campaign.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule to your SIEM to detect Okta FastPass phishing prevention events.\u003c/li\u003e\n\u003cli\u003eInvestigate users who triggered the detection to identify the phishing campaign and assess potential credential compromise.\u003c/li\u003e\n\u003cli\u003eReview Okta system logs for other suspicious activity associated with the targeted user accounts.\u003c/li\u003e\n\u003cli\u003eEducate users about phishing tactics and how to identify malicious websites to reduce susceptibility to future attacks.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T12:00:00Z","date_published":"2024-01-03T12:00:00Z","id":"/briefs/2024-01-okta-fastpass-phishing/","summary":"Okta FastPass detected and prevented a phishing attempt, indicating a user was likely targeted with a credential harvesting attack.","title":"Okta FastPass Phishing Attempt Detection","url":"https://feed.craftedsignal.io/briefs/2024-01-okta-fastpass-phishing/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Okta"],"_cs_severities":["medium"],"_cs_tags":["identity","okta","policy-tampering"],"_cs_type":"advisory","_cs_vendors":["Okta"],"content_html":"\u003cp\u003eOkta application sign-on policies control how users authenticate to applications integrated with Okta. An attacker who gains administrative access to an Okta tenant can modify or delete these policies, effectively weakening or bypassing multi-factor authentication (MFA) requirements and other security controls. This allows unauthorized access to sensitive applications and data. While this activity itself is not initial access, it represents a significant escalation of privileges and a deliberate attempt to subvert existing security measures within the Okta environment. Detection of these changes is critical to identify potential breaches early and prevent further damage.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains unauthorized access to an Okta administrator account through compromised credentials or other means.\u003c/li\u003e\n\u003cli\u003eThe attacker authenticates to the Okta admin dashboard.\u003c/li\u003e\n\u003cli\u003eThe attacker navigates to the \u0026ldquo;Security\u0026rdquo; section and then to \u0026ldquo;Authentication Policies\u0026rdquo;.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies the target application sign-on policy to modify or delete.\u003c/li\u003e\n\u003cli\u003eTo modify, the attacker changes the policy rules, such as disabling MFA requirements or allowing access from untrusted locations.\u003c/li\u003e\n\u003cli\u003eAlternatively, to delete, the attacker selects the policy and confirms its removal.\u003c/li\u003e\n\u003cli\u003eThe attacker\u0026rsquo;s actions are logged as \u0026ldquo;application.policy.sign_on.update\u0026rdquo; or \u0026ldquo;application.policy.sign_on.rule.delete\u0026rdquo; events in the Okta system log.\u003c/li\u003e\n\u003cli\u003eUnauthorized users can now access applications protected by the modified or deleted policy, potentially leading to data exfiltration or other malicious activities.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful modification or deletion of Okta application sign-on policies can severely compromise an organization\u0026rsquo;s security posture. This can lead to unauthorized access to sensitive applications and data, resulting in data breaches, financial losses, and reputational damage. The number of affected users and applications depends on the scope of the compromised policies.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Okta Application Sign-On Policy Modified or Deleted\u0026rdquo; to your SIEM and tune for your environment to detect changes to sign-on policies (rule reference).\u003c/li\u003e\n\u003cli\u003eMonitor the Okta system log for \u0026ldquo;application.policy.sign_on.update\u0026rdquo; and \u0026ldquo;application.policy.sign_on.rule.delete\u0026rdquo; events to identify suspicious activity (log source reference).\u003c/li\u003e\n\u003cli\u003eImplement strong access controls and MFA for Okta administrator accounts to prevent unauthorized policy modifications (best practice).\u003c/li\u003e\n\u003cli\u003eRegularly review Okta application sign-on policies to ensure they are properly configured and meet security requirements (best practice).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T12:00:00Z","date_published":"2024-01-03T12:00:00Z","id":"/briefs/2024-01-okta-sign-on-policy-changes/","summary":"Attackers may modify or delete Okta application sign-on policies to weaken security controls, potentially leading to unauthorized access and data breaches.","title":"Okta Application Sign-On Policy Modified or Deleted","url":"https://feed.craftedsignal.io/briefs/2024-01-okta-sign-on-policy-changes/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Okta"],"_cs_severities":["medium"],"_cs_tags":["okta","application-security","identity-management"],"_cs_type":"advisory","_cs_vendors":["Okta"],"content_html":"\u003cp\u003eThis alert detects modifications or deletions of applications within the Okta identity and access management platform. While the specific actor is unknown, the modification or deletion of an application can lead to significant disruptions and potential security breaches. The activity is detected through Okta system logs that record application lifecycle events. This is crucial for defenders because unauthorized changes to applications can lead to privilege escalation, data breaches, or denial of service. Monitoring these events allows for prompt investigation and mitigation of potentially malicious activity.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker gains unauthorized access to an Okta administrator account.\u003c/li\u003e\n\u003cli\u003eThe attacker authenticates to the Okta admin console.\u003c/li\u003e\n\u003cli\u003eAttacker navigates to the Applications section in the Okta admin console.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies a target application for modification or deletion.\u003c/li\u003e\n\u003cli\u003eIf modifying, the attacker alters application settings such as permissions, user assignments, or SSO configurations.\u003c/li\u003e\n\u003cli\u003eIf deleting, the attacker initiates the application deletion process.\u003c/li\u003e\n\u003cli\u003eOkta logs the \u0026ldquo;application.lifecycle.update\u0026rdquo; or \u0026ldquo;application.lifecycle.delete\u0026rdquo; event.\u003c/li\u003e\n\u003cli\u003eThe change impacts end-users and their ability to access resources through the modified or deleted application.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eThe impact of unauthorized application modification or deletion can be significant. Modified applications can grant unintended access to sensitive resources, leading to data breaches or privilege escalation. Deleted applications disrupt user access and business operations, potentially causing significant downtime and financial losses. The scope of the impact depends on the criticality of the affected application and the extent of the unauthorized changes.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule to your SIEM to detect \u003ccode\u003eapplication.lifecycle.update\u003c/code\u003e or \u003ccode\u003eapplication.lifecycle.delete\u003c/code\u003e events in Okta logs.\u003c/li\u003e\n\u003cli\u003eInvestigate any triggered alerts for unexpected application modifications or deletions, focusing on the user account that initiated the change (source: Okta logs).\u003c/li\u003e\n\u003cli\u003eReview Okta administrator account access and enforce multi-factor authentication to prevent unauthorized access (reference: Okta documentation on security best practices).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T12:00:00Z","date_published":"2024-01-03T12:00:00Z","id":"/briefs/2024-01-03-okta-app-modified-deleted/","summary":"Detects when an Okta application is modified or deleted, potentially indicating unauthorized changes or removal of critical applications.","title":"Okta Application Modified or Deleted","url":"https://feed.craftedsignal.io/briefs/2024-01-03-okta-app-modified-deleted/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Okta"],"_cs_severities":["medium"],"_cs_tags":["okta","api","token","revocation","identity"],"_cs_type":"advisory","_cs_vendors":["Okta"],"content_html":"\u003cp\u003eThis alert focuses on detecting the revocation of Okta API tokens. Okta API tokens are used to authenticate and authorize applications to access Okta\u0026rsquo;s APIs. When a token is revoked, it means that the token is no longer valid and can no longer be used to access Okta\u0026rsquo;s APIs. This can happen for a number of reasons, including: a user manually revoking the token, an administrator revoking the token, or Okta automatically revoking the token due to inactivity or security concerns. Detecting API token revocations is crucial because it can indicate that a token has been compromised and is being used by an attacker. A revoked token could be a sign of successful lateral movement or data exfiltration attempts within the Okta environment.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eInitial Access: An attacker gains unauthorized access to an Okta API token through methods like phishing, credential stuffing, or malware.\u003c/li\u003e\n\u003cli\u003eAPI Usage: The attacker uses the stolen API token to access Okta\u0026rsquo;s APIs, potentially gathering sensitive information or modifying user accounts.\u003c/li\u003e\n\u003cli\u003eAnomaly Detection: Okta\u0026rsquo;s security mechanisms or custom alerts identify unusual activity associated with the API token, such as access from unfamiliar locations or excessive API calls.\u003c/li\u003e\n\u003cli\u003eInvestigation Triggered: Security personnel initiate an investigation based on the flagged anomalous activity.\u003c/li\u003e\n\u003cli\u003eToken Revocation: As part of the incident response process, the compromised API token is manually or automatically revoked to prevent further unauthorized access. This action generates a \u0026ldquo;system.api_token.revoke\u0026rdquo; event in the Okta system log.\u003c/li\u003e\n\u003cli\u003ePost-Revocation Analysis: Security teams analyze the events leading up to the token revocation to identify the root cause of the compromise and assess the scope of the attacker\u0026rsquo;s activities.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful compromise of an Okta API token can lead to significant damage, including unauthorized access to sensitive user data, modification of user accounts and permissions, and disruption of critical business operations. If not detected promptly, attackers can leverage compromised tokens to escalate privileges, move laterally within the Okta environment, and potentially gain access to other connected systems. A single compromised API token could affect hundreds or thousands of users, depending on the scope of access granted to the token.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule to your SIEM to detect \u003ccode\u003esystem.api_token.revoke\u003c/code\u003e events in Okta logs.\u003c/li\u003e\n\u003cli\u003eInvestigate any detected \u003ccode\u003esystem.api_token.revoke\u003c/code\u003e events to determine the cause of the revocation and assess the potential impact.\u003c/li\u003e\n\u003cli\u003eReview Okta system logs for anomalous activity prior to the token revocation to identify the source of the compromise.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all Okta users to reduce the risk of credential compromise.\u003c/li\u003e\n\u003cli\u003eRegularly audit and review Okta API tokens to identify and revoke unused or overly permissive tokens.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T12:00:00Z","date_published":"2024-01-03T12:00:00Z","id":"/briefs/2024-01-okta-api-token-revoked/","summary":"Detection of Okta API token revocation events, indicating potential unauthorized access or compromise.","title":"Okta API Token Revoked","url":"https://feed.craftedsignal.io/briefs/2024-01-okta-api-token-revoked/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Okta Identity Cloud"],"_cs_severities":["medium"],"_cs_tags":["persistence","okta"],"_cs_type":"advisory","_cs_vendors":["Okta"],"content_html":"\u003cp\u003eThe 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains unauthorized access to an Okta account with sufficient privileges (e.g., Super Administrator).\u003c/li\u003e\n\u003cli\u003eThe attacker authenticates to the Okta Admin Console.\u003c/li\u003e\n\u003cli\u003eThe attacker navigates to the Security \u0026gt; API \u0026gt; Tokens section of the Okta Admin Console.\u003c/li\u003e\n\u003cli\u003eThe attacker creates a new API token with broad or specific permissions.\u003c/li\u003e\n\u003cli\u003eOkta logs the \u003ccode\u003esystem.api_token.create\u003c/code\u003e event.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the newly created API token to programmatically access Okta resources.\u003c/li\u003e\n\u003cli\u003eThe attacker may leverage the API token for various malicious activities, such as user enumeration, group manipulation, or application access.\u003c/li\u003e\n\u003cli\u003eThe attacker maintains persistent access to the Okta environment even if their initial access is revoked.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Okta API Token Created\u0026rdquo; to your SIEM to detect API token creation events (logsource: okta, service: okta).\u003c/li\u003e\n\u003cli\u003eInvestigate any detected \u003ccode\u003esystem.api_token.create\u003c/code\u003e events to verify the legitimacy of the token creation.\u003c/li\u003e\n\u003cli\u003eReview Okta system logs for unusual administrative activity preceding the API token creation event (logsource: okta, service: okta).\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all Okta administrator accounts to reduce the risk of unauthorized access.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T12:00:00Z","date_published":"2024-01-03T12:00:00Z","id":"/briefs/2024-01-okta-api-token-creation/","summary":"Detection of Okta API token creation events which can indicate malicious persistence activity.","title":"Okta API Token Creation","url":"https://feed.craftedsignal.io/briefs/2024-01-okta-api-token-creation/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Okta"],"_cs_severities":["medium"],"_cs_tags":["privilege-escalation","persistence","okta"],"_cs_type":"advisory","_cs_vendors":["Okta"],"content_html":"\u003cp\u003eThe assignment of administrator roles within Okta to users or groups is a sensitive action that requires careful monitoring. While legitimate administrator actions can account for these events, malicious actors may attempt to escalate privileges or establish persistence by assigning themselves or their controlled groups administrative rights. This activity could lead to unauthorized access, data breaches, or disruption of services within the Okta environment. Defenders should prioritize monitoring these role assignments to identify and respond to potential threats promptly.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eCompromise an Okta user account through phishing or credential stuffing.\u003c/li\u003e\n\u003cli\u003eLeverage the compromised account to authenticate to the Okta environment.\u003c/li\u003e\n\u003cli\u003eIdentify an existing administrator account within the Okta organization.\u003c/li\u003e\n\u003cli\u003eImpersonate the targeted admin user to assign admin roles.\u003c/li\u003e\n\u003cli\u003eAssign the Okta Administrator role to either a compromised user account or a newly created rogue group.\u003c/li\u003e\n\u003cli\u003eThe user or members of the rogue group now possess elevated privileges within the Okta environment.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages these elevated privileges to access sensitive applications, data, or configurations.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful assignment of administrator roles to unauthorized users can lead to severe consequences, including data breaches, unauthorized access to critical applications, and disruption of business operations. The impact can range from compromised user accounts to full control over the Okta tenant, affecting all integrated applications and services.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule to detect anomalous Okta admin role assignments to users or groups, focusing on \u003ccode\u003eeventType: group.privilege.grant\u003c/code\u003e and \u003ccode\u003eeventType: user.account.privilege.grant\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule to determine the legitimacy of the role assignment and the user or group involved.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all Okta user accounts, especially those with administrative privileges, to mitigate the risk of account compromise.\u003c/li\u003e\n\u003cli\u003eRegularly review Okta administrator role assignments and revoke any unnecessary privileges to minimize the attack surface.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T12:00:00Z","date_published":"2024-01-03T12:00:00Z","id":"/briefs/2024-01-03-okta-admin-role-assignment/","summary":"Detects the assignment of an Okta administrator role to a user or group, potentially indicating privilege escalation or persistence attempts by malicious actors.","title":"Detection of Okta Administrator Role Assignment to User or Group","url":"https://feed.craftedsignal.io/briefs/2024-01-03-okta-admin-role-assignment/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Okta"],"_cs_severities":["high"],"_cs_tags":["identity","okta","proxy","defense-evasion"],"_cs_type":"advisory","_cs_vendors":["Okta"],"content_html":"\u003cp\u003eThis threat brief focuses on detecting Okta user session starts that originate from anonymizing proxy services. Anonymizing proxies can be used by malicious actors to mask their true IP addresses and location, making it more difficult to trace their activities. The use of such proxies during Okta authentication is suspicious because it bypasses geographical restrictions and may indicate compromised credentials. Defenders should be aware that legitimate users may occasionally use anonymizing proxies for privacy reasons, but the activity warrants close scrutiny. The detection of this activity relies on Okta system logs and the security context of the authentication event.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker obtains valid Okta credentials through phishing, credential stuffing, or other means.\u003c/li\u003e\n\u003cli\u003eAttacker configures their network connection to route traffic through an anonymizing proxy service (e.g., Tor, VPN).\u003c/li\u003e\n\u003cli\u003eAttacker initiates an Okta user session using the compromised credentials.\u003c/li\u003e\n\u003cli\u003eOkta system logs record a \u0026ldquo;user.session.start\u0026rdquo; event.\u003c/li\u003e\n\u003cli\u003eThe \u0026ldquo;securityContext.isProxy\u0026rdquo; field within the Okta event is set to \u0026ldquo;true\u0026rdquo;, indicating the use of a proxy service.\u003c/li\u003e\n\u003cli\u003eIf successful, the attacker gains access to the Okta account and any associated applications or resources.\u003c/li\u003e\n\u003cli\u003eAttacker may then attempt to escalate privileges, access sensitive data, or perform other malicious activities within the Okta environment.\u003c/li\u003e\n\u003cli\u003eThe attacker may attempt lateral movement to other systems within the organization that trust Okta for authentication.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation can lead to unauthorized access to sensitive applications and data protected by Okta. This could result in data breaches, financial loss, or reputational damage. Depending on the compromised user\u0026rsquo;s privileges, an attacker may be able to escalate privileges and gain control over critical systems. The number of potential victims depends on the scope of applications using Okta for authentication.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule to your SIEM to detect Okta user sessions initiated through anonymizing proxies (logsource: okta, service: okta).\u003c/li\u003e\n\u003cli\u003eInvestigate all alerts generated by the Sigma rule to determine the legitimacy of the proxy usage.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) to reduce the risk of account compromise.\u003c/li\u003e\n\u003cli\u003eMonitor Okta system logs for other suspicious activities, such as failed login attempts or unusual access patterns (references: Okta System Log API).\u003c/li\u003e\n\u003cli\u003eReview and enforce Okta\u0026rsquo;s cross-tenant impersonation prevention and detection measures (references: Okta cross-tenant impersonation article).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-02T12:00:00Z","date_published":"2024-01-02T12:00:00Z","id":"/briefs/2024-01-okta-anonymizing-proxy/","summary":"Detection of Okta user sessions initiated through anonymizing proxy services, potentially indicating malicious activity or attempts to evade security controls.","title":"Okta User Session Start via Anonymizing Proxy Service","url":"https://feed.craftedsignal.io/briefs/2024-01-okta-anonymizing-proxy/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Okta"],"_cs_severities":["medium"],"_cs_tags":["identity","account-lockout","okta"],"_cs_type":"advisory","_cs_vendors":["Okta"],"content_html":"\u003cp\u003eThis brief describes detection measures for Okta user account lockouts. An account lockout occurs when a user exceeds the maximum number of permitted failed login attempts, potentially indicating a brute-force attack or other unauthorized access attempts against user accounts. Monitoring for account lockouts is crucial for identifying and mitigating potential security breaches. The rule detects the \u0026ldquo;Max sign in attempts exceeded\u0026rdquo; message in Okta logs, which signifies that an account has been locked. Detecting this activity can alert security teams to potential compromise attempts.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker attempts to authenticate to Okta with a valid or guessed username.\u003c/li\u003e\n\u003cli\u003eAttacker provides an incorrect password.\u003c/li\u003e\n\u003cli\u003eOkta logs the failed authentication attempt.\u003c/li\u003e\n\u003cli\u003eAttacker repeats steps 2 and 3 multiple times within a defined timeframe.\u003c/li\u003e\n\u003cli\u003eOkta\u0026rsquo;s account lockout policy is triggered when the maximum number of failed attempts is reached.\u003c/li\u003e\n\u003cli\u003eOkta logs an event with the \u003ccode\u003edisplayMessage\u003c/code\u003e \u0026ldquo;Max sign in attempts exceeded\u0026rdquo;.\u003c/li\u003e\n\u003cli\u003eThe user account is locked, preventing further login attempts.\u003c/li\u003e\n\u003cli\u003eSecurity team investigates the lockout event to determine the root cause and potential impact.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful account lockout can disrupt legitimate user access and indicate potential malicious activity. Multiple lockouts within a short period may signify a brute-force attack aimed at gaining unauthorized access to sensitive resources. While the lockout itself prevents immediate unauthorized access, it can lead to denial of service and requires investigation to rule out successful credential compromise. The number of impacted users depends on the scope and sophistication of the attack.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eOkta User Account Locked Out\u003c/code\u003e to your SIEM to detect account lockout events in Okta logs.\u003c/li\u003e\n\u003cli\u003eInvestigate any triggered alerts to determine the cause of the lockout, potentially indicating a brute-force attack (reference: \u003ccode\u003edisplayMessage: Max sign in attempts exceeded\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eReview and adjust Okta\u0026rsquo;s account lockout policies to balance security and usability based on your organization\u0026rsquo;s risk tolerance.\u003c/li\u003e\n\u003cli\u003eConsider implementing multi-factor authentication (MFA) to mitigate the risk of brute-force attacks and credential compromise.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-02T12:00:00Z","date_published":"2024-01-02T12:00:00Z","id":"/briefs/2024-01-02-okta-account-lockout/","summary":"Detection of an Okta user account lockout, which may indicate brute-force attempts or other malicious activity targeting user accounts.","title":"Okta User Account Lockout Detection","url":"https://feed.craftedsignal.io/briefs/2024-01-02-okta-account-lockout/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["low"],"_cs_tags":["privileged-access-detection","okta","machine-learning","privilege-escalation"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis alert identifies potentially malicious Okta activity based on unusual host names associated with privileged operations. The Elastic prebuilt machine learning job \u003ccode\u003epad_okta_rare_host_name_by_user_ea\u003c/code\u003e analyzes Okta logs to detect anomalies in device usage, specifically focusing on unusual host names. This activity could indicate a compromised user account, an attacker using stolen credentials, or an insider threat leveraging an unauthorized device to escalate privileges within the Okta environment. This detection is part of the Privileged Access Detection (PAD) integration, designed to identify abnormalities across Windows, Linux, and Okta events, starting with Elastic Stack version 9.4.0. Defenders should investigate users exhibiting this behavior to determine the legitimacy of the access and the device being used.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to an Okta user\u0026rsquo;s credentials, possibly through phishing (not specified in source, but likely).\u003c/li\u003e\n\u003cli\u003eThe attacker authenticates to Okta using the compromised credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to perform privileged operations within Okta (e.g., modifying user permissions, accessing sensitive applications).\u003c/li\u003e\n\u003cli\u003eThe attacker uses a device with a host name that is uncommon for the compromised user, triggering the machine learning alert.\u003c/li\u003e\n\u003cli\u003eOkta logs the privileged operation and the associated host name.\u003c/li\u003e\n\u003cli\u003eElastic\u0026rsquo;s machine learning job, \u003ccode\u003epad_okta_rare_host_name_by_user_ea\u003c/code\u003e, detects the unusual host name based on historical data.\u003c/li\u003e\n\u003cli\u003eA security alert is generated, indicating potential privileged access from an unusual host.\u003c/li\u003e\n\u003cli\u003eThe attacker escalates privileges within the Okta environment, potentially gaining access to sensitive resources or data.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful attack could lead to unauthorized access to sensitive applications and data managed by Okta. The potential impact includes data breaches, financial loss, and reputational damage. While the rule severity is low, successful privilege escalation can significantly increase the attacker\u0026rsquo;s access and control, impacting all applications and services integrated with Okta. The exact number of potential victims varies depending on the organization\u0026rsquo;s size and the scope of Okta\u0026rsquo;s usage.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnsure the Privileged Access Detection integration assets are installed and configured properly as per the \u003ca href=\"https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html\"\u003eofficial Elastic documentation\u003c/a\u003e.\u003c/li\u003e\n\u003cli\u003eInvestigate alerts from the \u003ccode\u003epad_okta_rare_host_name_by_user_ea\u003c/code\u003e machine learning job by reviewing user login history, device usage patterns, and associated IP addresses as outlined in the rule\u0026rsquo;s \u0026ldquo;Triage and analysis\u0026rdquo; section.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all privileged accounts to add an additional layer of security as mentioned in the \u0026ldquo;Response and remediation\u0026rdquo; section.\u003c/li\u003e\n\u003cli\u003eEnable Okta integration and configure the Fleet agent policy according to the \u003ca href=\"https://docs.elastic.co/en/integrations/okta\"\u003eElastic documentation\u003c/a\u003e to ensure proper data collection.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-02T12:00:00Z","date_published":"2024-01-02T12:00:00Z","id":"/briefs/2024-01-okta-unusual-hostname/","summary":"A machine learning job detected a user performing privileged operations in Okta from an uncommon device, potentially indicating a compromised account or insider threat attempting privilege escalation.","title":"Okta Privileged Operations from Unusual Host Name Detected","url":"https://feed.craftedsignal.io/briefs/2024-01-okta-unusual-hostname/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["low"],"_cs_tags":["privileged-access","privilege-escalation","okta"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis rule leverages machine learning to detect unusual spikes in Okta group membership events, potentially indicating privileged access activity. The detection logic is based on the \u0026ldquo;pad_okta_spike_in_group_membership_changes_ea\u0026rdquo; machine learning job. The rule aims to identify scenarios where attackers or malicious insiders are adding accounts to privileged groups within Okta to escalate their privileges, which could lead to unauthorized actions and data breaches. This rule requires the Privileged Access Detection integration assets to be installed, as well as Okta logs collected by integrations such as Okta. The rule\u0026rsquo;s anomaly threshold is set to 75, and it analyzes data from the last 3 hours at 15-minute intervals.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to an Okta account, potentially through compromised credentials or phishing.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the compromised account to access the Okta admin interface.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies high-privilege groups within Okta, such as those with access to sensitive applications or data.\u003c/li\u003e\n\u003cli\u003eThe attacker adds their controlled account or a compromised user account to one or more of these privileged groups.\u003c/li\u003e\n\u003cli\u003eOkta logs the group membership change event.\u003c/li\u003e\n\u003cli\u003eThe machine learning job \u0026ldquo;pad_okta_spike_in_group_membership_changes_ea\u0026rdquo; detects an unusual spike in these group membership events.\u003c/li\u003e\n\u003cli\u003eThe detection rule triggers, alerting security personnel to the potential privilege escalation.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the newly acquired privileges to access sensitive resources or perform unauthorized actions.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful privilege escalation attack in Okta can lead to significant damage. Attackers can gain access to sensitive applications and data, compromise other user accounts, and potentially disrupt business operations. The number of affected users and the scope of the damage depend on the privileges associated with the compromised groups. Detecting and responding to these spikes is crucial to preventing widespread data breaches and maintaining the integrity of the Okta environment.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnsure the Privileged Access Detection integration is installed and configured correctly, including the \u0026ldquo;pad_okta_spike_in_group_membership_changes_ea\u0026rdquo; machine learning job, as outlined in the \u003ca href=\"#setup\"\u003esetup instructions\u003c/a\u003e.\u003c/li\u003e\n\u003cli\u003eReview the specific Okta group membership events that triggered the alert to identify which accounts were added to privileged groups, as suggested in the \u003ca href=\"#triage-and-analysis\"\u003einvestigation guide\u003c/a\u003e.\u003c/li\u003e\n\u003cli\u003eImplement additional monitoring on affected accounts and privileged groups to detect any further suspicious activity, following the \u003ca href=\"#response-and-remediation\"\u003eresponse and remediation steps\u003c/a\u003e.\u003c/li\u003e\n\u003cli\u003eCreate exceptions for routine administrative tasks or automated scripts that legitimately manage group memberships to reduce false positives, as detailed in the \u003ca href=\"#false-positive-analysis\"\u003efalse positive analysis\u003c/a\u003e.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-02T12:00:00Z","date_published":"2024-01-02T12:00:00Z","id":"/briefs/2024-01-okta-group-spike/","summary":"A machine learning job has identified an unusual spike in Okta group membership events, indicating potential privileged access activity where attackers or malicious insiders might be adding accounts to privileged groups to escalate their access, potentially leading to unauthorized actions or data breaches.","title":"Okta Group Membership Spike Detection","url":"https://feed.craftedsignal.io/briefs/2024-01-okta-group-spike/"}],"language":"en","title":"CraftedSignal Threat Feed — Okta","version":"https://jsonfeed.org/version/1.1"}