转载自@探姬

原文链接： X 上的 探姬 | Hello-CTF ^-^：“在各种投毒轰炸的情况下，最好的办法就是最开始就别中招” / X

在各种投毒轰炸的情况下，最好的办法就是最开始就别中招

一篇关于 GitHub 供应链投毒、Rust 多阶段木马与 X 账号被盗的技术复盘，刚好我找回的账号，黑客送了我一个蓝v，就写一下。

事件背景

事情始于 GitHub 仓库 DeepSeek-TUI/DeepSeek-TUI。

当时第二天要比赛，想着拿几个模型去打，然后测一下效果，那会天天听到tui的项目，想着要不去试试，然后边打游戏边找，脑子根本没多想。

当时该项目约有 300+ Star，曾登上 GitHub Trending，在必应搜索 DeepSeek-TUI 时会被推到第一位。源项目 Hmbown/DeepSeek-TUI 本身是一个 Rust TUI 项目，而恶意 Fork 展开后与原版体积差距仅有约 2MB。

这 2MB 的增量，包含了一整套多阶段 Rust 木马。

后来再去查看这个仓库时，发现它已经从 GitHub 上消失了。但问题并没有因此结束——它的本体被多个知名项目收录，比如一个 Star 数高达 13k 的仓库 decolua/9router 就包含了它。此外还能看到一些 AI 项目在对这个工具做推荐，更有一些 Fork 直接保留了带毒样本的 Release 文件。这意味着即使原仓库被删除，恶意代码仍然通过"被收录"“被推荐”"被 Fork"的方式继续传播，进入更多人的视野。

时间线复盘

Day 0：下载与执行

下载并运行了该项目。Rust 编译的可执行文件，表面看起来正常。

Day 1：被忽略的邮件

谷歌发送了邮件，提示账号邮箱已被修改。但当时没有注意到这封邮件。

X 的安全机制存在一个 24-48 小时的修改限制窗口：攻击者修改邮箱后，如果原账号同时绑定了手机和邮箱，攻击者需要等待 48 小时才能彻底完成接管。在这 48 小时内，原主人仍有机会通过手机号夺回控制权。

错过了这个窗口期。

Day 2：被强制下线

24 小时后，X 账号被强制下线。此时才去查看邮件，发现了来自 X 和 Google 的告警。

后续：申诉与找回

接下来是向 X Support 提交工单、证明账号归属的申诉流程。

目前账号已找回。

技术解剖

找回账号后，对落地的样本进行了静态分析。

这是一个模块化的多阶段恶意软件家族。

基于本地 IDA 导出文件分析，该家族至少包含 5 个同源 Rust 样本，采用 rustc stable-x86_64-pc-windows-msvc 编译，开发者环境统一为 C:\Users\root\，共享 memexec-0.2.0 等 crate 依赖。

攻击链结构

[GitHub 投毒下载]

│

▼

[Stage2 样本家族] ──┬──► onedrive_sync.exe (x86) ──► 持久化 + Loader 双重角色

├──► audiocontrol.exe (x64) ──► 纯内存 Loader (RC4 解密)

├──► vs_vcode.exe (x64) ──► 内存 Loader + 双层伪装

├──► svc_service.exe (x64) ──► 纯持久化驻留模块

└──► WinHealhCare.exe (x64) ──► 主控 Payload (C2 / 命令分发)

五个样本的核心能力

权限维持机制

该家族采用多阶段、多权限维持、多释放路径的策略：

注册表层面：

• HKCU\Software\Microsoft\Windows\CurrentVersion\Run 写入随机化名（MediaIndexHelper、{NetworkManager} 等）

• HKLM 同级路径写入

• Winlogon Userinit 追加执行（C:\Windows\system32\userinit.exe, [恶意路径]）

计划任务层面：

• schtasks /Create /SC ONLOGON /RL HIGHEST，任务名伪装成 ChromeSyncHost、EdgeUpdateHelper、WindowsSecurityHost 等 16 个名称

• 覆盖登录触发、启动触发、每小时/每日重复执行

文件系统层面：

• 自我复制到 8 组硬编码路径：

o %APPDATA%\Microsoft\Windows\Templates\ChromeUpdateSvc.exe

o %LOCALAPPDATA%\Temp\MicrosoftSync.exe

o C:\ProgramData\Adobe\AdobeCloudSync.exe

o C:\ProgramData\Intel\IntelGraphicsHost.exe 等

• 随机后缀生成（字符池 a-z0-9），支持 {SUFFIX} 和 {USER} 占位符替换

• .lnk 快捷方式写入 Startup 目录

内存执行层面：

• 三个 Loader 样本均使用 memexec-0.2.0 将下一阶段 PE 无文件加载到内存

• NtAllocateVirtualMemory + VirtualProtect + IAT 修复 + TLS 回调 + 入口点 call rax

• audiocontrol.exe 使用 RC4 解密且密钥与 PID 绑定，内存 Dump 无法直接复现

• vs_vcode.exe 疑似新增自定义 entropy_reducer.rs 熵减层，规避基于熵的静态检测

反分析与反沙箱：

• WinHealhCare.exe 内置 7 项反沙箱检测：屏幕分辨率、物理内存、磁盘空间、CPU 核心数、计算机名、IsDebuggerPresent、以及 30+ 进程/DLL 黑名单（ollydbg、x32dbg、x64dbg、wireshark、vmware、vbox、cuckoo 等）

• audiocontrol.exe 检测 DEBUG 和 RUST_BACKTRACE 环境变量，存在则直接 ExitProcess(0)

• svc_service.exe 检测鼠标活动后才执行 Payload，并设置硬件断点注入（Dr0/Dr1/Dr7），同时具备直接 Syscall 能力

C2 与信息窃取

https://pastebin.com/raw/csi5UqpE      (主 C2 U1)

https://snippet.host/wtbtew/raw        (备用 C2 U1)

https://pastebin.com/raw/fTxiyhbL      (主 C2 U2)

https://snippet.host/iqqmib/raw        (备用 C2 U2)

http://checkip.amazonaws.com           (外网 IP 收集)

• 内置 5 种浏览器 User-Agent 轮换（Chrome 137/140/141、Firefox 143、Edge 140）

• 命令通过字符串匹配分发：chromeupdatesvc→HKCU持久化、microsoftsync→.lnk快捷方式、adobecloudhelper→计划任务

• 支持静默执行（CREATE_NO_WINDOW），支持 PowerShell + WshShell 脚本执行

微软浏览器（Edge/Chrome）的密码在这个阶段容易被后续加载的模块窃取。样本具备完整的命令执行与文件传播能力，可以下载执行凭证窃取工具，或由内存加载的 Payload 直接访问浏览器凭证存储。

几个关键的巧合

复盘这次事件，几个因素叠加导致了最终的结果：

GitHub 供应链投毒的信任基础

300+ Star、上过 Trending、搜索结果第一位、与原版仅差 2MB。Star 数和 Trending 构成了信任背书，降低了警惕性。更麻烦的是，它还被多个高星项目收录、被 AI 推荐，这种"二次背书"让风险更加隐蔽。

X 的历史 2FA 策略

2023 年，X 的二步验证策略是：必须订阅 Premium 才能使用 2FA。如果没有订阅，系统会取消二步验证。后面虽然支持了 Google Authenticator 和硬件安全密钥，但如果账号恰好处在那个未开启 2FA 的状态——账号就只有密码保护。

邮件告警未被及时处理

谷歌发送了邮件，X 也可能发送了通知，但都没有及时查看。攻击者不需要阻止你收到邮件，只需要确保你在 24 小时内不去处理。

48 小时窗口期

X 的"修改后 24h 内无法再次修改"机制，本意是保护用户，但在这里给了攻击者 24-48h 的缓冲期来完成接管。如果原主人错过这个窗口，就会失去通过原始手机号快速恢复的机会。

防守方的困境与唯一解

分析完这 5 个样本后，能体会到一旦执行后的排查难度：

• 清除了注册表 Run 键，还有计划任务；

• 删除了计划任务，Winlogon Userinit 可能被篡改；

• 修复了 Userinit，Startup 目录里可能有 .lnk；

• 删掉了落地文件，内存里可能还有 memexec 加载的无文件 Payload；

• 重启了电脑，svc_service.exe 可能通过 schtasks /ONLOGON /RL HIGHEST 重新建立。

多阶段、多权限维持、多释放路径，意味着需要进行完整的事件响应流程：内存取证、注册表全量检查、计划任务审计、网络流量回溯。

所以成本最低的方案，就是最开始就别中招。

对于普通用户：

• 启用一切可能的 2FA，优先使用硬件密钥或 Authenticator App

• 对账号安全类邮件保持关注，设置独立提醒

• 对 GitHub 上的"热门新项目"保持警惕，Star 可以被刷，Trending 可以被操控，与原版 diff 是基本操作

• 浏览器密码避免存储重要账号，使用独立密码管理器

关于开源信任的额外思考

这次事件还带来一个关于开源软件信任的观察。

人们常常觉得"开源 = 安全"，因为代码是公开的，任何人都可以审查。但开源的安全并不取决于开源本身，而是取决于实际有多少人在看、在看的人有没有能力发现问题、以及 release 里的二进制是否真的对应了仓库里的源码。

一个 300+ Star 的仓库，可能真正看过源码的人不到十个。而当它被 13k Star 的项目收录、被 AI 工具推荐时，这种"信任传递"会让更多人放下戒备——毕竟，“这么多人在用，应该没问题吧”。

但现实是，Star 数可以被刷，Trending 可以被操控，收录和推荐往往也只是基于功能描述而非安全审计。更关键的是，很多用户直接下载的是 Release 里的预编译二进制，而不是自己从源码编译。如果 release 里的可执行文件已经被替换，即使仓库里的源码看起来干净，也毫无意义。

所以对待开源项目，尤其是带预编译 release 的工具，多一个验证步骤并不麻烦：diff 一下源码、检查一下编译来源、在沙箱里先跑一遍。这些习惯在供应链投毒越来越频繁的今天，算是基本操作。

写在最后

找回账号后，把这 5 个样本完整分析了一遍。这是一个架构清晰、分工明确、具备反沙箱和多层持久化能力的恶意软件家族。

而我，因为一次正常的 GitHub 浏览、一封没看的邮件、一个历史遗留的 2FA 空窗期，账号就被盗了。

在各种投毒轰炸的情况下，最好的办法就是最开始就别中招。

因为一旦执行，要对抗的不再是某一个文件，而是一整套互为备份、扎根在系统各个角落的恶意生态。

希望这篇复盘，能让你在遇到下一个类似项目时，多留一个心眼。

附录：核心 IoC

转载者评论： 最近AI应用尤其是梁圣降价后很多人会开始考虑用一些关联性项目，从安全态势来看近期同类型投毒案例也是激增，大家务必注意安全