Let’s break down how the attack unfolds step by step:
让我们一步一步地分解攻击是如何展开的：
1. Probing the Docker Remote API server
1. 探测 Docker Remote API 服务器
The sequence of events in this attack campaign begins with a ping to the Docker Remote API server, which serves as the pivotal starting point for the ensuing chain of actions.
此攻击活动中的事件序列始于对 Docker 远程 API 服务器的 ping 操作，该服务器是后续操作链的关键起点。
2. Creating the container using the cmd.cat/chattr image:
2. 使用 cmd.cat/chattr 映像创建容器：
Upon confirming the server’s status as “OK,” the attacker proceeds to instantiate a container using the cmd.cat/chattr image.
在确认服务器的状态为“正常”后，攻击者继续使用 cmd.cat/chattr 映像实例化容器。
In the container creation request, we see the malicious actor employing chroot and volume binding to escape the container. Using chroot, the attacker can peek outside the container and then enter the host system using the Binds parameter, which specifies volume bindings.
在容器创建请求中，我们看到恶意行为者使用 chroot 和卷绑定来转义容器。使用 chroot，攻击者可以窥视容器外部，然后使用 Binds 参数进入主机系统，该参数指定卷绑定。
The binding /:/hs mounts the host’s root directory into the container’s /hs directory, granting the attacker unrestricted access to the host file system. It also binds the Docker socket (/var/run/docker.sock:/var/run/docker.sock), giving the container direct access to the Docker daemon on the host, therefore allowing the attackers to control Docker as if they were on the host machine itself.
绑定 /：/hs 将主机的根目录挂载到容器的 /hs 目录中，从而授予攻击者对主机文件系统的无限制访问权限。它还绑定 Docker 套接字 （/var/run/docker.sock：/var/run/docker.sock），使容器能够直接访问主机上的 Docker 守护程序，从而允许攻击者控制 Docker，就像他们在主机本身上一样。
3. Image creation in absence
3. 缺席时的图像创作
If the above request returns a “No such image” response, the attacker will pull the chattr docker image from the cmd.cat repository.
如果上述请求返回“No such image”响应，攻击者将从 cmd.cat 仓库中拉取 chattr docker 镜像。
4. Container deployment 4. 容器部署
With the image in place, the attacker proceeds to create a Docker container, effectively executing a replica of the previous step.
映像就位后，攻击者继续创建 Docker 容器，从而有效地执行上一步的副本。
While creating the docker container, the malicious actor executes a base64-encoded string:
在创建 docker 容器时，恶意参与者会执行 base64 编码的字符串：
This translates to the following shell script:
这将转换为以下 shell 脚本：
The script starts with a conditional check to determine if a file named “z” exists in the directory /usr/sbin/. If the file does not exist, the script proceeds to download and execute the malicious binary from its file server (hxxp[:]/leetdbs[.]anondns[.]net/z) and saves it to the directory /usr/sbin/, which is potentially ZiggyStarTux, an open-source IRC bot based on the Kaiten malware. This binary is packed using the UPX packer.
该脚本以条件检查开始，以确定目录 /usr/sbin/ 中是否存在名为“z”的文件。如果文件不存在，则脚本将继续从其文件服务器 （hxxp[：]/leetdbs[.] 下载并执行恶意二进制文件。anondns[.]net/z） 并将其保存到 /usr/sbin/ 目录，该目录可能是 ZiggyStarTux，一个基于 Kaiten 恶意软件的开源 IRC 机器人。此二进制文件使用 UPX 打包器打包。
While doing the analysis, we found the C&C server to be down. However, the following User-Agent strings present in the binary can be used to monitor the presence of this malware in the network:
在进行分析时，我们发现 C&C 服务器已关闭。但是，二进制文件中存在的以下用户代理字符串可用于监视网络中是否存在此恶意软件：
- User-Agent: HackZilla/1.67 [en] (X11; U; Linux 2.2.16-3 x64)
用户代理：HackZilla/1.67 （X11;一;Linux 2.2.16-3 x64）
- User-Agent: Mozilla/4.75 [en] (X11; U; Linux 2.2.16-3 i686)
用户代理：Mozilla/4.75 （X11;一;Linux 2.2.16-3 i686）
The strings present in this binary/code suggest this malware is using DropBear SSH, a relatively small SSH server and client application on TCP port 3022. This could serve as another clue for spotting the malware.
此二进制文件/代码中存在的字符串表明该恶意软件正在使用 DropBear SSH，这是一个相对较小的 SSH 服务器和 TCP 端口 3022 上的客户端应用程序。这可以作为发现恶意软件的另一个线索。
The deployed malware tries to connect its C&C server 45[.]9[.]148[.]193 on port 1219. Figure 6 depicts the initial network traffic, which shows the initial IRC communication.
部署的恶意软件试图连接其 C&C 服务器 45[.]9[.]148[.]端口 1219 上的 193。图 6 描述了初始网络流量，其中显示了初始 IRC 通信。
The significance of this attack campaign lies in its use of Docker images to deploy cryptojacking scripts on compromised systems. This tactic allows attackers to exploit vulnerabilities in Docker configurations while evading detection by security software. As cybersecurity researchers continue to monitor this malicious actor, it’s essential for organizations to strengthen their defenses against Docker-related attacks.
这次攻击活动的意义在于它使用 Docker 映像在受感染的系统上部署加密劫持脚本。这种策略允许攻击者利用 Docker 配置中的漏洞，同时逃避安全软件的检测。随着网络安全研究人员继续监控这种恶意行为者，组织必须加强对 Docker 相关攻击的防御。
Recommendations 建议
To protect development environments from attacks targeting containers and hosts, we recommend implementing the following best practices:
为了保护开发环境免受针对容器和主机的攻击，我们建议实施以下最佳做法：
- Containers and APIs should always be properly configured to minimize the chance of exploitative attacks. Docker has specific guidelines on how their users can strengthen their security.
应始终正确配置容器和 API，以最大程度地减少利用性攻击的机会。Docker 对用户如何增强安全性有具体的指导方针。
- Organizations should use only official or certified images to ensure that only trusted content is run within the environment.
组织应仅使用官方或经过认证的映像，以确保在环境中仅运行受信任的内容。
- Running containers should not be run with root privileges, but rather as application users instead.
运行容器不应以 root 权限运行，而应以应用程序用户身份运行。
- Containers should be configured so that access is granted only to trusted sources, such as the internal network.
应配置容器，以便仅向受信任的源（如内部网络）授予访问权限。
- Organizations should adhere to recommended best practices. For example, Docker provides a comprehensive list of best practices and has built-in security features users can follow to improve the security of their cloud environments.
组织应遵守推荐的最佳实践。例如，Docker 提供了全面的最佳实践列表，并具有用户可以遵循的内置安全功能，以提高其云环境的安全性。
- Security audits should be performed at regular intervals to check for any suspicious containers and images.
应定期执行安全审核，以检查任何可疑容器和映像。
- Conclusion 结论
The Commando Cat attack campaign highlights the threat posed by the abuse of exposed Docker remote API servers. By exploiting Docker configurations and leveraging open-source tools like cmd.cat, attackers can gain initial access and deploy malicious binaries, while evading conventional security measures. The campaign’s use of Docker images to propagate cryptojacking scripts underscores the importance of implementing robust container security practices.
Commando Cat 攻击活动凸显了滥用暴露的 Docker 远程 API 服务器所带来的威胁。通过利用 Docker 配置和利用 cmd.cat 等开源工具，攻击者可以获得初始访问权限并部署恶意二进制文件，同时规避传统的安全措施。该活动使用 Docker 映像来传播加密劫持脚本，强调了实施强大的容器安全实践的重要性。
Trend solutions 趋势解决方案
The following security solutions are recommended for safeguarding Docker servers.
建议使用以下安全解决方案来保护 Docker 服务器。
- Trend Vision One™ – Container Security – for automated container image and registry scanning that helps detect threats early on
趋势愿景一™ – 容器安全 – 用于自动容器映像和注册表扫描，帮助及早发现威胁
- Trend Cloud One™ – Workload Security – for protecting new and existing workloads against even unknown threats using techniques such as machine learning and virtual patching
Trend Cloud One™ – 工作负载安全 – 使用机器学习和虚拟修补等技术保护新的和现有的工作负载免受未知威胁
The following protections exist to detect malicious activity and shield Trend customers from the attack discussed in this blog entry:
存在以下保护措施来检测恶意活动并保护 Trend 客户免受本博客文章中讨论的攻击：
- 1010326 – Identified Docker Daemon Remote API Call
1010326 – 识别的 Docker 守护程序远程 API 调用
- 1008619 – Application – Docker
1008619 – 应用程序 – Docker
- 1010349 – Docker Daemon Remote API Calls
1010349 – Docker 守护程序远程 API 调用
Trend Vision One hunting query
Trend Vision One 搜寻查询
The following text lists potentially useful queries for threat hunting within Vision One:
以下文本列出了 Vision One 中威胁搜寻的潜在有用查询：
eventId:100115 AND (remarks: POST_IMG_BLD_CRE OR remarks: POST_CON_CREATE) AND “cmd.cat”
eventId：100115 AND（备注：POST_IMG_BLD_CRE或备注：POST_CON_CREATE）和“cmd.cat”
