在企业级安全运营场景中，NPM 供应链攻击的检测与响应需要从静态特征匹配升级为行为链关联分析。2024 年曝光的 Axios 供应链攻击事件涉及恶意版本包投递跨平台 RAT 载荷，其攻击链路呈现出「依赖安装 → postinstall 脚本执行 → 后台进程拉起 → C2 通信」的典型模式。本文聚焦该攻击模式的检测规则工程化，为安全运营团队提供可直接落地的 YARA 规则模板、Sigma 检测规则及 SIEM 告警关联方案，并附带 SOAR 自动化响应剧本的核心逻辑。

一、攻击链路特征拆解与检测设计原则

Axios 供应链攻击的核心特征并非单一恶意文件，而是一个多阶段攻击链。从检测工程角度，需要将该链路拆解为四个可独立检测的阶段：依赖包投递阶段、脚本执行阶段、载荷投递阶段与命令控制阶段。每个阶段的检测规则需要考虑不同的数据源与检测上下文，而非简单地匹配 IOC 黑名单。

第一阶段是依赖包投递。攻击者通过 compromise 维护者账号，将恶意版本推送到 npm registry。检测此阶段的数据源主要包括 CI/CD 管道的依赖安装日志与软件物料清单（SBOM）生成系统的审计日志。关键检测指标是版本号的异常跳变（如从 v1.13.x 直接跳变至 v1.14.1）以及发布时间的异常间隔。值得强调的是，单纯的版本号检测会产生大量误报，因此必须结合包体哈希校验失败或 PGP 签名验证失败等强信号进行关联。

第二阶段是 postinstall 脚本执行。这是供应链攻击的核心突破口。npm 允许包定义生命周期脚本，其中 postinstall 脚本在依赖安装完成后自动执行，且以项目构建用户的权限运行。检测此阶段需要获取 node_modules 目录的文件系统审计事件，特别是 postinstall、preinstall、install 等脚本文件的创建与执行事件。攻击者通常会在此阶段注入混淆的 JavaScript 代码或调用系统命令下载第二阶段载荷。

第三阶段是载荷投递与持久化。恶意包在此阶段投递 Python 或 Go 编写的 RAT（远程访问木马），并在系统中建立持久化机制。检测数据源包括进程创建事件（ETW/Sysmon Event ID 1）、文件创建事件（Sysmon Event ID 11）以及计划任务或服务创建事件。攻击载荷的典型特征包括非预期的 Python/Go 进程从 node_modules 目录启动、异常的网络连接尝试、以及可疑的 Crontab 条目。

第四阶段是命令控制通信。载荷与外部 C2 服务器建立通信，完成数据窃取或接收进一步指令。检测数据源为网络流量日志（DNS 查询、异常 TCP 连接）与 SIEM 的网络会话关联分析。关键检测逻辑是识别从 node_modules 目录启动的进程发起的非预期出站连接，特别是连接到已知恶意 IP 段或域名的流量。

检测设计应遵循分层防御原则：每层检测规则独立运行以保证检测覆盖率，通过 SIEM 关联引擎实现跨层关联以降低误报率。单一层次的检测告警仅作为调查线索，而非自动处置的触发条件。

二、YARA 规则编写：针对 NPM 攻击载荷的静态特征匹配

YARA 规则适用于在静态文件扫描场景中检测恶意载荷。在 NPM 供应链攻击的语境下，YARA 规则主要用于三个检测目标：构建产物的事前扫描、CI 工件的入库扫描、以及事件响应阶段的样本提取。

以下是一组针对 Axios 供应链攻击特征的 YARA 规则示例，可直接用于 ClamAV、YARA-Regule 或企业自行部署的文件扫描引擎：

第一条规则针对 postinstall 脚本中的混淆特征。攻击者惯用 Base64 编码字符串配合动态解码执行，以规避静态特征检测。规则通过匹配常见的编码特征组合加上下载行为的关键词来实现检测。实际部署时需要注意，单纯的 Base64 匹配会产生极高误报，因此必须限定在 npm 包目录结构内的文件中进行匹配，并结合脚本长度异常（通常超过 2KB 的 postinstall 脚本即为可疑信号）进行关联判断。

第二条规则针对跨平台 RAT 的 Payload 特征。根据公开的威胁情报分析，Axios 攻击事件中的恶意载荷为 Python 编写的跨平台木马，其特征包括硬编码的 C2 域名、Base64 编码的配置块、以及使用特定加密算法（如 AES-256-CBC）的通信协议。YARA 规则可匹配这些硬编码字符串的特定模式，但需要注意攻击者可能频繁更换 C2 域名，因此规则应设计为匹配编码结构而非固定 IOC。

第三条规则针对恶意脚本的文件名特征。攻击者倾向于使用看似合法的文件名（如 setup、build、install、init）来伪装恶意脚本。规则匹配 node_modules 目录下包含这些关键词且扩展名为 .js 或 .sh 的文件，同时结合文件内容的熵值检测（高熵值表明可能经过加密或混淆）来提升检测精度。

YARA 规则部署建议采用分层扫描策略。第一层为轻量级规则集，仅检测高置信度的硬编码特征，每日全量扫描构建产物与依赖缓存。第二层为重量级规则集，包含更复杂的正则匹配与字符串结构分析，仅在可疑事件触发后对特定工件进行深度扫描。这种分层策略可以在保证检测覆盖率的同时控制计算资源消耗。

三、Sigma 规则编写：面向 SIEM 的行为检测规则

Sigma 是一种通用的检测规则格式，支持转换为 Splunk、Elastic、KQL、QRadar 等多种 SIEM 平台的查询语法。Sigma 规则的优势在于一次编写、多平台复用，这对于使用多 SIEM 产品的企业尤为重要。

针对 NPM 供应链攻击，建议部署以下三组 Sigma 规则，分别对应攻击链路的核心阶段。

第一组规则检测异常的 npm 安装行为。核心检测逻辑是识别短时间内大量安装新依赖包的事件，特别是当安装来源为非内部私有 registry 或涉及高风险权限的包时。该规则的数据源为 CI/CD 日志（如 GitHub Actions、GitLab CI、Jenkins 的构建日志）或企业级包管理平台（如 Artifactory、Nexus）的审计日志。规则的查询逻辑筛选安装事件中的异常版本号模式、发布者账号的信誉评分（可通过外部威胁情报 API 补充）以及包体大小的异常偏离。

第二组规则检测 postinstall 脚本执行。该规则是整个检测链中最为关键的一环，因为绝大多数供应链攻击都依赖生命周期脚本作为攻击入口。规则的数据源为文件系统审计日志（Linux auditd 或 Windows Sysmon）。检测逻辑包含两个核心要素：一是 node_modules 目录下的脚本文件被执行，二是该脚本尝试网络连接或启动子进程。这两个要素的关联可以通过时间窗口（5 分钟内）来实现。

第三组规则检测可疑的出站网络行为。该规则定位攻击链路的末端阶段，检测从 node_modules 目录启动的进程发起的异常网络连接。数据源为网络流量日志或端点检测与响应（EDR）系统的进程网络事件。检测逻辑需要维护一个可信域名的白名单（如内部服务、已知合作伙伴 endpoint），对所有非白名单的出站连接进行告警，同时关联进程路径是否位于 node_modules 目录下。

Sigma 规则在实际部署时需要根据具体的数据源字段名称进行调整。例如，Splunk 环境需要将 Sigma 规则转换为 SPL 查询，Elastic 环境需要转换为 KQL。转换工具可使用开源的 sigmac 或 Sigma 官方提供的转换器。建议在转换后进行回归测试，验证规则在目标 SIEM 平台中能够正确匹配测试数据集。

四、SIEM 告警关联与风险评分模型

单一维度的检测告警往往不足以支撑安全运营团队的响应决策。在 NPM 供应链攻击场景下，建议构建基于攻击链阶段的风险评分模型，将分散的检测告警关联为完整的事件叙事。

风险评分模型的设计逻辑如下。每个检测规则根据其在攻击链路中的位置分配基础分数：依赖包投递阶段（10 分）、脚本执行阶段（25 分）、载荷投递阶段（40 分）、C2 通信阶段（50 分）。当同一主机上在短时间内（建议 30 分钟窗口）触发多个阶段的告警时，累加分数并提升告警等级。分数超过 60 分的告警应直接触发安全团队的应急响应流程，分数在 30 至 60 分之间的告警进入人工调查队列，30 分以下的告警仅作为威胁情报收集的补充来源。

告警关联的技术实现推荐使用 SIEM 的流分析引擎（如 Splunk 的 SPL 窗口函数、Elastic 的 ESL 管道处理器）。关联查询的逻辑是：以受攻击主机为单位，按时间排序聚合所有与 npm 相关的检测事件，识别是否存在跨阶段的攻击链模式。示例伪代码逻辑为：按主机分组、筛选 30 分钟内包含「npm install 事件 + postinstall 执行 + 网络外联」的事件序列。

此外，建议为每台主机维护依赖包版本清单（可通过定时运行 npm list --depth=0 获取），并在告警关联时自动比对受攻击主机是否包含已知的恶意版本（如 Axios v1.14.1、v0.30.4）。这种自动化清单比对可以大幅缩短从检测到确认的时间窗口。

五、SOAR 自动化响应剧本设计

在检测规则落地后，SOAR（安全编排、自动化与响应）剧本是将检测能力转化为实际防御效果的关键环节。针对 NPM 供应链攻击，建议设计三级响应剧本，分别对应不同的告警等级。

第一级剧本针对低风险告警，主要动作包括：自动提取告警相关联的依赖包信息（包名、版本、发布者、下载量），查询威胁情报平台获取包信誉评分，生成待人工审核的任务工单并分配至安全团队。该级别剧本不执行任何自动处置动作，仅加速人工分析流程。

第二级剧本针对中等风险告警，主要动作包括：隔离受攻击主机的网络连接（通过调用防火墙 API 或云安全组策略），暂停 CI/CD 管道的依赖安装任务，收集受攻击主机的完整进程列表与网络连接快照，生成事件调查报告并触发安全团队会审。该级别剧本的核心是遏制攻击扩散，同时保留充分的调查取证空间。

第三级剧本针对高风险告警（即确认的供应链攻击事件），主要动作包括：锁定所有使用相同依赖包版本的其他主机，撤销受影响主机的访问凭证，重置所有可能暴露的 API 密钥与部署凭证，触发完整的磁盘镜像与内存采集以支持事后取证。该级别剧本应设计为需要人工确认后才执行关键动作（如凭证撤销），以避免误操作导致业务中断。

SOAR 剧本的触发条件应与前述风险评分模型联动。建议在剧本执行日志中记录完整的时间线与动作序列，便于事后复盘与检测规则调优。

六、工程化落地的关键监控指标

检测规则部署完成后，需要通过量化指标持续评估其有效性。建议安全运营团队监控以下核心指标：

检测覆盖率指标。统计每月触发的供应链攻击相关告警中，由自动化检测规则产生告警的比例。目标值为 85% 以上，低于该值说明检测规则存在盲区，需要补充新的检测维度。

平均检测时间（MTTD）指标。从攻击链路首个阶段（依赖包安装）到安全团队收到告警的时间。目标值为 10 分钟以内，超过该值说明检测管道存在延迟，需要优化日志采集与规则执行效率。

误报率指标。由自动化检测产生但经人工确认为非恶意的告警占比。目标值为 20% 以下，高于此值说明规则过于宽松，需要增加关联条件或调整阈值。

自动化响应率指标。成功执行完整个自动化响应剧本的告警占比（不含人工介入阻断的案例）。该指标反映 SOAR 剧本的可用性与准确性。

建议将这些指标纳入安全运营仪表板的例行监控，每两周进行一次检测规则的有效性评审，根据最新的威胁情报更新 YARA 规则特征库与 Sigma 规则的关联逻辑。

资料来源

本文检测逻辑参考 Elastic Security Labs 发布的 Axios 供应链攻击检测方案；SOAR 剧本设计参考 SOC Prime 的威胁响应框架；风险评分模型基于 MITRE ATT&CK 供应链攻击战术的企业化改编。