Auditbeat — CraftedSignal Threat Feed

Potential Copy Fail (CVE-2026-31431) Exploitation via AF_ALG Socket

hello@craftedsignal.io — Thu, 30 Apr 2026 16:24:01 +0000

CVE-2026-31431, dubbed Copy Fail, is a Linux kernel vulnerability that allows an attacker to write controlled bytes into the page cache of a readable file by abusing the authencesn AEAD path through AF_ALG and splice(). Public exploitation targets setuid-root binaries such as /usr/bin/su, then executes the corrupted in-memory copy to gain root. The vulnerability lies in the shared host page cache, making container-originated activity a possible node-compromise attempt. This exploit leverages the AF_ALG interface, which, while uncommon for unprivileged users, may be used in specific environments like kernel crypto testing or HSM integrations. Defenders should prioritize patching vulnerable kernels and restricting AF_ALG socket creation for untrusted workloads to mitigate this risk.

Attack Chain

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

Unusual Process Connecting to Docker or Containerd Socket

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

This threat involves unauthorized processes connecting directly to container runtime sockets (Docker or Containerd) on Linux systems. This bypasses Kubernetes API server restrictions, potentially allowing attackers to create, execute, or manipulate containers without proper authorization or logging. The risk lies in attackers circumventing RBAC, admission webhooks, and pod security standards. The attack can start when a compromised process attempts to connect to the Docker or Containerd socket, potentially leading to privilege escalation and lateral movement within the containerized environment. This attack is significant because it undermines core security controls within container orchestration platforms.

Attack Chain

A malicious or compromised process gains initial access to the host system.
The process attempts to connect to the container runtime socket (e.g., /var/run/docker.sock or /run/containerd/containerd.sock).
The process bypasses the Kubernetes API server and associated security controls.
The attacker exploits the direct socket connection to create a new container.
The attacker gains access to sensitive data or resources within the container.
The attacker escalates privileges within the compromised container.
The attacker uses the compromised container to move laterally to other containers or hosts within the environment.
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.

Suspicious Unshare Usage for Namespace Manipulation

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

The unshare command in Linux is a utility used to create new namespaces, providing isolation for processes. While crucial for containerization and security, attackers can misuse unshare to escape container boundaries or escalate privileges by manipulating system namespaces. This occurs by creating namespaces that bypass established security controls. This activity is often observed when threat actors attempt to gain unauthorized access to host resources or elevate their privileges within a compromised system. The focus of this detection is on identifying unusual unshare executions that deviate from legitimate system management activities.

Attack Chain

An attacker gains initial access to a Linux system, potentially through exploiting a vulnerability in a containerized application.
The attacker executes the unshare command.
unshare creates new namespaces, isolating the attacker’s process from the rest of the system.
The attacker attempts to mount sensitive directories from the host system into the new namespace.
Using the newly gained access, the attacker attempts to modify system files, such as /etc/passwd or /etc/shadow, to create new privileged accounts.
The attacker leverages the elevated privileges to install persistent backdoors or malware on the host system.
The attacker attempts to move laterally to other systems on the network.
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.