文章总结： 本文深度解剖solarwinds与xzutils两起供应链攻击案例，指出攻击本质是打信任链而非漏洞。solarwinds通过攻陷构建系统植入带合法签名的后门，xzutils则通过社会工程伪装开源维护者投毒。检测失灵源于信任锚被攻陷，防御需将信任链纳入监控，实施构建隔离、可复现构建、维护者变更监控等措施。 综合评分： 92 文章分类： 供应链安全,漏洞分析,安全意识,攻防复盘,安全建设

供应链攻击解剖：从 SolarWinds 到 XZ Utils 后门

赛博57 赛博57

赛博57库

2026年9月6日 05:00 广东

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

| | | — | | SUPPLY CHAIN ATTACK AUTOPSY · 双案例解剖 供应链攻击解剖：从 SolarWinds 到 XZ Utils 后门 信任链如何被一步步打穿 · 检测为何集体失灵 · 一线怎么接招 |

| | | — | | 赛博57库 2026-09-05 · 攻防复盘 · 供应链安全 |

| | | — | | 📌 为什么写这两起案例 SolarWinds（2020）把后门签进合法更新，XZ Utils（2024）让攻击者成为开源维护者——两起攻击相差四年、打法完全不同，却都断在同一处：信任本身。本文不做新闻罗列，只做机制级解剖：攻击链每一环怎么走通、现有检测为什么看不见、一线防御往哪使劲。相关史实均核验自公开一手来源。 |

| | | — | | 2020 年 12 月，FireEye 在调查自家红队工具被盗时，意外牵出一起被隐瞒数月的供应链入侵：SolarWinds 的官方更新里，藏着带合法签名的后门，约 1.8 万家客户的信任一夜归零。2024 年 3 月末，一位德国程序员发现 sshd 登录”慢得反常”，顺藤摸瓜挖出 XZ Utils 后门——一个攻击者伪装成开源贡献者潜伏近三年，差点给全球 SSH 装上”万能钥匙”。两起攻击相隔四年、打法完全不同，却指向同一个本质：攻击者打的不是漏洞，是信任本身。本文逐环节拆解这两条攻击链，回答三个问题——立足点怎么找、检测为何集体失灵、一线蓝队能学到什么。 |

01 · 供应链攻击的两种范式：打分发链，还是打人

先建立一个最小模型。任何软件的交付都经过一条信任链：

| | | — | | 开发者 → 版本控制 → 构建系统 → 签名 → 分发渠道 → 镜像/仓库 → 部署 → 运行 |

用户（和组织）之所以敢运行一个程序，是因为信任这条链上的每一环：代码是作者写的、构建是可信的、签名是真的、下载源是官方的。供应链攻击不碰漏洞，而是直接取代链条上的某一环，让恶意代码以”合法身份”流到用户手里。

两起标杆案例恰好覆盖两种范式：

•  SolarWinds（2020）= 打”商业分发链”：入侵厂商内部构建/发布设施，把后门编进带官方签名的更新包。用户端看到的是”SolarWinds 官方更新，签名有效”。

•  XZ Utils（2024）= 打”人”：不碰任何厂商内网，而是伪装成开源贡献者，花近三年时间成为项目的信任维护者，再亲手发布带后门的版本。用户端看到的是”项目维护者发布的新版本”。

| | | | | — | — | — | | 维度 | SolarWinds | XZ Utils | | 目标软件 | Orion 网络监控平台（商业闭源） | xz/liblzma 压缩库（开源） | | 信任载体 | 厂商合法代码签名 | 维护者身份与发布流程 | | 立足点 | 入侵构建/发布系统 | 社会工程”考编”进项目 | | 潜伏周期 | 约 9 个月（2019.9 进入 → 2020.3-6 投放） | 近 3 年（2021 建号 → 2024.2 投毒） | | 载荷隐藏处 | 官方更新里的恶意 DLL | 官方 tarball（git 仓库里没有） | | 绕过什么 | 签名验证、软件白名单、沙箱 | 代码审计、GitHub 扫描、fuzzing |

两条链的断裂点不同，但断的环节都是”信任”——这正是它们能骗过所有人、也最难防御的原因。下文分别解剖。

02 · SolarWinds（2020）：把后门签进”合法更新”

2.1 为什么是 Orion

SolarWinds Orion 是网络与系统监控平台，当时拥有约 3.3 万客户，其中美国联邦政府机构的渗透率极高——财政部、商务部下属 NTIA、国土安全部等都在用（司法部、能源部后来也出现在受害者名单上）。对情报机构型攻击者而言，Orion 是”装在政府网络内部的门禁系统”：拿下它的更新通道，就等于拿到了进入大量高价值内网的分发管道。

2.2 攻击链拆解：五步走通

01  立足（不晚于 2019 年 9 月）：攻击者进入 SolarWinds 的软件发布基础设施。调查显示其访问了 SolarWinds 的内部系统，并在构建系统中落脚——不是靠一个零日漏洞，而是通过 IT 环境渗透逐步摸到构建环节。

02  植入（约 2020 年 2 月前）：在构建系统里植入恶意代码，最终编入名为 SolarWinds.Orion.Core.BusinessLayer.dll 的合法组件。DLL 使用 SolarWinds 自己的代码签名证书签名——签名是真的，因为签名的机器被攻陷了。

03  投放（2020 年 3 月—6 月）：恶意 DLL 随 Orion 2019.4 至 2020.2.1 HF1 的官方热修复包，通过正常更新机制推送给客户。SolarWinds 后来在 SEC 文件中披露：约 3.3 万客户中不到 1.8 万收到了受影响版本。

04  潜伏与回连：恶意代码在受害机器上休眠 12—14 天，之后才尝试联系命令控制服务器；通信伪装成正常 SolarWinds 遥测流量，C2 域名 avsvmcloud.com 等通过 DNS 解析切换，规避静态封禁。

05  定向二次打击（最关键）：SUNBURST 只是”大门钥匙”。攻击者对高价值目标手动跟进：窃取 SAML token 签名证书（即后来广为人知的 Golden SAML 手法），伪造身份令牌，以”合法用户”身份进入 Azure AD、Office 365 与内网应用——后门只负责递钥匙，进门靠的是伪造的合法身份。

2.3 结果与归因

受波及组织全球至少 200 家，含美国财政部、商务部下属 NTIA、国土安全部等联邦机构，FireEye 自身也是受害者（其红队工具被盗，反而成为发现整起事件的契机）。微软将此攻击命名为 Solorigate，FireEye 命名为 SUNBURST；美国官方归因于俄罗斯对外情报局（SVR）下属的 APT29（Cozy Bear / Nobelium）。

2.4 为什么检测集体失灵

•  签名是真的：恶意 DLL 带 SolarWinds 合法证书，杀软、EDR、应用白名单把”可信签名软件”直接放行；

•  行为不突兀：回连流量模仿 Orion 正常遥测，长白名单域名低频查询，没有”恶意软件该有的动静”；

•  休眠 12—14 天：多数沙箱和动态分析跑不到两周就放行；

•  二次阶段用的是合法身份：Golden SAML 伪造的令牌让 SIEM 看到的是”正常用户登录”，而非入侵。

一句话教训：签名验证验证的是”代码是谁签的”，不是”签名的机器是否可信”。当信任锚本身被攻陷，所有依赖它的检测全部失效。

03 · XZ Utils（2024）：潜伏近三年，只为成为”自己人”

3.1 攻击面：压缩库里的”数字地基”

xz/liblzma 是几乎所有 Linux 发行版预装的压缩库。正常情况下 OpenSSH 不依赖它，但部分发行版通过 systemd 间接把 sshd 与 liblzma 链接在一起——这意味着，liblzma 里的一段恶意代码，理论上能在 SSH 认证流程中执行。安全界事后评价：如果这个后门没被发现，它会给植入者一把打开”全球数亿台运行 SSH 的机器”的万能钥匙。

3.2 三年社会工程：Jia Tan 时间线

攻击者以一个虚构身份”Jia Tan”（GitHub: JiaT75）活动，手法不是入侵，而是扮演模范开源贡献者：

•  2021：创建 GitHub 账号。首个动作不在 xz，而在 libarchive——提交一个看似无害的补丁，实则把 safe_fprint 悄悄换成不安全变体（试探社区审查力度，成功合并且无人讨论）。

•  2022 年 4 月：向 xz 邮件列表提交第一个补丁；同一时间，新账号 “Jigar Kumar” 出现并施压要求合并该补丁，随后开始向项目原作者 Lasse Collin 施压”该增加维护者了”。三天后，JiaT75 向 xz 提交首个代码并成为稳定贡献者。

•  2023 年 1 月 7 日：JiaT75 的首个提交被合并——社区信任的里程碑。同年 3 月，Google oss-fuzz 的主联系邮箱从 Lasse Collin 换成 Jia Tan（这一步意义重大：他能看到并影响模糊测试配置）；同月，一个疑似马甲账号 “Hans Jansen” 提交了基于 ifunc 的 crc64 实现，为后门机制做铺垫。7 月，Jia 在 oss-fuzz 中关闭了对 ifunc 代码的模糊测试——提前拆掉可能发现后门的探测器。

•  2024 年 2 月：提交最终步骤——以”新增测试文件”为名义的两份二进制数据文件。随后发布的 5.6.0 / 5.6.1 tarball 包含完整后门，而 git 仓库中对应提交并无恶意内容——恶意载荷只存在于 Jia Tan 发布的发布包中。他甚至试图在 Ubuntu 冻结测试版之前把版本塞进去。

支撑这次渗透的还有一个马甲网络：Jigar Kumar、krygorin4545、misoeater91、Dennis Ens 等账号只在 xz 相关讨论中出现，没有其他任何公开开发足迹，彼此在时间上严密配合施压与背书。

3.3 后门机制：构建期注入 + ifunc 劫持

•  两个伪装成测试数据的压缩文件在 tarball 里休眠，正常情况下不被执行；

•  一个被恶意修改的构建脚本（build-to-host.m4）在 configure 阶段触发，解压并注入恶意代码——审计 GitHub 源码看不到，因为恶意步骤只存在于发布 tarball；

•  注入代码用 ifunc（GNU 间接函数） 机制替换 liblzma 中 crc32/crc64 等函数的解析——正常功能照常运转，但解析器被指向恶意实现；

•  最终效果：sshd 的 RSA 公钥认证路径被挂钩，持有特定 Ed448 私钥的攻击者可在认证前触发远程代码执行；

•  代码高度混淆、多阶段、条件触发（仅在特定架构与构建配置下激活），沙箱与审计环境难以触发完整链路。

3.4 发现与收场

•  2024 年 3 月末：软件开发者 Andres Freund 发现 Debian 试验版系统的 sshd CPU 占用异常偏高、且 Valgrind 报出可疑错误，顺藤摸瓜定位到 liblzma。3 月 29 日，oss-security 公开披露；

•  CVE-2024-3094，CVSS 10.0（最高严重度）；

•  影响面：主要停留在各发行版的开发分支（Debian sid/testing、Fedora Rawhide、Kali 等），主流稳定版在披露前未被广泛安装；

•  收场：Debian / Red Hat / SUSE 等紧急回滚到旧版本重建，GitHub 短暂禁用 xz 镜像；原维护者 Lasse Collin 于 2024 年 5 月 29 日发布修复版 5.6.2；

•  余波（2025 年 8 月）：安全公司 Binarly 发现 Docker Hub 上的多个 Debian 历史镜像仍含该后门——官方选择保留为历史制品并警告”开发构建不得用于生产”。教训：清理要清到镜像层，容器镜像一旦被拉取就会永久留在供应链里。

3.5 为什么这次几乎成功

•  打的是人不是代码：全程不依赖任何漏洞，依赖的是开源维护者的倦怠与善意——Lasse Collin 长期独自维护 xz，精力不济是公开话题，”增加维护者”的施压因此显得合理；

•  人的环节没有验证机制：谁在合并提交、谁拿到了权限、谁握着 fuzzing 邮箱——社区靠直觉而非制度；

•  载荷藏在 tarball 而非 git：代码审计、GitHub 自动扫描、镜像比对全部落空；

•  高度定向触发：开发分支先行、条件触发，等进入稳定版时已经”信任”完成。

04 · 对照与启示：两条信任链，断在同一个地方

| | | | | — | — | — | | 环节 | SolarWinds 的断法 | XZ Utils 的断法 | | 代码 | 恶意代码混入合法组件源码 | 恶意构建步骤不在 git、只在 tarball | | 构建 | 构建系统被攻陷 | 构建流程由”维护者”亲手修改 | | 签名/身份 | 用厂商真证书签名 | 用社区授予的维护者身份背书 | | 分发 | 官方更新通道推送 | 官方发布渠道（tarball）发布 | | 用户感知 | “官方更新 + 有效签名” | “维护者发布的新版本” |

共同点比差异更值得警惕：

01  目标不是漏洞，是信任载体——签名的构建机、社区的维护者席位，这些”信任锚”几乎没有任何技术检测手段；

02  长期潜伏换一次性信任，然后小动静、高定向地行动（SolarWinds 只对高价值目标二次跟进；XZ 的后门条件触发、静默等待）；

03  “看起来合法”就是最好的伪装——杀毒、EDR、SIEM 全部基于”恶意特征”工作，而供应链攻击的特征是”合法主体做了不该做的事”。

对一线最扎心的启示：供应链攻击无法靠”更快的补丁”防御——它绕过了漏洞管理，攻击的是你信任的软件本身。安全体系如果只盯”漏洞”而不盯”信任链”，就永远接不住这类攻击。

05 · 一线行动：把信任链变成检测面

防御供应链攻击的正确姿势，是把”信任链”本身纳入监控。按生命周期分层落地：

5.1 构建与发布环节（防 SolarWinds 型）

•  构建系统隔离与审计：构建机与办公网分段，构建/发布账号用硬件密钥 + 双人审批，发布操作全量留痕——SolarWinds 的教训是”一个内部账号就能摸到签名机”；

•  签名私钥硬件化：代码签名私钥进 HSM/云 KMS，任何机器上不留可导出的私钥副本；

•  可复现构建：同一源码应能产出字节一致的产物（配 SBOM 记录依赖树）。可复现构建是发现”构建环节被动手脚”的最强手段；

•  产物哈希发布：官方公布每个版本的哈希，用户端校验。

5.2 依赖与开源环节（防 XZ 型）

•  维护者变更监控：对你锁定的关键依赖，监控”谁新获得了提交权限/谁成了新维护者/主联系邮箱是否变更”——XZ 事件中这三件事全是信号，社区却无人告警；

•  发布包与 git 一致性校验：定期比对 release tarball 与 git tag 内容（哈希/文件清单）。XZ 的恶意载荷只存在于 tarball，这类比对是直接命中；

•  依赖锁版本 + 哈希校验：CI 与运行时锁死依赖版本与哈希，对包仓库投毒这类攻击，恶意版本数小时内即可扩散，靠”过几天再升”防不住；

•  给关键开源项目捐款/参与审查：对”数字地基”级依赖（压缩库、加密库、构建工具），用资源换制度——bus factor 为 1 的项目就是下一个 xz 的温床。

5.3 运行检测（两案通用）

•  异常出站与 DNS：监控低频、长白名单域名的 DNS 查询与遥测伪装流量（SUNBURST 模式）；对更新类进程的出站连接保持可见；

•  身份层异常：SAML/OAuth 令牌签发频率突变、跨租户访问、非常规时间登录——Golden SAML 类攻击在身份日志里留痕；

•  关键进程基线：sshd 等关键服务的 CPU/内存/系统调用基线，偏离即告警（XZ 的发现正是一个工程师注意到 sshd 异常慢）；

•  供应链事件应急预演：假设”某官方源被污染”，提前写好剧本——该断哪个镜像、回滚到哪个版本、如何全网清查。

06 · 收尾

SolarWinds 与 XZ Utils 相隔四年，一个打商业闭源、一个打开源社区，但攻击者做的是同一件事：找一个没人监控的信任环节，住进去，然后让恶意代码以合法身份流动。检测工具会越来越强，但信任锚（签名机、维护者席位）的攻防不会消失——因为只要人类还在信任软件，这条链就存在。

对安全团队，最值得做的三件事：把关键依赖的发布包与 git 一致性校验自动化；给代码签名与发布流程上隔离与审计；以及，把”供应链事件”写进应急响应预案——现在写，别等下一次 SolarWinds 或 XZ 出现再写。

来源与说明

•  SolarWinds 事件时间线与技术细节：美国联邦政府 2020 数据泄露事件公开记录（SEC 文件、CISA 紧急指令 21-01）、微软 Solorigate 分析、FireEye/Mandiant SUNBURST 报告、CrowdStrike Golden SAML 分析（2020.12—2021）

•  XZ Utils 后门：oss-security 披露帖（2024-03-29）、CVE-2024-3094（NVD，CVSS 10.0）、Evan Boehs《Everything I Know About the XZ Backdoor》时间线整理、xz 维护者 Lasse Collin 官方说明（tukaani.org）

•  后续影响：Binarly 2025-08 Debian Docker 镜像后门遗留发现

•  文中”休眠 12—14 天””至少 200 家组织””不晚于 2019 年 9 月”等数字均出自上述公开记录；两起攻击的归因结论（SVR/APT29）为美方官方立场

•  本文为事件复盘与技术分析，供一线安全建设参考；具体版本与修复状态请以厂商官方公告为准

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：赛博57库 赛博57 赛博57《供应链攻击解剖：从 SolarWinds 到 XZ Utils 后门》