Okta — CraftedSignal Threat Feed

Okta Identity Provider Creation Detected

hello@craftedsignal.io — Thu, 25 Jan 2024 12:00:00 +0000

The 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.

Attack Chain

An attacker gains initial access to an Okta tenant with sufficient administrative privileges, either through compromised credentials or by exploiting a vulnerability.
The attacker navigates to the Okta admin console.
The attacker creates a new identity provider (IdP) within the Okta tenant (system.idp.lifecycle.create).
The attacker configures the rogue IdP with attacker-controlled settings, such as SAML endpoints or OIDC configurations, potentially pointing to an attacker-controlled server.
The attacker configures routing rules within Okta to direct specific users or groups to authenticate through the newly created, malicious IdP.
Users attempting to access Okta-protected applications are redirected to the attacker-controlled IdP for authentication.
The attacker’s IdP captures user credentials or issues fraudulent authentication tokens, allowing the attacker to impersonate legitimate users.
The 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.

Impact

A 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.

Recommendation

Deploy the Sigma rule “Okta Identity Provider Created” to your SIEM to detect the creation of new identity providers and tune it for your environment.
Regularly review and validate all configured identity providers within your Okta tenant to ensure their legitimacy.
Implement strong access controls and multi-factor authentication for all Okta administrative accounts to prevent unauthorized creation of identity providers.
Monitor Okta system logs for suspicious activity related to identity provider configuration and authentication.
Investigate any alerts triggered by the “Okta Identity Provider Created” Sigma rule to determine the legitimacy of the IdP creation event.

Okta User Account Created

hello@craftedsignal.io — Tue, 23 Jan 2024 12:00:00 +0000

This 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.

Attack Chain

An attacker gains initial access to an Okta administrator account, potentially through phishing, credential stuffing, or exploiting a vulnerability.
The attacker authenticates to the Okta admin portal.
The attacker navigates to the user management section within the Okta admin console.
The attacker creates a new user account, potentially mimicking an existing user or using a generic naming convention.
The attacker assigns the new user account specific roles and permissions, potentially granting elevated privileges.
The attacker may use the newly created account to access sensitive applications and data within the Okta-protected environment.
The attacker uses the compromised or newly created account to maintain persistence within the Okta environment.

Impact

A 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.

Recommendation

Deploy the Sigma rule “New Okta User Created” to your SIEM to detect user creation events and tune for your environment.
Investigate any detected user creation events for legitimacy, focusing on the source IP address and the administrator account used.
Implement multi-factor authentication (MFA) for all Okta administrator accounts to mitigate the risk of credential compromise.
Review Okta event logs regularly for suspicious activity, including user creation, permission changes, and application access.
Establish baseline user creation patterns to identify anomalous behavior, such as accounts created outside of normal business hours.

Okta Security Threat Detected

hello@craftedsignal.io — Tue, 23 Jan 2024 12:00:00 +0000

This alert focuses on identifying security threats detected by Okta’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 security.threat.detected. 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.

Attack Chain

An attacker attempts to gain unauthorized access to an Okta account, possibly through credential stuffing or brute-force attacks.
Okta’s ThreatInsight analyzes the login attempt, evaluating factors such as IP address reputation, geographical location, and login frequency.
ThreatInsight identifies the login attempt as a security threat based on predefined risk factors.
Okta generates a system log event with eventType security.threat.detected, recording details of the suspicious activity.
The security team receives an alert based on the Sigma rule detecting the security.threat.detected event.
The security team investigates the alert, examining the associated IP address, user account, and other relevant log data.
Based on the investigation, the security team takes appropriate remediation steps, such as blocking the IP address, resetting the user’s password, or enabling multi-factor authentication.

Impact

A 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’s cloud infrastructure and potentially compromise other critical systems.

Recommendation

Deploy the provided Sigma rule to your SIEM to detect security.threat.detected events in Okta system logs.
Investigate all triggered alerts to determine the nature and scope of the threat.
Review Okta’s ThreatInsight configuration to ensure it is properly configured and tuned for your environment (references: Okta ThreatInsight documentation).
Monitor Okta system logs for suspicious activity, such as unusual login patterns, account lockouts, and password resets (references: Okta system log documentation).
Enforce strong password policies and multi-factor authentication to reduce the risk of unauthorized access.

Okta Admin Role Assignment Creation

hello@craftedsignal.io — Tue, 23 Jan 2024 12:00:00 +0000

Okta 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.

Attack Chain

Initial Access: Attacker gains unauthorized access to an Okta account, possibly through credential phishing, brute-force attacks, or exploitation of vulnerabilities.
Privilege Check: The attacker verifies the privileges of the compromised account to determine if it has sufficient permissions to create new admin role assignments.
Account Impersonation: The attacker uses the compromised account to access the Okta admin dashboard.
Role Assignment Creation: The attacker navigates to the role assignment section and initiates the creation of a new admin role assignment.
Configuration: The attacker specifies the target user or group for the new admin role assignment.
Audit Logging: Okta logs the event ‘iam.resourceset.bindings.add’ indicating the creation of a new admin role assignment.
Persistence: 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.

Impact

Successful 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.

Recommendation

Deploy the Sigma rule Okta Admin Role Assignment Created to your SIEM and tune it for your environment to detect suspicious admin role creation activity in Okta logs.
Investigate any alerts generated by the Okta Admin Role Assignment Created rule to determine if the role assignment was legitimate and authorized.
Implement multi-factor authentication (MFA) for all Okta accounts, especially those with administrative privileges, to mitigate the risk of credential compromise.
Regularly review and audit Okta admin role assignments to identify and remove any unnecessary or unauthorized privileges.

Okta End-User Reports Suspicious Account Activity

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

This 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 “report suspicious activity” 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.

Attack Chain

An attacker gains unauthorized access to an end-user’s Okta account, possibly via credential phishing or password reuse.
The attacker attempts to perform actions such as accessing applications, changing profile details, or initiating password resets.
The legitimate end-user observes suspicious activity in their Okta account, such as unfamiliar login locations, unauthorized application access, or unexpected password reset requests.
The end-user utilizes the “report suspicious activity” feature within their Okta account portal.
This action generates an Okta system log event with the eventType user.account.report_suspicious_activity_by_enduser.
The detection rule triggers based on this specific Okta log event.
Security analysts investigate the reported activity, examining Okta logs and other relevant data sources.
Based on the investigation, appropriate remediation steps are taken, such as resetting the user’s password, revoking active sessions, and blocking any identified malicious IP addresses.

Impact

A 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.

Recommendation

Deploy the Sigma rule “Okta Suspicious Activity Reported by End-user” to your SIEM to detect when users report suspicious activity, using eventType: 'user.account.report_suspicious_activity_by_enduser'.
Review Okta system logs for further details surrounding the events that prompted the user report (see references for log details).
Implement end-user training programs to educate users on how to identify and report suspicious activity.
Investigate all triggered alerts to determine the root cause of the reported suspicious activity.

Okta Alerts Following Unusual Proxy Authentication

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

Attackers 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.

Attack Chain

An attacker obtains valid Okta credentials through phishing, credential stuffing, or other means. (T1078)
The attacker initiates an Okta user session from behind a proxy (VPN, Tor, etc.) to mask their origin.
Okta classifies the connection as originating from a proxy.
The user successfully authenticates and starts a session.
Post-authentication, the attacker attempts to access sensitive applications or data. (T1078.004)
The attacker’s activity triggers an Okta security alert, such as unusual access patterns or MFA bypass attempts.
The detection rule correlates the proxy authentication event with the subsequent security alert.
Security team investigates and responds to the potential account compromise.

Impact

A successful attack can lead to unauthorized access to sensitive data, privilege escalation, and lateral movement within the organization’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.

Recommendation

Deploy the Sigma rule “Okta Alerts Following Unusual Proxy Authentication” to your SIEM and tune for your environment to detect suspicious activity after proxy authentication.
Investigate correlated security alerts triggered after proxy authentication events for affected users, as highlighted by the Sigma rule.
Monitor Okta system logs for authentication events originating from known malicious proxy IP addresses and block them at the network perimeter.
Review user’s Okta activity for signs of account takeover (MFA changes, new devices, unusual app access) after proxy authentication.
Implement multi-factor authentication (MFA) to reduce the risk of account compromise via stolen credentials, as this attack relies on valid accounts.

Okta Unauthorized Application Access Attempt

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

This detection identifies instances where a user attempts to access an application within an Okta environment without proper authorization. The activity is logged within the Okta system logs, providing a clear indication of the unauthorized access attempt. This type of event is crucial for defenders as it may signify several issues, including compromised user accounts, misconfigured application permissions, or internal users attempting to escalate their privileges. This detection focuses specifically on the “User attempted unauthorized access to app” message within Okta logs. Identifying and investigating these events promptly can prevent data breaches and maintain the integrity of the Okta environment.

Attack Chain

A user attempts to access a protected application integrated with Okta.
Okta evaluates the user’s authentication status and group memberships against the application’s access policies.
The user lacks the necessary permissions or roles assigned to access the requested application.
Okta denies access to the application for the user.
Okta generates a system log event with the “User attempted unauthorized access to app” message.
The security monitoring system ingests the Okta log event.
The detection rule triggers based on the specific log message.
An alert is generated, prompting security analysts to investigate the unauthorized access attempt and take appropriate remedial actions.

Impact

Successful unauthorized access to applications can lead to significant data breaches, compromise sensitive information, and disrupt business operations. While this detection identifies attempted unauthorized access, repeated attempts or eventual success due to misconfiguration can result in severe consequences. A single successful breach can lead to data exfiltration, financial loss, and reputational damage. Identifying and remediating these attempts is crucial to preventing these outcomes.

Recommendation

Deploy the provided Sigma rule to your SIEM or security monitoring platform to detect unauthorized application access attempts in Okta (Sigma rule: “Okta Unauthorized Access to App”).
Investigate all triggered alerts promptly to determine the root cause of the unauthorized access attempt (Okta logs).
Review and validate application access policies within Okta to ensure users have appropriate permissions and roles assigned.
Implement multi-factor authentication (MFA) for all users to reduce the risk of compromised accounts being used for unauthorized access (Okta configuration).
Monitor Okta system logs for related events, such as account lockouts or password reset attempts, which might indicate account compromise (Okta logs).

Okta FastPass Phishing Attempt Detection

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

This 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.

Attack Chain

An attacker crafts a phishing email or message mimicking a legitimate Okta login page.
The user receives the phishing message and clicks the embedded link.
The user is directed to a fake Okta login page that is designed to steal credentials.
The user enters their Okta username and password on the phishing site.
The phishing site attempts to authenticate the user to Okta using the stolen credentials.
Okta FastPass detects that the authentication attempt is originating from a known phishing site.
Okta FastPass declines the authentication request, preventing access.
The Okta system logs record the event “user.authentication.auth_via_mfa” with outcome “FAILURE” and reason “FastPass declined phishing attempt”.

Impact

While 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.

Recommendation

Deploy the provided Sigma rule to your SIEM to detect Okta FastPass phishing prevention events.
Investigate users who triggered the detection to identify the phishing campaign and assess potential credential compromise.
Review Okta system logs for other suspicious activity associated with the targeted user accounts.
Educate users about phishing tactics and how to identify malicious websites to reduce susceptibility to future attacks.

Okta Application Sign-On Policy Modified or Deleted

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

Okta 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.

Attack Chain

An attacker gains unauthorized access to an Okta administrator account through compromised credentials or other means.
The attacker authenticates to the Okta admin dashboard.
The attacker navigates to the “Security” section and then to “Authentication Policies”.
The attacker identifies the target application sign-on policy to modify or delete.
To modify, the attacker changes the policy rules, such as disabling MFA requirements or allowing access from untrusted locations.
Alternatively, to delete, the attacker selects the policy and confirms its removal.
The attacker’s actions are logged as “application.policy.sign_on.update” or “application.policy.sign_on.rule.delete” events in the Okta system log.
Unauthorized users can now access applications protected by the modified or deleted policy, potentially leading to data exfiltration or other malicious activities.

Impact

Successful modification or deletion of Okta application sign-on policies can severely compromise an organization’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.

Recommendation

Deploy the Sigma rule “Okta Application Sign-On Policy Modified or Deleted” to your SIEM and tune for your environment to detect changes to sign-on policies (rule reference).
Monitor the Okta system log for “application.policy.sign_on.update” and “application.policy.sign_on.rule.delete” events to identify suspicious activity (log source reference).
Implement strong access controls and MFA for Okta administrator accounts to prevent unauthorized policy modifications (best practice).
Regularly review Okta application sign-on policies to ensure they are properly configured and meet security requirements (best practice).

Okta Application Modified or Deleted

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

This 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.

Attack Chain

Attacker gains unauthorized access to an Okta administrator account.
The attacker authenticates to the Okta admin console.
Attacker navigates to the Applications section in the Okta admin console.
The attacker identifies a target application for modification or deletion.
If modifying, the attacker alters application settings such as permissions, user assignments, or SSO configurations.
If deleting, the attacker initiates the application deletion process.
Okta logs the “application.lifecycle.update” or “application.lifecycle.delete” event.
The change impacts end-users and their ability to access resources through the modified or deleted application.

Impact

The 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.

Recommendation

Deploy the provided Sigma rule to your SIEM to detect application.lifecycle.update or application.lifecycle.delete events in Okta logs.
Investigate any triggered alerts for unexpected application modifications or deletions, focusing on the user account that initiated the change (source: Okta logs).
Review Okta administrator account access and enforce multi-factor authentication to prevent unauthorized access (reference: Okta documentation on security best practices).

Okta API Token Revoked

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

This alert focuses on detecting the revocation of Okta API tokens. Okta API tokens are used to authenticate and authorize applications to access Okta’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’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.

Attack Chain

Initial Access: An attacker gains unauthorized access to an Okta API token through methods like phishing, credential stuffing, or malware.
API Usage: The attacker uses the stolen API token to access Okta’s APIs, potentially gathering sensitive information or modifying user accounts.
Anomaly Detection: Okta’s security mechanisms or custom alerts identify unusual activity associated with the API token, such as access from unfamiliar locations or excessive API calls.
Investigation Triggered: Security personnel initiate an investigation based on the flagged anomalous activity.
Token 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 “system.api_token.revoke” event in the Okta system log.
Post-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’s activities.

Impact

Successful 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.

Recommendation

Deploy the provided Sigma rule to your SIEM to detect system.api_token.revoke events in Okta logs.
Investigate any detected system.api_token.revoke events to determine the cause of the revocation and assess the potential impact.
Review Okta system logs for anomalous activity prior to the token revocation to identify the source of the compromise.
Implement multi-factor authentication (MFA) for all Okta users to reduce the risk of credential compromise.
Regularly audit and review Okta API tokens to identify and revoke unused or overly permissive tokens.

Detection of Okta Administrator Role Assignment to User or Group

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

The 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.

Attack Chain

Compromise an Okta user account through phishing or credential stuffing.
Leverage the compromised account to authenticate to the Okta environment.
Identify an existing administrator account within the Okta organization.
Impersonate the targeted admin user to assign admin roles.
Assign the Okta Administrator role to either a compromised user account or a newly created rogue group.
The user or members of the rogue group now possess elevated privileges within the Okta environment.
The attacker leverages these elevated privileges to access sensitive applications, data, or configurations.

Impact

Successful 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.

Recommendation

Deploy the provided Sigma rule to detect anomalous Okta admin role assignments to users or groups, focusing on eventType: group.privilege.grant and eventType: user.account.privilege.grant.
Investigate any alerts generated by the Sigma rule to determine the legitimacy of the role assignment and the user or group involved.
Implement multi-factor authentication (MFA) for all Okta user accounts, especially those with administrative privileges, to mitigate the risk of account compromise.
Regularly review Okta administrator role assignments and revoke any unnecessary privileges to minimize the attack surface.

Okta User Session Start via Anonymizing Proxy Service

hello@craftedsignal.io — Tue, 02 Jan 2024 12:00:00 +0000

This 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.

Attack Chain

Attacker obtains valid Okta credentials through phishing, credential stuffing, or other means.
Attacker configures their network connection to route traffic through an anonymizing proxy service (e.g., Tor, VPN).
Attacker initiates an Okta user session using the compromised credentials.
Okta system logs record a “user.session.start” event.
The “securityContext.isProxy” field within the Okta event is set to “true”, indicating the use of a proxy service.
If successful, the attacker gains access to the Okta account and any associated applications or resources.
Attacker may then attempt to escalate privileges, access sensitive data, or perform other malicious activities within the Okta environment.
The attacker may attempt lateral movement to other systems within the organization that trust Okta for authentication.

Impact

Successful 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’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.

Recommendation

Deploy the provided Sigma rule to your SIEM to detect Okta user sessions initiated through anonymizing proxies (logsource: okta, service: okta).
Investigate all alerts generated by the Sigma rule to determine the legitimacy of the proxy usage.
Implement multi-factor authentication (MFA) to reduce the risk of account compromise.
Monitor Okta system logs for other suspicious activities, such as failed login attempts or unusual access patterns (references: Okta System Log API).
Review and enforce Okta’s cross-tenant impersonation prevention and detection measures (references: Okta cross-tenant impersonation article).

Okta User Account Lockout Detection

hello@craftedsignal.io — Tue, 02 Jan 2024 12:00:00 +0000

This 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 “Max sign in attempts exceeded” message in Okta logs, which signifies that an account has been locked. Detecting this activity can alert security teams to potential compromise attempts.

Attack Chain

Attacker attempts to authenticate to Okta with a valid or guessed username.
Attacker provides an incorrect password.
Okta logs the failed authentication attempt.
Attacker repeats steps 2 and 3 multiple times within a defined timeframe.
Okta’s account lockout policy is triggered when the maximum number of failed attempts is reached.
Okta logs an event with the displayMessage “Max sign in attempts exceeded”.
The user account is locked, preventing further login attempts.
Security team investigates the lockout event to determine the root cause and potential impact.

Impact

A 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.

Recommendation

Deploy the Sigma rule Okta User Account Locked Out to your SIEM to detect account lockout events in Okta logs.
Investigate any triggered alerts to determine the cause of the lockout, potentially indicating a brute-force attack (reference: displayMessage: Max sign in attempts exceeded).
Review and adjust Okta’s account lockout policies to balance security and usability based on your organization’s risk tolerance.
Consider implementing multi-factor authentication (MFA) to mitigate the risk of brute-force attacks and credential compromise.

Masquerading Business Application Installers

hello@craftedsignal.io — Tue, 02 Jan 2024 12:00:00 +0000

Attackers often attempt to trick users into downloading and executing malicious executables by disguising them as legitimate business applications. This tactic is used to bypass security measures and gain initial access to a system. These malicious executables, often distributed via malicious ads, forum posts, and tutorials, mimic the names of commonly used applications such as Slack, WebEx, Teams, Discord, and Zoom. The executables are typically unsigned or signed with invalid certificates to further evade detection. This allows the attacker to execute arbitrary code on the victim’s machine, potentially leading to further compromise. This campaign aims to target end-users who are less security-aware, and this makes social engineering attacks like this very effective.

Attack Chain

The user visits a compromised website or clicks on a malicious advertisement.
The user is prompted to download an installer file masquerading as a legitimate business application (e.g., Slack, Zoom, Teams) from a download directory.
The downloaded executable is placed in the user’s Downloads folder (e.g., C:\Users*\Downloads*).
The user executes the downloaded file.
The executable, lacking a valid code signature, begins execution.
The malicious installer may drop and execute additional malware components.
The malware establishes persistence, potentially using techniques such as registry key modification.
The malware performs malicious activities, such as data exfiltration or lateral movement.

Impact

Successful execution of a masqueraded business application installer can lead to a complete system compromise. The attacker gains initial access and can deploy various malware payloads, including ransomware, keyloggers, and data stealers. This can result in data breaches, financial loss, and reputational damage. Although the specific number of victims and sectors targeted are not detailed, the widespread use of the applications being spoofed (Slack, Zoom, etc.) suggests a broad potential impact.

Recommendation

Implement the Sigma rule Potential Masquerading as Business App Installer to detect unsigned executables resembling legitimate business applications in download directories.
Enable process creation logging to capture the execution of unsigned executables.
Educate users on the risks of downloading and executing files from untrusted sources.
Implement application whitelisting to restrict the execution of unauthorized applications.
Regularly update endpoint detection and response (EDR) tools to detect and prevent the execution of known malware.
Monitor process execution events for processes originating from the Downloads folder that lack valid code signatures.