MCP 插件市场被植入木马：聊聊我搞的 8 层防御体系

直接说结论：别太信任开源社区的 MCP Server 镜像，尤其是那些通过 ZIP 包分发的。前段时间我的 MCP 市场就中招了，一个典型的 Typosquatting（域名抢注/拼写欺骗）攻击，对方克隆了一个极其像原版的仓库，结果在 Release 的 ZIP 包里塞了个 Trojan:Win64/Lazy.PGPK!MTB。

这个木马套路很老，用一个 .cmd 引导文件去启动 .exe，然后加载一个混淆过的 Lua 字节码文件作为 Payload。最坑的是，我之前的审计流水线只检查元数据（名字、描述、System Prompt），压根没去扫描包内部的文件，直接就给 Commit 到 dist/skills/ 目录里了。

为了防止下次被这种低级错误搞崩，我把防御线拉到了 8 层，重点分享一下这次针对二进制和恶意软件新加的几层实操方案。

核心防御逻辑

一、元数据初筛 (L1.5)
这层最省钱，直接扫元数据。重点看有没有 ignore previous instructions 这种典型的 Prompt 注入模式，或者是否声明了危险的文件/SQL/HTTP 访问权限。

二、静态代码扫描 (L1.6)
不用部署沉重的 Semgrep，直接用 JS 正则实现 36 条规则。覆盖了命令注入、SSRF 和路径穿越。另外对 Stripe、GitHub、AWS 等 API Key 做了强匹配。
踩坑点： 之前 process.env.X 总是触发硬编码 Key 的报警，后来得在扫描前先把环境变量模式剔除掉。

三、二进制与恶意软件检测 (L1.7) —— 重点
这次专门针对 ZIP 包做了递归扫描（防止套娃 ZIP）。只要出现以下特征直接标记为 critical 并进入隔离区：

敏感后缀： .exe, .dll, .scr, .msi 以及 .bat, .cmd, .ps1 等启动脚本。

特征模式： 比如 start X.exe Y.txt 这种分段启动模式，或者 Base64 编码的 PowerShell 命令。

异常文件： 超过 100KB 且不是合法 JSON 的文本文件（大概率是字节码 Payload）。

具体扫描逻辑参考：

const BINARY_EXTENSIONS = ['.exe', '.dll', '.scr', '.msi'];
const LAUNCHER_EXTENSIONS = ['.bat', '.cmd', '.vbs', '.ps1'];
// 匹配分段启动或混淆代码的正则
const MALWARE_PATTERNS = [
  /start\s+.\.exe\s+.\.txt/i,
  /eval\(atob\(.*\)\)/i,
  /-encodedcommand\s+[A-Za-z0-9+/=]{100,}/i
];

四、家族签名库 (L1.8)
引入了类 YARA 的规则，针对 17 个已知的恶意软件家族进行指纹比对，并挂载到 MITRE ATT&CK 框架的 ID 上，方便快速定位攻击手段。

目前这套流程跑在生产环境下，任何命中关键规则的插件会被直接 quarantined（隔离），从目录中剔除并记录在安全审计接口里。对于后端工程来说，这种“宁可误杀，不可漏过”的策略在处理第三方插件时是最稳的。