Closing the Binary Blind Spot: Domain-Knowledge Injection for LLM Malware Triage in npm Packages

消除二进制盲区：通过领域知识注入提升LLM在npm包恶意软件分类中的能力 | Databricks博客

跳至主要内容

网络安全

2026年10月16日

消除二进制盲区：通过领域知识注入提升LLM在npm包恶意软件分类中的能力

作者：Databricks威胁研究团队

引言

针对软件包注册表的供应链攻击在数量和复杂性上都在增长[1]。公开研究经常观察到各种威胁行为者将恶意软件部署到npm注册表，从垃圾邮件活动[2]到朝鲜民主主义人民共和国（DPRK）恶意软件的持续扩散[3, 4, 5]，再到2025年和2026年的高影响力TeamPCP组织[6, 7]。DPRK和TeamPCP组织有成功入侵广泛使用的开源项目的记录，以实现最大化的下游影响[8]。

为了直接研究这一问题，我们自2025年11月起开始收集npm恶意软件样本，并观察到在通过OSV npm恶意软件公告[9]验证的11,413个软件包版本中，npm注册表上的大多数恶意软件将有效载荷隐藏在软件包源代码中或从外部服务器获取，占已验证数据集的96.2%。剩余的3.8%（432个软件包版本）包含二进制文件。虽然数量较少，但它们在分类过程中可能带来不成比例的风险。一个经过剥离且无法被工具读取源代码的不透明二进制文件可能被嵌入在看似干净的源代码和元数据的伪装中，从而可能误导LLM得出良性判断。

我们评估了一组LLM如何在不同混淆和模糊程度的定制二进制有效载荷上进行推理，识别出针对该向量特有的失败模式，并通过一种专门设计且成本效益高的领域知识编码方案来解决这些问题，从而提升预算模型和前沿模型的检测质量。

背景

为支持更广泛的研究社区，我们构建了一个实时监控npm注册表的扫描器，并在LLM分类前运行静态分析阶段：使用YARA[10]分析tarball文件，使用Semgrep[11]和npm注册表API分析JavaScript代码和元数据，并对编译后的产物进行二进制分析模块处理。该扫描器将输出组装成结构化提示，LLM返回包含推理过程的判断结果，并在最多三轮交互中请求额外文件。

我们的分析发现，包含捆绑二进制文件的软件包既是最罕见的，也是最难分类的。分发恶意JavaScript的攻击者可以假设目标系统已具备执行有效载荷的运行时环境，而二进制文件必须为多种目标机器编译。在OSV确认的npm恶意软件中，包含二进制文件的软件包比仅包含源代码的软件包更频繁地无法得出明确的恶意判断（14.4% vs 6.2%）。

先前的研究通过专家撰写的训练数据对开源模型进行指令微调，将知识编码到模型权重中[12]。这种方法无法触及封闭的托管模型，且需要随着威胁环境的变化重新训练。我们采用相反的方法，在推理阶段通过预计算的静态证据注入专业知识，这些证据在模型推理前已嵌入到提示中。

实验设计

目标

我们评估LLM是否能够检测到其他方面看似干净的软件包中预编译二进制文件中隐藏的恶意逻辑。第二个问题是检测失败是否具有系统性而非随机性。第三个问题是，编码二进制问题的领域知识是否能提高检测准确性。

对抗性有效载荷

我们构建了五种原生 Node.js 插件（.node 文件）的有效载荷类型（表 1），涵盖常见的供应链攻击模式。导入功能从可防御的（fopen、connect、gethostname）到极少合法的（带有 dup2 的 execve）不等，每个包都使用专业的 package.json、README、JavaScript 绑定和 binding.gyp 将二进制文件封装成完整模块。

sysmon 窃取器实现了从可读基线到剥离符号并使用 XOR 编码字符串的加固构建的混淆梯度，而其他四种类型仅出现在单一混淆层级。我们刻意选择单字节 XOR，因为与 RC4 等更强加密算法不同，它在反汇编时不会为模型留下结构性标记。

该集合镜像了真实恶意软件的特征。在 OSV 确认的携带二进制文件的 npm 包中，文件格式包括 PE、ELF（全部剥离）和 Mach-O，行为涵盖凭证和环境窃取、持久化、数据外泄和 C2 通信、主机侦察以及载荷投放。

表 1. 攻击性有效载荷类型及其导入特征。

| 包名 | 类型 | 关键导入 | 模糊性 | |--------------|--------------|-----------------------------------|--------| | sysmon-native | 凭证窃取器 | fopen, connect, send, gethostname | 高 | | buildchain-native | 载荷/后门 | execve, connect, chmod, socket, fwrite | 低 | | netpulse-native | 反向 shell | execve, dup2, connect, socket | 中 | | hashworker-native | 加密矿池桩 | pthread_create, connect, send, recv | 中 | | taskd-native | 持久化 | system, fopen, fwrite, chmod | 中 |

测试模型

我们评估了七家供应商提供的九个模型（表 2）：七个预算模型代表团队在代码库中实际可能运行的模型，其中四个为开源权重模型，另外两个为更高能力的基线模型作为高价点的行为参考。我们还仅将最昂贵的 Claude Opus 4.6 作为成本参考进行测试。

表 2. 测试模型及其角色。

| 模型 | 供应商 | 角色 | |-----------------------|--------------|----------------| | Claude Haiku 4.5 | Anthropic | 预算模型 | | Proprietary | Google | | | Gemini 3.5 Flash | Google | | | Gemma 3 12B | Open-weight | | | GPT-5.4-nano | OpenAI | | | Qwen3-Next 80B | Alibaba | | | GLM 5.3 Flash | Zhipu | | | Llama 3.1 8B | Meta | | | Claude Sonnet 4.6 | Baseline behavior | 基线行为 | | Kimi K3 | Moonshot | | | Claude Opus 4.6 | Cost baseline | 成本基线 |

为隔离特征影响，每个有效载荷对每个模型进行两次扫描：一次不带特征，一次带特征。两次运行的提示、上下文和二进制分析完全一致。所有模型在两种条件下的推理设置保持恒定：温度 0，系统和分析提示全程一致，输出限制为 8192 个 token。

能力特征架构

能力特征是一种声明式操作手册，它将恶意技术（如凭证窃取或持久化）编码为一组加权条件，基于扫描器的静态证据进行判断。这些特征覆盖 npm 和 PyPI 上的源码和二进制技术。

图 1 展示了特征如何进入扫描流程：

• 静态阶段从包中提取证据
• 每个特征根据其可疑、恶意和关键阈值对证据进行评分，该评分体系独立于模型自身的判断
• 当达到阈值时，引擎会在模型推理前向提示中注入结构化摘要（约 1800 个 token），同时包含静态分析和元数据分析阶段的发现
• 模型基于综合证据形成自身判断，在本实验中可能完全覆盖特征触发结果

图 1. 带能力特征的扫描流程图

结果

每个模型都针对所有十个有效载荷进行了扫描。我们将HIGHLY_SUSPICIOUS或MALICIOUS判定为检测成功；在已知恶意载荷上判定为SUSPICIOUS或BENIGN则视为失败。失败分析聚焦于七模型预算层级（70个模型-载荷测试），两个基线（20次测试）仅作为参考上限并单独报告。

未启用能力配置文件

未启用配置文件时，预算层级在70次测试中失败35次（50%），其中20次为明确良性，有51次（73%）未能达到恶意判定阈值。两个行为基线在升级阈值上均未失败，仅在恶意判定上出现一次失败（Sonnet，sysmon v3）。预算层级内的失败呈现出明显的、可重复的模型特异性模式（表3），而非随机错误；Gemini单独在检测能力上与基线一致，尽管是通过虚构推理而非真实分析实现的。完整判定结果和置信度矩阵见附录（表A1）。

启用能力配置文件

启用配置文件后，35次无配置文件检测失败案例中有32次（91%）恢复为有效检测，且没有任何模型对任何载荷返回良性判定。所有未启用配置文件时失败的模型在启用后均实现完全检测，除GPT-5.4-nano外，其在三个载荷上仍存在三个残留失败案例（判定为可疑）。在可负担层级中，升级阈值的失败率从50%降至4%（70次测试中3次），恶意判定阈值的失败率从73%降至34%。

表3. 各模型检测率（在已知恶意载荷上判定为高度可疑或更高等级），未启用与启用能力配置文件时的对比。

未启用配置文件

启用配置文件

0/10

7/10

1/10

10/10

4/10

5/10

6/10

9/10

Gemini 3.5 Flash

最典型的单一案例是Qwen3-Next对混淆的sysmon-native窃取程序：在未启用配置文件时，输入完全相同的字节流，经过四次配置文件触发后，判定为良性（置信度0.98）并建议加入白名单；启用配置文件后判定为恶意（置信度0.98）并建议阻止。基线模型Sonnet和Kimi在未启用配置文件时已正确判定，证据进一步强化了其结论，因此配置文件在此类已具备正确推理能力的模型上起到强化而非扭曲的作用。

配置文件触发机制

技术特异性配置文件根据每个载荷的攻击模式触发。

表4. 在关键或恶意阈值下，每个载荷触发的能力配置文件。

关键配置文件触发

T004（二进制伪装），T001（凭证窃取），T002（网络外泄），T003（环境侦察）

T004（二进制伪装），T007（部署器/阶段器），T002（网络外泄），T001（凭证窃取）

T004（二进制伪装），T006（反向Shell）

T004（二进制伪装），T002（网络外泄）

T004（二进制伪装）

讨论

失败模式分析

实验揭示了四种失败模式，每种模式都覆盖了面板中大量模型而非单一模型（表5）。这些模式并非互斥，因为一个良性判定可能同时是拒绝和合理化，因此表格报告了每种模式的普遍性，单个模型的行总和可能超过十。我们从判定层级读取拒绝和回避，从书面推理中读取合理化和虚构。

导致这些现象的两个因素是：第一是领域知识，预算型LLM缺乏在包上下文中解释二进制结构证据的能力[13]；第二是原始能力。阅读剥离后的字符串混淆二进制需要反汇编和解码，而预算层级并未尝试进行这些操作。

表5. 无配置文件的十种负载下，九种模型（共90次扫描）的每种模型失败模式统计。

合理化

驳回

回避

虚构

Haiku 4.5

4

–

Sonnet 4.6

5

1

2

10

8

6

9

模型（共9种）

占比

~37%

22%

16%

~23%

采用多数表决的集成方案无法解决这个问题。在混淆的sysmon原生窃取器（版本2）案例中，九个判断结果出现三份良性（Gemma、Qwen、Llama）、两份可疑（Haiku、GPT-5.4-nano）、一份高度可疑（GLM）、三份恶意（Gemini、Kimi、Sonnet）的分裂局面。多数意见低于检测阈值，导致投票返回错误结论。这些模式不会相互抵消，反而会叠加，因此任何投票方案在未先弥补领域知识差距前都无法提供可靠覆盖。这与已知的LLM集成中多数投票的局限性一致，其中相关错误会收敛到错误答案而非相互抵消[14, 15]。

合理化（约37%的扫描，六种模型）会调用上下文线索、安装脚本、原生模块打包方式或包描述信息，构建出覆盖二进制信号的良性解释。Haiku将未混淆的sysmon v1判断为恶意（置信度0.98），但一旦字符串采用XOR编码，其判断降至可疑，将node-gyp-build视为标准组件，将.node扩展名视为合法插件，与记录的后期合理化行为一致[16]。因此混淆反而颠倒了预期关系：负载隐藏得越彻底，分配的严重程度反而越低，且由于理由保持内部一致性，对未混淆样本的评估永远无法触发这种判断。

驳回（22%，四种模型）完全不分析二进制文件就直接返回良性判断。Qwen3-Next在十种负载中的九种返回良性（置信度0.98），并建议对包括netpulse反向Shell和taskd持久化工具在内的所有负载进行白名单添加，其声明意图完全忽略了二进制文件的导入项。该判断对导入项歧义完全不敏感，且统一的高置信度掩盖了失败事实，使任何下游阈值检测无法发现问题。

回避（16%，四种模型）仅标记可疑但从未升级为明确判断。GPT-5.4-nano在十种负载中的八种以0.55-0.62置信度返回可疑判断，从未达到高度可疑或恶意级别，其中buildchain原生组件仅获得0.62置信度的可疑判断，并建议采取"监控"行动。可疑判断看起来像是正常分析，但除了YARA和Semgrep阶段外未增加任何新内容，在仅阻止恶意阈值的策略下这些负载得以通过。

虚构（约23%，六种模型）是特殊案例，判断结果正确但理由被编造，因此记录该判断用于审计的流水线会积累误导后续分析人员或任何基于这些数据微调的模型的虚假指标。该现象甚至出现在两个基线模型中，因此无论能力层级如何都会重复出现。Gemini是最明显案例：它对所有十种负载都返回恶意判断，但编造了细节，在taskd中报告"地址0x401490处的解密例程"，在netpulse中报告"地址0x4013b0处的自定义XOR解密循环"，尽管这两个地址都不存在于扫描输入中，且两种负载都不包含加密算法。虚构内容集中在证据最薄弱的单函数x86负载中，这些负载的扫描仅暴露一个真实地址。

结构性差距

漏检是结构性问题，而非单个模型的缺陷。预算级模型在升级阈值以下的失败案例主要表现为合理化和忽视，其中二进制文件与干净的源代码、node-gyp-build安装脚本、专业的元数据以及合理的README并存，这些对于原生模块来说都属于常规特征。没有任何单一证据误导模型。35次失败案例中，每次至少依赖两个良性信号，其中24次同时依赖四个信号，14次将二进制文件自身的导入重新解释为标准系统调用（表6）。大语言模型可以独立分析二进制证据[17, 18]，但在此场景中失败是情境相关的。

表6. 35次检测失败案例中引用的良性情境信号

引用的良性信号 | 次数 ---|--- 调用标准的install脚本(node-gyp-build) | 35/35 原生插件/.node打包 | 32/35 元数据/声明目的"一致" | 32/35 干净的lib/index.js JavaScript | 21/35 将二进制自身导入重新解释为"标准/正常" | 14/35

失败模式的可预测性

这些模式具有可预测性，每个模型都会表现出某种失败模式，但没有任何模型在整个输出中表现出确定性，因此防御者无法简单选择更优模型。两类模型甚至以不同方式失败，忽视行为几乎完全表现为开源权重模型特征（Gemma、Qwen和Llama的20个无配置良性判断中18个属于此类），而专有模型很少忽视，更多表现为合理化、犹豫或编造。这影响模型选择。少量未混淆或低歧义包的测试集会让预算模型看起来足够可靠，却隐藏其对混淆凭证窃取器的失败，而混淆技术在真实恶意软件中反复出现，Binary String Obfuscation配置在425个OSV确认的二进制包中触发了74个（17%）。仅测试高歧义负载则产生相反效果，会误判可用模型并迫使团队过度投入前沿模型。正确判断也不必然意味着正确标签，因为预算模型常错误标记恶意性却分配错误分类，因此分类和声明证据仅是分诊提示，而非归因的绝对真相。

成本影响

基准模型Sonnet 4.6和Kimi K3在无配置时检测所有负载，成本约为预算级的3倍，但配备配置后其检测精度与预算级相当且价格更低。配置还会改变每个模型的token处理量（表7），方向取决于模型在无辅助时的工作强度。预算级从约1800-token证据块中获取适度输入溢价，输入量增加9-34%，分析过程基本不变，而全面模型则呈现相反趋势。无配置时Opus每扫描请求额外文件约收集10.5K输入token，配备配置后降至7.2K（-32%），Kimi因相同原因输出token减少13%。配置为廉价模型增加小幅可控输入成本，却从昂贵模型中大幅削减成本。

表7. 每模型每扫描token使用量（10个负载平均值），无配置和有配置情况对比

输入（无配置） | 输入（有配置） | 输入变化 | 输出（无配置） | 输出（有配置） | 输出变化 ---|---|---|---|---|--- 5,381 | 7,213 | +34% | 933 | 1,616 | +73% 7,000 | 7,614 | +9% | 493 | 488 | -1% 5,866 | 7,623 | +30% | 420 | 506 | +21% 4,900 | 6,428 | +31% | 568 | 729 | +28% 5,691 | 7,267 | +30% | 772 | 1,110 | +48% 5,531 | 6,606 | +19% | 746 | 1,110 | +49% 4,884 | 6,402 | +30% | 351 | 351 | +16% 5,382 | 7,214 | +34% | 1,472 | 8,706 | +8% 5,572 | 4,842 | -13% | 4,842 | 4,842 | -13%

Opus 4.6

10,551

−32%

1,254

1,370

生产环境验证

恶意集合

公开的OSV公告[9]（排除已撤回条目）确认存在470个恶意npm包版本包含原生二进制文件，总计604个二进制文件。按格式划分，它们包括PE（273个）、ELF（215个，全部为剥离版本）和Mach-O（113个），其中3个无法识别；按编译器划分，363个为原生C/C++，183个为Go，58个为Rust。这241个Go或Rust二进制文件（占总数的40%）正是引擎运行时感知机制设计针对的场景，其中50个ELF文件经过UPX压缩。在这些470个恶意包中，425个属于我们扫描的非撤回版本，构成了检测评估集。

良性集合

良性集合仅基于外部信号定义，不依赖引擎自身的判断结果。当包包含原生二进制文件、月下载量超过100万且从未出现在OSV中时，该包会被纳入集合，总计287个不同包包含2,449个包版本。扫描器将其中104个升级为高度可疑或以上级别，误报率为包版本的4.25%，集中在287个包中的6个（占2%）。所有104个包的静态分析规则均触发告警，其中33个包的二进制能力分析达到恶意或关键阈值，表明升级确实反映了二进制文件、打包方式、高熵值段和可疑导入等真实信号。剩余误报率是静态二进制模糊性的固有属性。

检测

评估集包含恶意集合中425个带有生产环境判断结果的二进制包版本（即我们判断结果库中非撤回子集）。针对这些包和良性集合，扫描器在升级阈值下的检测精确率为0.77，召回率为0.81，F1值为0.79（见表8）。召回率的计算基于OSV的包级标签，该标签无法隔离恶意组件，而二进制能力分析推动了74%的检测，其余检测基于JavaScript、元数据或源代码信号触发升级。

表8. 在升级阈值下，针对OSV确认的二进制恶意软件和良性验证集的检测性能。

TP

FN

FP

TN

精确率

召回率

F1

345

80

104

2345

0.77

0.81

0.79

扫描器成功识别出425个阳性中的345个；60个被标记为可疑，20个被判定为良性，硬遗漏率为4.7%。检查这20个被清除包的元数据（无需打开二进制文件），约有一半包含未修改的可识别第三方工具（ripgrep、node-pty、NSIS安装程序插件），OSV将恶意属性归因于安装程序或JavaScript层；其余包包含自身编译的CLI工具，被标记为账户劫持活动或可信度较低的公告。因此二进制层面的遗漏率低于整体数据，但我们并不声称每个被清除的二进制文件都是良性的。

局限性

生产数据是根据OSV的包级标签进行衡量的，这些标签将整个包标记为恶意，而不会隔离负责的组件；一些被清除的包被错误标记，其有效载荷是JavaScript或元数据而非二进制文件。因此，报告的召回率和误报率描述的是针对这些标签的性能，而非针对二进制检测的性能，后者可能略高或略低。托管模型背后是持续更新的端点，因此绝对判断结果反映的是某一服务周期的状态，可能会随时间漂移，这就是为什么我们的结论基于同一周期内无配置文件和有配置文件条件下字节完全相同输入的差异，而非任何单一判断结果。

结论

四种失败模式（合理化、拒绝、回避和虚构）在测试面板中反复出现，在升级阈值下导致50%的预算级测试出现检测失败，在更严格的恶意标准下达到73%。能力配置文件通过在模型推理前注入预计算的二进制领域知识，将升级阈值下的失败率降低至4%，并消除所有良性判断，同时将良性集合中的误报率控制在包版本的4.25%（104个/2,449个；占独立包的2%），这一比例足够分析师手动清除。这些方法使一个成本低廉得多的模型能够达到与更昂贵模型相当的检测精度。

附录

表A1. 无能力配置文件的判断结果（判断结果和置信度），按模型和有效载荷分类。这是表3和“无能力配置文件结果”部分中总结的完整矩阵。

buildchain

hashworker

netpulse

taskd

sysmon v1

sysmon v2

sysmon v3

sysmon v4

sysmon v5

sysmon v6

HIGHLY_SUSP 0.85

MAL 0.92

MAL 0.98

SUSP 0.72

SUSP 0.65

HIGHLY_SUSP 0.78

MAL 0.99

MAL 0.95

BENIGN 0.95

SUSP 0.62

SUSP 0.55

BENIGN 0.78

BENIGN 0.98

HIGHLY_SUSP 0.70

HIGHLY_SUSP 0.80

MAL 0.90

SUSP 0.60

MAL 0.85

SUSP 0.80

SUSP 0.70

MAL 0.93

MAL 0.97

HIGHLY_SUSP 0.82

参考文献

[1] Sonatype. “2026软件供应链状态报告”. 2026. https://www.sonatype.com/state-of-the-software-supply-chain/introduction

[2] SourceCodeRed. “印尼食物垃圾邮件活动发布超过86,000个恶意NPM包”. 2025. https://sourcecodered.com/indonesianfoods-npm-worm/

[3] Kieran Miyamoto. “DPRK npm包”. https://dprk-research.kmsec.uk/

[4] Amazon. “亚马逊识别出朝鲜黑客组织背后的开源供应链攻击”. 2026. https://aws.amazon.com/blogs/security/amazon-identifies-north-korean-hacker-group-behind-open-source-supply-chain-attacks/

[5] OpenSourceMalware. “PolinRider：DPRK威胁行为者在数百个GitHub仓库中植入恶意软件”. 2026. https://github.com/OpenSourceMalware/PolinRider

[6] Zscaler. “追踪Shai-Hulud：ChainDrop NPM蠕虫内部分析”. 2026. https://www.zscaler.com/blogs/security-research/tracking-shai-hulud-inside-chaindrop-npm-worm

[7] CISA. “影响npm生态系统的广泛供应链妥协”. 2025. https://www.cisa.gov/news-events/alerts/2025/09/23/widespread-supply-chain-compromise-impacting-npm-ecosystem

[8] Unit42. “npm威胁格局：攻击面和缓解措施”. 2026. https://unit42.paloaltonetworks.com/monitoring-npm-supply-chain-attacks/

[9] OSSF. “OpenSSF恶意包”. https://github.com/ossf/malicious-packages

[10] VirusTotal. “什么是YARA？”. 2026. https://docs.virustotal.com/docs/what-is-yara

[11] Semgrep. “Semgrep: lightweight static analysis for many languages”. https://semgrep.dev

[12] Levi, M. 等. “CyberPal.AI: Empowering LLMs with Expert-Driven Cybersecurity Instructions”. 2024. https://arxiv.org/pdf/2408.09304v1

[13] Ullah, S. 等. “LLMs Cannot Reliably Identify and Reason About Security Vulnerabilities (Yet?): A Comprehensive Evaluation, Framework, and Benchmarks”. 2024. https://arxiv.org/abs/2312.12575

[14] Traad, F.; Chehab, A. “To Ensemble or Not: Assessing Majority Voting Strategies for Phishing Detection with Large Language Models”. 2024. https://arxiv.org/abs/2412.00166

[15] Li, Q. 等. “Beyond Majority Voting: LLM Aggregation by Leveraging Higher-Order Information”. 2025. https://arxiv.org/abs/2510.01499

[16] Sharma, M. 等. “Towards Understanding Sycophancy in Language Models”. 2023. https://arxiv.org/abs/2310.13548

[17] Patsakis, C. 等. “Assessing LLMs in Malicious Code Deobfuscation of Real-world Malware Campaigns”. 2024. https://doi.org/10.1016/j.eswa.2024.124912

[18] Jelodar, H. 等. “Large Language Model (LLM) for Software Security: Code Analysis, Malware Analysis, Reverse Engineering”. 2025. https://arxiv.org/abs/2504.07137

订阅博客，获取最新文章

订阅我们的博客，最新文章将直接发送到您的邮箱。

立即订阅

查看所有博客

slice-start id="_gatsby-scripts-1"

slice-end id="_gatsby-scripts-1"