这篇论文是USENIX Security 24’收录的论文，作者是四川大学的Cheng等人。其利用行为序列来检测检测恶意的NPM包。
¶1 方法介绍
总体来看，作者在这里将DONAPI分为了6个部分。分别为软件包重建器（依赖重建），恶意shell命令检测器，混淆代码检测器，静态检测工具，动态检测工具和最终的多因素分类器。其中，恶意shell命令检测器与除了最终多因素分类器以外，基本上和其他的部分没有什么关系，在这里将这个模块单独命名为shell分析部分。而1、3、4、5号模块，则是检查javascript代码是否具备恶意行为的核心，在这里我单独称这些模块为javascript分析部分。
javascript分析部分首先会将包里面所有的javascript文件及其依赖整理起来，合成成为一个大的js文件。因为不太方便跨文件的提取AST，所以作者将软件包中所有的代码整合到一个文件中（模块1：软件包重建）。
然后，作者会利用混淆代码检测检查这个文件中是否具备任何混淆部分。混淆是恶意软件用来逃脱检测的一项常用手段，这项技术会使基于AST的静态分析方法失效。因此需要将有混淆的部分单独分开来，所有使用了混淆代码的软件包将会交给动态检测工具处理。对于未混淆的部分，则进行静态检测这一相对成熟的技术。对于提取出恶意行为，经过随机森林测试发现有问题的软件包，也交给动态检测工具进行进一步检查核实。
Shell分析部分则是相当简单的，作者使用了几条YARA规则进行匹配，若匹配到则记录恶意行为。此外，在这个部分还会检查shell中的url信息来进一步帮助确定行为。url信息的检查是通过匹配是否为热门URL网址之类的一些设计的特征，以及机器学习算法随机森林获得的。至于为什么用随机森林而不用其他的作者在实验部分给了实验进行研究。
对于多层次分类器，其中behavior层的信息是在第2、第4、第5步的分析中提取出来的。这个部分主要是用来对恶意软件进行分类。
¶1.1 软件包重建
为了排除跨文件的恶意软件代码执行（这也是攻击者常用的隐藏手段）。首先，作者通过正则等手段提取entry file,也就是在安装过程中和import过程中会执行的文件。主要是基于package.json中的执行命令区域中的设置提取的。
然后，作者生成AST树并遍历 。如果遍历过程种遇到了require和import语句，就寻找require和import的文件，提取AST树然后嫁接到原先的AST树。当然，对于exports/export语句，作者也会做记录。详见作者论文中的算法。
最后，生成完整个包的AST树之后，作者将AST变回js代码，留作后续操作。
¶1.2 混淆代码检测
作者设计了25种混淆特征对混淆包进行检测，并且使用了随机森林算法（RF）对这些特征进行学习分类，来确定是否为混淆包。混淆包将会绕过静态分析，直接交给动态分析的部分进行检查。具体的选择的特征可以看到作者的额外说明。
¶1.3 静态分析检测
可以说，这个部分就是点题之处：Behavior Sequence正是在这个部分被提取出来的。作者在这个部分关注了四种类型的API：网络连接API、文件系统API、进程API和动态代码执行（eval）API。作者声称主要使用AST来提取API序列，若AST不可用则是用regex处理。然后，作者基于这些API序列，设置了规则，将这些API序列匹配为12种行为特征（behavior feature）。
（疑问：作者已经在1.1部分就已经构建好AST了，这里为什么还要按再构建一次，为什么还有构建失败的问题）
由于静态分析可能比较慢，作者在4.4.1小节做了实验，最终确定静态分析的超时时间为300秒，其可以覆盖97%的包。
但是，作者并没有在论文中指出这12种行为特征是基于什么规则匹配的（是针对API有无还是针对API序列，按照文中对BF1的描述应该是针对API序列）。只对了BF1将敏感数据传输出去这一特征进行了解说。
注意到在overview部分作者使用了随机森林进行良性/恶性包的分类，但是在详细的部分中并没有对随机森林分类这个地方进行详细说明。
¶1.4 动态分析检测
动态分析部分是整个模块最为耗时的部分，作者监测了132个API，并在后文的分析中称这些API覆盖了所有的恶意行为的调用API。动态分析主要分析两个部分：安装过程和import过程。在这两个过程中90%的恶意包将会发作。
关于动态分析的超时设置（也就是说作者最多等恶意软件包多久发作），作者在4.4.1小节做了详尽的实验。抽取了15000个包进行动态分析检测，最终发现设置600秒超时时间可以使89%的包在超时时间内跑完安装/import过程。
至于这132个API是什么，以及API序列抽象提取为行为的详细内容还是在作者的额外说明里头。
此外，作者使用docker作为容器进行动态分析，实际上docker的安全性并不高，作者的行为是存在一定安全风险的。
¶1.5 多层次分类器
这也是本篇论文的创新点之一，这个有点类似于APT攻击检测中HOLMES（HOLMES: Real-Time APT Detection through Correlation of Suspicious Information Flows）所做的，将原子级的API调用和API序列抽象成多种恶意攻击行为，来对恶意软件包进行分类。 具体的分类可以看到作者提供的网站，还有这个额外说明的网站。
不过这个网站只是给出了行为对应的敏感API，似乎并没有给出API序列对应的行为。此外，网站也给出了部分作者检测出的恶意软件包。
总体来说，作者在这个步骤将恶意软件分为5类，分别为敏感信息窃取（M1），敏感文件操作（M2），恶意软件导入（M3），反向shell（M4），可疑代码执行（M5）。并且提炼出了40种可疑行为，其检测226种API。
实际上，个人不太搞懂的是，作者在这里设置的40种行为与5类的恶意软件的映射，是基于API序列的还是仅仅基于是否存在API/是否存在40种行为中的某些行为？
¶2 实验
作者在实验部分提出了3个RQ：
- RQ1 Accuracy：各个模块的有效性和精确度；
- RQ2 Efficiency：各个模块最佳的超时时间和整体工具的效率；
- RQ3 Validity：整个工具的工作效果，以及与对比工具的比较。
¶2.1 数据集的使用
作者在实验中使用了如下恶意软件数据集，并且自己收集了约600多个恶意软件包。去重之后共1159个。对于良性数据集，作者常使用npm最流行的500个软件包作为良性数据集。
- Redlili (已失效) 1,214个
- Backstabber 1,504个
- ReversingLabs （较难收集） 39个
- Maloss 332个
- Cuteboi （已失效） 500个
- Synk-blog（较难收集） 32个
- Lofygang （有一些typo-squatting的包）10个
- Sonatype-blog （较难收集）315个
¶2.2 有效性实验设置
作者在RQ1中设置了如下的实验，主要是对于各个模块的单独测试：
- （软件包重建器）重建失败的比例
- 混淆包的召回率和精确率
- Shell命令分析中URL检测器的检测效果
- 多层次分类器对于5种类型的恶意软件包的分类recall情况
作者也分析了在部分情况下DONAPI表现不佳的原因（4.3.2小节）。
随后，在RQ3中，作者对于整个工具进行了对比实验，对比工具收集了GUARDDOG（https://github.com/DataDog/guarddog）、AMALFI(Sejfia et al. Practical automated detection of malicious npm packages）和SAP（Ladisa et al. On the feasibility of cross-language detection of malicious packages in npm and pypi）。并使用了1159个恶意软件包（本文2.1小节提及的）和npm top5000的软件包（良性数据集）进行了实验。结果表明DONAPI表现效果最佳。
作者也分析了在5类恶意软件包中各个软件的召回率情况，以及误报情况。
¶2.3 性能实验设置
性能实验中，作者首先是计算了各个模块适宜的超时时间（已经在上文中提及了）。此外，作者计算了处理15479个包(约1.6亿行，重建后约2千万行）的检测时间（约22小时，2150行/s，重建后约256行/s）。不过基于npm社区包的增加情况，作者认为他们的攻击能够及时的检测每天新产生的软件包（约1.6万个）。
不过值得注意的是，这1.6万个每天的产生包需要DONAPI花费22个小时完成，还是比较紧张的。
此外，可以看到，进入动态检测的软件包的比例高达30%以上（基于收集的3天的package），也就是说静态分析部分效果应该还是可以进一步提升的。不应该放那么多的包进比较慢的动态检测部分。
¶3 讨论和related work
作者在讨论部分提到了几个比较有趣的事情：
- 恶意代码的reuse情况也是相当明显的，存在部分的payload reuse。
- 恶意代码特别喜欢通过将payload分布在多个包中来规避检查。
在related work中，主要列举的related work涵盖了机器学习、权限管理系统（不太清楚为什么要把这个列为related work）、和依赖分析系统。