Gafgyt Malware Broadens Its Scope in Recent Attacks

The Gafgyt malware attack begins with the exploitation of misconfigured Docker Remote API servers, allowing attackers to gain initial access and deploy malicious containers. BlueRock's Container Capability Control effectively mitigates this step by ensuring that only containers with specified capabilities are permitted to run, thereby preventing the deployment of unauthorized or malicious containers like those used in the Gafgyt attack. Once the container is deployed, the attacker attempts to escalate privileges by using 'chroot' and 'bind' to mount the host's root directory, potentially gaining control over the host system. BlueRock's Container Runtime Socket Protection (Available 2024 Dec) further secures this environment by restricting container capabilities, thus preventing unauthorized access to the host's filesystem and thwarting privilege escalation attempts. These mechanisms collectively ensure that the deployment and execution of malicious containers are effectively controlled and monitored, significantly reducing the risk of such attacks.

• T1133: External Remote Services: The attackers targeted misconfigured Docker Remote API servers to spread the Gafgyt malware. This indicates that the attackers gained initial access through exploiting external remote services that were improperly secured, allowing them to connect to and manipulate these services remotely.
• T1610: Deploy Container: The attackers deployed the Gafgyt malware by creating a Docker container using a legitimate 'alpine' docker image. This shows the use of the 'Deploy Container' technique, where the attacker utilizes containerization to execute their malicious payload.
• T1611: Escape to Host: The article mentions that the attacker used 'chroot' and 'Binds' to mount the host's root directory to the /mnt directory inside the container. This allowed the container to access and modify the host's filesystem, representing a privilege escalation through escaping the container to the host.
• T1059.004: Command and Scripting Interpreter: Unix Shell: The attackers downloaded the Gafgyt botnet binary as a file named 'rbot' and executed it. This action is an example of using a command and scripting interpreter, specifically a Unix shell, to execute commands on the compromised system.
• T1105: Ingress Tool Transfer: The article describes the attacker downloading the Gafgyt botnet binary from a remote location to the Docker container. This process involves transferring tools or payloads into a compromised environment, aligning with the 'Ingress Tool Transfer' technique.
• T1071: Application Layer Protocol: The Gafgyt malware communicates with a command-and-control server using hardcoded IP addresses and ports. This is indicative of the 'Application Layer Protocol' technique, where malware uses standard protocols to communicate with its C2 infrastructure.
• T1016: System Network Configuration Discovery: The Gafgyt malware performs a network discovery action by determining the local IP address of the victim host using Google's DNS server. This aligns with the 'System Network Configuration Discovery' technique, where the malware gathers information about the network interfaces and configurations.
• T1498: Network Denial of Service: The primary impact of the Gafgyt malware deployment is launching distributed denial-of-service (DDoS) attacks using various protocols like UDP, TCP, and HTTP. This represents the 'Network Denial of Service' technique, where the goal is to disrupt the availability of targeted systems or networks.

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.