免责声明：本文为个人技术学习与工程实践笔记，所涉操作仅应在获得授权的环境中进行。因不当使用造成的后果由使用者自行承担。
开源 Polymarket 交易机器人中的供应链投毒风险与识别
IOC：www.polymarketapi.xyz || data-update.polymarketapi.xyz
MD5：63e119d4e3f98a5a9775bd95fd1fb513
Filename：redis.exe上述域名与样本可直接用于出口流量阻断、DNS 日志检索与终端 IOC 排查。
前段时间，我订阅的 GitHub 监控机器人推送了几个国产化的 Polymarket 市场预测机器人项目。出于评估新项目的习惯，我抽查了这些仓库的代码，发现其中若干项目存在供应链投毒，程序运行后即可窃取用户私钥，本文以其中一个仓库为例。下图为 Polymarket 关键词的搜索结果截图，与开头描述无关
凡涉及资金与私钥的 GitHub 项目，都应当逐行核对代码以及间接引入的安装包依赖。
据仓库描述，该项目用于预测 Polymarket 的 5 分钟市场；从代码实现上看，所谓预测只是调用模型生成的一批内容，并不具备实际策略价值。
README 的排版与术语都相当规范，因此很容易被当作成熟项目，但其中配置私钥的步骤存在明显的诱导性引导。
随后核对了项目的背景信息，作者在 X 上持续转发自己的工具，频率约为每天数条。
该项目的 GitHub 与 X 账号均为新注册账号，同时有一批粉丝量较大的账号在集中转发。这里需要注意：账号的粉丝量、Star 数都不能作为项目可信度的证据，Star 数偏低而转发声势很大的组合尤其值得警惕；如不具备代码审计能力，可借助静态分析或代码安全审查工具辅助判断，例如 Claude Code Security。
作者的 Github 仓库
作者的 X 账号
截至 2026 年 2 月 24 日，已有用户因该项目产生实际损失，单笔金额不大，但涉及的是可直接变现的链上资产。
标榜免费的资金类工具通常有代码之外的变现方式，因此代码审查不能省略。我大致审计了该仓库的代码，整体质量接近由模型直接生成的水平，能否跑通尚不确定，但该项目发布后长期存续且未被平台处置，本身就是一件值得注意的事。
一个可供参考的经验：若仓库中大量使用 Emoji、渐变配色、营销化措辞，技术栈是常见的 Vercel + Next.js 组合，并配有大段夸张的项目背景描述，那么项目与代码很可能由模型生成，其中更可能夹带与项目无关的逻辑，需要重点核对。
整个仓库本身的业务代码没有明显问题，风险集中在 Cargo.toml，也就是依赖层面。npm 生态的投毒事件通常在社区中被较快发现，而 Rust 生态的差异在于任何人都可以向 crates.io 上传自己的依赖包，且发布过程不经过人工审核。
该项目引用了一个名为 rpc-check 的依赖包。追溯该包可以发现它发布时间很短，且其维护者信息与主仓库开发者能够对应，这一点基本可以判定为同一来源的供应链投毒。这里需要强调依赖的传递性：如果 A 引用 B、B 引用恶意包 C，那么 C 的代码同样会在本机执行，仅审查直接依赖无法覆盖这一风险。查看该包后发现其代码仍在更新，并采用了相对较新的隐蔽手法 （本文仅分析其刚发布的版本）。
该包的 Security 页面显示，已有研究者将相关问题上报至 crates.io。
具体详见
https://rustsec.org/advisories/RUSTSEC-2026-0014.html
该包具体做了什么？下面通过 docs.rs 查看其公开源码。
该包会释放一个名为 redis.exe 的文件。提交沙箱与威胁情报平台分析后确认其为远控木马（Cobalt Strike），后果不必展开。
调用点位于 src/report.rs，其中包含大量混淆内容。
https://docs.rs/crate/rpc-check/latest/source/src/report.rs
所谓混淆实际上是单字节 XOR，即用固定密钥对字符串逐字节异或。
解开后可以看到恶意脚本 safe_update.sh，其中包含明显的命令执行行为。
解码后的脚本内容如下（具体命令不再列出）。
最后归纳这次投毒行为的完整链路以及对应的识别点。
环节一：信誉伪装与诱导下载（识别要点）
这类项目通常面向有盈利诉求、且日常接触私钥的 Web3/Polymarket 开发者。仓库会以模型生成的规范 README 包装自身，再借助 GitHub Star 与 X 上的集中转发制造“已被广泛使用”的印象。识别要点在于把可验证的技术事实与营销信息分离：README 的排版、Star 数、转发量都不构成可信度证据，只有代码与依赖树是可验证的。
环节二：传递依赖投毒（依赖链可见性）
主仓库的业务代码保持干净，恶意逻辑被拆分到第三方依赖包（本文中的 rpc-check），并复用与主项目一致的维护者名称以降低戒心。识别要点是建立完整的依赖链可见性：恶意代码不一定出现在直接依赖中，任何深度为 N 的传递依赖都会在本机执行。
环节三：混淆与平台差异（静态检测特征）
该样本通过单字节 XOR 隐藏外连地址与 Shell 指令，以规避代码托管平台的静态扫描和杀毒软件的关键词匹配，并按运行环境切换行为：Windows 侧落盘常驻木马，Linux/macOS 侧执行一次性脚本。静态检测的落点因此不在明文字符串匹配，而在可疑的解码/执行组合：字符串解码例程与进程创建、网络请求相邻出现，即是需要人工复核的信号。
环节四：凭据读取与数据外传（主机与流量特征）
样本通过 tokio::spawn 启动后台异步任务，在不影响程序正常功能的前提下静默读取 .env 等文件中的 PRIVATE_KEY，并以仿冒域名（如 *.polymarketapi.xyz）作为回传端点，借助开发者对 API 域名的习惯性忽略来掩盖异常流量。对应两个检测面：主机侧关注非程序自身目录下的敏感文件读取行为，网络侧关注与官方域名高度相似但不完全一致的出站请求。
环节五：驻留与后续处置（终端排查）
Windows 侧会写入伪装为常规工具名的可执行文件（如 redis.exe）并建立命令与控制通道；私钥外传后，后端脚本会持续监控地址余额并转移资产。这意味着处置必须与密钥轮换同步进行：仅清除本机恶意文件而保留原私钥，资产仍会在后续被转移。
依赖治理：把依赖树纳入可审查范围
针对传递依赖投毒，依赖治理是成本最低、覆盖面最广的一层控制。
- 还原完整依赖树。使用
cargo tree查看直接与间接依赖的引入路径，重点确认Cargo.toml中未显式声明、却出现在构建产物中的包；cargo tree -i <package>可反查某个包是被谁引入的。 - 对照漏洞与恶意包数据库。
cargo audit可基于 RustSec 咨询数据库检查Cargo.lock中的依赖版本，本文所涉问题即以 RUSTSEC 编号公开披露；同时可结合cargo deny对依赖来源、许可证与重复版本做策略校验。 - 锁定并审查变更。提交
Cargo.lock，使依赖版本可复现；升级或新增依赖时审查 lockfile 差异，避免在构建过程中自动拉取新版本。 - 阻断即时发布窗口。对资金类工具，优先使用内部镜像或 vendoring 方式固定依赖，并延迟采纳发布时间极短的新包；发布历史短的包是此类投毒的共同特征。
主机与流量侧的检测与加固
- 进程链异常。正常运行的程序不应在用户目录、临时目录或自身安装目录写入新的可执行文件并随即启动，此类“写入后立即执行”的父子进程关系应直接告警。
- 文件落地点巡检。结合已知 IOC，检索用户目录与临时目录中与正常组件同名的可执行文件；本文样本使用
redis.exe这一名称，若该文件出现在数据库产品的标准安装目录之外，即可判定为异常。 - 出站访问收敛。对交易类程序运维主机实施默认拒绝的出站策略，仅放行经确认的交易所 API 与依赖源；旁路记录 DNS 与 TLS SNI，对与合法 API 域名高度相似、注册时间很短的域名告警。
- 凭据与密钥的最小暴露。私钥不应以明文形式长期存放于运行第三方代码的主机；生产环境应使用硬件钱包或托管签名服务，限定可签名范围，并配合定期轮换；
.env等文件需限制权限并纳入访问审计。 - 加固事件响应顺序。确认中招后应先隔离主机、再轮换全部相关密钥与 API 凭据，最后才做取证与清除，避免边清理边被继续转移资产。
排查清单
- 是否安装或运行过引用
rpc-check的项目，可从Cargo.lock中直接检索该包名。 - 主机上是否存在与 IOC 一致的
redis.exe，及其是否有计划任务、服务或启动项与之关联。 - DNS 与代理日志中是否存在指向
*.polymarketapi.xyz的请求记录。 - 相关钱包地址是否出现非本人发起的转出记录，私钥是否可判定为已泄露。
- 同上主机登录过的交易所 API Key、社交账号与邮箱凭据是否需要一并轮换。
恶意字符串解混淆方法
样本的混淆强度很低，对固定密钥逐字节异或即可还原。分析时无需直接执行样本，可在隔离环境中提取密文字节数组与密钥，用脚本完成解码，并将还原出的域名、路径与命令写入 IOC 清单，用于流量阻断与终端检索。公开的沙箱与威胁情报平台也可用于确认文件性质，本文样本即由此判定为远控木马。
至此，本次投毒行为的完整链路与对应的识别、加固措施均已说明。
