转载自@探姬
原文链接： 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 / 命令分发)
五个样本的核心能力
样本 角色 关键能力 WinHealhCare.exe 主控端 C2 轮询(Pastebin/Snippet.host)、命令执行(cmd/powershell)、文件传播(8组路径)、反沙箱(7项检测)、外网IP收集 audiocontrol.exe x64 Loader RC4 解密嵌入载荷(PID绑定密钥)、memexec-0.2.0 内存加载、TLS回调、DEBUG/RUST_BACKTRACE反调试 vs_vcode.exe x64 Loader+伪装 共享 audiocontrol 核心代码，新增entropy_reducer.rs 熵减解密层，硬编码 JSON+TOML 双套伪装配置
onedrive_sync.exe
x86 持久化Loader
注册表 Run 键写入、互斥体Global\{CoreTask1461}_、自我复制为manager.exe、PE资源HRLBXLNQ提取+memexec
svc_service.exe
纯持久化
计划任务(schtasks /ONLOGON /RL HIGHEST)、Winlogon Userinit 追加、Startup目录、硬件断点注入(Dr0/Dr1/Dr7)、防火墙规则添加、CLR/.NET加载(clroxide)、直接 Syscall
权限维持机制
该家族采用多阶段、多权限维持、多释放路径的策略：
注册表层面：• 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
类型 指标 C2 URL https://pastebin.com/raw/csi5UqpE、https://pastebin.com/raw/fTxiyhbL、https://snippet.host/wtbtew/raw、https://snippet.host/iqqmib/raw 释放文件名 ChromeUpdateSvc.exe、MicrosoftSync.exe、AdobeCloudHelper.exe、OneDriveSyncHost.exe、manager.exe、svc_host.exe、~update.tmp.exe 注册表值名 MediaIndexHelper、{NetworkManager}、System、Network、Host、Controller、USB 计划任务名 ChromeSyncHost、EdgeUpdateHelper、WindowsSecurityHost、AdobeCloudSync、TelemetrySyncSvc等 互斥体 HPCQM、Global{CoreTask1461}_、Global\6TpMUGXh_QnWf8m 伪装配置 “System Service Manager” 2.1.4、“Document Workspace” 10.0.22621.1 防火墙规则前缀 name=Telemetry_In_、name=Telemetry_Out_转载者评论： 最近AI应用尤其是梁圣降价后很多人会开始考虑用一些关联性项目，从安全态势来看近期同类型投毒案例也是激增，大家务必注意安全
7 个帖子 - 7 位参与者