Npm malware package detection method based on behavior analysis and matching of graph model

Abstract

The present application belongs to the technical field of software engineering, and specifically relates to an NPM malicious software package detection method based on behavior analysis and matching of a graph model. The method comprises the following steps: constructing a program suspicious behavior graph by using a static analysis technique; collecting NPM malicious software packages as a data set from multiple information sources; in an offline stage, constructing a program suspicious behavior graph for existing malicious software packages, and obtaining a malicious behavior graph by manual clipping; in a deployment stage, inputting an NPM software package to be detected, first analyzing an installation script contained in a configuration file, and identifying whether malicious behavior exists, then performing obfuscation detection on code files, and for a software package not containing obfuscated code, generating a program suspicious behavior graph in three stages of installation, import and running, and matching the program suspicious behavior graph with a known malicious behavior graph generated in the offline stage to realize detection of malicious behavior. The method can help detect NPM malicious software packages and reduce the harm caused by malicious code.

Description

Technical Field

[0001] The present invention belongs to the technical field of software engineering, and in particular relates to a method for detecting NPM malware packages. Background Art

[0002] Open source software refers to software whose source code is open and allows users to use, modify, and distribute it freely. By reusing existing code, developers do not need to write code from scratch, which significantly reduces the cost of software development, accelerates innovation, and improves the transparency and security of the code. These advantages have led to the widespread adoption of open source software worldwide. According to the Open Source Security and Risk Analysis Report released by Synopsys in 2024 [1], 96% of code bases contain open source software. At the same time, the open source community witnessed 301 million contributions to open source software on GitHub by developers in 2023 [2], which shows that the influence and importance of open source software are growing. However, with the popularity and widespread use of open source software, security issues in the open source software supply chain have become increasingly prominent. As more companies and developers rely on open source components, attackers are increasingly turning their attention to the supply chain and attempting to launch attacks by attacking the open source software supply chain. This trend has exacerbated security risks and posed a major threat to the open source software ecosystem [3][5][6][7]. Ladisa et al. [4] proposed a classification method for open source software supply chain attacks, which provides an important reference for understanding and preventing these threats. Among supply chain security risks, malware package poisoning is a common attack method. These malware packages may disguise themselves as legitimate software, inducing developers or enterprises to inadvertently integrate them into applications, thereby causing security issues. Recently, researchers have discovered that two widely used package management repositories, NPM and PyPI, are flooded with a large number of malware packages [8][9]

[10]

[11]

[12]

[13] , posing a security threat to many downstream applications. According to a Sonatype report [6], more than 245,000 malware packages were discovered in 2023 alone, which is twice the total number of malware packages discovered in all previous years since 2019.

[0003] In the face of this type of software package poisoning attack, automated malware package detection tools are particularly important, especially NPM, which is currently the largest Node.JS package management and distribution center with more than two million software packages. Therefore, it is crucial to effectively detect malware packages. There are many automated malware package detection tools. Duan et al.

[14] used static analysis and dynamic analysis for software packages and combined them with heuristic rules for detection. This rule-based method is simple and efficient, but it is prone to a high false positive rate. Ohm et al.

[15] used an unsupervised learning method to analyze the AST representation of malware packages using the Markov clustering algorithm and generated signatures for each cluster to detect new software packages. Sejfia et al.

[16] proposed a malware package detection tool AMALFI based on supervised learning. By extracting metadata features and source code features of software packages, they trained a classifier to detect new software packages. The learning-based method converts the code into discrete feature representations, which to a certain extent loses the order of behavior when the malicious code is executed. Zhang et al.

[17] constructed a natural language sequence to describe the behavior of malware packages through feature extraction, natural language description, and function call graph generation, and used the Bert model for classification. Zahan et al.

[17] used prompt engineering to detect malware packages, but due to the high cost of using ChatGPT, large-scale detection is difficult to achieve. In summary, the current detection tools have the following shortcomings: (1) Existing tools cannot fully model malicious behavior, which involves not only sensitive API calls, but also the control flow and data dependencies between these API calls. (2) Existing methods rely on manual calibration to collect sensitive APIs, and the collection of third-party dependencies is not sufficient. (3) Existing tools require a lot of manpower in actual use due to the high false alarm rate and the lack of detailed output information (such as the specific location of the malicious code). Summary of the Invention

[0004] The purpose of the present invention is to provide a method for detecting NPM malware packages with high efficiency and low consumption, thereby effectively detecting malware packages and reducing the harm caused by malicious code.

[0005] The NPM malware package detection method provided by the present invention includes an offline phase and a deployment phase. The deployment phase is divided into three stages: installation, import, and operation. The present invention first uses static analysis technology to construct a program behavior graph with sensitive APIs as nodes and data dependencies and control flows as edges. Sensitive APIs are automatically identified using a large model. Then, information about NPM malware packages is collected from multiple information sources to form a data set.

[0006] In the offline phase, for existing malware packages, a suspicious behavior graph of the program is constructed, and the malicious behavior graph is obtained through manual cropping.

[0007] During the deployment phase, the NPM package to be tested is input. The installation script contained in its configuration file is first analyzed to identify whether there is malicious behavior and determine the entry points for the executable files during the installation and import phases. Subsequently, the code files are obfuscated. For packages that do not contain obfuscated code, suspicious behavior graphs of the program during the installation, import, and run phases are generated. These graphs are then matched with known malicious behavior graphs generated during the offline phase to detect malicious behavior.

[0008] For specific malicious behaviors that match, based on dynamic analysis, the API hooking method is used to obtain the parameter content of the specified API, and combined with the API type, it is handed over to the large model for further malicious behavior judgment.

[0009] The specific steps are as follows:

[0010] (1) Static analysis technology is used to construct a suspicious program behavior graph with sensitive APIs as nodes and data dependencies and control flows as edges. Sensitive APIs are identified and classified automatically by a large model.

[0011] Using static analysis tools, given a program's execution entry point, a behavior graph is generated. Based on this behavior graph, sensitive APIs are identified and located. These APIs can be categorized as built-in or third-party APIs. Next, a suspicious behavior graph of the program is constructed based on the identified sensitive APIs. In the suspicious behavior graph, each node corresponds to a sensitive API, and the edges represent the control flow and data dependencies between APIs.

[0012] It includes the following sub-steps:

[0013] (1) Based on the static analysis tool Joern

[19] , the control flow information and data dependencies contained in the code are analyzed. The control flow information is represented in the form of a control flow graph (CFG), and the data dependencies are represented in the form of a data dependency graph (DDG).

[0014] (2) Given an execution entry, the control flow graph is traversed to simulate the program execution process and generate a program behavior graph (PBG). During the traversal process, the nodes encountered are added to the program behavior graph, and corresponding edges are added to the behavior graph based on the edge information in the original control flow graph and the data dependency graph. In particular, during the traversal process, four types of nodes are analyzed and processed, including:

[0015] Import node (import or require): The import statement is used to import modules. When encountering this type of node, the type of the imported module is analyzed, classified as a built-in module, a third-party module, or a local module, and the corresponding alias is recorded.

[0016] Function Call Node: A function call statement is a call to a declared function. When such a node is encountered, the corresponding called function (Callee) is located based on the call graph (CG). Next, the data dependency graph is used to determine whether there are data dependencies related to the function call parameters. If such a dependency exists, the function call node and the called function node are connected using a data dependency edge; if not, they are connected using a control flow edge.

[0017] API call node (API Call): An API call statement refers to calling an API provided by a built-in module or a third-party dependency. Each API call node can be divided into two categories: sensitive or non-sensitive. To identify sensitive built-in APIs, we obtain the official documentation of the API and pre-set the corresponding sensitive behavior types, such as file reading, network requests, etc., and then use the big model to classify the official description of the API to identify sensitive APIs. For sensitive third-party APIs, we analyze the source code and API comments, and also use the big model for classification to achieve the identification of sensitive APIs. For sensitive APIs, the corresponding return value type will also be recorded to assist in the analysis of the API calls involved in the return value.

[0018] Assignment: For assignment statements, the type of the right-hand expression is first analyzed. If the right-hand expression is an API call, the behavior category and return value type of the API call are further analyzed and bound to the object on the left-hand side of the assignment.

[0019] (3) Based on the identified sensitive APIs and their edge relationships in the program behavior graph, a suspicious behavior graph (SBG) of the program is extracted and constructed. In the graph, each node corresponds to an identified sensitive API, and the edges in the graph represent the control flow relationships and data dependencies between APIs.

[0020] (2) Collect information about NPM malware packages from multiple information sources as a dataset.

[0021] Collect software packages related to the NPM ecosystem from public malware package datasets; collect security intelligence related to the NPM ecosystem from well-known security blogs and obtain corresponding software packages.

[0022] It includes the following sub-steps:

[0023] (1) We collected malware packages from the public malware package datasets Backstabber's knife collection

[11] and MalOSS

[14] , and screened out malware packages related to the NPM ecosystem.

[0024] (2) Collect information from well-known security websites, such as Sonatype, Fortinet, and Hacker News, and obtain security intelligence information related to the NPM ecosystem from the blogs of these websites, including: package name, version number, and release date. Based on this information, collect malware packages that have been removed from the local NPM repository cache.

[0025] (3) In the offline phase, a suspicious behavior graph of the program is constructed for the existing malware package, and the malicious behavior graph is obtained through manual cutting. The specific process is as follows:

[0026] First, prepare the dataset required to generate the malicious behavior graph:

[0027] Use the NPM malware packages collected in step (2) as a dataset for generating malicious behavior graphs;

[0028] Use the method in step (1) to generate corresponding suspicious program behavior graphs for these malware packages;

[0029] The suspicious behavior graph may contain sensitive APIs that are not related to malicious behavior. Therefore, these irrelevant API nodes are removed through manual trimming to obtain the final malicious behavior graph.

[0030] (IV) In the deployment phase, the NPM software package to be tested is input, and the installation script contained in the configuration file of the software package is first analyzed to determine the entry of the execution file in the installation phase and the import phase, and to identify whether there is malicious behavior therein. Next, the code file is obfuscated and detected; for software packages that do not contain obfuscated code, suspicious behavior graphs of the program are generated from the three phases of installation, import, and operation, and matched with known malicious behavior graphs to detect malicious behavior. For malicious behaviors that are partially matched, the API hooking method is adopted. Through dynamic analysis, the parameter content of the specified API is extracted from the execution log. The parameter content is combined with the API type and handed over to the large model for further malicious behavior judgment. Specifically, it includes the following sub-steps:

[0031] (1) The NPM package to be tested is used as the input of this step. The installation script in the package.json configuration file within the package is processed, specifically analyzing the scripts in the preinstall, install, and postinstall fields. The executable file entries of the package during the installation and import phases are analyzed based on regular expressions, and a large model is used to judge the scripts to detect whether there is malicious behavior in the scripts.

[0032] (2) Malicious code often uses obfuscation to hide its malicious behavior. In the current step, obfuscated code is detected. The features for obfuscation detection are composed of semantic information and syntactic features of the code. Semantic information features include the number of code lines, the number of blank characters, the number of obfuscated identifiers, etc. Syntactic features are extracted based on AST sequences and n-grams models. The detection process is based on a trained binary classifier, and the model used is a random forest.

[0033] (3) If the software package does not contain obfuscated code, then use the method in step (1) to generate a suspicious behavior graph of the program from the three stages of installation, import, and operation. The suspicious behavior graph is matched with the malicious behavior graph obtained in step (3) to detect malicious behavior.

[0034] (4) To reduce the false positive rate, additional analysis is performed on some of the malicious behaviors detected in step (3). The API types to be analyzed include file reading and writing, command execution, executable file execution, and dynamic function generation. Custom code is inserted before the API to be analyzed to obtain its actual parameters. Based on dynamic analysis, the specified parameter content is extracted from the execution log. These actual operation parameters are then combined with the API type and submitted to the large model for judgment to further determine whether malicious behavior exists.

[0035] The technical features and performance advantages of the present invention mainly include:

[0036] By using static analysis technology to construct a program behavior graph, with sensitive APIs as nodes and data dependencies and control flows as edges, a global modeling of program behavior is achieved, making the analysis more accurate and fine-grained. The large model automatically identifies and classifies sensitive APIs, significantly reducing the workload of manual collection and annotation. During the deployment phase, program behavior analysis is subdivided into three stages: installation, import, and operation. It can fully cover all execution links of the software package, detect potential malicious behaviors, and ensure the comprehensiveness of detection. In addition, special detection is carried out on the obfuscation of the code, and binary classification processing is performed using obfuscation features to expand the detection range of malicious code. API hooking technology and dynamic analysis are used to obtain the operating parameters of the API in real time, further confirm the existence of malicious behavior, and effectively reduce the false alarm rate. The present invention can not only detect and identify malicious behavior and its type, but also accurately locate the location of malicious code, thereby greatly improving the efficiency of manual inspection.

[0037] The present invention primarily uses static analysis to construct program behavior, and further verifies specific situations that are prone to false positives through dynamic analysis. Compared with methods that rely solely on dynamic analysis, the present invention is superior in terms of resource usage and performance overhead. BRIEF DESCRIPTION OF THE DRAWINGS

[0038] Figure 1 The figure is a flowchart of the NPM malware package detection method based on behavioral analysis and matching of a graph model according to the present invention.

[0039] Figure 2 Schematic diagram of the conversion from program behavior graph to suspicious behavior graph. DETAILED DESCRIPTION

[0040] The following is a process of determining whether a given NPM package contains malicious code. Figure 1 , as follows:

[0041] (1) After entering the NPM package to be tested, the package.json configuration file is first processed, specifically analyzing the installation scripts in the preinstall, install, and postinstall fields. Regular expressions are used to analyze the executable file entries of the package during the installation and import phases, and the script is judged using a large model to determine whether the script has malicious behavior. The prompt words used to determine whether the script is malicious are shown in Table 1 below:

[0042] Table 1

[0043]

[0044] (2) Obfuscation detection is performed on the code. The obfuscation detection features are composed of semantic information and syntactic features of the code. Semantic information features include the number of code lines, the number of blank characters, the number of obfuscated identifiers, etc. Syntactic features are extracted based on AST sequences and n-grams models. The detection process is based on a trained binary classifier, and the model used is a random forest. If obfuscation is detected, it is considered that malicious code has been detected.

[0045] (3) If the software package does not contain obfuscated code, a suspicious program behavior graph corresponding to the installation, import, and runtime of the software package is generated. The sample code snippets in the software package to be detected are shown in Appendix 1. The corresponding program behavior graph is generated for the code, and sensitive APIs are identified and located. Based on the sensitive APIs identified and located and their edge relationships in the program behavior graph, a suspicious program behavior graph is constructed. Figure 2 The left side of the figure shows the program behavior graph corresponding to the code sample, and the right side shows the conversion of the program behavior graph to the sensitive behavior graph. The blue edges represent control flow relationships (i.e., the logical execution order). For example, in the left figure, http.get points to fs.createWriteStream through control flow, then points to flemished.on, and finally connects to fs.chmod and child_process.exec. The red edges represent data dependencies. For example, the data of flemished.on in the left figure depends on http.get, while the data of neroli.write depends on fs.createWriteStream. In the suspicious behavior graph, only nodes related to sensitive APIs are retained. The edge types in the suspicious behavior graph are derived based on the combination of control flow and data dependency relationships in the program behavior graph. By utilizing the transitivity of edge types, the relationship between these APIs is intuitively represented. After the suspicious behavior graph is converted, the suspicious behavior graph is matched with the known malicious behavior graph to detect possible malicious behavior.

[0046] (4) For malicious behavior graphs that are partially matched, additional analysis is required. By inserting custom code before the API to be analyzed, the parameters of its actual runtime are obtained. The code is shown in Appendix 2. Line 10 shows the code for API hooking, which is used to capture the specific parameter values ​​of the function during actual operation. Subsequently, based on dynamic analysis, the specified parameter content is extracted from the execution log, and these parameters are combined with the API type and handed over to the large model for judgment to further determine whether malicious behavior exists. The prompt words used for sensitive file reading analysis are shown in Table 2 below.

[0047]

[0048] By following these four steps, you can detect malicious behavior in the package being tested and locate the specific location of the malicious code within the file. This detection tool can effectively identify NPM malware packages, reducing the required manpower and the potential harm that malicious code can cause to downstream software.

[0049] (5) The experimental dataset consists of a collection of open-source malware packages and the top 5,000 most downloaded NPM non-malware packages. The malware packages include 244 unobfuscated malware packages and 120 obfuscated malware packages. The experiment uses ten-fold cross-validation as the evaluation method, and uses precision, recall, and F1 score as evaluation metrics. Four NPM malware package detection tools are compared. The specific results are shown in Table 3 below. SpiderScan is the tool used in this paper.

[0050] tool Accuracy Recall F1 value GuardDog 57.1％ 59.9％ 58.5％ SAP 95.4％ 48.7％ 64.2％ AMALFI 73.1％ 72.9％ 72.8％ CEREBRO 88.1％ 80.7％ 84.2％ SpiderScan 96.5％ 89.7％ 92.9％ .

[0051] The tool corresponding to the present invention achieved the highest F1 value, which was 8.7% to 34.4% higher than other tools, fully demonstrating its superiority in NPM malware package detection.

[0052] Appendix 1, sample code snippet of the software package to be tested

[0053]

[0054] Appendix 2, API hook code

[0055]

[0056] References

[0057] [1].Synopsys.2024.Open Source Security and Risk AnalysisReport.Retrieved May 20,2024fromhttps: / / www.synopsys.com / software-integrity / open-source-security-risk-analysis-report.

[0058] [2].GitHub Inc.2023.The state of open source and rise of AI in2023.Retrieved May 20,2024

[0059] from https: / / github.blog / 2023-11-08-the-state-of-open-source-and-ai / .

[0060] [3].Yacong Gu,Lingyun Ying,Yingyuan Pu,Xiao Hu,Huajun Chai,RuiminWang,Xing Gao,andHaixin Duan.2023.Investigating package related securitythreats in software registries.InProceedings of the IEEE Symposium onSecurity and Privacy.1578-1595.

[0061] [4].Piergiorgio Ladisa,Henrik Plate,Matias Martinez,and OlivierBarais.2023.Sok:Taxonomy ofattacks on open-source software supply chains.InProceedings of the IEEE Symposium onSecurity and Privacy.1509-1526.

[0062] [5].OpenSSF.2023.2023 OpenSSF Annual Report.Retrieved May 20,2024fromhttps: / / openssf.org / download-the-2023-openssf-annual-report /

[0063] [6].Sonatype.2023.State of the Software Supply Chain.Retrieved May20,2024 fromhttps: / / www.sonatype.com / state-of-the-software-supply-chain / introduction

[0064] [7].Xinyuan Wang.2021.On the feasibility of detecting software supplychain attacks.InProceedings of the IEEE Military CommunicationsConference.458-463.

[0065] [8].Fortinet.2023.Malicious Packages Hidden in NPM.Retrieved May 20,2024 fromhttps: / / www.fortinet.com / blog / threat-research / malicious-packages-hiddin-in-npm

[0066] [9].Wenbo Guo,Zhengzi Xu,Chengwei Liu,Cheng Huang,Yong Fang,and YangLiu.2023.AnEmpirical Study of Malicious Code In PyPI Ecosystem.In Proceedingsof the 38th IEEE / ACMInternational Conference on Automated SoftwareEngineering.166-177.

[0067]

[10] .The Hacker News.2023.116 Malware Packages Found on PyPIRepository InfectingWindows and Linux Systems.Retrieved May 20,2024fromhttps: / / thehackernews.com / 2023 / 12 / 116-malware-packages-found-on-pypi.html

[0068]

[11] .Marc Ohm,Henrik Plate,Arnold Sykosch,and MichaelMeier.2020.Backstabber’s knifecollection:A review of open source softwaresupply chain attacks.In Proceedings of the 17thInternational Conference onDetection of Intrusions and Malware,and Vulnerability Assessment.23-43.

[0069]

[12] .Ruturaj K Vaidya,Lorenzo De Carli,Drew Davidson,and VaibhavRastogi.2019.Securityissues in language based software ecosystems.arXivpreprint arXiv:1903.02613(2019).

[0070]

[13] .Xiaoyan Zhou,Feiran Liang,Zhaojie Xie,Yang Lan,Wenjia Niu,Jiqiang Liu,HainingWang,and Qiang Li.2024.A Large-scale Fine-grained Analysisof Packages in Open-SourceSoftware Ecosystems.arXiv preprint arXiv:2404.11467(2024).

[0071]

[14] .Ruian Duan,Omar Alrawi,Ranjita Pai Kasturi,Ryan Elder,BrendanSaltaformaggio,andWenke Lee.2020.Towards measuring supply chain attacks onpackage managers for interpretedlanguages.In Proceedings of the 28th AnnualNetwork and Distributed System SecuritySymposium.

[0072]

[15] .Marc Ohm,Lukas Kempf,Felix Boes,and Michael Meier.2022.TowardsDetection ofMalicious Software Packages Through Code Reuse by MalevolentActors.Gesellschaft fürInformatik,Bonn.

[0073]

[16] .Adriana Sejfia and Max 2022.Practical automated detectionof malicious npmpackages.In Proceedings of the 44th International Conferenceon Software Engineering.1681- 1692.

[0075]

[17] .Junan Zhang,Kaifeng Huang,Bihuan Chen,Chong Wang,Zhenhao Tian,and Xin Peng.

[0076] 2023.Malicious Package Detection in NPM and PyPI using a Single Modelof MaliciousBehavior Sequence.arXiv preprint arXiv:2309.02637(2023).

[0077]

[18] .Nusrat Zahan,Philipp Burckhardt,Mikola Lysenko,FerossAboukhadijeh,and LaurieWilliams.2024.Shifting the Lens:Detecting Malware innpm Ecosystem with Large LanguageModels.arXiv preprint arXiv:2403.12196(2024).

[0078]

[19] .Joern.2019.Joern-The Bug Hunter’s Workbench.Retrieved May 20,2024 fromhttps: / / joern.io / 。

Claims

1. A method for detecting NPM malware packages based on behavioral analysis and matching using a graph model, comprising an offline phase and a deployment phase; the deployment phase is divided into three phases: installation, import, and operation; and characterized by: First, using static analysis techniques, we construct a program behavior graph with sensitive APIs as nodes and data dependencies and control flows as edges. Sensitive APIs are automatically identified using a large model. We then collect information about NPM malware packages from multiple sources to form a dataset. In the offline phase, for existing malware packages, a suspicious behavior graph of the program is constructed, and the malicious behavior graph is obtained through manual cropping. During the deployment phase, the NPM package to be tested is input. The installation script contained in its configuration file is first analyzed to identify whether there is malicious behavior and determine the entry points for the executable files during the installation and import phases. Subsequently, the code files are obfuscated. For packages that do not contain obfuscated code, suspicious behavior graphs of the program during the installation, import, and run phases are generated. These graphs are then matched with known malicious behavior graphs generated during the offline phase to detect malicious behavior. For specific malicious behaviors that match, we use the API hooking method based on dynamic analysis to obtain the parameter content of the specified API. Combined with the API type, the large model is used to further determine the malicious behavior. The specific steps are as follows: (1) Using static analysis technology to construct a suspicious program behavior graph with sensitive APIs as nodes and data dependencies and control flows as edges. Sensitive APIs are automatically identified and classified by a large model; Using static analysis tools, given a program's execution entry point, a behavior graph of the program is generated. Based on this behavior graph, sensitive APIs are identified and located. These APIs can be categorized as built-in APIs and third-party APIs. Next, based on the identified sensitive APIs, a suspicious behavior graph of the program is constructed. In the suspicious behavior graph, each node corresponds to a sensitive API, and the edges in the graph represent the control flow and data dependencies between APIs. (2) Collecting information about NPM malware packages from multiple information sources as a dataset; Specifically, we collected software packages related to the NPM ecosystem from public malware package datasets; collected security intelligence related to the NPM ecosystem from well-known security blogs, and obtained the corresponding software packages; (3) During the offline phase, a suspicious behavior graph of the program is constructed for the existing malware package, and the malicious behavior graph is obtained through manual trimming; (IV) During the deployment phase, the NPM software package to be tested is input. First, the installation script contained in the configuration file of the software package is analyzed to determine the entry point of the executable file in the installation and import phases, and to identify whether there is malicious behavior therein. Next, the code file is obfuscated. For software packages that do not contain obfuscated code, suspicious behavior graphs of the program are generated from the three phases of installation, import, and operation, and matched with known malicious behavior graphs to detect malicious behavior. For partially matched malicious behaviors, the API hooking method is used to extract the parameter content of the specified API from the execution log through dynamic analysis. The parameter content is combined with the API type and handed over to the large model for further malicious behavior judgment.

2. The NPM malware package detection method according to claim 1, characterized in that: Step (1) specifically includes the following sub-steps: (1) Based on the static analysis tool Joern, the control flow information and data dependency relationships contained in the code are analyzed; the control flow information is represented in the form of a control flow graph (CFG), and the data dependency relationships are represented in the form of a data dependency graph (DDG); (2) Given an execution entry, traverse the control flow graph to simulate the program execution process and generate the program's behavior graph (PBG). During the traversal process, the encountered nodes are added to the program's behavior graph, and corresponding edges are added to the behavior graph based on the edge information in the original control flow graph and the data dependency graph; (3) Based on the sensitive APIs identified and located and their edge relationships in the program behavior graph, the suspicious behavior graph (SBG) of the program is extracted and constructed. In the SBG, each node corresponds to an identified sensitive API, and the edges represent the control flow relationships and data dependencies between APIs.

3. The NPM malware package detection method according to claim 2, characterized in that: In sub-step (2) of step (1), four types of nodes are analyzed and processed, including: Import node: The import statement is used to import modules. When encountering this type of node, the type of the imported module is analyzed, classified as a built-in module, a third-party module, or a local module, and the corresponding alias is recorded; Function call node: A function call statement refers to a call to a declared function. When such a node is encountered, the corresponding called function is located based on the call graph (CG). Next, the data dependency graph is used to determine whether there is a data dependency related to the function call parameters. If such a dependency exists, the function call node and the called function node are connected using a data dependency edge. If not, they are connected using a control flow edge. API call node: An API call statement refers to calling an API provided by a built-in module or a third-party dependency. Each API call node is categorized as sensitive or non-sensitive. To identify sensitive built-in APIs, we obtain the official API documentation, pre-set the corresponding sensitive behavior type, and then use the big model to classify the official API description to identify sensitive APIs. For sensitive third-party APIs, we analyze the source code and API comments, and also use the big model to classify them, thereby achieving identification of sensitive APIs. For sensitive APIs, the corresponding return value type is also recorded to assist in analyzing the API call involved in the return value. Assignment node: For assignment statements, the type of the expression on the right side is first analyzed. If the expression on the right side is an API call, the behavior category and return value type of the API call are further analyzed, and this information is bound to the object on the left side of the assignment.

4. The NPM malware package detection method according to claim 3, characterized in that: Step (2) specifically includes the following sub-steps: (1) Collect malware packages from the public malware package datasets Backstabber's knife collection and MalOSS, and filter out malware packages related to the NPM ecosystem; (2) Collect well-known security websites and obtain security intelligence information related to the NPM ecosystem from the blogs of these websites, including: package name, version number, and release date; based on this information, collect malware packages that have been removed from the local NPM repository cache.

5. The NPM malware package detection method according to claim 4, characterized in that: The specific process of step (3) is as follows: First, prepare the dataset required to generate the malicious behavior graph: Use the NPM malware packages collected in step (2) as a dataset for generating malicious behavior graphs; Use the method in step (1) to generate corresponding suspicious program behavior graphs for these malware packages; The suspicious behavior graph may contain sensitive APIs that are not related to malicious behavior. Therefore, these irrelevant API nodes are removed through manual trimming to obtain the final malicious behavior graph.

6. The NPM malware package detection method according to claim 5, characterized in that: Step (4) specifically includes the following sub-steps: (1) Take the NPM software package to be detected as input, process the installation script in the package.json configuration file within the software package, and specifically analyze the scripts in the preinstall, install, and postinstall fields; analyze the executable file entries of the software package during the installation and import phases based on regular expressions, and use a large model to judge the scripts to detect whether there is malicious behavior in the scripts; (2) Malicious code usually uses obfuscation to hide its malicious behavior. In the current step, the obfuscated code is detected. The features of obfuscation detection are composed of the semantic information and syntactic features of the code, where the semantic information features include the number of code lines, the number of blank characters, and the number of obfuscated identifiers. Syntactic features are extracted based on AST sequences and n-grams models. The detection process is based on a trained binary classifier using a random forest model. (3) If the software package does not contain obfuscated code, then use the method in step (1) to generate a suspicious behavior graph of the program from the three stages of installation, import, and operation for the software package that does not contain obfuscated code; match the suspicious behavior graph with the malicious behavior graph obtained in step (3) to detect malicious behavior; (4) Conduct additional analysis on some of the malicious behaviors detected in step (3). The API types to be analyzed include file reading and writing, command execution, executable file running, and dynamic function generation; Insert custom code before the API to be analyzed to obtain its actual parameters. Based on dynamic analysis, extract the specified parameter content from the execution log. Then, these actual operating parameters are combined with the API type and submitted to the big model for judgment to further determine whether there is malicious behavior.

Images