Attack Chain

1. An attacker gains initial access to a compromised host within the Kubernetes cluster or a host with network access to the Kubelet ports.
2. The attacker uses a utility like curl, wget, python, or similar tools to craft an HTTP request targeting the Kubelet API on ports 10250 or 10255.
3. The request includes a path like /pods, /runningpods, /metrics, /exec, or /containerLogs to gather information about the cluster’s state and configuration.
4. The attacker examines the response to identify potential targets for lateral movement, such as specific pods or containers of interest.
5. The attacker attempts to execute commands within a container using the /exec endpoint, potentially leveraging exposed service account tokens or other credentials.
6. The attacker uses gathered information to move laterally to other pods or nodes within the cluster, escalating privileges as they go.
7. The attacker compromises sensitive data or critical applications running within the Kubernetes cluster.

Impact

Successful exploitation can lead to full cluster compromise. Attackers can gain unauthorized access to sensitive data, disrupt critical applications, and move laterally to other resources within the Kubernetes environment. This could lead to significant financial losses, reputational damage, and legal liabilities. The potential impact includes data breaches, denial of service, and complete control over the Kubernetes infrastructure.

Recommendation

• Deploy the Sigma rule Kubelet API Access via Process Arguments to your SIEM to detect suspicious process executions.
• Restrict access to Kubelet ports 10250/10255 at the network layer to limit pod-to-node or host-to-node traffic as recommended in the overview section.
• Harden Kubelet configuration by disabling anonymous authentication and enforcing webhook authentication/authorization as described in the overview section.

Attack Chain

1. The attacker identifies a vulnerable system running the xz utility.
2. The attacker crafts a malicious payload designed to exploit the undisclosed vulnerability within xz.
3. The attacker delivers the malicious payload to the vulnerable system. The specific delivery mechanism is not detailed (e.g., network service, malicious file).
4. The xz utility processes the malicious payload, triggering the vulnerability.
5. Due to the vulnerability, the attacker gains the ability to execute arbitrary code on the targeted system.
6. The attacker’s code executes with the privileges of the xz process, potentially allowing for elevated privileges.
7. The attacker may then install a backdoor or other persistent mechanism to maintain access to the compromised system.
8. The attacker pivots to other systems on the network or exfiltrates sensitive data.

Impact

Successful exploitation of this vulnerability allows a remote attacker to execute arbitrary code on the targeted system. This can lead to complete system compromise, data theft, and further malicious activities within the network. Given the widespread use of the xz utility, a large number of systems are potentially vulnerable. The impact could range from disruption of services to significant data breaches.

Recommendation

• Investigate systems running the xz utility for suspicious activity.
• Deploy the Sigma rules provided below to detect potential exploitation attempts.
• Monitor process execution for unexpected activity originating from the xz utility using process_creation logs.
• Implement network monitoring to identify suspicious connections originating from systems where xz is used.

Attack Chain

1. An attacker gains initial access to a container, possibly through exploiting a vulnerability or misconfiguration in the application running within the container.
2. The attacker attempts to mount the host’s root filesystem within the container using the mount command, often targeting /dev/sd* devices. This requires sufficient privileges within the container, or the exploitation of a container escape vulnerability to gain such privileges.
3. The mount command is executed with arguments specifying the device to mount and the mount point within the container’s file system.
4. The attacker then executes the chroot command, changing the root directory of the current process to the mounted host’s root filesystem.
5. After successfully executing chroot, the attacker’s perspective shifts to the host’s file system, allowing them to access and modify sensitive files and configurations.
6. The attacker uses their newly acquired access to install backdoors, create new user accounts with elevated privileges, or modify system configurations to establish persistence.
7. The attacker may attempt to move laterally to other containers or systems within the network, leveraging their compromised position on the host.
8. The final objective is to gain complete control over the host system and potentially the entire infrastructure, leading to data exfiltration, system disruption, or other malicious activities.

Impact

A successful container escape can have severe consequences, potentially leading to complete compromise of the host system and the data it contains. Depending on the environment, this could affect a single server or spread to many hosts. The compromise of containerized environments can lead to data breaches, service disruption, and reputational damage. Given the sensitive nature of data often processed within containers, the impact can range from financial losses to regulatory penalties.

Recommendation

• Deploy the Sigma rules in this brief to your SIEM and tune for your environment to detect potential container escapes.
• Enable Elastic Defend integration to collect process data, and ensure Session View data is enabled to enhance visibility as mentioned in the setup guide.
• Review and harden container configurations to minimize privileges granted to containerized processes, reducing the attack surface for escape attempts.
• Implement network segmentation to limit the potential for lateral movement following a successful container escape.
• Monitor process execution logs for unusual mount and chroot command sequences within container environments using Elastic Defend, SentinelOne, and Crowdstrike logs.

Attack Chain

1. An attacker gains initial access to a container, potentially through exploiting a vulnerability in the containerized application.
2. The attacker identifies sensitive host mounts within the container’s filesystem, such as /host, /proc/1/root, or other unexpected node paths.
3. The attacker executes the chroot command, specifying an alternate root filesystem, typically a host-linked mount.
4. The chroot command redirects system calls to the new root filesystem, effectively isolating the attacker from the container’s original environment.
5. The attacker leverages the new root filesystem to access files, directories, and processes on the host system outside the container’s boundaries.
6. The attacker may then attempt to escalate privileges by exploiting vulnerabilities in host system services or binaries.
7. The attacker may install malware or establish persistence mechanisms on the host system.
8. The attacker uses the compromised host system to pivot to other systems on the network or to exfiltrate sensitive data.

Impact

A successful container escape can lead to full compromise of the underlying host system, potentially impacting all containers running on the same host. This can enable attackers to access sensitive data, disrupt services, and move laterally within the network. In multi-tenant environments, a container escape can compromise the security of other tenants sharing the same infrastructure. A single successful container escape can lead to a widespread breach impacting numerous systems and applications.

Recommendation

• Deploy the Sigma rule Chroot Execution in Container Context to your SIEM and tune for your environment.
• Enable process execution telemetry from Elastic Defend and Auditd Manager on Linux to ensure the required data is available for detection.
• Investigate any alerts generated by the Sigma rule to determine if the chroot execution was authorized and the target directory is an internal build root versus a host filesystem mount.
• Monitor for follow-on shell execution, access to the container runtime socket, or kubelet credential paths, as these are common indicators of container escape attempts.

Attack Chain

1. Reconnaissance: The attacker gains limited visibility into the environment (e.g., compromised CI runner, web container) and identifies the kernel version. Kernel version information is obtained without elevated privileges.
2. Script Execution: The attacker executes a compact Python script that interacts with standard kernel interfaces, without relying on networking, compilation, or third-party libraries.
3. AF_ALG Abuse: The script abuses an interaction between the AF_ALG (asynchronous crypto) socket interface, the splice() system call and improper error handling during a failed copy operation.
4. Kernel Page Cache Corruption: This interaction leads to a controlled 4-byte overwrite in the kernel page cache, corrupting sensitive kernel-managed data.
5. Privilege Escalation: By corrupting kernel structures associated with credentials or execution context, the attacker escalates their process to UID 0.
6. Boundary Breach: The system’s privilege boundary is broken, neutralizing SELinux/AppArmor protections, and bypassing local security controls.
7. Lateral Movement/Container Escape: The attacker can now use the root privileges gained to perform lateral movement or escape the container.

Impact

Successful exploitation of CVE-2026-31431 leads to full root privilege escalation, resulting in high impact to confidentiality, integrity, and availability. This could facilitate container breakout, multi-tenant compromise, and lateral movement within shared environments. The vulnerability’s reliability, stealth (in-memory-only modification), and cross-platform applicability make it particularly dangerous in cloud, CI/CD, and Kubernetes environments.

Recommendation

• Identify all instances of affected products and versions in your environment and prioritize patching (CVE-2026-31431).
• Deploy the Sigma rule for suspicious process execution under /tmp, often used in exploit PoCs, and tune for your environment.
• Monitor for suspicious AF_ALG socket creation events, as indicated in the Attack Chain, using the provided Sigma rule.
• If patches are unavailable, consider implementing network isolation and access controls as interim mitigation measures.

Attack Chain

1. Attacker gains initial access to the system with limited privileges (e.g., through exploiting a vulnerability or using stolen credentials).
2. Attacker identifies a writable directory outside of standard system binary paths (e.g., /tmp, /var/tmp).
3. Attacker copies or creates a symbolic link to a setuid-capable shell (e.g., /bin/bash, /bin/dash) into the identified writable directory. This copied shell retains the setuid bit.
4. Attacker executes the copied or linked shell from the non-standard path with the -p flag (e.g., /tmp/bash -p). The -p flag instructs the shell to preserve privileges, effectively running with the effective user ID (EUID) of root.
5. Auditd logs this process execution event, capturing the non-standard path, the use of the -p flag, the root EUID, and the non-root RUID.
6. The detection rule identifies the process execution event based on the criteria outlined above.
7. Attacker now has a root shell and can perform administrative tasks, install malware, or further compromise the system.

Impact

A successful privilege escalation attack can grant an attacker complete control over the compromised system. This allows them to access sensitive data, install malicious software, modify system configurations, and potentially pivot to other systems on the network. This can lead to data breaches, system downtime, and significant financial losses. The risk score for this type of activity is considered high due to the potential for significant impact.

Recommendation

• Deploy the Sigma rule Potential Root Effective Shell from Non-Standard Path via Auditd to your SIEM and tune for your environment.
• Ensure that Auditd Manager or Auditbeat is properly configured to collect process execution events with relevant fields (event.action, user.id, user.effective.id, process.args, and process.executable) as described in the rule setup to enable the rule to function correctly.
• Investigate any alerts generated by this rule by inspecting process.executable, process.args, process.parent, and the full command line reconstructed in audit logs.
• Regularly audit all setuid binaries on the filesystem to identify any unauthorized or malicious setuid executables.
• Implement access controls and file integrity monitoring to prevent unauthorized modification of system binaries and writable directories.

Attack Chain

1. An unprivileged user initiates multiple AF_ALG socket creation events (auditd.data.syscall == “socket” and auditd.data.a0 == “26”) or splice operations.
2. The attacker leverages the vulnerability to corrupt the page cache of a setuid-root binary, such as /usr/bin/su.
3. The attacker executes the targeted setuid-root binary (e.g., /usr/bin/su).
4. Due to the corrupted page cache, the executed binary behaves in an unexpected manner, leading to a privilege escalation.
5. The process transitions to a root UID, indicating successful privilege escalation.
6. A root shell is spawned, providing the attacker with elevated privileges.
7. The attacker performs actions requiring root privileges, such as creating persistence mechanisms or accessing sensitive credentials.
8. The attacker potentially compromises the entire host or node, especially in containerized environments.

Impact

Successful exploitation of CVE-2026-31431 leads to privilege escalation, allowing attackers to gain root access on the affected Linux system. This can result in complete system compromise, data exfiltration, and the ability to install malware or create persistent backdoors. In containerized environments, a compromised container can lead to node compromise, affecting other containers running on the same host. The vulnerability affects systems running vulnerable kernel versions, potentially impacting a wide range of servers and workstations.

Recommendation

• Deploy the Sigma rule “Potential Copy Fail (CVE-2026-31431) Exploitation via AF_ALG Socket - Socket Creation Burst” to detect initial exploitation attempts based on AF_ALG socket activity.
• Deploy the Sigma rule “Potential Copy Fail (CVE-2026-31431) Exploitation via AF_ALG Socket - Privilege Escalation” to detect privilege escalation attempts by monitoring executed processes with an effective user ID of root.
• Immediately patch the kernel with the vendor fix for CVE-2026-31431 to eliminate the underlying vulnerability.
• Until patching is possible, consider blocking algif_aead module loading or restricting AF_ALG socket creation via seccomp for untrusted workloads.
• Add audit rules for socket, splice, and bind events as described in the rule’s Setup instructions to ensure comprehensive monitoring of AF_ALG related syscalls.

Attack Chain

1. An unprivileged local attacker gains access to a vulnerable Linux system.
2. The attacker utilizes the AF_ALG socket-based interface to access Linux kernel crypto functions from user space.
3. The attacker uses the splice() system call to perform a controlled 4-byte write in the page cache of a readable file, instead of a normal buffer.
4. The attacker targets a setuid-root binary file for modification.
5. The 4-byte write alters the behavior of the setuid-root binary.
6. The attacker executes the modified setuid-root binary.
7. Due to the altered behavior, the binary grants the attacker elevated privileges.
8. The attacker gains root privileges on the system.

Impact

Successful exploitation of the Copy Fail vulnerability (CVE-2026-31431) allows an unprivileged local attacker to gain root privileges on a vulnerable Linux system. Theori demonstrated and confirmed the exploit on Ubuntu 24.04, Amazon Linux 2023, RHEL 10.1, and SUSE 16, highlighting the widespread impact. Multi-tenant Linux hosts, Kubernetes/container clusters, CI runners/build farms, and cloud SaaS environments running user code are at high risk.

Recommendation

• Apply available kernel patches for CVE-2026-31431 on affected Linux distributions, prioritizing multi-tenant environments (e.g., Ubuntu 24.04 LTS, Amazon Linux 2023, RHEL 10.1, SUSE 16).
• As an interim mitigation, disable the vulnerable crypto interface by blocking AF_ALG socket creation or disabling the algif_aead module, as described in the overview.
• Monitor for the execution of unusual processes after the modification of binaries in /tmp or /var/tmp using the Sigma rule “Detect Suspicious Splice Usage for Privilege Escalation”.
• Deploy the Sigma rule “Detect algif_aead module removal” to detect attempts to disable the vulnerable module.

Attack Chain

1. The attacker gains initial local access to the target system through legitimate means or by exploiting a separate vulnerability.
2. The attacker identifies the vulnerable CUPS service running on the system.
3. The attacker crafts a malicious payload designed to exploit the CUPS vulnerability. This payload could be a specially crafted print job or a manipulated configuration file.
4. The attacker executes the malicious payload, triggering the vulnerability in CUPS.
5. Due to the vulnerability, CUPS executes the attacker’s code with administrator privileges.
6. The attacker uses the elevated privileges to install persistent backdoors, modify system configurations, or escalate privileges further.
7. The attacker moves laterally within the network or exfiltrates sensitive data.
8. The final objective is complete system compromise, data theft, or disruption of services.

Impact

Successful exploitation of this CUPS vulnerability allows a local attacker to gain complete control over the affected system. This could lead to data theft, system disruption, or the installation of persistent backdoors. The widespread use of CUPS in Linux and macOS environments makes this a significant threat. If successfully exploited, attackers can achieve complete system compromise and potentially move laterally within the network.

Recommendation

• Monitor for suspicious CUPS processes being spawned by unusual parent processes using the CUPS Spawning Suspicious Processes Sigma rule.
• Inspect CUPS configuration files for unauthorized modifications using the CUPS Configuration File Modification Sigma rule.
• Investigate any unexplained privilege escalation events originating from the CUPS service.

Attack Chain

1. The attacker gains initial access to the system via an unspecified method (e.g., compromised account, physical access).
2. The attacker identifies a vulnerable version of sudo installed on the system.
3. The attacker crafts a malicious sudo command or exploits a configuration flaw to leverage one of the vulnerabilities.
4. Sudo executes the malicious command with elevated privileges due to the vulnerability.
5. The attacker uses the elevated privileges to modify system files or execute commands as root.
6. The attacker installs a backdoor or creates a new privileged account for persistent access.
7. The attacker uses the escalated privileges to access sensitive data or perform other malicious actions.

Impact

Successful exploitation of these vulnerabilities allows a local attacker to gain complete control of the affected system. This can lead to data theft, system corruption, or the installation of malware. The number of potential victims is dependent on the number of systems running vulnerable versions of sudo.

Recommendation

• Monitor process creations for unexpected sudo usage patterns, especially commands run with root privileges that deviate from normal administrative tasks. (See Sigma rule “Detect Suspicious Sudo Usage”).
• Enable audit logging for sudo to capture detailed information about command execution.
• Regularly update sudo to the latest version to patch known vulnerabilities.

Attack Chain

1. The attacker gains initial limited access to the target Linux system through legitimate means or by exploiting a separate vulnerability.
2. The attacker identifies the presence of PackageKit on the system and its accessibility to the current user.
3. The attacker leverages the PackageKit vulnerability. Due to the lack of specific information on the vulnerability, this could involve manipulating PackageKit’s API or command-line interface to perform actions with elevated privileges.
4. PackageKit, due to the vulnerability, incorrectly authorizes the attacker’s request.
5. The attacker executes commands or scripts with elevated privileges, such as root.
6. The attacker installs malicious software or modifies system configurations to establish persistence.
7. The attacker further compromises the system, gaining access to sensitive data and potentially pivoting to other systems on the network.

Impact

Successful exploitation of this vulnerability allows a local attacker to escalate their privileges to root, resulting in complete system compromise. This could lead to data theft, system disruption, and the installation of malware. The number of victims and specific sectors targeted are currently unknown. However, given the widespread use of PackageKit across various Linux distributions, a successful exploit could have broad implications.

Recommendation

• Monitor process creations for unexpected PackageKit activity initiated by non-root users, using the “PackageKit Privilege Escalation - Unexpected Process Invocation” Sigma rule.
• Implement the “PackageKit Privilege Escalation - File Modification” Sigma rule to detect unauthorized modifications to PackageKit configuration files or binaries.
• Investigate any suspicious PackageKit processes identified through monitoring logs, focusing on those running with elevated privileges.

Attack Chain

1. An attacker identifies a vulnerable version of LibRaw within a Red Hat Enterprise Linux system. This may involve scanning for specific LibRaw versions or identifying services reliant on the library.
2. The attacker crafts a malicious raw image file designed to exploit a specific vulnerability in LibRaw’s parsing logic.
3. The attacker delivers the malicious file to the target system. This could involve uploading the file to a web server, emailing it as an attachment, or injecting it into a data stream processed by LibRaw.
4. The vulnerable LibRaw library attempts to process the malicious image file.
5. Due to the vulnerability (e.g., a buffer overflow or integer overflow), LibRaw crashes, leading to a denial-of-service. Alternatively, the attacker gains control of the program counter.
6. The attacker executes arbitrary code within the context of the LibRaw process, potentially gaining control over the entire system.
7. The attacker uses the initial foothold to escalate privileges and move laterally within the network.
8. The final objective is to disrupt services and/or exfiltrate sensitive data.

Impact

Successful exploitation of these vulnerabilities can lead to arbitrary code execution, potentially granting an attacker full control over affected systems. This could result in data breaches, system compromise, and service disruption. A denial-of-service condition could also disrupt critical services reliant on the vulnerable systems. The number of affected systems depends on the prevalence of vulnerable LibRaw versions within Red Hat Enterprise Linux deployments. The specific impact will depend on the privileges of the compromised process and the system’s role within the network.

Recommendation

• Monitor process execution for unexpected child processes spawned by applications utilizing LibRaw (see “Detect Suspicious Process Creation from LibRaw” Sigma rule).
• Implement file integrity monitoring to detect unauthorized modifications to LibRaw binaries (see “Detect LibRaw Binary Modification” Sigma rule).
• Investigate and block any anomalous network connections originating from systems utilizing LibRaw.
• Consult Red Hat security advisories for specific CVEs and patch information as they become available.

Attack Chain

1. Attacker identifies a ProFTPD server exposed to the internet.
2. Attacker crafts a malicious SQL injection payload.
3. Attacker sends the crafted SQL injection payload through a ProFTPD command or parameter.
4. ProFTPD processes the malicious payload without proper sanitization.
5. The payload is passed to the underlying database server.
6. The database executes the injected SQL command.
7. The attacker retrieves sensitive data or modifies database records.
8. Attacker may use the gained access to further compromise the server or network.

Impact

Successful exploitation of the SQL injection vulnerability in ProFTPD allows unauthorized access to the underlying database. This can lead to the disclosure of sensitive information, modification of data, or even complete database compromise. The number of victims and sectors targeted are currently unknown, but public-facing ProFTPD servers are at risk. A successful attack could lead to significant data breaches, service disruption, and reputational damage.

Recommendation

• Apply the latest security patches for ProFTPD as soon as they are available to remediate SQL injection vulnerabilities.
• Monitor ProFTPD logs for suspicious activity and SQL injection attempts (see Sigma rule below).
• Implement proper input validation and sanitization techniques to prevent SQL injection vulnerabilities in ProFTPD configurations.
• Review database access permissions for the ProFTPD user to minimize the impact of potential SQL injection attacks.

Attack Chain

1. Attacker crafts a malicious NTFS image containing a specially designed security descriptor.
2. The security descriptor includes multiple ACCESS_DENIED ACEs.
3. Each ACE within the descriptor contains WRITE_OWNER permissions.
4. The ACEs originate from distinct group SIDs, triggering the overflow condition.
5. The attacker delivers the malicious NTFS image to a system running a vulnerable version of NTFS-3G. This may occur through physical media or network shares.
6. The victim system attempts to read the malicious NTFS image using a vulnerable NTFS-3G version, such as during a stat, readdir, or open operation.
7. The ntfs_build_permissions_posix() function is called to process the security descriptor.
8. The heap buffer overflow occurs during the processing of the malicious ACEs, corrupting heap memory. This can lead to denial of service or potentially arbitrary code execution.

Impact

Successful exploitation of CVE-2026-40706 allows for heap memory corruption in the ntfs-3g binary, which runs with elevated privileges due to its SUID-root configuration. The observed consequence is memory corruption. Depending on the extent of the corruption, this could lead to denial-of-service or arbitrary code execution. Given the wide usage of NTFS-3G for mounting NTFS volumes on Linux and other systems, a successful exploit could affect a large number of systems.

Recommendation

• Upgrade NTFS-3G to version 2026.2.25 or later to patch CVE-2026-40706 (reference: https://github.com/tuxera/ntfs-3g/releases/tag/2026.2.25).
• Monitor systems for unexpected crashes or errors related to ntfs-3g operations, which may indicate exploitation attempts. Deploy the Sigma rules below to your SIEM and tune for your environment.
• Consider implementing stricter access controls and validation measures on NTFS images to prevent the use of malicious images (mitigation based on the vulnerability description).

Attack Chain

1. An attacker identifies a NestJS application running a version prior to 11.1.19.
2. The attacker crafts a TCP packet containing multiple small, valid JSON messages.
3. The attacker sends the crafted TCP packet to the vulnerable NestJS application.
4. The NestJS application’s handleData() function receives the TCP packet.
5. The handleData() function recursively processes each JSON message in the packet.
6. With each recursive call, the buffer shrinks.
7. The maxBufferSize is never reached because of the stack overflow.
8. The call stack overflows, leading to a RangeError and application crash, resulting in a denial of service.

Impact

Successful exploitation of CVE-2026-40879 leads to a denial-of-service condition. A single attacker can potentially bring down a vulnerable NestJS application with a relatively small payload of approximately 47KB. This can impact businesses relying on the affected NestJS application, leading to service disruptions and potential data loss. The vulnerability affects any application using NestJS versions before 11.1.19, making a large number of applications potentially vulnerable.

Recommendation

• Upgrade all NestJS applications to version 11.1.19 or later to patch CVE-2026-40879.
• Deploy the Sigma rule Detect Suspicious NestJS TCP Payload to identify potentially malicious TCP traffic targeting NestJS applications.
• Monitor network traffic for large TCP packets containing many small JSON messages, which may indicate an attempted exploit.

Attack Chain

1. Attacker gains local access to a Linux system running a vulnerable version of util-linux.
2. Attacker identifies a vulnerable utility within the util-linux package. (Specific utility name not provided).
3. Attacker crafts a malicious input or command designed to trigger the vulnerability.
4. Attacker executes the malicious input/command using the vulnerable utility.
5. The vulnerability causes the targeted utility to crash or enter a non-responsive state, contributing to a denial-of-service condition.
6. The vulnerability allows the attacker to read sensitive information from the system’s memory or file system.
7. Attacker exfiltrates the disclosed information.
8. Attacker leverages the disclosed information for further malicious activities.

Impact

Successful exploitation of this vulnerability allows a local attacker to trigger a denial-of-service condition, potentially disrupting critical system services. The attacker can also disclose sensitive information, leading to potential data breaches or further compromise of the system. The number of affected systems is unknown but depends on the prevalence of the vulnerable util-linux version.

Recommendation

• Investigate the specific vulnerable utility and version within util-linux to determine the scope of impact using OS package management tools (dpkg, rpm).
• Monitor process execution for unusual command-line arguments or behaviors associated with util-linux utilities using process_creation logs.
• Deploy the Sigma rules provided in this brief to your SIEM and tune them for your environment.

Attack Chain

1. Attacker identifies a vulnerable Red Hat Hardened Images RPM (jq or pyOpenSSL) running on a target system.
2. Attacker crafts a malicious payload tailored to exploit a specific vulnerability within the identified RPM.
3. The attacker leverages a network connection to send the malicious payload to the target system.
4. The vulnerable RPM processes the payload, triggering the vulnerability (e.g., buffer overflow, arbitrary code injection).
5. The attacker gains unauthorized access to the system with the privileges of the compromised process.
6. The attacker escalates privileges to gain root access, potentially by exploiting further vulnerabilities or misconfigurations.
7. The attacker installs malware or modifies system files to establish persistence.
8. The attacker performs malicious activities, such as data exfiltration, denial-of-service attacks, or further lateral movement within the network.

Impact

Successful exploitation of these vulnerabilities in Red Hat Hardened Images RPMs could result in significant damage. An attacker could gain complete control over the affected systems, leading to data breaches, system outages, and further compromise of the network. The lack of specific vulnerability details makes quantifying the scope of impact difficult, but the potential for code execution makes this a high-priority threat. Affected sectors are broad due to the widespread use of Red Hat systems.

Recommendation

• Deploy the Sigma rule Detect Vulnerable Red Hat Package Installation to identify systems installing or upgrading the jq or pyOpenSSL packages, which may indicate a vulnerable system.
• Investigate systems identified by the Sigma rule for unusual network activity or suspicious processes to find potentially compromised hosts.
• Monitor process creation events for unexpected execution of binaries by the jq or pyOpenSSL processes to detect potential exploitation using the Detect Suspicious Process Execution by Vulnerable RPM Sigma rule.

Attack Chain

1. Attacker compromises the SecureDrop Server, gaining control over its file handling processes.
2. Attacker crafts a malicious gzip archive containing filenames with absolute paths (e.g., /opt/securedrop/client/db.sqlite).
3. Attacker uploads this malicious gzip archive to the compromised SecureDrop Server.
4. The SecureDrop Client retrieves the malicious gzip archive from the SecureDrop Server via Tor.
5. The SecureDrop Client attempts to extract the contents of the gzip archive using a vulnerable extraction routine.
6. Due to improper filename validation, the extraction process overwrites critical files, such as the SQLite database, on the client’s virtual machine (sd-app).
7. The attacker achieves code execution by manipulating the overwritten files to execute arbitrary code upon the next application startup or during normal operation.
8. The attacker gains unauthorized access to decrypted source submissions and can exfiltrate sensitive data.

Impact

Successful exploitation of CVE-2026-35465 allows a compromised SecureDrop Server to execute arbitrary code on the SecureDrop Client’s virtual machine. This leads to a complete breach of confidentiality, integrity, and availability of decrypted source submissions handled by the client. Journalists relying on SecureDrop could have their sources exposed, leading to severe repercussions for both journalists and their sources. The impact is limited to SecureDrop deployments running vulnerable versions (0.17.4 and below).

Recommendation

• Upgrade all SecureDrop Client installations to version 0.17.5 or later to remediate CVE-2026-35465.
• Monitor SecureDrop Client systems for unusual file writes, especially to critical directories such as /opt/securedrop/client/ using the provided Sigma rule.
• Review and harden the SecureDrop Server’s security configuration to prevent initial compromise, as exploitation requires prior access to the server.

Attack Chain

1. An attacker gains local access to a system running a vulnerable version of xrdp (<= 0.10.5) with valid user credentials.
2. The attacker initiates an xrdp session, triggering the vulnerable session execution component.
3. The xrdp session attempts to drop privileges as part of its normal operation.
4. An error occurs during the privilege drop process due to the flaw described in CVE-2026-32107.
5. Due to the improper error handling, the privilege drop fails, or partially fails, leaving the process with elevated privileges.
6. The attacker exploits this partially dropped or retained privilege context. This step requires a currently unspecified, additional exploit.
7. The attacker executes arbitrary code with root privileges due to the incomplete privilege drop.
8. The attacker persists or pivots to other systems based on their elevated access.

Impact

Successful exploitation of CVE-2026-32107 allows a local attacker to gain root privileges on a vulnerable system. This can lead to complete system compromise, including data theft, modification, or destruction. While the vulnerability requires an additional exploit to be fully realized, the high CVSS score reflects the significant impact of a successful attack. The number of potential victims is dependent on the prevalence of vulnerable xrdp versions within an organization’s infrastructure.

Recommendation

• Upgrade xrdp to version 0.10.6 or later to remediate CVE-2026-32107, as per the GitHub release notes (https://github.com/neutrinolabs/xrdp/releases/tag/v0.10.6).
• Monitor systems running xrdp for unexpected privilege escalation attempts or suspicious process behavior.
• Consider deploying the provided Sigma rule to detect suspicious process creation events related to xrdp exploitation.

Attack Chain

1. Attacker gains initial access to a system where they can influence rsync parameters. This could be through a compromised user account or a vulnerable service.
2. Attacker crafts a malicious rsync command that includes the -X or --xattrs option to enable extended attribute processing.
3. The crafted command is executed on the victim machine, targeting a vulnerable rsync version (3.0.1 to 3.4.1).
4. During the receive_xattr function call, the untrusted length value provided by the attacker is passed to the qsort function.
5. The qsort function attempts to sort the extended attributes based on the attacker-controlled length.
6. Due to the manipulated length value, the qsort function accesses memory outside the allocated buffer, leading to a use-after-free condition.
7. The use-after-free condition allows the attacker to potentially overwrite memory with malicious code.
8. The attacker’s code is executed within the context of the rsync process, granting them control of the system.

Impact

Successful exploitation of CVE-2026-41035 can lead to arbitrary code execution on the affected system. The impact can range from data corruption to complete system compromise. Given the widespread use of rsync for data synchronization and backups, a successful attack could affect a large number of systems across various sectors. The vulnerability is particularly concerning on non-Linux platforms, where the likelihood of successful exploitation is higher.

Recommendation

• Upgrade rsync to a version beyond 3.4.1 to patch CVE-2026-41035.
• Implement the file integrity monitoring rule to detect unauthorized modification of rsync binaries.
• Deploy the Sigma rule to detect rsync commands using the -X or --xattrs option, as those options are required to trigger this vulnerability.
• Where possible, disable the use of the -X or --xattrs option for rsync to prevent exploitation of this vulnerability.

Attack Chain

1. Attacker identifies a vulnerable radare2 installation configured on a UNIX system without SSL.
2. Attacker crafts a malicious PDB file name containing embedded OS commands.
3. Attacker supplies the crafted PDB file name as input to the rabin2 -PP command.
4. rabin2 processes the PDB name without proper sanitization.
5. The embedded OS commands within the PDB name are executed by the system.
6. Attacker gains arbitrary code execution within the context of the radare2 process.
7. Attacker leverages the initial access to escalate privileges.
8. Attacker performs malicious actions such as data exfiltration, system compromise, or denial of service.

Impact

Successful exploitation of CVE-2026-41015 allows an attacker to execute arbitrary commands on the affected system. This can lead to complete system compromise, including data theft, malware installation, or denial of service. The impact is particularly severe if radare2 is running with elevated privileges. The number of potential victims is dependent on the number of radare2 installations running vulnerable versions and configurations, but it is estimated to be relatively low due to the specific configuration requirements and the short lifespan of the vulnerable code in the git repository.

Recommendation

• Apply the patch from commit 9236f44 to remediate the command injection vulnerability in radare2.
• Avoid configuring radare2 on UNIX systems without SSL to reduce the attack surface.
• Deploy the Sigma rule radare2-suspicious-rabin2-execution to detect exploitation attempts involving the rabin2 command.
• Monitor process execution for rabin2 with unusual command-line arguments as indicated by the rule radare2-rabin2-pdb-injection.

Attack Chain

1. Attacker crafts a malicious Zarf package.
2. The attacker modifies the zarf.yaml manifest within the package to include a Metadata.Name field containing path traversal sequences (e.g., ../../../../tmp/evil).
3. The attacker repacks the Zarf package, recalculating checksums if necessary.
4. The attacker distributes the malicious Zarf package.
5. A victim user downloads the malicious Zarf package.
6. The victim executes zarf package inspect sbom --output-dir /tmp <malicious-package.tar.zst> or zarf package inspect documentation --output-dir /tmp <malicious-package.tar.zst>.
7. Zarf extracts the Metadata.Name from the zarf.yaml file.
8. Zarf constructs an output path by joining the user-specified output directory (/tmp) with the malicious Metadata.Name (../../../../tmp/evil), resulting in /tmp/../../../../tmp/evil. The tool attempts to write the SBOM or documentation data to this path, resulting in writing the file to /tmp/evil. This allows attackers to write files such as SSH authorized keys, cron jobs, or shell profiles.

Impact

Successful exploitation of this vulnerability allows an attacker to write arbitrary files to the file system, limited by the permissions of the user running the zarf package inspect command. This can lead to several critical consequences: privilege escalation by writing to authorized_keys files, arbitrary code execution by writing cron jobs, or persistent compromise by writing to shell profiles. This vulnerability affects users running the zarf package inspect sbom or zarf package inspect documentation command on untrusted packages. The affected packages are go/github.com/zarf-dev/zarf versions >= 0.23.0 and < 0.74.2.

Recommendation

• Upgrade Zarf to version v0.74.2 or later to patch CVE-2026-40090.
• Avoid inspecting unsigned Zarf packages as a workaround until the upgrade is complete, as mentioned in the advisory.
• Deploy the Sigma rule “Detect Zarf Package Inspection with Path Traversal” to identify attempts to exploit this vulnerability via command-line arguments.
• Monitor file creation events in sensitive directories (e.g., /home/$USER/.ssh, /etc/cron.d) for files created by the zarf binary using the “Detect Zarf Arbitrary File Write” Sigma rule.

Attack Chain

1. The attacker analyzes the jq source code and identifies the use of MurmurHash3 with the hardcoded seed 0x432A9843.
2. The attacker develops a script to generate JSON keys that will collide with each other when hashed using MurmurHash3 and the specific seed.
3. The attacker crafts a JSON object, approximately 100KB in size, containing numerous colliding keys.
4. The attacker submits this malicious JSON object to a system running jq, potentially via an API endpoint or as input to a data processing script.
5. The jq process parses the JSON object and attempts to perform hash table lookups. Due to the collisions, these lookups become extremely slow, consuming excessive CPU resources.
6. The CPU utilization on the target system spikes, potentially impacting the performance of other applications.
7. The jq process may become unresponsive or crash due to resource exhaustion.
8. The system experiences a denial-of-service condition, preventing legitimate users or processes from accessing jq functionality.

Impact

Successful exploitation of CVE-2026-40164 can lead to denial-of-service conditions on systems utilizing the jq JSON processor. The vulnerability impacts environments where jq is used, including CI/CD pipelines, web services, and data processing scripts. If successfully exploited, critical processes relying on jq may become unavailable, leading to disruptions in automated workflows, web application outages, and data processing delays. The relatively small size of the malicious JSON payload (approximately 100KB) makes this vulnerability practical and easily exploitable.

Recommendation

• Upgrade to jq version containing commit 0c7d133c3c7e37c00b6d46b658a02244fdd3c784 or later to patch the vulnerability (reference: CVE-2026-40164).
• Monitor CPU utilization on systems running jq for unusually high activity, especially when processing JSON data, to detect potential exploitation attempts (reference: Attack Chain - Step 6).
• Implement resource limits and rate limiting on services that accept JSON input to mitigate the impact of denial-of-service attacks (reference: Impact).

Attack Chain

1. A malicious user, with privileges to submit builds to the Nix daemon, crafts a Nix derivation designed to exploit the vulnerability.
2. The malicious derivation includes instructions to create a symlink within the build chroot. This symlink points to a sensitive system file outside of the chroot environment, such as /etc/shadow or /etc/passwd.
3. The Nix daemon initiates the build process within a sandboxed environment. The derivation builder creates the specified symlink during the build.
4. During the fixed-output derivation output registration phase, the Nix process attempts to copy the output from the temporary output location to the Nix store.
5. The Nix process encounters the malicious symlink. Due to insufficient validation, it follows the symlink to the target file in the root filesystem.
6. The Nix process overwrites the contents of the target file with the derivation’s output, effectively modifying the sensitive system file.
7. By overwriting a file like /etc/shadow, the attacker can manipulate user account information, including password hashes.
8. The attacker gains root privileges by logging in as a modified or newly created user.

Impact

Successful exploitation of this vulnerability in multi-user Nix installations allows any user capable of submitting builds to the Nix daemon to achieve root privilege escalation. This could lead to complete system compromise, including data theft, modification, or destruction. The severity is critical because it bypasses standard security measures and directly impacts system integrity. The number of potentially affected systems is broad, encompassing any Linux system utilizing a vulnerable version of Nix in a multi-user configuration, which is a common setup.

Recommendation

• Immediately upgrade Nix to version 2.34.5, 2.33.4, 2.32.7, 2.31.4, 2.30.4, 2.29.3, or 2.28.6 to patch CVE-2026-39860.
• Monitor process creation events for suspicious activity related to nix-daemon and file modifications in sensitive directories such as /etc/passwd and /etc/shadow using the provided Sigma rule.
• Implement file integrity monitoring (FIM) on sensitive system files to detect unauthorized modifications.
• Regularly audit and restrict the allowed-users configuration of the Nix daemon to minimize the attack surface.

Attack Chain

1. Attacker identifies a vulnerable parseusbs instance running a version prior to 1.9.
2. The attacker crafts a malicious volume path argument containing shell metacharacters (e.g., ;/).
3. The attacker executes parseusbs with the -v flag, supplying the crafted volume path as the argument. Example: parseusbs -v "; command"
4. parseusbs passes the unsanitized volume path argument to the os.popen() function along with the ls command.
5. The os.popen() function executes the combined command within a shell, injecting the attacker’s commands.
6. The injected commands are executed with the privileges of the parseusbs process.
7. The attacker gains arbitrary command execution, potentially leading to system compromise.
8. The attacker achieves persistence, lateral movement, or data exfiltration depending on the injected commands.

Impact

Successful exploitation of CVE-2026-40030 allows an attacker to execute arbitrary commands on the system where parseusbs is running. This can lead to a full system compromise, including data theft, modification, or destruction. Given a CVSS v3.1 score of 7.8, this vulnerability is considered high severity. While specific victim counts and sectors are unknown, any system running a vulnerable version of parseusbs is at risk, particularly if the application processes user-supplied volume paths.

Recommendation

• Upgrade parseusbs to version 1.9 or later to remediate CVE-2026-40030 (Reference: Overview).
• Deploy the Sigma rule Detect Suspicious Parseusbs Command Line Arguments to identify potential exploitation attempts (Reference: Rules).
• Monitor command-line arguments passed to parseusbs for shell metacharacters (e.g., ;/|&) (Reference: Attack Chain).

Attack Chain

1. Attacker identifies a vulnerable Podman Desktop instance running a version prior to 1.26.2 exposed on the network.
2. Attacker connects to the unauthenticated HTTP server exposed by Podman Desktop.
3. The attacker sends a large number of HTTP requests without proper connection management.
4. The server fails to enforce connection limits, leading to an exhaustion of available file descriptors on the host system.
5. The attacker sends specially crafted requests designed to trigger resource-intensive operations, consuming excessive kernel memory.
6. As file descriptors and kernel memory are depleted, the Podman Desktop application becomes unresponsive.
7. The system experiences a denial-of-service condition, potentially leading to application crash or a full host freeze.
8. The attacker analyzes verbose error responses to gain insights into internal paths and system details, potentially including usernames on Windows, to prepare for further attacks.

Impact

Successful exploitation of CVE-2026-34045 can lead to a complete denial-of-service of the Podman Desktop application, disrupting container and Kubernetes development workflows. In severe cases, the entire host system may freeze, requiring a reboot and causing data loss or corruption. The information disclosure aspect of the vulnerability, leaking internal paths and usernames, can aid attackers in crafting more targeted and sophisticated attacks against the compromised system. The lack of authentication makes all installations of vulnerable Podman Desktop versions potential targets, impacting developers and organizations relying on this tool.

Recommendation

• Immediately upgrade Podman Desktop to version 1.26.2 or later to patch CVE-2026-34045.
• Implement network segmentation and firewall rules to restrict access to the Podman Desktop HTTP server only to trusted networks, mitigating external exploitation.
• Deploy the Sigma rule “Detect Excessive HTTP Requests to Podman Desktop” to identify potential denial-of-service attempts against vulnerable Podman Desktop instances.
• Monitor webserver logs for unusual HTTP requests and error responses from Podman Desktop, correlating them with potential exploitation attempts. Enable webserver logging to activate the rule above.

Attack Chain

1. Attacker identifies a vulnerable OpenSSH server running on an Ubuntu Linux system with GSSAPI enabled.
2. Attacker initiates an SSH connection to the target server.
3. During the GSSAPI authentication exchange, the attacker sends a specially crafted request.
4. The vulnerable OpenSSH GSSAPI implementation fails to properly handle the malicious request.
5. The server enters an unstable state due to the unhandled exception or memory corruption.
6. The OpenSSH process crashes, leading to a denial-of-service.
7. Repeated exploitation can keep the SSH service unavailable, preventing legitimate users from accessing the system.

Impact

Successful exploitation of this vulnerability can result in a denial-of-service condition, rendering the affected OpenSSH server unavailable. This can disrupt critical services relying on SSH for remote access and management. The number of potential victims is widespread, affecting any Ubuntu Linux system running a vulnerable version of OpenSSH with GSSAPI enabled. The impact ranges from temporary service outages to prolonged inaccessibility of affected systems, potentially leading to significant operational disruptions.

Recommendation

• Monitor network connections for unusual SSH traffic patterns, particularly those involving GSSAPI authentication (see the “Detect Suspicious SSH GSSAPI Authentication” rule).
• Review OpenSSH server logs for error messages or crashes occurring during GSSAPI authentication attempts (see the “Detect OpenSSH GSSAPI Authentication Failures” rule and enable detailed logging).
• Investigate any instances of OpenSSH processes crashing or becoming unresponsive, especially after receiving inbound network connections.
• Stay informed about future security updates from OpenSSH and Ubuntu Linux that address this vulnerability, and apply them promptly upon release.

Attack Chain

1. The attacker crafts a malicious ZIP archive containing a specially crafted skill file.
2. The filenames within the ZIP archive include path traversal sequences such as ../.
3. The attacker uploads the malicious ZIP archive to the prompts.chat application.
4. prompts.chat processes the uploaded ZIP archive without properly sanitizing the filenames.
5. The application extracts the contents of the ZIP archive, writing files to locations specified in the malicious filenames.
6. Path traversal sequences in the filenames allow the attacker to write files outside the intended extraction directory.
7. The attacker overwrites shell initialization files (e.g., .bashrc, .profile, .bash_profile) or other executable files.
8. When a user logs in or a new shell is spawned, the overwritten initialization file executes malicious code, granting the attacker arbitrary code execution on the system.

Impact

Successful exploitation of CVE-2026-22661 allows an attacker to write arbitrary files to the client system, leading to potential overwrite of sensitive system files and arbitrary code execution. The vulnerability affects systems running vulnerable versions of prompts.chat. The impact includes complete compromise of the system, data theft, and further propagation of malicious activities.

Recommendation

• Apply the patch by upgrading to commit 0f8d4c3 or later to remediate CVE-2026-22661.
• Implement server-side filename validation and sanitization to prevent path traversal attacks when handling ZIP archives within prompts.chat.
• Deploy the Sigma rules provided in this brief to your SIEM to detect potential exploitation attempts.
• Monitor web server logs for suspicious requests containing path traversal sequences in filenames as identified by the provided rules.

Attack Chain

1. An attacker gains local access to a Linux system with the vulnerable Amazon Athena ODBC driver installed (version before 2.0.5.1).
2. The attacker crafts specially crafted connection parameters designed to inject OS commands. This could involve manipulating fields expected by the driver to trigger command execution.
3. The attacker initiates a connection to Amazon Athena using the vulnerable ODBC driver and the crafted connection parameters.
4. The ODBC driver attempts to authenticate using the browser-based authentication component, loading the malicious connection parameters.
5. Due to the vulnerability, the crafted parameters are not properly sanitized, leading to OS command injection.
6. The injected OS commands are executed on the system with the privileges of the user running the ODBC driver.
7. The attacker can leverage the command execution to install malware, create new user accounts, or exfiltrate sensitive data.

Impact

Successful exploitation of CVE-2026-5485 allows an attacker to execute arbitrary commands on a vulnerable Linux system. The impact includes potential data theft, system compromise, and lateral movement within the network. Given the nature of command injection, the attacker has significant control over the compromised system, allowing for a wide range of malicious activities. Organizations using the affected Amazon Athena ODBC driver on Linux should prioritize patching to mitigate this risk.

Recommendation

• Upgrade the Amazon Athena ODBC driver to version 2.0.5.1 or later on all Linux systems to remediate CVE-2026-5485.
• Monitor process creation events on Linux systems for unusual processes spawned by the ODBC driver using the Sigma rules provided below.
• Implement strict access control policies on Linux systems to limit the ability of attackers to leverage local access to exploit the vulnerability.
• Enable logging for ODBC driver activity and review logs for suspicious connection attempts.
• Deploy the provided Sigma rule to detect potential exploitation attempts by monitoring for command line arguments indicative of command injection.

Attack Chain

1. An attacker gains initial access to a system with kubectl installed and configured to interact with a Kubernetes cluster.
2. The attacker executes the kubectl command with arguments like port-forward to create a local port that forwards traffic to a service or pod within the cluster.
3. The attacker uses kubectl proxy to create a proxy server that allows them to access the Kubernetes API server from their local machine.
4. The attacker employs kubectl expose to create a new service that exposes a deployment, replication controller, or pod as a new Kubernetes service, potentially opening up unintended access points.
5. The attacker may execute these commands from a shell like bash, or from a script located in a temporary directory like /tmp/ or /var/tmp/, to evade detection.
6. The attacker leverages the modified network configurations to establish unauthorized access to sensitive services or data within the Kubernetes cluster.
7. The attacker may use the proxied or forwarded connections to exfiltrate data from the cluster to an external location.

Impact

Successful exploitation via kubectl network configuration modification can lead to unauthorized access to sensitive data and services within a Kubernetes cluster. This can result in data breaches, service disruptions, and lateral movement within the cluster. The low severity score suggests that while the risk exists, the impact might be limited if proper Kubernetes security best practices are followed. The rule aims to detect these actions early, preventing potential damage to the cluster.

Recommendation

• Enable Elastic Defend integration or equivalent EDR solutions to monitor process execution and network connections (Data Source: Elastic Defend, Data Source: Crowdstrike, Data Source: SentinelOne).
• Deploy the provided Sigma rule to detect suspicious kubectl commands with network-related arguments (rules section). Tune the rule based on your environment to minimize false positives.
• Investigate any alerts generated by the Sigma rule, focusing on the parent process and the command-line arguments of the kubectl command (rules section, Resources: Investigation Guide).
• Implement enhanced monitoring and logging for kubectl activities and network configuration changes within the Kubernetes cluster to proactively detect and respond to similar threats in the future (Resources: Investigation Guide).

Attack Chain

1. The attacker gains initial access to the Linux system, possibly through exploitation of a vulnerability or stolen credentials (not detailed in source).
2. The attacker deploys the BPFDoor backdoor onto the compromised system.
3. BPFDoor establishes persistence by injecting itself into the kernel using eBPF.
4. BPFDoor attempts to blend in with legitimate system activity by accessing or manipulating process ID (.pid) and lock (.lock) files in the /var/run directory.
5. Specifically, BPFDoor may access files like /var/run/aepmonend.pid, /var/run/auditd.lock, /var/run/cma.lock, /var/run/console-kit.pid, /var/run/consolekit.pid, /var/run/daemon.pid, /var/run/hald-addon.pid, /var/run/hald-smartd.pid, /var/run/haldrund.pid, /var/run/hp-health.pid, /var/run/hpasmlit.lock, /var/run/hpasmlited.pid, /var/run/kdevrund.pid, /var/run/lldpad.lock, /var/run/mcelog.pid, /var/run/system.pid, /var/run/uvp-srv.pid, /var/run/vmtoolagt.pid, and /var/run/xinetd.lock.
6. This access may involve reading, writing, or modifying these files to conceal its presence.
7. BPFDoor uses the eBPF-based communication channel to receive commands from a remote attacker.
8. The attacker executes arbitrary commands on the compromised system, potentially leading to data theft, system disruption, or further lateral movement.

Impact

A successful BPFDoor infection can lead to a persistent and stealthy backdoor on a Linux system. Given the nature of eBPF, detection is difficult, potentially allowing attackers long-term access to the system and sensitive data. Telecom networks are specifically mentioned, indicating potential disruption of critical communications infrastructure. The number of victims and specific damage caused varies per deployment.

Recommendation

• Deploy the Sigma rule BPFDoor Abnormal Process ID or Lock File Accessed to your SIEM to detect suspicious access to lock and PID files in /var/run based on auditd logs.
• Investigate any alerts triggered by the Sigma rule, focusing on identifying the process accessing the lock or PID file and whether it is legitimate.
• Implement network monitoring to identify unusual eBPF activity.
• Regularly review and update intrusion detection systems (IDS) signatures to include known BPFDoor indicators.

Attack Chain

1. A local attacker gains access to the target RHEL system.
2. The attacker crafts a malicious XSLT stylesheet designed to exploit the libxslt vulnerability.
3. The attacker leverages a local program that uses libxslt to parse the crafted stylesheet. This could be a custom application or a common utility that relies on libxslt for XSLT processing.
4. When the vulnerable libxslt library parses the malicious stylesheet, it triggers a buffer overflow or other memory corruption vulnerability.
5. The memory corruption allows the attacker to overwrite critical system memory or inject malicious code.
6. If a DoS condition is triggered, the affected service or application crashes, leading to a disruption of service.
7. If the attacker successfully injects and executes arbitrary code, they gain control of the affected process with the privileges of the user running the application.
8. The attacker can then leverage their gained access to escalate privileges and perform further malicious activities on the system, such as installing backdoors or exfiltrating sensitive data.

Impact

Successful exploitation of this vulnerability can lead to a denial-of-service condition, causing the affected application or service to crash and become unavailable. More critically, it can allow a local attacker to execute arbitrary code with the privileges of the user running the vulnerable application. This could lead to full system compromise if the affected application runs with elevated privileges. The impact is amplified in environments where libxslt is used to process untrusted or user-supplied XSLT files.

Recommendation

• Identify all systems running Red Hat Enterprise Linux that utilize the libxslt library.
• Monitor process creations for suspicious child processes spawned by applications utilizing libxslt with the provided Sigma rules.
• When available, apply the appropriate patches or updates for libxslt provided by Red Hat to remediate the vulnerability.
• Implement strict input validation and sanitization for XSLT stylesheets processed by applications to mitigate the risk of exploitation.

Attack Chain

1. Attacker gains write access to the aquasecurity/trivy-action repository on GitHub.
2. The attacker modifies the action’s entrypoint.sh script to include malicious code for credential theft. Specifically, the attacker prepends approximately 105 lines of malicious code.
3. The attacker uses git tag repointing to retroactively poison existing release tags (e.g., @0.24.0) to point to the malicious commit.
4. Developers’ CI/CD pipelines reference the compromised trivy-action using a poisoned tag (e.g., aquasecurity/trivy-action@0.24.0).
5. When a workflow runs, the GitHub Actions runner downloads and executes the malicious entrypoint.sh script, granting it access to the runner’s environment, secrets, and network.
6. The malicious script enumerates running processes to identify potential targets for credential theft.
7. The malicious code exfiltrates credentials and secrets.
8. The original trivy scanner is executed, masking the malicious activity and allowing the workflow to complete normally.

Impact

The compromise of the trivy-action GitHub Action allowed attackers to steal credentials and secrets from CI/CD pipelines that used the compromised action. Because the malicious code ran with the full privileges of the runner, it had access to sensitive information such as API keys, deployment tokens, and cloud credentials. The number of affected organizations is unknown, but given the widespread adoption of trivy-action, the potential impact is significant. Successful exploitation can lead to unauthorized access to cloud resources, code repositories, and other sensitive systems.

Recommendation

• Inspect your CI/CD pipeline configurations for usage of the aquasecurity/trivy-action and audit the integrity of the referenced tags against the known good commits, if available from Aqua Security’s advisories.
• Implement tooling and processes to verify the integrity of third-party GitHub Actions used in CI/CD pipelines.
• Monitor process execution on GitHub Actions runners for suspicious activity, such as enumeration of processes or unexpected network connections (see Sigma rule below).
• Enable and review process creation logs on CI/CD runner environments to identify anomalous script execution (see Sigma rule below).

Attack Chain

1. The attacker identifies a vulnerable act instance running a version prior to 0.2.86 with its cache server exposed on all interfaces.
2. The attacker probes the exposed act cache server to determine accessible endpoints and version information.
3. The attacker analyzes common GitHub Actions workflows and identifies predictable cache keys.
4. The attacker crafts a malicious cache archive containing payloads designed for remote code execution.
5. The attacker uploads the malicious cache archive to the vulnerable act instance using the predicted cache key.
6. A legitimate user triggers a local GitHub Actions workflow using act.
7. The act instance retrieves the attacker’s malicious cache archive instead of the expected legitimate cache.
8. The malicious payload within the cache is executed within the Docker container, leading to remote code execution on the host system running act.

Impact

Successful exploitation of this vulnerability allows an attacker to achieve arbitrary remote code execution on the host system running the vulnerable version of act. This can lead to complete system compromise, data theft, and further lateral movement within the network. The vulnerability affects any user running a version of act prior to 0.2.86 with the cache server exposed. While the number of directly affected users is unknown, the potential impact on development environments and CI/CD pipelines is significant.

Recommendation

• Upgrade to version 0.2.86 or later of the act project to remediate the vulnerability (CVE-2026-34042).
• Implement network access controls to restrict access to the act cache server to only trusted networks and hosts.
• Monitor network connections to the act cache server for unexpected or unauthorized access.
• Enable process monitoring on systems running act to detect potentially malicious processes spawned from Docker containers.

Attack Chain

Since the specific vulnerabilities are not detailed, the following attack chain represents a generalized exploitation scenario:

1. Vulnerability Discovery: The attacker identifies a vulnerable version of NGINX or NGINX Plus through reconnaissance.
2. Exploit Development/Acquisition: The attacker develops a custom exploit or obtains one from public or private sources targeting the identified vulnerability (e.g., buffer overflow, integer overflow, or configuration flaw).
3. Target Selection: The attacker identifies a vulnerable NGINX instance exposed to the network.
4. Initial Exploitation: The attacker sends a specially crafted request to the targeted NGINX server, triggering the vulnerability. This might involve manipulating HTTP headers, crafting specific URL parameters, or exploiting flaws in request handling.
5. Privilege Escalation (if needed): Depending on the vulnerability, the attacker may need to escalate privileges to gain full control of the system. This could involve exploiting additional vulnerabilities or misconfigurations.
6. Data Manipulation/Security Bypass/DoS: The attacker leverages the exploited vulnerability to manipulate data served by NGINX, bypass authentication or authorization mechanisms, or initiate a denial-of-service attack by consuming excessive resources.
7. Arbitrary Code Execution (Potential): If the vulnerability allows, the attacker executes arbitrary code on the NGINX server, potentially installing malware, establishing persistence, or using the compromised server as a pivot point for further attacks.
8. Lateral Movement/Exfiltration (Potential): After gaining a foothold, the attacker may attempt to move laterally within the network, compromising other systems and exfiltrating sensitive data.

Impact

Successful exploitation of these vulnerabilities can lead to significant damage. A denial-of-service attack can disrupt critical services, causing financial losses and reputational damage. Data manipulation can compromise the integrity of information served by NGINX, leading to incorrect decisions or further attacks. Bypassing security measures can grant unauthorized access to sensitive resources. Arbitrary code execution allows the attacker to take complete control of the server, potentially leading to data theft, system compromise, and further attacks on internal infrastructure. The exact number of potential victims is unknown, but it could be extensive given the widespread use of NGINX and NGINX Plus.

Recommendation

• Upgrade NGINX and NGINX Plus to the latest patched versions to remediate known vulnerabilities.
• Implement the “Detect Suspicious Nginx Configuration Changes” Sigma rule to detect unauthorized modifications to the Nginx configuration.
• Deploy the “Detect Nginx DoS Attempts” Sigma rule to monitor for suspicious traffic patterns indicative of a denial-of-service attack against Nginx.
• Implement strict access controls to limit exposure of NGINX servers to untrusted networks.
• Regularly review NGINX configuration files for misconfigurations and security vulnerabilities.

Attack Chain

1. The attacker gains valid credentials for the 389 Directory Server, possibly through credential stuffing, phishing, or other means.
2. The attacker establishes an authenticated connection to the 389 Directory Server (likely over LDAP or LDAPS).
3. The attacker crafts a malicious request that exploits the vulnerability within 389-ds-base. This request could involve a specially formatted LDAP query or modification operation.
4. The vulnerable code within 389-ds-base processes the malicious request, leading to arbitrary code execution in the context of the 389 Directory Server process.
5. The attacker leverages the initial code execution to escalate privileges to root or another privileged account. This could involve exploiting other vulnerabilities or misconfigurations on the system.
6. The attacker installs malware, backdoors, or other malicious tools on the compromised system.
7. Alternatively, the attacker triggers a denial-of-service condition, causing the 389 Directory Server to crash or become unresponsive.
8. The attacker uses the compromised system as a foothold to move laterally within the network, targeting other critical systems and data.

Impact

Successful exploitation of this vulnerability could allow attackers to gain complete control of Red Hat Enterprise Linux systems running the 389 Directory Server. This could lead to data breaches, system outages, and further compromise of the network. The potential for denial-of-service attacks could disrupt critical services and impact business operations. The number of affected systems depends on the prevalence of 389-ds-base deployments within an organization’s infrastructure.

Recommendation

• Apply the security patches provided by Red Hat for the 389-ds-base package to remediate the vulnerability.
• Deploy the Sigma rules below to your SIEM to detect potential exploitation attempts targeting 389-ds-base.
• Monitor authentication logs for the 389 Directory Server for suspicious login attempts or unusual activity.
• Review and enforce strong password policies to mitigate the risk of credential compromise.
• Implement network segmentation to limit the impact of a potential breach.

Attack Chain

1. A user-space program triggers a specific kernel function that queues a work item to a workqueue.
2. The work item is scheduled for execution, but before it begins, the user-space program requests cancellation of the work item via a workqueue cancellation API.
3. Due to a race condition or improper synchronization, the work item is canceled but not fully removed from the workqueue’s internal data structures.
4. The kernel attempts to access the work item after it has been freed, resulting in a use-after-free vulnerability.
5. An attacker manipulates memory layout to place controlled data at the memory location of the freed work item.
6. The kernel code now operates on the attacker-controlled data, leading to memory corruption or information leakage.
7. The attacker leverages the memory corruption to overwrite critical kernel data structures, such as function pointers or security credentials.
8. Successful exploitation leads to privilege escalation, allowing the attacker to execute arbitrary code with kernel-level privileges.

Impact

The ‘Out-of-Cancel’ vulnerability class can lead to severe consequences, including kernel crashes (denial of service), privilege escalation, and potentially arbitrary code execution within the kernel. A successful exploit could allow an attacker to gain complete control over the affected system. Due to the ubiquitous nature of the Linux kernel, a wide range of systems are potentially vulnerable, impacting servers, desktops, embedded systems, and mobile devices. While the exact number of vulnerable systems is unknown, the widespread use of affected kernel versions implies a significant potential impact.

Recommendation

• Monitor kernel logs for errors related to workqueue cancellations to detect potential exploitation attempts. Enable auditd to log kernel function calls related to workqueue management (audit.rules).
• Deploy the Sigma rule Detect Potential Use-After-Free in Workqueue Cancellation to identify suspicious kernel events related to workqueue operations.
• Investigate any reported kernel panics or crashes, focusing on stack traces that involve workqueue-related functions.
• Stay informed about kernel patches and security advisories related to workqueue vulnerabilities and apply them promptly.

Attack Chain

1. The attacker gains initial local access to a Linux system.
2. The attacker identifies a vulnerable application linked against the affected GNU libc library.
3. The attacker crafts a malicious input specifically designed to exploit the vulnerability within the glibc library. This could involve manipulating function calls, memory allocation, or other glibc functionalities.
4. The attacker executes the vulnerable application with the crafted malicious input.
5. The malicious input triggers the vulnerability within glibc, allowing the attacker to inject arbitrary code into the application’s memory space.
6. The attacker’s injected code executes within the context of the vulnerable application, potentially gaining elevated privileges or access to sensitive data.
7. The attacker leverages the compromised application to further escalate privileges or move laterally within the system.
8. The attacker achieves their final objective, which could include data exfiltration, system compromise, or denial of service.

Impact

Successful exploitation of this vulnerability allows a local attacker to execute arbitrary code, potentially leading to complete system compromise. The attacker gains the privileges of the user running the vulnerable application. The widespread use of glibc across Linux systems makes this vulnerability a significant threat. While the number of victims is unknown, the potential impact is high across various sectors using Linux-based infrastructure. A successful attack can result in data breaches, system instability, and unauthorized access to sensitive information.

Recommendation

• Monitor process execution for unusual activity indicative of code injection, focusing on processes utilizing glibc functions (Enable process_creation logging).
• Deploy the Sigma rule “Detect glibc Exploitation via Malicious Input” to your SIEM to identify potential exploitation attempts.
• Investigate any abnormal behavior or crashes in applications that rely on glibc.
• Implement strict access control policies to limit unauthorized local access to systems.

Attack Chain

1. The attacker gains local access to a Red Hat Enterprise Linux system. This could be achieved through various means, such as compromising a user account or exploiting a separate vulnerability to gain initial access.
2. The attacker crafts a malicious XSLT stylesheet specifically designed to exploit the libxslt vulnerability. This stylesheet could contain code intended for execution or file manipulation.
3. The attacker utilizes a program or script that leverages libxslt to process the crafted malicious stylesheet. This could involve using command-line tools or applications that rely on libxslt for XML transformations.
4. During the processing of the malicious stylesheet, the libxslt vulnerability is triggered, leading to the execution of arbitrary code within the context of the application using libxslt.
5. The attacker leverages the code execution to escalate privileges on the system, potentially gaining root access.
6. Alternatively, the attacker uses the vulnerability to manipulate files on the system, modifying configurations, injecting malicious code into existing files, or exfiltrating sensitive data.
7. The attacker maintains persistence on the compromised system, ensuring continued access and control.
8. The attacker achieves their objective, which could be data theft, system disruption, or further lateral movement within the network.

Impact

Successful exploitation of this vulnerability could allow a local attacker to gain complete control over the affected Red Hat Enterprise Linux system. This may lead to data breaches, system outages, or the installation of backdoors for persistent access. Given the widespread use of RHEL in enterprise environments, a successful attack could have significant consequences across various sectors. The potential for arbitrary code execution and file manipulation makes this a high-severity vulnerability.

Recommendation

• Monitor process execution for unexpected or unusual activity involving libxslt binaries using the provided Sigma rule Detect Suspicious Libxslt Process Execution.
• Implement file integrity monitoring to detect unauthorized modifications to critical system files using the Sigma rule Detect Malicious File Modification via Libxslt.
• Regularly audit user privileges and access controls to minimize the potential impact of a successful exploit.
• Investigate and remediate any identified instances of potentially malicious XSLT stylesheets being processed on RHEL systems.

Attack Chain

1. An attacker gains initial access to a system through an unspecified vulnerability.
2. The attacker attempts to execute a malicious binary from /tmp or /dev/shm.
3. Inner Warden’s LSM hook blocks the execution of the binary, preventing the initial execution attempt.
4. The attacker attempts to escalate privileges by exploiting a vulnerability, triggering the commit_creds kprobe.
5. Inner Warden detects the privilege escalation attempt.
6. The attacker attempts to establish a command-and-control (C2) connection.
7. Inner Warden detects the C2 callback and blocks the attacker’s IP address using XDP, preventing further communication.
8. Inner Warden nodes share signals of the suspicious activity, prompting other nodes within the mesh to adjust their behavior, increasing security across the distributed environment.

Impact

Successful deployment of Inner Warden could prevent privilege escalation attacks, block execution of malicious code from temporary directories, disrupt command-and-control communication, and mitigate brute force and port scanning attempts. A compromised node could potentially send false positives, but Inner Warden’s trust scoring is designed to avoid large-scale disruption. The primary impact is improved host security posture and potentially reduced incident response workload through automated threat mitigation.

Recommendation

• Deploy the process creation rule below to detect executions blocked by Inner Warden’s LSM hook from /tmp or /dev/shm.
• Deploy the network connection rule to identify C2 callbacks blocked by Inner Warden’s XDP-based IP blocking.
• Investigate any alerts generated by the privilege escalation detection rule, indicating potential exploitation attempts.
• Monitor for alerts generated by Inner Warden regarding potential poisoning or false positives.

Attack Chain

1. Initial Compromise: An attacker gains initial access to a Linux system through methods such as exploiting vulnerabilities or using stolen credentials.
2. Privilege Escalation: Once inside, the attacker attempts to escalate privileges to gain root access using exploits or misconfigurations.
3. Persistence Establishment: The attacker employs various Linux persistence mechanisms to ensure continued access to the compromised system. These techniques include manipulating init scripts, cron jobs, and systemd services.
4. Init Script Modification: The attacker modifies init scripts located in /etc/init.d/ or /etc/rc.d/ to execute malicious code during system startup.
5. Cron Job Manipulation: The attacker schedules malicious tasks using cron jobs by adding entries to /etc/crontab or user-specific crontab files.
6. Systemd Service Modification: The attacker creates or modifies systemd service files in /etc/systemd/system/ to execute malicious code as a service.
7. Reverse Shell Installation: The attacker installs a reverse shell to maintain persistent access by connecting back to an attacker-controlled server. This may involve techniques like download-execute or obfuscation.
8. Data Exfiltration/Malicious Activity: With persistent access established, the attacker proceeds to exfiltrate sensitive data, deploy ransomware, or perform other malicious activities.

Impact

Successful exploitation and persistence within a Linux environment can allow attackers to maintain long-term access, leading to data theft, system disruption, or the deployment of ransomware. The impact can range from data breaches and financial losses to reputational damage and operational downtime. The scope of impact depends on the level of access gained and the attacker’s objectives.

Recommendation

• Deploy the Sigma rule for detecting init script modifications to identify potential persistence attempts (reference: Sigma rule for init script modification).
• Deploy the Sigma rule for detecting cron job modifications to identify potential persistence attempts (reference: Sigma rule for cron job modification).
• Regularly audit systemd service configurations for unauthorized modifications using the Sigma rule (reference: Sigma rule for systemd service modification).
• Use Persistnux or similar tools to regularly scan systems for known persistence mechanisms and review the generated reports (reference: Persistnux tool).

Attack Chain

1. Attacker gains initial local access to a vulnerable Linux system.
2. Attacker crafts a malicious AppArmor profile or modifies an existing one to exploit parsing vulnerabilities. This could involve exploiting weaknesses in how AppArmor handles specific characters, escape sequences, or profile directives.
3. The attacker loads the crafted profile using apparmor_parser or a similar tool.
4. The vulnerable AppArmor implementation fails to correctly parse the profile, leading to a bypass of security restrictions.
5. Attacker executes a program or script that would normally be blocked by AppArmor under a correctly enforced profile.
6. Due to the bypassed restrictions, the attacker gains access to resources or capabilities normally restricted to the root user.
7. Attacker leverages these elevated privileges to execute arbitrary commands as root.
8. The attacker achieves full system compromise, including data exfiltration, installation of malware, or other malicious activities.

Impact

Successful exploitation of these vulnerabilities allows a local, unprivileged attacker to gain complete control over a vulnerable Linux system. This can lead to data breaches, system downtime, and the installation of persistent backdoors. The scope of impact depends on the prevalence of vulnerable AppArmor versions in different Linux distributions. Systems relying on AppArmor for security isolation are particularly at risk, potentially undermining container security or application sandboxing.

Recommendation

• Consult the Qualys blog post (linked in references) for specific CVE identifiers and patch information as soon as it is released.
• Apply patches for AppArmor as soon as they become available from your Linux distribution vendor.
• Monitor system logs for suspicious use of apparmor_parser and other AppArmor utilities.
• Audit existing AppArmor profiles for potential vulnerabilities and misconfigurations.

Attack Chain

1. An attacker gains initial access to a host system, possibly through exploiting a vulnerability in an application running outside the container (e.g., web application).
2. The attacker identifies a containerized application running on the compromised host.
3. The attacker exploits a vulnerability within the container, or abuses a privileged workload within the container, to gain elevated privileges or code execution within the container.
4. The attacker uses curl or wget to download additional tools or scripts into the container. These tools might include reverse shells, credential dumping tools, or data exfiltration utilities.
5. The attacker executes the downloaded tools to further compromise the container or the underlying host.
6. The attacker uses curl or wget to stage data for exfiltration to an external server. This may involve compressing and encoding data before transmission.
7. The attacker initiates the data exfiltration process using curl or wget to send the staged data to a remote server controlled by the attacker.
8. The attacker achieves their final objective, which could include data theft, system disruption, or further lateral movement within the network.

Impact

Compromised containers can lead to data breaches, service disruptions, and further attacks on internal systems. Successful exploitation could allow attackers to steal sensitive data, install malware, or pivot to other parts of the network, impacting confidentiality, integrity, and availability. The number of affected systems depends on the scope of the container deployment and the privileges granted to the compromised container.

Recommendation

• Deploy the Sigma rule Detect Curl or Wget Execution from Container Context to your SIEM and tune for your environment.
• Enable Auditd Manager with syscall coverage including execve to capture process execution and arguments within containers, as mentioned in the rule’s setup instructions.
• Correlate alerts from this rule with network logs to identify the destination IP addresses and domains contacted by the compromised container.
• Baseline trusted images and exclude stable image digests or namespaces when noisy to reduce false positives, as suggested in the rule’s false positives section.

Attack Chain

1. Initial access is gained via exploitation of a vulnerability in a web application or web server component running on a Linux system (e.g., through SQL injection or remote code execution).
2. A web shell is uploaded to the compromised web server, often disguised as a legitimate file or hidden within existing directories.
3. The attacker interacts with the web shell through HTTP requests, using it as a command and control interface.
4. The web shell executes commands on the server, initiating outbound network connections to non-standard ports.
5. These connections may be used to communicate with external C2 servers, download additional payloads, or exfiltrate sensitive data.
6. The attacker uses the web shell to move laterally within the network, targeting other systems and services.
7. The attacker attempts to establish persistence on the compromised server, ensuring continued access even after system reboots.
8. The final objective is data theft, system compromise, or disruption of services.

Impact

Compromised web servers can lead to significant data breaches, system downtime, and reputational damage. While this rule triggers on low-severity behavior, successful exploitation can lead to complete system compromise. The number of affected systems depends on the scope of the initial vulnerability and the attacker’s ability to move laterally. Organizations in all sectors that rely on web-based applications are potentially at risk.

Recommendation

• Deploy the provided Sigma rule to your SIEM to detect web server processes initiating connections to unusual destination ports and tune for your environment.
• Enable Elastic Defend integration to collect the necessary network event data from Linux endpoints to activate the rule.
• Review and customize the list of excluded destination ports and internal IP ranges in the Sigma rule to match your organization’s specific network configuration and legitimate traffic patterns.
• Investigate any alerts generated by the rule to determine if the activity is malicious or benign, focusing on the process name, user, destination IP, and destination port.

Attack Chain

1. Attacker gains initial access to a container with limited privileges.
2. The attacker exploits a vulnerability within the container to execute code as the runc init process.
3. The runc init process spawns a child process while retaining a non-root user ID in audit telemetry.
4. The child process is assigned an effective user ID of 0 (root), bypassing normal permission controls.
5. The attacker leverages the elevated privileges to modify sensitive files or execute commands as root within the container’s namespace.
6. The attacker may then attempt to escape the container by exploiting kernel vulnerabilities or misconfigurations to gain access to the host system.
7. Upon gaining access to the host system, the attacker can install malware, steal sensitive data, or disrupt services.

Impact

A successful privilege escalation attack within a container environment can lead to complete compromise of the container and potentially the host system. This can result in data breaches, service disruptions, and unauthorized access to sensitive resources. The impact is significant because a single compromised container can become a launchpad for attacks against other containers or the underlying infrastructure.

Recommendation

• Deploy the Sigma rule “Potential Privilege Escalation via Runc Init” to your SIEM to detect suspicious runc init process executions.
• Enable Linux audit logging via the Auditd Manager integration, ensuring that execve and identity-related fields are captured.
• Investigate any alerts generated by the Sigma rule by examining the full audit event details, including process ancestry, user IDs, and container metadata.
• Review container configurations and security profiles to identify potential misconfigurations that could facilitate privilege escalation.
• Implement network segmentation to limit the blast radius of a compromised container.

Attack Chain

1. An attacker gains initial access to a Linux system, potentially through a compromised account or vulnerability exploitation.
2. The attacker identifies privileged commands they need to execute to achieve their objectives, such as gaining root access or modifying sensitive files.
3. To evade detection, the attacker obfuscates their commands using techniques like encoding, compression, or complex string manipulation.
4. The attacker executes the obfuscated privileged commands via the command line.
5. Elastic Defend or Sysmon Linux captures the command-line activity and logs it to Elasticsearch.
6. The Privileged Access Detection ML job analyzes the command lines and calculates their entropy.
7. If the entropy exceeds a predefined threshold, the ML job flags the activity as anomalous and generates an alert.
8. Security analysts investigate the alert to determine the nature of the suspicious activity and take appropriate action.

Impact

A successful privilege escalation can grant an attacker complete control over a Linux system, allowing them to steal sensitive data, install malware, or disrupt critical services. While this rule itself triggers on unusual command line activity, the underlying behavior could lead to a full system compromise. The number of potential victims is directly related to the scope of the Linux environment being monitored. Sectors commonly targeted by privilege escalation attacks include technology, finance, and government.

Recommendation

• Deploy the Privileged Access Detection integration and ensure that Linux logs from Elastic Defend or Sysmon Linux are being ingested (Setup section).
• Review and tune the machine learning job pad_linux_high_median_process_command_line_entropy_by_user_ea to minimize false positives based on your environment (False positive analysis section in rule).
• Create a case management workflow triggered by the “High Command Line Entropy Detected for Privileged Commands” rule to ensure alerts are promptly investigated.
• Implement the remediation steps outlined in the investigation guide to contain and eradicate any confirmed malicious activity (Response and remediation section).

Attack Chain

1. An attacker gains initial access to a container or a restricted session on a Linux host.
2. The attacker identifies a target PID, often the init process (PID 1), to enter its namespace.
3. The attacker executes the nsenter command with the --target or -t flag, specifying the target PID. Additional namespace flags like --mount, --uts, --ipc, --net, and --user may also be used.
4. Auditd logs the nsenter execution, capturing the process name, arguments, and other relevant metadata.
5. The detection rule identifies the nsenter execution based on the command name and the presence of the --target or -t flag.
6. The attacker, now within the target PID’s namespace, executes commands with the privileges of that process. This may include reading sensitive files, modifying system configurations, or executing malicious code.
7. The attacker leverages the escalated privileges to further compromise the host system, potentially gaining root access or deploying malware.
8. The attacker establishes persistence mechanisms to maintain access to the compromised host, such as creating new systemd units or modifying existing ones.

Impact

Successful exploitation can lead to complete compromise of the host system. Attackers can gain root privileges, access sensitive data, and deploy malware. In containerized environments, this can allow attackers to escape the container and access the underlying host, potentially affecting other containers running on the same host. The impact is especially significant in production environments where compromised hosts can disrupt critical services and expose sensitive data.

Recommendation

• Deploy the Auditd Manager integration on Linux hosts to collect process execution telemetry, as specified in the setup instructions.
• Implement the Sigma rule “Nsenter to PID Namespace via Auditd” to detect suspicious nsenter executions.
• Tune the Sigma rule by excluding known false positives, such as legitimate nsenter executions by platform engineers or CNI/snap workflows, as mentioned in the false positives section.
• Investigate any detected nsenter executions by reviewing process arguments, parent processes, user identities, and host information, as outlined in the triage and analysis section.
• Isolate any compromised hosts, revoke credentials, inspect for persistence, and re-image if integrity cannot be proven, as recommended in the response and remediation section.

Attack Chain

1. An attacker gains initial access to a Linux system, potentially through exploiting a vulnerability or using compromised credentials.
2. The attacker identifies cron job directories, such as /etc/cron.d/ or /var/spool/cron/crontabs/.
3. The attacker creates a new cron file within one of these directories.
4. The cron file contains malicious commands or scripts designed to execute at a specific time or interval. This could include commands to download and execute malware or establish a reverse shell.
5. The cron daemon automatically executes the commands specified in the newly created cron file according to the defined schedule.
6. The attacker gains persistent access to the system, allowing them to maintain control even after reboots.
7. The attacker may escalate privileges by scheduling commands that run with elevated permissions.
8. The attacker uses the persistent access to perform further malicious activities, such as data exfiltration or lateral movement.

Impact

Successful exploitation can grant attackers persistent access to compromised Linux systems, potentially leading to privilege escalation and unauthorized execution of arbitrary code. This can lead to data breaches, system compromise, and disruption of services. The impact is magnified if the compromised system has access to sensitive information or critical infrastructure.

Recommendation

• Deploy the Sigma rule “Detect New Cron File Creation” to your SIEM to detect the creation of cron files in cron directories and tune for your environment.
• Monitor file creation events in cron directories such as /etc/cron.d/, /etc/cron.daily/, /etc/cron.hourly/, /etc/cron.monthly/, /etc/cron.weekly/, /var/spool/cron/crontabs/, and /var/spool/cron/root using file_event logs.
• Baseline normal cron file creation activity and apply additional filters to reduce false positives based on the specific environment, as mentioned in the rule description.

Attack Chain

1. An attacker gains initial access to a compromised container or host within the Kubernetes cluster, potentially through exploiting a vulnerability in a running application.
2. The attacker executes a reconnaissance command, such as curl or wget, from within the compromised container, targeting the Kubelet API on port 10250 or 10255.
3. The curl or wget command is executed from a temporary directory like /tmp or /dev/shm to avoid detection.
4. The attacker attempts to enumerate running pods and services by querying the /pods or /runningpods endpoints of the Kubelet API.
5. If successful, the attacker identifies a target pod within the cluster based on the enumerated information.
6. The attacker leverages the Kubelet API to execute commands within the target pod, potentially escalating privileges or accessing sensitive data.
7. The attacker attempts to move laterally to other nodes or containers within the Kubernetes cluster, repeating the reconnaissance and exploitation steps.
8. The ultimate goal is to gain control over the entire Kubernetes cluster, enabling data exfiltration, resource hijacking, or disruption of services.

Impact

Successful exploitation of the Kubelet API can lead to a complete compromise of the Kubernetes cluster. Attackers can gain unauthorized access to sensitive data, escalate privileges, and disrupt critical services. While the number of victims may vary depending on the organization’s security posture, a successful attack could impact all applications and data managed by the cluster. Organizations in any sector utilizing Kubernetes are potentially at risk.

Recommendation

• Enable syscall auditing and ensure that event.category:network events are generated for network connections, as outlined in the rule’s setup guide.
• Deploy the provided Sigma rule to your SIEM and tune it based on your environment to reduce false positives.
• Restrict pod-to-node access to port 10250 using network policies or security groups to limit the attack surface, as noted in the rule’s documentation.
• Implement Kubernetes API audit logging to detect unauthorized access attempts and credential access, correlating with process argument telemetry as mentioned in the triage steps.

Attack Chain

1. A malicious or compromised process gains initial access to the host system.
2. The process attempts to connect to the container runtime socket (e.g., /var/run/docker.sock or /run/containerd/containerd.sock).
3. The process bypasses the Kubernetes API server and associated security controls.
4. The attacker exploits the direct socket connection to create a new container.
5. The attacker gains access to sensitive data or resources within the container.
6. The attacker escalates privileges within the compromised container.
7. The attacker uses the compromised container to move laterally to other containers or hosts within the environment.
8. The attacker achieves their objective, such as data exfiltration or system compromise.

Impact

Successful exploitation allows attackers to bypass Kubernetes security measures, create unauthorized containers, and potentially gain control over the entire cluster. The observed impact includes privilege escalation, lateral movement, and data exfiltration. The severity of this attack depends on the level of access granted to the compromised container and the sensitivity of the data and resources within the cluster.

Recommendation

• Enable Auditd Manager to capture network and socket events, specifically monitoring for connect calls to Unix sockets as described in the Auditd Manager documentation.
• Deploy the Sigma rule “Unusual Process Connecting to Docker or Containerd Socket” to detect suspicious processes connecting to container runtime sockets, tuning process.executable and user.name for known legitimate processes.
• Monitor file permissions on the socket paths (/var/run/docker.sock, /run/docker.sock, /var/run/containerd/containerd.sock, /run/containerd/containerd.sock) and restrict access to trusted groups only.

Attack Chain

1. A non-privileged user gains initial access to the system, potentially through compromised credentials or exploiting a vulnerability.
2. The attacker navigates to a user-writable directory such as /tmp or /home/<user>.
3. The attacker crafts a malicious script or uses a one-liner command to invoke a SUID binary.
4. The SUID binary (e.g., sudo, pkexec, su) is executed with minimal arguments.
5. The system executes the command with root privileges due to the SUID bit being set on the binary.
6. The attacker leverages the elevated privileges to modify system files, install malicious software, or create new administrative accounts.
7. The attacker establishes persistence to maintain access to the compromised system.
8. The attacker achieves their final objective, which could include data exfiltration, system disruption, or further lateral movement within the network.

Impact

Successful exploitation of SUID binaries can lead to full system compromise. An attacker can gain complete control over the affected Linux system, potentially leading to data breaches, service disruptions, and the installation of persistent malware. This can affect critical infrastructure and sensitive data, causing significant financial and reputational damage. The severity is amplified when multiple systems are compromised, allowing for lateral movement and further exploitation within the network.

Recommendation

• Enable process creation logging and ensure that process.user.id, process.real_user.id, and process.parent.user.id are being captured to activate the rules below.
• Deploy the “Suspicious SUID Binary Execution” Sigma rule to your SIEM and tune for your environment.
• Review authentication and sudoers policies to identify and remediate any misconfigurations.
• Investigate any alerts generated by the Sigma rules to determine the legitimacy of the SUID binary execution and the parent process context.
• Implement file integrity monitoring on sensitive system binaries and directories, particularly those related to privilege escalation, to detect unauthorized modifications.
• Restrict the use of SUID binaries where possible and enforce strict permissions on those that are necessary.

Attack Chain

1. An attacker gains initial access to a Linux system through various means, such as exploiting a vulnerability or compromising credentials.
2. The attacker uses a utility like cp, cat, or curl to access sensitive files such as /var/run/secrets/kubernetes.io/serviceaccount/token or /root/.ssh/id_rsa.
3. Auditd logs the file access event, capturing details about the process, user, and file path.
4. The detection rule identifies the suspicious process based on its name, executable path (e.g., /tmp/*), or command-line arguments.
5. The rule checks if the accessed file is in the list of sensitive identity files.
6. If both conditions are met, the rule triggers an alert, indicating potential unauthorized access to sensitive credentials.
7. The attacker exfiltrates the stolen credentials or uses them to move laterally within the network.
8. The attacker uses the stolen credentials to access cloud resources or other sensitive systems.

Impact

Successful exploitation 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 financial losses. The targeted files contain credentials for Kubernetes clusters, cloud environments (AWS, Azure, Google Cloud), and SSH keys, potentially impacting a wide range of resources. The impact is particularly severe in environments where these credentials are used for managing critical infrastructure or accessing sensitive data.

Recommendation

• Deploy the Auditd Manager integration with the specified audit rules in the provided setup steps to monitor access to sensitive identity files on Linux systems. Ensure auditd is properly configured and running (auditctl -l) to generate the necessary logs.
• Deploy the Sigma rules provided to detect suspicious processes accessing sensitive identity files and tune them for your environment by excluding legitimate processes or users as needed.
• Investigate alerts generated by the Sigma rules, focusing on the process name, executable, parent command line, and the accessed file path to determine the legitimacy of the access.
• Review and harden file permissions on shared credential stores to prevent unauthorized access. Rotate exposed keys and tokens and invalidate cloud sessions if a compromise is suspected, as suggested in the rule’s documentation.

Attack Chain

1. An attacker crafts a malicious PyPI package containing specially formatted metadata, including an RPM macro directive (e.g., within the package summary).
2. A Fedora packager, intending to package a legitimate Python package, uses pyp2spec to generate an RPM spec file from the malicious PyPI package.
3. pyp2spec writes the attacker-controlled metadata, including the unescaped RPM macro directive, into the generated spec file.
4. The packager, or an automated system, uses an RPM tool like rpmbuild -bs, rpmbuild --nobuild, or rpm -q --specfile to inspect or build the package from the spec file.
5. The RPM tool parses the spec file and, upon encountering the RPM macro directive, executes the embedded command.
6. The attacker’s command executes on the build machine, potentially granting the attacker access to the packager’s credentials (dist-git SSH keys, Koji build credentials, Bodhi update credentials).
7. The attacker uses the compromised credentials to commit malicious source code to the distribution’s Git repository (dist-git).
8. The malicious code is built and distributed to end users through the normal package update pipeline, resulting in a supply chain attack.

Impact

Successful exploitation allows attackers to execute arbitrary commands on the build machine. This can lead to the compromise of sensitive credentials, such as SSH keys and build system credentials. In the Fedora ecosystem, this could enable an attacker to inject malicious code into packages that are distributed to end users, potentially affecting millions of systems. The vulnerability poses a high risk to package maintainers and build systems.

Recommendation

• Upgrade to pyp2spec version 0.14.1 or later to remediate the code injection vulnerability as described in the advisory (https://github.com/advisories/GHSA-r35x-v8p8-xvhw).
• Implement file integrity monitoring on RPM spec files, alerting on unexpected modifications, to detect potentially malicious injected code. Use file_event logs with a rule like the one below.
• Monitor process executions originating from RPM tools (rpmbuild, rpm), focusing on unusual or unexpected commands that could indicate exploitation, using process_creation logs and the Sigma rule provided.

Attack Chain

1. An attacker gains initial access to a Linux system through an undisclosed method (e.g., exploiting a vulnerability or social engineering).
2. The attacker uploads or creates a script containing a base64-encoded payload.
3. The attacker uses a Python one-liner, invoking the python interpreter.
4. The Python script imports the base64 module.
5. The script decodes the base64-encoded payload using functions like b64decode, b32decode, or similar.
6. The decoded payload is executed using eval() or exec() within the same Python one-liner.
7. The executed payload establishes persistence, downloads further malware, or performs lateral movement.
8. The attacker achieves their objective, such as data exfiltration or system compromise.

Impact

Successful exploitation can lead to a full system compromise, data exfiltration, or the deployment of persistent backdoors. The obfuscation techniques make detection difficult, potentially allowing attackers to operate undetected for extended periods. While the specific number of victims and targeted sectors remain unknown, the technique’s effectiveness in evading security measures makes it a high-priority threat.

Recommendation

• Deploy the Sigma rule “Detect Python Base64 One-Liners - Linux” to your SIEM to detect the execution of Python one-liners utilizing base64 decoding (logsource: process_creation/linux).
• Investigate any process creation events matching the Sigma rule, focusing on the parent processes and executed commands to identify the source of the malicious activity.
• Enable and monitor process creation logs on Linux systems to ensure visibility of command-line execution, which is essential for detecting this type of attack (logsource: process_creation/linux).
• Implement application control policies to restrict the execution of unsigned or untrusted scripts, mitigating the risk of malicious payload execution after decoding.

Attack Chain

1. Attacker compromises a mirror, HTTP repository, or poisons a CDN cache used by apko.
2. A user initiates an apko build process, specifying a package to be included in the image.
3. Apko requests the specified package from the compromised source.
4. The attacker substitutes the legitimate package with a malicious or altered .apk package.
5. Apko downloads the substituted package.
6. Apko verifies the signature on APKINDEX.tar.gz but fails to validate the downloaded .apk package against the checksum in the index.
7. Apko installs the malicious or altered package into the container image.
8. The resulting container image is built with the compromised package, potentially leading to arbitrary code execution or other malicious activity when the image is deployed.

Impact

Successful exploitation of this vulnerability allows an attacker to inject arbitrary packages into container images built with vulnerable versions of apko. This can lead to a variety of adverse outcomes, including arbitrary code execution within containers, data exfiltration, and denial-of-service attacks. The lack of package validation provides a significant opportunity for attackers to compromise the integrity of containerized applications and infrastructure.

Recommendation

• Upgrade to apko version 1.2.7 or later once a fix is available from the vendor.
• Monitor network traffic for unexpected connections to untrusted or unusual package repositories using network connection logs and create rules to alert on such activity.
• Implement integrity monitoring on the build system to detect unauthorized modification of files, specifically focusing on downloaded packages. This can be achieved through file integrity monitoring tools that generate file_event logs.
• Deploy the provided Sigma rule to detect suspicious process executions within containers shortly after the build process.

Attack Chain

1. An attacker gains initial access to a Linux system, potentially through exploiting a vulnerability in a containerized application.
2. The attacker executes the unshare command.
3. unshare creates new namespaces, isolating the attacker’s process from the rest of the system.
4. The attacker attempts to mount sensitive directories from the host system into the new namespace.
5. Using the newly gained access, the attacker attempts to modify system files, such as /etc/passwd or /etc/shadow, to create new privileged accounts.
6. The attacker leverages the elevated privileges to install persistent backdoors or malware on the host system.
7. The attacker attempts to move laterally to other systems on the network.
8. The attacker achieves their final objective, such as data exfiltration or system disruption.

Impact

Successful exploitation via unshare can lead to privilege escalation, container escape, and unauthorized access to sensitive resources on the host system. The impact includes potential data breaches, system compromise, and lateral movement within the network. While the number of victims is unknown, the widespread use of containerization technologies makes this a significant threat, particularly for organizations relying on Linux-based container environments and cloud infrastructures.

Recommendation

• Deploy the Sigma rule Namespace Manipulation Using Unshare to your SIEM to detect suspicious unshare command executions and tune for your environment.
• Enable Auditbeat or Elastic Defend to collect the necessary process execution data to trigger the provided Sigma rule, as outlined in the rule’s setup section.
• Review and tune the provided Sigma rule’s exclusion list based on your environment’s legitimate use cases for unshare, as described in the “False positive analysis” section.
• Implement additional monitoring and alerting for unusual unshare usage patterns to enhance detection capabilities and prevent future occurrences as recommended in the “Response and remediation” section.

Attack Chain

1. A containerized process is compromised, potentially through an initial exploit or misconfiguration.
2. The attacker executes the unshare command within the container.
3. unshare is used to create new namespaces, isolating the attacker’s process from the container’s limitations.
4. The attacker manipulates these namespaces to gain access to resources outside the container.
5. The attacker attempts to escape the container by leveraging the newly created namespaces.
6. Upon successful escape, the attacker gains access to the host system.
7. The attacker escalates privileges on the host, potentially exploiting vulnerabilities or misconfigurations.
8. The attacker achieves full control over the host system, allowing for data exfiltration, system compromise, or lateral movement.

Impact

Successful exploitation can lead to container escape, allowing attackers to gain unauthorized access to the host system. This can result in privilege escalation, data exfiltration, and complete system compromise. The rule aims to detect and prevent such attacks by identifying suspicious usage of the unshare command, helping to maintain the integrity and security of containerized environments.

Recommendation

• Deploy the provided Sigma rule to your SIEM to detect suspicious unshare executions within containers and tune for your environment.
• Review and whitelist legitimate uses of unshare by system management tools like udevadm and systemd-udevd to reduce false positives, as mentioned in the rule’s description.
• Implement additional monitoring and alerting for unusual unshare usage patterns to enhance detection capabilities and prevent future occurrences.

Attack Chain

1. Attacker gains initial access to a compromised host within the Kubernetes environment.
2. Attacker downloads or transfers the kubeletctl binary to the compromised host.
3. Attacker executes kubeletctl scan to identify accessible Kubelet API endpoints by scanning for open ports 10250 and 10255.
4. Attacker uses kubeletctl pods to enumerate running pods on a targeted node based on the scan results.
5. Attacker leverages kubeletctl exec or kubeletctl attach to gain shell access to a pod.
6. Attacker uses the compromised pod to move laterally within the Kubernetes cluster, potentially accessing sensitive data or resources.
7. Attacker may attempt to access Kubernetes credentials, such as service account tokens or kubeconfigs, for further privilege escalation.

Impact

Successful exploitation can allow attackers to enumerate pods and nodes, execute commands within containers, and potentially move laterally within the Kubernetes cluster. This could lead to unauthorized access to sensitive data, resource hijacking, or complete compromise of the Kubernetes environment. The CyberArk research cited in the references describes how kubeletctl can be leveraged to attack Kubernetes clusters.

Recommendation

• Deploy the Sigma rule Potential Kubeletctl Execution to detect suspicious execution of the kubeletctl binary on Linux hosts, focusing on command-line arguments such as scan, pods, exec, and attach.
• Monitor host and container telemetry for connections to Kubelet ports (10250/10255) using a network connection rule and look for scanning patterns across multiple nodes.
• Restrict access to Kubelet ports at the network layer and harden Kubelet authentication/authorization based on the recommendations in the provided references.
• Rotate/revoke any exposed Kubernetes credentials (service account tokens, kubeconfigs, client certs) and investigate for follow-on discovery or execution attempts.

Attack Chain

1. An attacker gains initial access to a container, possibly through exploiting a vulnerability in a containerized application.
2. The attacker identifies a container with weak configurations, such as exposed PIDs, shared namespaces, or privileged mounts.
3. The attacker executes nsenter with the -t or --target flag, specifying a target PID or namespace.
4. The nsenter command joins the target namespace (mount, network, PID, user, or IPC) based on specified flags (-m, -n, -p, -U, or -i).
5. The attacker gains access to the host system’s resources or processes due to the namespace sharing or privileged access.
6. The attacker escalates privileges on the host system, potentially gaining root access.
7. The attacker pivots to other containers or the host infrastructure, expanding their control.
8. The attacker achieves their final objective, such as data exfiltration, system disruption, or deploying malware on the host.

Impact

A successful container escape can allow an attacker to compromise the underlying host system. This can lead to the compromise of other containers running on the same host, as well as sensitive data stored on the host system. The impact can range from data breaches to complete infrastructure takeover. If the host is a node in a Kubernetes cluster, the attacker might be able to compromise the entire cluster.

Recommendation

• Deploy the Sigma rule Detect Nsenter Container Escape to your SIEM and tune for your environment to detect suspicious nsenter executions within containers.
• Review container configurations and enforce least privilege to prevent unauthorized namespace sharing and privileged mounts.
• Monitor container logs for nsenter executions with target flags, as indicated by the log source logs-cloud_defend.process* and the query in this brief.
• Restrict the use of hostPath volumes and other sensitive mounts within container deployments.
• Reduce recurrence by avoiding host namespace sharing, restricting hostPath and sensitive mounts, and blocking unnecessary capabilities.