本文作者为“SecureNexusLab供应链安全”战队，将从赛题介绍、总体思路、赛题详解等方面进行报告。篇幅较长，建议点赞收藏！

本赛道由两大挑战组成，分别是npm恶意软件包识别与PyPI恶意软件包识别。

随着软件供应链复杂性的增加，开源软件包的使用已经成为现代软件开发中的一个重要组成部分。然而，开源软件包的引入也带来了新的安全挑战，特别是攻击者向开源软件源中投放恶意软件包，危害开发者及其使用的系统。近年来，攻击者利用这种方式进行供应链攻击的案例显著增加，因此对恶意软件包的检测已经成为了一个热门的研究课题。

本赛道旨在要求选手从提供的数据集中精准检测出包含恶意行为的软件包。恶意行为可能包括但不限于恶意代码注入、后门程序、信息窃取等。选手可以运用各种检测技术（包括但不限于静态分析、动态分析、行为分析等），开发出高效、准确的算法或模型来检测恶意软件包。赛道基于真实世界的最新数据，精心设计了两个针对不同生态系统的数据集，选手需要分别应对不同的挑战：

挑战一：npm恶意软件包识别

参赛人员需要在所提供的50000个npm软件包中尽可能准确地识别出其中所包含的500个恶意软件包，并按照要求提供最终检测结果。

挑战二：PyPI恶意软件包识别

参赛人员需要在在所提供的50000个PyPI软件包中尽可能准确地识别出其中所包含的500个恶意软件包，并按照要求提供最终检测结果。

本章将介绍本战队的在检测恶意软件包时的技术路线和所采用的技术，并详细介绍各个步骤的工作原理。

2.1 概述

我们需要从大规模数据集中尽可能全面且准确地挖掘未知类型的漏洞。有别于代码漏洞，恶意行为是攻击者有意为之的行为，这意味着判断行为是否恶意需要人工主观地确定，但是人工审计成本十分高昂。同时任何检测工具都存在漏报与误报，导致检测恶意行为难以完全脱离人工审计。

因此面对情况未知的数据集时，首先需要的就是在保证尽可能少漏报的情况下进行粗粒度筛选，迅速缩小恶意样本范围。其次，应设计自动化检测工具辅以人工审计来减少误报。

综上，检测流程主要分为两个阶段：初筛阶段和优化阶段。

在第一个阶段的关键挑战在于冷启动问题，即，在没有针对性的恶意知识的情况下如何检测恶意软件包。目前现有的静态检测工具往往需要配置详尽准确的检测规则才能拥有很好的检测效果，而动态检测工具则普遍在效率和召回率上存在天然的劣势。由于不清楚目标数据集中的恶意软件包的分布信息，我们无法为静态检测工具提供定制化的检测知识，也无法设计有针对性的高效动态检测策略。

为解决上述问题，首先可以先利用不依赖于先验知识的工具进行恶意软件包检测，以便对待测目标数据集有一个整体的感性认识。此外可以利用已有的大规模数据集中的知识对恶意软件包进行匹配。如图2.1所示，我们分别设计了聚类检测工具、恶意包相似性匹配的检测工具，此外也利用了现有的审计工具拓展匹配范围。

在优化阶段，目标是降低漏报和误报，我们需要解析第一阶段的结果来获取恶意行为知识，并且利用这些知识来挖掘新的恶意软件包。为此我们设计了优化阶段。其主要分为两个组件：基于大语言模型的检测组件和基于规则匹配的检测组件。其中基于大语言模型（Large Language Model，LLM）的审计组件主要用于进行对软件包的恶意软件包评分和恶意行为定位。而基于规则匹配的检测组件则利用LLM定位的规则精确检测恶意样本。当发现新的恶意软件包时，这些软件包会被输入LLM继续进行迭代分析，从而发现更多的恶意样本。

图 2.1 整体工作流程

2.2 思路详述

2.2.1 初筛阶段

由于缺乏知识而导致在检测未知的软件包数据集时不能获取很好的效果是软件供应链安全领域的焦点问题。许多现有静态检测工具都受此困扰因而无法得到较好的检测效果。我们将采用基于代码聚类的检测方法、恶意包相似性检测和代码审计开源工具来解决这个难题。下文中我们将分别对其进行详细的介绍。

2.2.1.1 聚类检测工具

恶意软件检测工具常常需要在对大量专家知识的需求与对大量计算资源的需求中进行取舍。为了打破这个困境，我们利用并拓展了我们发表在软件工程领域顶会ASE 2023的工作[1]，一种基于代码聚类分析的不依赖于显式先验知识的轻量级投毒检测方法。该方法利用恶意软件在功能上异于良性软件且相对数量稀少的特点，通过寻找软件包聚类中离群点来发现恶意软件包。

在分析了一些已知恶意样本后，我们发现有两个可利用的事实。首先，恶意软件包远比正常软件包稀少，发现恶意软件包犹如大海捞针。尽管仓库中出现了许多恶意软件包，但绝大多数软件包仍然是良性的。其次，在安装过程中，恶意软件包所执行的操作与良性软件包所执行的操作在功能上有显著不同，后者经常形成集群。良性软件包在安装时的活动往往相似是因为良性软件包在安装阶段通常专注于配置和管理软件包的构建、发布和安装。然而，恶意软件包在安装时执行的危险操作对于正常软件包是不希望出现的，且很少出现在其中，如访问敏感信息和安装后门。

基于上述观察，我们扩展实现了发表在ASE 2023上的MPHunter（Malicious Packages Hunter）工具，用于检测npm和PyPI中的安装时恶意软件包。其核心思想在于将离群程度最高的安装时脚本识别为潜在恶意安装脚本来检测恶意软件包。MPHunter首先采用聚类技术对软件包的安装时脚本和安装时命令行进行分组并识别异常点，即与大多数（良性）样本不同的样本。随后，根据它们的偏离程度以及与已知恶意样本的距离对异常点进行排序。潜在的安装脚本和安装时命令行被突出显示以供进一步审核，从而识别恶意软件包。

图2.2 MPHunter流程图

如图2.2所示，MPHunter通过以下三个步骤检测恶意包。

首先，从目标包的安装脚本中提取标准化的Token序列，这确保了从具有同构语义的脚本获得的标记序列尽可能一致。然后使用一个序列嵌入模型对序列进行编码，将新上传的软件包和预先收集的良性软件包的安装脚本表示为向量（参见图2.2，①）。

其次，使用基于密度的聚类技术对得到的嵌入向量进行聚类，以识别异常点，即恶意安装代码脚本的候选点（参见图2.2，②）。

最后，通过测量候选样本与良性样本以及已知恶意样本之间的距离来对候选样本进行排名（参见图2.2，③）。这使我们能够选择最可能的可疑代码进行审计，以检测新上传的恶意包。远离良性样本但接近已知恶意样本的候选样本将被进一步用于基于大语言模型与规则匹配的检测方法进行分析。

与现有研究不同，MPHunter直接利用现成的良性软件包和已知的恶意样本，避免了提取显式检测知识的繁琐和容易出错的手动分析，很适合应用于对数据集缺乏了解的初筛阶段。

2.2.1.2 相似性匹配工具

在样本分析过程中，我们发现存在可以在GitHub仓库等网络平台上检索到的恶意包，推测赛题数据中存在真实的恶意样本，因此尝试利用已知知识，设计了基于相似性匹配的恶意包检测工具，旨在通过对比已知恶意包与待测包之间的结构和内容相似度，识别潜在的恶意软件包。基本思路如下：

数据收集与预处理：首先收集了大量的已知恶意包样本，由于赛题数据中进行了匿名化处理，因此我们主动地对收集到的恶意数据以及赛题数据进行包名归一化处理。

基于包相似性的过滤：为了找到相似的潜在恶意样本，需要提取包中的某些特征作为比较的参考，因此我们分析赛题数据确定了较为稳定的信息，诸如目录树、配置文件等，作为包特征进行相似性匹配。

最终，所有被标记为高相似性的包都将交付给基于大模型的审计阶段。

2.2.1.3 开源恶意包检测工具

我们选择使用 Guarddog [2]作为代码审查工具，旨在利用其较为全面的规则集配置。Guarddog 是一款强大且灵活的静态代码检测工具，能够自动扫描包括Python和JavaScript在内的多种语言的软件包，识别潜在的问题和缺陷。

2.2.2 优化阶段

此阶段我们的目标是通过自动化手段与人工审查相结合的方式，高效地检测并识别软件包中的潜在恶意代码。本阶段的核心在于利用先进的大语言模型技术，结合传统的基于规则的检测方法，实现对恶意软件的有效筛查与深度分析。

2.2.2.1 基于LLM的检测组件

基于初步筛选的结果，我们把筛选出的结果作为待测包集合，使用通义千问大语言模型[3]的代码审计能力，调用API对待测集合进行恶意检测。

我们在设计prompt时，使用了评分机制，给LLM提供可能存在恶意的代码，让其在1-5分范围内进行打分，其中1分代表无恶意行为，5分代表存在明显的恶意行为。在评分时我们让LLM省略评分外的其他回答，以提升LLM输出审计结果的效率。

在获得LLM对各个待测文件的评分结果后，我们筛选出高分的结果，再次输入给LLM，并且设计了一个新的prompt，让其识别出出代码中的恶意点和恶意类型，为后续的人工筛选提供指导。

2.2.2.2 基于规则的检测组件

我们结合大语言模型的结果，通过简单的人工审计筛选出明确的恶意包，并且参考大语言模型对恶意行为的分析，总结出恶意包具有的共性基本特征，书写匹配规则。同时也利用了恶意包数据集和安全报告来拓展规则。

下一步，我们使用总结出的规则，通过模式匹配的方式，对所有剩余的包进行新一轮的筛选，把新筛选出的包作为新一轮的待测包集合由大模型进行再次判定。

3.1 挑战一：npm恶意软件包检测

3.1.1 赛题分析

赛题简介：

在本次比赛中，赛事方准备了50,000个npm软件包，其中包含了500个恶意软件包，模拟了现实中npm所面对的投毒威胁。参赛选手们需要设计检测方案来尽可能准确且全面地检测出这些恶意软件包。赛事方对包名、版本和作者等元数据信息通过哈希函数进行了匿名化处理，并且针对部分软件包进行了代码混淆处理，进一步提升了检测的难度。

npm基本背景：

作为规模最大的第三方软件仓库，npm正面临着严峻的恶意软件投毒威胁[4][5][6][7]。每天数以万计的JavaScript软件包通过npm进行发布，其中不时夹杂攻击者上传的恶意软件包。如何迅速且准确地从海量软件包中将这些恶意软件包检测出来是所有软件供应链都面临的一个关键挑战。

图3.1 npm软件包文件结构

常见的npm软件包的文件结构如图3.1所示，其通常包括一个package.json文件，其中包含了在文件的元数据和准备执行的脚本。值得注意的是，攻击者为了尽可能地提高攻击代码被成功执行的概率，通常选择在安装时执行恶意代码片段。在安装一个npm软件包时，软件包中package.json文件所包含的安装时Shell脚本会被执行。这些安装时Shell脚本常常会通过node等命令执行其他安装时代码脚本，如，preinstall.js, index.js等。

• npm中的恶意行为：

  无论是安装时Shell脚本还是安装时代码脚本，都有可能被注入恶意代码。被注入的恶意代码主要可以分为：窃取信息、埋下后门、破坏系统、算力窃取、网络病毒、访问恶意网页和恶意蜜罐等[8]。

3.1.2 恶意包检测

依据第三节所介绍的总体思路，我们首先采用了MPHunter和Guarddog先进行了检测，还对比目标软件包和现有恶意软件数据集中的代码特征来检测恶意软件包，随后利用基于LLM的规则挖掘方法来获取新的规则，并使用规则匹配的方法准确定位恶意行为。下面我们将分别介绍各个步骤。

3.1.2.1 初筛阶段

正如在 2.2小节中所介绍的那样，在没有先验知识的情况下我们先使用MPHunter和Guarddog两款工具来进行检测。MPHunter是一种基于代码聚类的恶意软件包检测工具，可以在不依赖先验知识的情况下检测恶意软件包。而Guarddog则提前配置了较为全面的这检测规则，也可以作为基于聚类的方法的补充。

• 聚类检测工具：

  我们从MPHunter检测到的1000个结果中选择了排名前800的包，提交系统通过得分反向计算，得出其中有374个正确恶意软件包的结论。

• 开源检测工具：

  在Guarddog发现的4026个潜在恶意包中最多有315个恶意软件包。尽管存在较高的误报率，但此阶段有效地拓展了我们的规则知识，让我们对数据集的分布有了感性认识。所检测出的候选恶意软件包都将交给基于LLM的方法进行恶意行为定位和恶意程度评估。

• 相似性匹配工具：

  除了使用现有的工具之外，我们还利用npm官方数据集来进行恶意软件包相似性对比。我们提取了所有待测数据集的README和LICENSE文件，并通过大语言模型来总结提取其中的关键特征信息。通过对比这些关键特征信息与npm官方数据集中近期删除的软件包中的对应文件来发现恶意软件。但是结果并不如人所愿，我们没能找到任何恶意软件包，我们推测赛方准备的数据集中的软件包并非近期发现的，因此未能包括在本次数据集中。

3.1.2.2 优化阶段

3.1.2.2.1 基于LLM的检测组件

在解题前期，我们的主要目标是为了尽可能多的减少漏报，同时缩小检测范围，因此将结合了基于代码聚类的检测方法MPHunter以及静态代码检测工具Guarddog的检测结果作为最初的检测目标，得到了5000个左右的文件级路径信息。这些路径信息将作为LLM的输入，由LLM对其中代码进行安全威胁评分。

针对NodeJS代码威胁评分的prompt如下：

"You are a code audit assistant. Next, I will send you some NodeJS code for you to audit. You only need to answer the five numbers 1-5, where 1 indicates no malicious intent and 5 indicates a high probability of malicious intent. Omit other answers."

其输出结果示例如图3.2所示：

图3.2 使用LLM对NodeJS代码进行威胁评分

经过抽样检测，我们认为评分为1和2的结果中包含真实恶意行为的可能性较低。因此，后续只保留了评分3-5的结果。经过统计，前期得到的所有检测目标中共提取评分为5的软件包465个，评分为3和4的软件包共474个。

为了更进一步的提高检测自动化程度，减少人工审计的参与度，针对评分3-5的结果，我们进一步改进prompt，要求其再次审计，并在这次审计过程中给出恶意代码位置。需要注意的是，由于赛题中存在一定数量的混淆代码，加大了LLM的分析难度，因此针对混淆代码，prompt做了单独限定。prompt如下：

"You are a professional malicious code audit expert.I will provide you with the contents of a potentially malicious code file.Please help me determine if the file contains truly malicious code.f you think it is not, simply output 'not vuln' and ignore other outputs. If, after careful analysis, you believe the code is malicious, provide the line of code where the malicious behavior occurs, within 200 characters.Please note that the code may use code obfuscation techniques to evade static code analysis. Please distinguish between full code obfuscation and partial character obfuscation. Full code obfuscation scrambles the entire file, while partial character obfuscation only obfuscates specific parts, such as the content of a URL.I only want you to output 'OBS' when encountering full code obfuscation, ignoring all other outputs. For partial character obfuscation, please make every effort to analyze the code and provide the line of malicious behavior within 200 characters."

我们注意到，在实际使用过程中，LLM并不能很好的区分代码混淆，很容易把代码中部分经过编码的字符判定为代码混淆，从而不能很好的分析并输出恶意代码位置，因此在prompt中做了一定解释。

使用该prompt的结果示例如下：

表3.1 LLM输出结果

字符串拼接是一种防御关键词匹配的方法，使用LLM可以准确识别该类恶意行为。

其中，输出为代码混淆的（OBS）的部分内容如图3.3所示：

图3.3 LLM判断为OBS的代码截图

针对收集到的代码混淆的结果（OBS），我们使用了开源的NodeJS代码反混淆工具js-deobfuscator[9]进行处理，该工具能够快速的生成准确的反混淆结果。处理后的代码会让LLM再进行一次单独审计。

在最后，我们额外选择了另一款LLM产品来审计当前结果，和当前结果做交叉验证。同时，在审计之后，要求LLM给出恶意行为模式，作为当前规则匹配的补充。例如，针对如下图所示的代码：

图3.4 恶意代码示例

LLM总结出的行为模式如下：

1.检测是否使用 os, fs 等模块访问关键系统信息（如 /etc/passwd, /etc/shadow, 环境变量）。

2.对 fs.readFileSync, fs.readFile 调用参数进行匹配，定位常见敏感路径。

3.检查 axios.post, fetch, http.request 等方法的 URL 参数。如果目标地址不是受信任的域名（如企业内部域），标记为可疑。

因此，我们可以将这些结果与已有规则做结合，进一步扩充规则库。

3.1.2.2.2 基于规则的检测组件

在开赛前，我们调研了npm恶意包检测相关论文，在论文Maltracker[10]中作者开源了其使用的恶意数据集，通过搜集该数据集中出现的恶意域名、IP、敏感字符串等信息，我们构建了最初的恶意包检测规则集合。集合示例如表3.2所示。

表 3.2 恶意包检测规则集合示例

随着比赛的持续深入，我们在使用LLM进行辅助审计的过程中会要求LLM如果确认输入目标是恶意代码，那么需要对恶意行为模式进行总结。经过人工确认输出后，这些行为模式会被作为新的检测规则，加入到检测规则集合中。

最后，恶意代码检测规则的第三部分来自星图实验室往期发布的关于NodeJS安全威胁的相关报告中。如图3.5所示，从这些专业的研究报告中我们提取了更多的新规则。

图3.5 星图实验室安全报告截图

在实际的比赛过程中，为了降低误报，提升检测效率，我们使用了严格的字符匹配方法匹配所有检测规则。但实际上，经过与MPHunter等工具以及LLM的结果对比，基于规则匹配方法的检测结果基本上是重复的结果。这也从侧面验证了前文提到方法的有效性。

3.2 挑战二：PyPI恶意软件包检测

3.2.1 赛题分析

PyPI基本背景：

PyPI是一个面向 Python 开发者的中央存储库，提供了大量的第三方软件包，也存在恶意软件包的传播问题。恶意包通常嵌入在正常功能的代码中，并利用标识符混淆、字符串加密和编码计数躲避检测并增加静态分析难度。

PyPI软件包的构成：

如图3.6所示，一个PyPI软件包的文件架构中通常包含有多个关键文件，其中setup.py安装脚本尤其受到攻击者的偏爱，因为软件包在通过pip install命令进行安装的时候便会自动执行该脚本。

图3.6 PyPI软件包文件结构

PyPI恶意行为模式：

根据文献[11]的研究，PyPI上的恶意包表现出多种不同的行为模式。具体统计如下：

- 信息窃取（49.44%） ：通过网络请求将用户数据发送到远程服务器。
- 命令执行（59.33%）：执行系统命令或调用外部程序。
- 代码执行（2.62%）：加载并执行远程下载的代码。
- 远程控制（0.75%） ：通过网络连接控制受害者的系统。
- 未经授权的文件操作（47.19%）：读取、写入或删除用户的文件。

三种主要的攻击向量：

安装时攻击：最常见，在包安装过程中被执行，一般在 setup.py 中实现。
运行时攻击：恶意代码在程序运行过程中被执行，触发点可能在任何py文件。
导入时攻击：在模块导入时被执行，通常在__init__.py文件中。

赛题数据分析：

赛题提供的数据集中，共有 5 万个样本，其中只有大约一半的包包含 setup.py 文件，约10%的包没有py文件。分析发现，数据中的包经过了匿名化处理，同时，无论是良性包还是恶意包，都存在标识符混淆现象，例如函数名和变量名的更改，由于这种混淆不仅限于用户自定义的标识符，甚至可能影响到标准库的 API 函数名，因此传统的动态分析方法在这种情况下可能失效。此外我们还发现了诸如字符串加密、视觉欺骗等混淆手段。

3.2.2 恶意包检测

3.2.2.1 初筛阶段

聚类检测工具

与检测npm软件包时相似，检测PyPI恶意软件包同样冷启动的问题，即，基于规则的恶意软件检测工具难以检测出尚未匹配在规则库中的恶意行为，而且在没有先验知识的情况下难以进行规则扩展。MPHunter因为其不依赖于先验知识的特性，可以解决冷启动问题。

通过运行MPHunter，我们共挖掘出一千余个潜在恶意候选者，其中排名前800的样本其中包含了数百个恶意样本。这些恶意样本共有107种之多，其中包含有多种未被配置在规则库中的恶意行为，很好地拓展了现有的规则库。我们将这些新增的规则配置到了我们自己开发的规则审计工具，并找到了大量的恶意软件包。与此同时，有些恶意行为所包含的混淆行为和恶意导入行为也引发了我们的思考，引导我们设计了更多针对性的检测工具。

开源检测工具

我们同样选用开源工具Guarddog作为初筛工具，在50000个样本上进行全量检测。Guarddog初步检测的结果有2916个，通过分析Guarddog给出的检测报告，我们发现误报率较高的原因是Guarddog设计的恶意判定规则较为宽泛，因此有很多包含系统操作命令（OS Command）、未知URL等的包全部被划分为恶意，因此需要后续进一步的细筛。但是Guarddog确实为我们检测出了一些恶意的包，为我们后续的恶意样本分析提供了基础。

相似性匹配工具

为了构建有效的恶意包检测模型，我们首先需要一个高质量的恶意包数据集。为此，我们获取了由论文[11]收集并公开的 PyPI 恶意包数据集，该数据集包含了 9503 个恶意包的共 10823 个版本。

为了消除包名带来的干扰，我们对所有包名进行了归一化处理：

包名提取：从每个包的 PKG-INFO 文件中使用字符串匹配技术提取包名。
包名替换：将包中所有目录和文件中出现的包名部分全部替换为统一的标识符“xxx”，确保在后续的相似性检测过程中，包名不会成为影响结果的因素。
目录树结构匹配：根据观察，赛题数据中代码包的结构与文件并没有被大量修改，因此我们首先利用包中目录树进行初步的相似性匹配，这种信息不仅考虑了目录的整体结构，还包括文件名和文件数量的差异。
文件相似性计算：为进一步提高匹配精度，我们考虑利用包中文件的内容进行更细的过滤。由于赛题数据中部分进行了混淆处理，无法直接用哈希比较，因此我们采用了编辑距离作为衡量文件内容相似性的标准，只有当待测包中存在高相似性的文件内容时，才能保留作为候选包。给定待比较的两个文件F1和F2，C函数表示获取文件内容，D函数表示计算两个文本间的编辑距离，L函数表示计算文本的长度，相似性具体计算如公式5所示：

相似性阈值判断：我们设定相似性阈值为 0.8，当两个文件的相似性超过这个阈值时，我们认为这两个文件具有高度相似性，可能是恶意软件的变种或经过简单修改的副本，所在的包将被标记为高风险对象，进入下一步的审查流程。

总体流程如下图所示：

图3.7 PyPI恶意包相似性匹配流程

3.2.2.2 优化

3.2.2.2.1 基于LLM的检测组件

在大语言模型LLM的使用上，我们选择了代码理解能力较强，且对长文本有良好支持的通义千问qwen-plus模型，辅助我们完成代码审计工作。

第一步，我们让大语言模型筛选出它认为含有恶意行为可能性高的软件包。

在设计prompt时，我们选择让大语言模型对待测的代码从1-5进行打分，1分表示代码完全安全，而5分代表代码中存在明显的恶意行为。同时如果审计的文件是出现恶意行为分布最为重灾区的setup.py和__init__.py，我们会提供给大模型确切的信息。完整的prompt如下：

“You are a code audit assistant. Next, I will give you a setup.py / __init__.py / python code program to determine if the program is malicious. You only need to answer the five numbers 1-5, where 1 indicates no malicious intent and 5 indicates a high probability of malicious intent. Answer only with a number! Omit other answers.”

输出结果示例如图3.8所示：

图3.8 大语言模型输出示例

我们首先把前边方法筛选出的可能具有恶意行为的包进行大语言模型的评分。评分完成后，我们对分数的分布进行了验证和统计。我们发现所有包中得分4分的数量往往最少，且在人工审阅4分的包时，其包含恶意行为的可能性和5分相当。而得分在1-2分的包中，含有恶意行为的包所占的比率极低，因此，我们选择每次将得分4分和5分的包标记为高风险，以供后续的工作。

第二步，我们将第一步标记为高风险的包进行恶意点的识别，让大语言模型指出该包中所存在的恶意行为的确切位置和恶意类型，prompt设计如下：

“You are a code audit assistant. Next, I will give you a potential malicious setup.py / __init__.py / python code program for you to audit. You only need to identify the specific malicious code points and malicious type in the code. Omit other answers.”

3.2.2.2.2 基于规则的检测组件

通过对赛题提供的数据集以及大语言模型的分析报告进行深入分析，我们发现并总结了以下三种主要的恶意行为模式：

1. 信息泄漏：通过网络请求将用户的敏感信息发送到远程服务器。
2. 下载执行：下载并执行远程服务器上的代码，从而实现更复杂的攻击。
3. 解码执行：包含加密或编码的恶意代码，运行时进行解码并执行。

为了有效地检测这些恶意行为，我们参考了论文[2]中的思想，使用不同API类型的集合对恶意模式进行形式化表示。具体来说，我们对每个恶意行为进行了详细的划分，确定了匹配所需的API类型，并从实际样本和网络资料中丰富拓展了各API类型的具体函数名或关键词。最终，我们获得了如图3.8所示的规则信息。

图3.9 收集总结的部分恶意规则

除了上述最常见的模式，我们还发现了其他类型的攻击。如表3.3所示，这些攻击特征比较明显，可以直接通过提取关键词进行检索：

表3.3 恶意行为模式

此外我们也利用开源工具中已有规则和相关技术报告丰富规则库。

我们根据这些规则信息，编写了相应的模式匹配代码，遍历所有Python文件，寻找符合要求的模式匹配。例如对于信息泄露类型，需同时匹配到信息获取和网络请求相关的api或关键词。

方案流程如图3.10所示。

图3.10 基于多源规则进行拓展匹配流程

最终总结出7个恶意api模式 和 1033个恶意链接，在迭代后最终新确认71个tp，有效减少了漏报。

4.1 TEA滥用

对npm样本进行整体数据分析时，我们注意到其中存在一批垃圾软件包。进一步的采样发现，个别无用垃圾软件包中包含有tea.yaml文件。

此前我们从星图实验室的发文[12]中了解到，NPM软件供应链中出现了一种滥用web3软件供应链激励机制的恶意行为。因此对这些软件包的命名模式、tea受益方、依赖关系等进行了简单分析。

以表4.1-1所示的软件包为例，其依赖都具有@ffras4vnpm/<随机生成拉丁文单词串>的特征，且版本号均为1.0.0，疑似同一作者生成的无意义的软件包。其依赖表如图4.1所示：

图4.1 无意义的依赖包列表

另有如表4.1-2、表4.1-3和表4.1-4所示的软件包等包具有高度相似的依赖。如图4.2所示，命名模式为btcweb3-xuyunpp<\d{2}>。我们推测该系列包通过组成依赖网络社区进行TEA滥用。

图4.2 高度相似的依赖

4.2 存在恶意URL的垃圾软件包

对可追溯到来源的软件包进行分析时，我们发现其中一个已被官方npm源删除的如表4.1-5所示的软件包具有可疑意图。其恶意代码片段如图4.3所示，通过[13]进行的恶意风险评估得分如图4.4所示。

图4.3 恶意代码片段

图4.4 恶意代码风险评估

该软件包名为"bingo-blitz-free-credits-2023-i-how-to-get-free035"，为垃圾包，但README中的信息疑似具有金融诈骗意图。

将其中URL "https://legalcoins.vip/bingoblitz" 于URL库中搜索发现其确为高风险网址。经与出题人沟通得知，该包不在赛题数据所标注的恶意包中。

4.3 攻击对象非软件包安装者的恶意软件包

对可追溯到来源的软件包进行分析时，我们发现其中一个已在官方npm源删除的如表4.1-6所示的软件包具有文件访问、进程执行、大量字符串等基础风险特征。进一步的审查发现，其功能应当为根据词表随机生成软件包名，并发布至npm。其自动发布重复的垃圾软件包 ，并有意逃脱对低级随机字符串的检测，属于对npm registry的恶意行为。经与出题人沟通得知，该包不在赛题所标注的恶意包范围中。

4.4 软件包名附录

表4.1 软件包名录

首先，我们感谢出题人的精心准备和耐心答疑，感谢主办方为我们提供了一个能够深入学习，磨砺自我的机会。在这次比赛中，我们对软件供应链所面临的安全威胁有了更深刻和感性的认识，其中，对于无先验知识情况下的恶意软件检测问题更是引发了我们深入的思考。这一切都离不开赛事方在幕后的辛勤工作，感谢你们为我们带来了一次美好的参赛体验。

除此之外，我们还想特别感谢一下我们的指导老师们。大海航行靠舵手，感谢老师每次开会时的耐心指导，保证我们在向着正确的方向努力。同时也要感谢老师们在赛后对我们的关心和全力支持。

作为组长，我还想以我个人身份感谢一下各位组员，感谢你们陪伴我一同付出，也感谢你们对我的帮助与支持，我从这次比赛中学到了很多。这次比赛锻炼了我们的团队合作能力，让我们充分意识到交流沟通的重要性。在一次次讨论、头脑风暴，甚至是争论中，我们不仅迸发出无数思想的火花，而且使得本就深厚的友谊变得更加牢固。

感谢合作伙伴的助力 让我们走得更高更远