Policy — CraftedSignal Threat Feed

Okta Policy Rule Modification or Deletion

hello@craftedsignal.io — Mon, 29 Jan 2024 12:00:00 +0000

Okta is a widely used identity and access management platform. Threat actors may target Okta configurations to weaken an organization’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.

Attack Chain

Initial Access: The attacker gains unauthorized access to an Okta administrator account, possibly through credential theft or phishing.
Authentication: The attacker authenticates to the Okta admin dashboard using the compromised credentials.
Discovery: The attacker enumerates existing policy rules to understand the current security configuration.
Modification: 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.
Deletion: Alternatively, the attacker deletes a policy rule entirely, effectively removing a layer of security.
Privilege Escalation: With weakened or removed policy rules, the attacker escalates privileges, gaining access to sensitive applications or data.
Lateral Movement: The attacker leverages the compromised Okta environment to move laterally within the organization’s network, accessing additional systems and resources.
Impact: The attacker achieves their final objective, such as data exfiltration, financial fraud, or system disruption, due to the weakened security posture.

Impact

Successful modification or deletion of Okta policy rules can severely compromise an organization’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’s subsequent actions. Organizations in all sectors that rely on Okta for identity management are vulnerable.

Recommendation

Deploy the “Okta Policy Rule Modified or Deleted” Sigma rule to your SIEM to detect unauthorized changes (rule reference).
Review Okta system logs regularly for policy rule modifications or deletions, focusing on unusual source IPs or user agents.
Implement multi-factor authentication (MFA) for all Okta administrator accounts to prevent unauthorized access (reference: Okta documentation).
Enforce the principle of least privilege for Okta administrator roles, limiting the number of users who can modify policy rules.
Alert on eventType policy.rule.update or policy.rule.delete in Okta logs using the provided Sigma rule (rule reference).

S3Browser IAM Policy Creation with Default Bucket Name

hello@craftedsignal.io — Fri, 26 Jan 2024 12:00:00 +0000

The S3Browser utility is being used to create Inline IAM policies within AWS. This activity is flagged as suspicious when the policy includes the default S3 bucket name placeholder value of . This could indicate that the user has not properly configured the policy or is unaware of the implications of using a generic placeholder, potentially granting unintended access to S3 resources. This behavior was observed being used by the threat actor Guivil. The use of S3Browser in this manner poses a risk of privilege escalation, persistence, and unauthorized access to sensitive data stored in S3 buckets.

Attack Chain

An attacker gains initial access to an AWS account, possibly through compromised credentials or misconfigured IAM roles (T1078.004).
The attacker utilizes the S3Browser utility to interact with AWS S3 buckets.
The attacker attempts to create an Inline IAM policy using S3Browser.
The attacker fails to replace the default bucket name placeholder with a specific bucket ARN.
The attacker saves the IAM policy with the default bucket name placeholder, leading to a broad or unintended scope of permissions.
The poorly configured policy is applied to a user, role, or group.
The attacker potentially escalates privileges or gains unauthorized access to S3 resources.
The attacker persists in the environment with the newly created or modified IAM policy.

Impact

Creation of an IAM policy with the default bucket name placeholder leaves S3 buckets open to potential unauthorized access. A successful attack could lead to data exfiltration, data modification, or denial of service. The scope of the impact depends on the specific permissions granted within the policy and the resources accessible through the affected IAM user, role, or group.

Recommendation

Deploy the Sigma rule “AWS IAM S3Browser Templated S3 Bucket Policy Creation” to your SIEM and tune for your environment to detect this specific activity.
Investigate any instances where PutUserPolicy events are associated with the S3Browser user agent (logsource: aws/cloudtrail).
Review existing IAM policies for the presence of the default bucket name placeholder arn:aws:s3:::/* (logsource: aws/cloudtrail).

Okta Policy Modification or Deletion Detected

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

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

Attack Chain

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

Impact

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

Recommendation

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