2026-07-26 05:05:48 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

文章总结： unit42发现了一个名为TuxBotv3Evolution的新型物联网僵尸网络框架，其开发过程借助了大型语言模型（LLM）。该框架由C语言编写的机器人代理和Go语言编写的命令与控制（C2）服务器组成，支持多种架构，并通过暴力破解等方式感染设备以实施DDoS攻击。分析显示，由于LLM辅助开发引入的错误，该版本部分功能存在缺陷，但开发者可能已发布修复后的完整版本，这使其潜在威胁不容忽视。 综合评分： 85 文章分类： 恶意软件,物联网安全,APT,网络安全,技术标准

cover_image

TuxBot v3：基于LLM辅助开发的物联网僵尸网络框架内部结构

原创

unit42 unit42

暗镜

2026年7月20日 06:00 北京

在小说阅读器读本章

去阅读

unit42发现了一个此前未被记录的模块化物联网 (IoT) 僵尸网络框架，名为 TuxBot v3 Evolution。

恶意软件作者利用LLM辅助代码开发，但结果喜忧参半。虽然人工智能能够按照他们的要求生成僵尸网络代码，但其中包含的安全免责声明却被开发者在发布前遗漏了。

尽管LLM显然对构建僵尸网络起到了辅助作用，但分析样本中的几个功能未能正常工作。虽然人工代码审查可以轻松解决这些错误，但作者却忽略了这一步骤。然而，很可能存在经过修正、更加完善的版本，这大大增加了该恶意软件的潜在威胁。

unit42 从内部遥测数据中恢复了该框架的详细信息。数据包括完整的源代码、17 种架构的编译二进制文件以及自动化的分布式拒绝服务 (DDoS) 性能测试报告。该僵尸程序会将受感染的设备编程为显示控制台横幅“已感染 Akiru”。

TuxBot v3 Evolution 框架包含以下部分：

一款基于 C 语言的机器人代理，可交叉编译为从 ARM 和 MIPS 到 x86_64、PowerPC、RISC-V 等架构。

一个基于 Go 语言的命令与控制 (C2) 服务器，带有 DDoS 攻击出租面板。

自定义漏洞利用虚拟机

基于 Docker 的测试基础设施

自动化建造系统

该机器人代理使用 1,496 个凭证对暴力破解目标设备的 Telnet 访问权限，包含针对 30 多个物联网设备系列的漏洞利用代码，并通过加密的 TCP 通道与 C2 服务器通信。

备用C2机制包括：

SHA512域名生成算法（DGA）

使用 Ed25519 签名的命令进行点对点 (P2P)

IRC

DNS TXT 查询

HTTP轮询

TuxBot 框架详情

TuxBot 是一个模块化的物联网僵尸网络框架，它源自多个已知的物联网僵尸网络代码库。开源的工具包。

图 1 显示了 TuxBot v3 Evolution 安装程序的屏幕截图。根据系统配置，该框架维护双版本：安装程序版本为3.5.2 ， Docker 配置文件中的版本为3.0.0-EVOLUTION-FINAL 。

图 1. TuxBot 交互式设置向导屏幕。

unit42发现了两个重要的 TuxBot 数据来源。第一个发现是一个包含该框架完整源代码的存档。该存档包含：

61 个 C++ 源文件

58个标题

它自己的编译器和虚拟机

测试环境的 Docker Compose 配置

用于多架构测试的快速模拟器 (QEMU) 设置

254份自动化DDoS基准测试报告

unit42的第二个发现是一个，它也被打包在源代码树的 QEMU 测试目录下，文件名以点号为前缀进行隐藏。该样本已于 2026 年 1 月 20 日提交至 VirusTotal。

将此二进制文件与源代码进行比较后发现，这是一个开发版本。该二进制文件编译时，其 C2 IP 地址设置为回环 IP 地址 127.0.0.1，僵尸网络协议端口设置为 31337。由于这些信息可以在僵尸网络设置过程中修改，因此运营者可能拥有使用真实 C2 IP 地址且已修复此处记录的漏洞的生产版本。

unit42恢复并分析的 TuxBot 框架功能约有 70% 可用。核心感染流程（扫描、凭证暴力破解、持久化、主 C2 服务器搭建和 DDoS 攻击）运行正常。Telnet、SSH、HTTP 和 Android 调试桥 (ADB) 扫描器均运行正常。此外，Telnet 扫描器拥有 1496 个凭证对，仍然是一个有效的感染途径。

除了暴力破解之外，其他利用方式十分有限。这三个漏洞利用系统都无法正常工作，原因各不相同，我们将在后续分析中详细说明。此外，还有一个扫描器启动了，但其硬编码的投放器 IP 地址已不再有效。

由于一些漏洞，其他几个功能也无法使用，其中大部分漏洞都源于大型语言模型（LLM）辅助开发。开发者依赖LLM生成C模块、移植漏洞利用程序并编写C2服务器代码。

LLM的原始推理过程被原封不动地保留在源代码中，并且LLM会臆造出开发者未经验证就发布的加密实现。在我们的分析过程中，我们通过向LLM发送一些有针对性的提示，修复了其中几个缺陷。这意味着，如果攻击者能够访问相同的源代码，他们只需付出极小的努力就能生成一个更完整的版本。

开发时间表

包含源代码的归档文件中还包含一个 Git 日志。该 Git 日志使我们能够构建一个时间线，展示该僵尸网络的开发进度，如表 1 所示。

| | | | | — | — | — | | 日期 | 事件 | 证据 | | 2025年1月3日 | 开发者从 GitHub 克隆了 MHDDoS（DDoS 攻击脚本）。 | MHDDoS/子目录中的 Git 日志泄露了工作站主机名newtuxdev.sevielw.digikalas[.]online | | 2025年8月6日 | 开发者域名digikalas[.]online已注册 | Namecheap 注册，提供冰岛隐私保护（受隐私保护机构 Withheld for Privacy ehf 保护），Cloudflare DNS | | 2026年1月4日至6日 | 生成了 254 份自动化 DDoS 基准测试报告 | 找到的软件包包含报告、目录时间戳和针对 Docker 目标的 JSON 测试配置 | | 2026年1月20日 | 第一个 TuxBot 样本出现在 VirusTotal 上。 | SHA256 哈希值为 71dfbb171eca4ef9d02ff630b56e5283bbef7b375d4dbe9e8c9531bef312fa8d，x86_64 调试版本，包含符号 | | 2026年3月5日 | C2 服务器首次出现在 Xpanse 上 | 209.182.237[.]133:2222，横幅SSH-2.0-CNC-Control-Server | | 2026年4月22日 | 内部遥测中检测到六个新样本 | 未在 VirusTotal 上检出，支持多种架构，使用 GCC 14.2.0 生产版本构建。 |

表 1. TuxBot Framework 开发时间表。

源代码和公开数据提供了大致的开发时间线。从随附的 Git 日志中获取的开发者主机名表明，该工作站托管在伊朗。开发者域名newtuxdev.sevielw.digikalas[.]online已失效，但其父域名digikalas[.]online在我们研究期间仍然有效，并解析到伊朗 Arvan Cloud 内容分发网络 (CDN) 上的一个 IP 地址。

2026年1月以来的254份基准报告显示：

在三个基于 Docker 的僵尸网络主机上对 12 种攻击方法进行积极测试

测量数据包速率、吞吐量和错误率

此次测试发生在第一个样本出现在 VirusTotal 上的几周前，这与部署前的后期开发推进阶段相符。

源代码包含 IP 地址185.10.68[.]127，我们以此为支点，将 TuxBot 连接到 Keksec/Kaitori（Tsunami/Mirai/Gafgyt 的一个变体）生态系统，并共享一个基础设施。

框架概述

根据框架描述，TuxBot 的开发者构建了一个他们称之为专业级的 C2 框架平台，该平台具有多用户管理面板、自动化部署和模块化攻击功能。图 2 显示了僵尸网络面板的参考图。

图 2. TuxBot C2 机器人主控面板命令参考。

C2 服务器是用 Go 编写的，它使用三个监听器，每个监听器使用不同的 TCP 端口接收传入连接。

第一个监听器在 TCP 端口 1999（或 31337，取决于版本）上提供机器人协议，负责向已连接的机器人分发加密命令。该端口还复用了一个由魔术字节头部标识的管理员二进制协议。

第二个监听器是 TCP 端口 2222 上的 SSH 服务器，它为操作员提供一个交互式 shell。这就是图 3 所示的 DDoS 攻击雇佣界面。操作员登录后，可以看到已连接的机器人数量，并以!method target duration 的格式发出攻击命令。

图 3. TuxBot SSH C2 控制面板系统状态屏幕。

如图 4 所示，C2 服务器对每个用户实施并发攻击次数、最大持续时间和机器人分配配额限制。所有这些都由 MariaDB 数据库提供支持，该数据库存储用户帐户、攻击日志和权限信息。

第三个监听器是 TCP 端口 9999 上的机器 API，它使用 JSON 接口，旨在进行程序化访问。

集成式构建系统可自动完成整个部署过程：

安装依赖项（Go、MariaDB、交叉编译工具链）

初始化数据库模式

生成配置

编译 C2

如图 5 所示，该机器人已针对 17 种目标架构进行了交叉编译。

图 5. 僵尸客户端（恶意软件制品）的漏洞加载和交叉编译。

这些目标架构包括：

x86_64

手臂

ARM64

MIPS

米普塞尔

MIPS64

PowerPC

编译后的二进制文件被放置在通过 HTTP 提供的目录中，因此被攻击的设备可以下载适合其架构的二进制文件。

该框架包含针对多种测试场景的配置。“竞技场”配置会启动一个 C2 服务器、五个僵尸程序副本以及一台运行nginx和socat监听器的目标主机，监听游戏服务器端口（Minecraft、TeamSpeak、FiveM、Xbox Live）。这使得开发者能够在受控环境中测试针对真实协议监听器的 DDoS 攻击方法。其他配置则用于测试 P2P gossip 恢复机制、与所有扫描器完全集成以及启用隐身和持久化功能的类生产环境部署。

一个有趣的设计细节是，源代码将 SSH 横幅配置为SSH-2.0-CNC，但 Xpanse 上位于209.182.237[.]133的实时 C2 服务器显示的横幅却是SSH-2.0-CNC-Control-Server。这种差异表明生产环境部署使用的是发现的源代码的修改版本，进一步证实了运营商可能拥有一个独立的、更完整的版本。

机器人概述

分析详情

该机器人是一个 C 程序，编译后生成一个静态链接的二进制文件。它链接到和，以支持 X25519、ChaCha20、Poly1305、SHA512 和 Ed25519 算法。

原始二进制文件是一个早期调试版本，符号完整，使用 GCC 11.4.0 编译，而不是生产版本的 GCC 14.2.0。该僵尸程序会将受感染的设备编程为显示控制台横幅“ Infected By Akiru”

程序运行时，会遵循固定的初始化顺序。在初始化伪随机数生成器并初始化 libsodium 之后，它会执行以下操作：

加载 C2 地址

设置反调试保护

隐藏其进程名称

安装持久化

启动一系列子系统，这些子系统包括：

然后主进程进入循环，从 C2 服务器接收加密命令并分发攻击。

字符串表和异或键漏洞

TuxBot 将敏感字符串（C2 地址、扫描器调用、漏洞利用有效载荷）存储在一个 XOR 加密的表中，并在运行时解密该表。表键先前定义为0xDEDEFB4F。

toggle_obf()函数将这个 32 位密钥拆分成四个组成字节（0x4F、0xFB、0xDE、0xDE），并将每个表项的每个字节与这四个字节依次进行异或运算。由于异或运算具有结合性，这四个运算合并成一个有效的密钥。两个0xDE字节相互抵消（任何字节与其自身进行异或运算的结果为零），因此0x4F XOR 0xFB = 0xB4。

该表包含 58 个条目。其中 49 个条目使用密钥 0xB4 可正确解密，

使用正确的密钥（0x54）解密它们，即可得到表 2 中所示的预期值。

表 2. 字符串表解密值。

所有四个漏洞利用有效载荷都在其中硬编码了投放器 IP 地址185.10.68[.]127，该 IP 地址在 2026 年 5 月初被 VirusTotal 标记为恶意地址。

这个漏洞的后果非常严重。IRC C2 备用通道、HTTP C2 轮询通道以及四个存储在表中的漏洞利用有效载荷在运行时均无法正常工作。僵尸程序会尝试使用它们，但由于字符串值损坏而静默失败。例如，IRC 通道尝试对乱码字节调用inet_addr()函数，结果返回INADDR_NONE，并每隔 10 秒重试一次连接。

我们通过在初始化时将原始字符串与运行时密钥（0xB4 ）进行异或运算，成功修复了add_entry_plaintext()函数的调用问题，确保密钥始终匹配。修复后，IRC C2频道可以连接并加入#tuxbot频道，并接受攻击命令，如

凭证表

该机器人自带 1496 个用于 Telnet 暴力破解的用户名/密码对。文件头明确标明“// START IMPORTED FROM DDOS-ROOTSEC pass_file”。每个条目都与密钥0xB4进行异或运算（与运行时密钥匹配，因此这些破解程序能够正常工作）。

包含 1495 个登录凭据的列表包括标准默认值和供应商特定默认值。

C2 协议

TuxBot 采用分层 C2 架构，包含一个主通道和五个备用机制。在我们分析的版本中，只有主通道和五个备用机制中的三个能够正常工作。

主通道：加密 TCP

机器人通过 TCP 端口 1999（或 31337，取决于构建配置）连接到 C2 服务器。握手过程首先由机器人发送 4 个字节：0xDEADBE01。然后，它生成并发送其 32 字节的公钥。C2 服务器回复其自身的 32 字节公钥。

备用频道

该框架定义了五个额外的 C2 通道，如表 3 所示。

| | | | | — | — | — | | 渠道 | 执行 | 地位 | | DNS TXT | 通过8.8.8[.]8查询c2.tuxbot.local | 功能 | | DGA | 种子格式为-TuxBotv3-Evolution-Seed-2025-，SHA-512 算法，每天 20 个域名。 | 功能 | | P2P | TCP 端口 13337，Ed25519签名命令 | 功能 | | IRC | TCP 端口 6667，明文 | 破碎的 | | HTTP轮询 | 投票hxxp[:]//127.0.0[.]1/cmd | 破碎的 |

表 3. C2 通道及其实现状态。

辅助频道：IRC协议

损坏的 IRC 实现表明了使用辅助通信渠道的意图，

修复后，它会派生一个子进程，该子进程连接到 IRC 服务器，加入一个频道（默认为#tuxbot），并监听以! 字符为前缀的PRIVMSG命令。它支持 12 种攻击方法（ udp、syn、ack、vse、stomp、greip、greeth、udpplain、bypass、std、socket和dns），外加一个kill命令。

命令以明文 IRC 消息的形式到达，并由parse_irc_command()函数解析。然后，命令被转换为与主加密通道相同的二进制数据包格式，然后再传递给attack_parse()。

与主频道不同，IRC频道没有加密也没有身份验证。任何知道服务器和频道的人都可以控制机器人。

DGA详情

dga_generate_domain ()函数会生成一个格式为%04d-%02d-%02d-TuxBotv3-Evolution-Seed-2025-%d 的种子字符串，其中日期为当前 UTC 日期，最后一个整数每个周期从 0 到 19 循环一次。这样每天可以生成 20 个候选域名。

计算该字符串的 SHA512 哈希值，并将摘要的前 12 个字节映射到小写字母（将摘要[i] % 26 转换为az字符集）以形成域名标签。顶级域名 (TLD) 从包含 6 个条目的表（.com、.net、.org、.info、.biz和.cc）中选择，选择方法为摘要[12] % 6。主 C2 重连循环和弹性模块均使用此函数在主 C2 地址无法访问时尝试使用 DGA 域名。

漏洞利用

源代码树包含四类漏洞利用方法。但只有一种能在运行时生效。这是开发过程中引入的漏洞直接导致的。

漏洞利用类别 1：硬编码的 C 函数（已实现但从未调用）

十六个漏洞利用函数以原生 C 代码实现，涵盖不同厂商和设备上的 13 个 CVE 漏洞。每个函数都会构造一个HTTP或SOAP请求，其中包含一个%s格式的字符串，用于指定投放器的 IP 地址。代码完整，如果调用应该可以正常工作。但是，exploit_engine_init()函数在整个代码库中没有任何调用者。没有任何扫描器或传播模块引用它。这十六个漏洞利用函数被编译到二进制文件中，因此被视为无效代码。

漏洞利用类别 2：利用虚拟机（已调用但已损坏）

主Telnet扫描器会生成一个专用的漏洞利用工作线程，该线程会循环调用vm_run_random()函数攻击随机IP地址，这使得它成为该僵尸程序在运行时唯一尝试使用的漏洞利用系统。开发者构建了一种自定义的领域特定语言，用于将漏洞利用程序编写为文本文件；一个Go编译器，用于将漏洞利用程序编译成二进制包；以及一个C虚拟机，用于执行这些程序。

我们还观察到 27 个.expl文件，这是开发者为该框架创建的自定义文件格式。每个文件包含一个漏洞利用程序，使得漏洞利用集成采用模块化方式，而非硬编码。这些程序被编写并编译成一个 10,694 字节的漏洞利用包，该包可以覆盖 13 个 CVE 漏洞（包括、和）以及两个非 CVE 漏洞。

该软件包执行失败的原因是 Go 编译器将0x54555845（“ TUXE ”），而 C 虚拟机期望的魔数为0x4558504C（“ EXPL ”）。软件包在加载时被拒绝，漏洞利用工作线程虽然运行，但并未执行任何操作。除了魔数不匹配之外，编译器也从未发出OP_CONNECT操作码，并且编译器和虚拟机之间的变量语法也存在差异。这意味着即使修复了文件魔数，也无法使软件包正确执行。

漏洞利用类别 3

此类别包含 XOR 表有效载荷，但由于 XOR 密钥不匹配而失效。字符串表中存储了四个 XOR 加密条目形式的攻击有效载荷。这些有效载荷针对不同的厂商，原本是作为一种替代的传播机制。它们都使用了错误的 XOR 密钥（0x54而非0xB4）进行加密，导致运行时 HTTP 请求乱码。

漏洞利用类别 4

该类别包括用于远程代码执行 (RCE) 和 ADB 的功能专用扫描器。

综上所述，漏洞利用类别如表 4 所示。

表 4. 漏洞利用类别和数量（按实施状态）。

泛物联网攻击的漏洞利用方法均已失效，原因各不相同。所有 CVE 及其状态的完整表格请参见“入侵指标”部分。

DDoS攻击方法

攻击调度系统注册了 78 个攻击向量。这些向量仅映射到六个实际的处理函数，如表 5 所示。

| | | | | — | — | — | | 处理程序（标识符） | 向量 | 描述 | | attack_udp_generic_optimized | 25 | 使用原始套接字和sendmmsg()函数发送 512 个数据包进行 UDP/GRE/ICMP 洪水攻击 | | attack_tcp_syn_optimized | 47 | TCP SYN 洪水攻击，也映射到所有第 7 层 HTTP 方法 ID | | attack_tcp_ack_optimized | 2 | TCP ACK 洪水攻击 | | attack_tcp_stomp_optimized | 1 | TCP ACK+PSH 洪水攻击 | | 攻击 UDP DNS 优化 | 2 | DNS 查询泛滥 | | 攻击矿工 | 1 | 加密货币挖矿占位符 |

表 5. DDoS 方法处理程序及其描述。

映射到attack_tcp_syn_optimized 的47 个向量包括开发者尝试从 MHDDoS 移植的所有 HTTP 应用层方法：

洪水

洪水过后

Slowloris DDoS攻击

Apache Range 标头攻击

WordPress XMLRPC pingback 攻击

Cloudflare绕过攻击变种

这些方法都有源代码实现，但attack_init()会将它们的所有向量 ID 都路由到TCP SYN处理程序。例如，输入!get target 60 的操作员如果期望收到 HTTP GET 洪水攻击，实际上会收到 TCP SYN 洪水攻击。

HTTP攻击方法被编译成死代码并写入二进制文件。

源代码树包含大约 92 个独立的方法实现，分布在三个不同的分支中：

来自传统 Mirai 代码库的 30 个

12 个带有 AISURU 后缀的变体，这些函数存在于编译后的二进制文件中，但永远不会被调用，因为attack_init()会将所有内容重定向到六个优化处理程序。

网络 HTTP 暴力破解扫描支持

源代码揭示了一种模块化架构，该架构旨在实现高效的网络扫描，特别是使用专用的 HTTP 扫描例程来发现易受攻击的 Web 接口。

HTTP 扫描器作为一个独立的子进程运行，在一个无限循环的非阻塞select()函数中管理最多 128 个并发连接。对于每个空闲时段（大约每帧 5% 的概率），它会随机选择一个公共 IP 地址，并连接到 TCP 端口 80 或 8080，但不包括环回地址和不可路由的 IP 地址范围。

然后，扫描器会尝试与随机的管理端点（例如/admin或/cpanel ）建立非阻塞 TCP 连接。它使用硬编码列表中的凭据组合（例如admin:admin ），通过 HTTP GET 请求中的 Base64 编码的Authorization: Basic标头来实现此目的。

如果响应返回成功的HTTP/1. * 请求，状态码为200 OK，扫描器会打印调试日志并终止连接。关键在于，源代码表明此功能尚未完全实现，因为成功的传播逻辑已被简化，完全缺少向 C2 服务器报告成功感染的功能。如果尝试在 5 秒后超时或失败，则会直接关闭连接并释放连接槽以供重用。

持久性和隐蔽性

持久化和隐蔽子系统遵循物联网僵尸网络生态系统中已建立的成熟模式，因此我们不会详细描述每项技术。

自卫机制

反虚拟机模块采用加权评分系统，阈值为 30，结合了 10 多种检测方法，其中包括：

DMI 文件检查

VMware/VirtualBox/QEMU

七家虚拟机厂商的 MAC 地址前缀匹配

磁盘大小和 CPU 数量启发式算法

基于时间的检测

内核模块扫描

检查是否运行分析工具（gdb、IDA、Ghidra、radare2、Wireshark、Volatility）。

分析详情

开发者使用 LLM 编写了该框架的大部分内容。多个文件中保留了 LLM 的原始思路，这些思路以注释的形式逐字记录。这些注释是 LLM 在执行移植任务时的内部推理过程。该推理过程包含自我中断、决策以及对“用户”（即调用 LLM 的开发者）的引用。

表 6 总结了 TuxBot v3 Evolution 各个主要组件的运行状态。

| | | | — | — | | 成分 | 地位 | | 多架构编译（17 个目标） | 功能 | | 主加密 C2（X25519 + ChaCha20-Poly1305） | 功能 | | Telnet 暴力破解扫描器（1,496 个凭据） | 功能 | | SSH扫描器 | 功能 | | HTTP扫描器 | 功能 | | ADB扫描仪 | 功能 | | 漏洞利用引擎 | 这是死代码。可以通过调用漏洞利用引擎函数来激活它。 | | 利用虚拟机 | 破碎的 | | RCE扫描仪 | 部分的 | | DDoS（UDP/TCP/DNS 洪水攻击） | 功能 | | 持久化（systemd/cron/shell/watchdog） | 功能 | | 隐蔽（进程模拟/迁移/反虚拟机） | 功能 | | 竞争对手杀手 | 功能 | | DGA（SHA-512，每天 20 个域名） | 功能 | | P2P八卦（Ed25519签名） | 功能 | | 凭证列表 | 功能 | | IRC C2 回退 | 破碎的 | | HTTP C2 回退 | 破碎的 | | XOR 表漏洞利用有效载荷（4 个条目） | 破碎的 | | L7 HTTP DDoS 攻击方法（MHDDoS 端口） | 死代码 | | 多态引擎 | 死代码 | | CF/CAPTCHA绕过模块 | 死代码 | | 矿业 | 占位符/非功能性 | | Windows 构建 | 非功能性 |

表 6. TuxBot 框架各组件的运行状态。

在研究过程中，UNIT42利用少量 LLM 辅助提示修复了这些问题,通过重建了正确的表项，并通过几个有针对性的提示修复了 IRC C2 频道。鉴于运营商已经掌握了源代码，并且一直在积极部署二进制文件（2026 年 4 月发布了六个新样本），我们可以合理地推断，包含部分或全部修复的版本已经存在于实际环境中。

基础设施和生态系统

通过搜索公开数据，UNIT42发现了活跃的基础设施以及与更广泛的物联网僵尸网络生态系统的连接。

主 C2 服务器位于新加坡，IP 地址为209.182.237[.]133 。连接到该服务器上的 TCP 端口 2222 会显示SSH-2.0-CNC-Control-Server横幅，该横幅最早于 2026 年 3 月 5 日在 Xpanse 上被发现，也可通过访问。SSH 密钥交换采用的密钥交换算法与 Go 的crypto/ssh库（而非 OpenSSH）存在关联。

位于185.10.68[.]127的投放服务器托管在 FlokiNET 上，这是一家总部位于冰岛的服务器提供商，以其安全可靠的托管服务而闻名。2026 年 5 月，该 IP 地址在 VirusTotal 上被检测到 91 次恶意活动，其中 11 次被检测到，至少有 10 个可通信的恶意软件样本和 6 次相关的下载。

该投放服务器在/bins/bot.提供 TuxBot 有效载荷，并在不同的 URL 路径上提供 Kaitori v3.9 二进制文件。该 IP 地址的被动 DNS 历史记录显示，自 2021 年以来，其域名与 DDoS 攻击行为一致，包括vrunabo[.]su、rezy1337.ted[.]ge和high.cpu.co[.]ua。

这两个服务器通过jetross[.]com Let’s Encrypt TLS 证书连接，该证书出现在两个主机上，将新加坡的 C2 服务器与冰岛的 dropper 绑定到同一运营商名下。

投放器 IP 地址是连接 TuxBot 与更广泛的 Keksec/AISURU 生态系统的关键节点。2025 年 7 月，我们从内部遥测数据中恢复了 82 个 Kaitori v3.9 样本，这些样本通过不同的 URL 路径从185.10.68[.]127下载了有效载荷。另一个样本（一个 Go 二进制文件）同时与194.46.59[.]169（一个已知的 AISURU IP 地址）和185.10.68[.]127通信。TuxBot、Kaitori 和 AISURU 工具都使用同一个投放器服务器，但它们的代码库是独立的。

源代码中还隐藏着另一个恶意软件。远程代码执行 (RCE) 扫描引擎包含一个硬编码的有效载荷，该载荷会使用用户代理r00ts3c-owned-you从hxxp[:]//188.166.2[.]226/OwO/Tsunami.x86下载文件。该字符串是从 r00ts3c Tsunami 代码库复制粘贴而来，该代码库包含在开发者于 2025 年 1 月克隆的 MHDDoS 代码库中。

该IP地址指向一个已停用的DigitalOcean服务器，该服务器目前服务于Ubiquiti的UISP平台。此有效载荷为无效代码。

开发者域名digikalas[.]online解析到伊朗 Noyan Abr Arvan 服务器上的37.32.24[.]195 。其 TLS 证书涵盖api.digikalas[.]online和health.digikalas[.]online，表明它托管的 Web 应用程序并非仅限于恶意软件开发。该开发者子域名已在 Git 历史日志数据中泄露。

结论

TuxBot v3 Evolution 揭示了一个物联网僵尸网络框架的开发快照。该框架具备一些可运行的核心功能，但存在一些缺陷，这些缺陷源于少量可复现的漏洞。

从 2026 年 1 月起，基于该框架编译的二进制文件已开始出现在网络上。C2 基础设施至少从 2026 年 3 月起就已投入使用。

在整个项目中，开发人员大量依赖LLM生成的代码。这种方法加快了集成速度，并使原本可能由单个开发人员完成的工作——构建一个支持多种架构的僵尸网络——变得轻而易举

LLM 还引入了一些未被发现的漏洞，因为生成的代码表面上看起来不错。例如，XOR 密钥不匹配、虚拟机魔法不兼容、从未被调用的漏洞利用引擎以及虚构的 Argon2id 实现等等，这些错误如果通过人工代码审查就能立即发现。然而，开发人员却轻信了生成的代码，继续进行后续工作。

TuxBot 运营者通过与 Kaitori v3.9 和 AISURU 工具共享基础设施，融入了 Keksec 生态系统。该组织以并行运行多个物联网僵尸网络变种而闻名。

TuxBot 似乎是该系列的另一个变种。它旨在超越常见的 Mirai 分支，配备了加密的 C2 服务器、DGA 和模块化漏洞利用系统，尽管在我们恢复的版本中，该系统尚未正常工作。

这些损坏的功能是可以修复的。我们在分析过程中通过重建 IRC C2 通道并使用几个有针对性的 LLM 提示符解密不匹配的表项，证明了这一点。这个框架的完整版本并非理论上的威胁，而是一个潜在的威胁。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：暗镜 unit42 unit42《TuxBot v3：基于LLM辅助开发的物联网僵尸网络框架内部结构》