chromebackdoor

ChromeBackdoor 深度剖析：当 MITB 从漏洞转向配置

项目背景与痛点

Man-in-the-Browser 并不是新概念，2007 年前后就有系统性论述。它真正难做的部分从来不是“看见 DOM”，而是“让代码以合法的身份，跑进浏览器的信任域里”。

过去十年，浏览器厂商系统性地收紧了这条路径：扩展商店签名、Chrome 的 Secure Preferences HMAC 校验、Manifest V3 把后台页降级为随时会被回收的 Service Worker、站点隔离切断跨域 iframe 的脚本访问。传统靠 BHO、靠插件 DLL 注入的打法基本失效，剩下的空间被压缩到两个方向：要么寻找浏览器 0day，要么利用企业环境里本就存在的“合法配置通道”。

graniet/chromebackdoor 明确站在后者。它把自己定位成 PoC 而不是武器，核心价值不在技术原创性，而在链路整合：生成一个单文件 exe，落地后在主流浏览器上加载恶意扩展或脚本，把 DOM 数据回传到 C2。对红队而言，这意味着在评估某个组织“终端侧持久化检测能力”时，有了一个可复现、可对比的基线样本；对蓝队而言，它是一个免费的攻击面地图。

核心技术揭秘

从项目定位推断，它的实现可以拆成三层。

投递层负责生成 .exe。作者 graniet 长期活跃在 Go 安全工具生态，合理推测是一个 Go 编译的单文件 stub，扩展资源通过 go:embed 或 base64 内嵌。单文件、静态链接、无需目标机安装运行时——这几乎是 Go 做 dropper 的标准答案，代价是体积偏大且容易被静态特征命中。

驻留层是最见功力的部分。它需要探测已安装的浏览器类型与用户配置目录，然后按浏览器选择不同的落地方式。对 Chromium 系，可选路径有两条：命令行参数 --load-extension，或者直接改写 Preferences 中的 extensions.settings。对 Firefox，最省事的是写入 distribution/policies.json，用企业策略强制安装扩展。

这里有个绕不开的取舍：Chrome 对 Preferences 里的扩展条目做 HMAC 完整性校验，手工改写会被判定为文件损坏并整体重置。所以 PoC 更可能绕开它，走命令行或策略文件路线——这不是破解，而是回避，代价是留下极其显眼的痕迹（进程命令行、策略文件写入）。

采集层是扩展的 content script 拿到 DOM，序列化后交由后台页面走 HTTP(S) 或 WebSocket 回传。在 MV3 下后台是 Service Worker，会被随时回收，做长连接的命令通道需要用 chrome.alarms 或 offscreen document 保活；若项目仍基于 MV2，说明它瞄准的是策略宽松或版本较老的环境。

一个必须点破的现实：抓 DOM 不等于抓凭证。现代登录流程大量走 fetch/XHR 加短期 token，密码框常见于跨域 iframe，站点隔离之后根本读不到。所以这类工具实际收获的是“页面结构 + 表单快照 + 会话上下文”，要形成完整杀伤链，还需叠加键盘钩子或网络层拦截。README 里“send all DOM datas”的说法，在真实环境中会立刻撞上体积与噪音问题——全量上传必须节流，我推测实现里存在按事件触发或增量 diff 的策略。

功能亮点与差异

跨浏览器覆盖。多数同类 PoC 只做 Chrome，它把 Edge、Brave、Opera、Firefox 一并纳入，适配成本主要花在配置路径枚举上，但对红队来说命中率提升明显。

生成即用。目标机不需要 Python、Node 或任何运行时，落地一个文件就能自举。

不依赖 0day。这是最值得警惕的设计选择：它利用的是“配置与策略”这类合法通道，因此在完全打补丁的浏览器上依然可能奏效。它把风险从“漏洞管理”转移到了“终端配置治理”，而后者在很多组织里几乎无人负责。

与常见工具横向对比：BeEF 是 Hook 页面，前提是存在 XSS；Evilginx 是反向代理钓鱼，骗的是人；chromebackdoor 是本地持久化加浏览器内执行，靠的是“驻”。三者不在同一赛道，不能简单比强弱。

应用场景与落地建议

仅在书面授权的红队评估、企业策略审计、安全意识培训演示中使用，并严格遵守《网络安全法》及《刑法》285/286 条相关规定。

实操层面：一律在虚拟机快照中运行，不要碰宿主；重点观察三类痕迹——进程命令行里的 --load-extension、policies.json 的无预期写入、以及浏览器配置目录的异常变更。蓝队可以直接据此编写检测规则，这比追样本哈希有价值得多。另外注意，该工具的 C2 通道设计相当粗糙，真实评估中应替换为受控域名，避免误连第三方。

综合评价

优点在于链路完整、单文件交付、跨浏览器适配，工程化程度明显高于一般“贴一段注入代码”的 PoC，作为教学样本和检测基线非常合格。

缺点同样清晰：它没有免杀设计，C2 简陋，全量 DOM 回传的噪音与性能问题没有真正解决；面对 Chrome 的 Secure Preferences 它选择绕行而非突破，痕迹刺眼；MV3 全面铺开后，其扩展方案的效果会明显退化。

一句话总结：这是一个优秀的攻击面说明书，而不是一件趁手的兵器。它真正的贡献，是提醒防御方——浏览器的信任边界不止在代码签名，还在那些没人审计的配置文件里。