Intelligent malicious code analysis method and system, medium and product

Abstract

The invention discloses an intelligent malicious code analysis method and system, a medium and a product, and relates to the field of network security. The method comprises the following steps: acquiring a malicious code sample, and performing packing detection and automatic unpacking on the malicious code sample to obtain original code data; performing static analysis on the original code data to obtain static characteristics and code instructions of the malicious code samples, generating static code anchor point identifiers, and performing monitoring point injection on an operating system API (Application Program Interface) in a preset adaptive sandbox environment to obtain a target adaptive sandbox environment; executing the malicious code sample in the target adaptive sandbox environment to perform dynamic analysis, generating dynamic behavior data, and defending sandbox escape behaviors; and performing matching query on the static characteristics, the dynamic behavior data and an external threat library to obtain a comprehensive traceability result associated with the malicious code sample. By implementing the technical scheme provided by the invention, the malicious code detection accuracy is improved.

Description

Technical Field

[0001] This application relates to the field of cybersecurity, specifically to an intelligent malware analysis method, system, medium, and product. Background Technology

[0002] With the iterative upgrading of cyberattack methods, malicious code, such as ransomware, Trojans, and worms, is exhibiting significant characteristics such as strong concealment, rapid mutation, and complex attack chains. These advanced threats can easily bypass traditional defense boundaries and infiltrate and spread through sophisticated social engineering, zero-day exploits, and other methods, posing an increasingly severe challenge to critical information infrastructure, corporate data assets, and personal privacy security.

[0003] In the field of malware detection, static analysis is a fundamental and widely used technique. It identifies known threats by extracting the signatures of the file under test and comparing them with a known malware signature database. However, this technique has a fundamental flaw: with the widespread use of techniques such as code obfuscation, packing, and polymorphic mutation, malware can easily change its binary characteristics, resulting in frequent or even completely different signatures. This makes static analysis methods, which rely on fixed signature databases, severely inadequate in detecting unknown or variant malware, leading to a high risk of false negatives and low detection accuracy. Summary of the Invention

[0004] This application provides an intelligent malware analysis method, system, medium, and product, which improves the accuracy of malware detection.

[0005] The first aspect of this application provides an intelligent malware analysis method. This method includes: acquiring a malware sample to be analyzed; performing packing detection and automatic unpacking on the malware sample to obtain raw code data; performing static analysis on the raw code data to obtain static features of the malware sample and code instructions with potential behavioral risks, wherein the code instructions are direct or indirect calls to operating system APIs; generating static code anchor identifiers based on the static addresses of the code instructions in the raw code data; and injecting monitoring points into operating system APIs within a preset adaptive sandbox environment based on the static code anchor identifiers to obtain a target adaptive sandbox environment; executing the malware sample in the target adaptive sandbox environment for dynamic analysis to generate dynamic behavior data, and detecting whether the malware sample exhibits sandbox escape behavior during the dynamic analysis process; if it is determined that the malware sample exhibits sandbox escape behavior, then defending against the sandbox escape behavior; and matching the static features and the dynamic behavior data with an external threat database to obtain a comprehensive tracing result associated with the malware sample.

[0006] By employing the aforementioned technical solutions, malicious code samples can be detected and automatically unpacked, effectively removing their protective shells and obtaining raw code data, thus providing a foundation for subsequent static analysis. Static analysis of the raw code data extracts static features and potentially risky code instructions from the malicious code samples, providing targeted monitoring targets for dynamic analysis. Generating static code anchor markers based on the static addresses of code instructions and injecting monitoring points into the operating system APIs within a pre-defined adaptive sandbox environment allows for precise location of critical malicious code behaviors, improving the efficiency and accuracy of dynamic analysis. Executing the malicious code sample within the target adaptive sandbox environment simulates a real execution environment, capturing dynamic behavioral data of the malicious code. Furthermore, detecting and defending against sandbox escape behavior effectively prevents malicious code from evading analysis. Finally, matching the static features and dynamic behavioral data with an external threat database yields comprehensive tracing results, revealing key information such as the source and attack purpose of the malicious code, providing support for threat intelligence analysis and tracing investigations.

[0007] Optionally, the step of performing packing detection and automatic unpacking on the malicious code sample to obtain the original code data specifically includes: calculating the hash value of the malicious code sample and deduplicating the malicious code sample by comparing the hash value with an existing sample library; identifying the file format of the deduplicated malicious code sample to determine the file type of the malicious code sample; based on the file type, using a machine learning-based intelligent packing detection model to perform packing detection on the malicious code sample; if the malicious code sample is detected to be protected by packing, then selecting the corresponding unpacking engine to unpack the malicious code sample according to the identified packing method to obtain the unpacked original code data; if the malicious code sample is detected to be unprotected, then outputting the file data of the malicious code sample as the original code data.

[0008] By employing the above technical solutions, hash value calculation and comparison of malicious code samples can quickly identify known samples, avoiding redundant analysis and improving analysis efficiency. File format identification can determine the file type of the malicious code sample, providing a reference for subsequent packing detection and unpacking processing. Using a machine learning-based intelligent packing detection model, it can automatically identify whether a malicious code sample is protected by a packer, improving the accuracy of packing detection. Based on the identified packing method, the corresponding unpacking engine is selected for unpacking processing, which can adaptively cope with different packing techniques and obtain the unprotected original code data. For malicious code samples that are not protected by a packer, the file data is directly output as the original code data, saving unnecessary unpacking processing time.

[0009] Optionally, the step of injecting monitoring points into the operating system API within the preset adaptive sandbox environment based on the static code anchor identifier to obtain the target adaptive sandbox environment specifically includes: traversing the import table of the malicious code sample and extracting all imported operating system API functions; for each operating system API function, setting an interception hook associated with the operating system API function at the entry point of the corresponding API function in the preset adaptive sandbox environment; registering the static code anchor identifier associated with the operating system API function as parameter information into the interception hook to form a target API function injected with monitoring points; and replacing and updating the target API function based on the preset adaptive sandbox environment to obtain the target adaptive sandbox environment.

[0010] By employing the above technical solution and traversing the import table of the malicious code sample, all imported operating system API functions can be extracted, identifying key APIs that the malicious code may call. Setting interception hooks at the entry points of the corresponding API functions in the preset adaptive sandbox environment allows for real-time capture of malicious code calls to these API functions. Registering static code anchor points as parameters in the interception hooks enables the association of dynamic malicious code behavior with static code locations at runtime, achieving precise location and tracking of malicious code behavior. By replacing and updating the API functions in the preset adaptive sandbox environment, a target adaptive sandbox environment with injected monitoring points is obtained. This allows for dynamic monitoring and data collection of key behaviors without affecting the normal execution of the malicious code, providing data support for subsequent behavior analysis.

[0011] Optionally, the step of executing the malicious code sample in the target adaptive sandbox environment for dynamic analysis and generating dynamic behavior data specifically includes: introducing the malicious code sample into the target adaptive sandbox environment, which is built based on virtualization technology and contains multiple virtual machine images with different configurations to simulate a real application execution environment; selecting a target virtual machine image compatible with the malicious code sample in the target adaptive sandbox environment, and adjusting the system parameters of the target virtual machine image according to the characteristics of the malicious code sample; creating a virtual execution environment for executing the malicious code sample based on the adjusted target virtual machine image, and porting the malicious code sample to the sandbox environment. The system runs in a virtual execution environment. Within this environment, it captures the malicious code sample's behavior of calling operating system API functions and obtains the call parameters and return results based on the interception hook. Based on the captured behavior information and the obtained call parameters and return results, it generates multiple intermediate behavior log files reflecting different execution stages of the malicious code sample. It then performs comprehensive analysis on these intermediate behavior log files to extract key behavioral features of the malicious code sample, including process creation logs, file read / write logs, registry operation logs, and network communication logs. Based on these key behavioral features, it constructs a dynamic behavioral feature vector of the malicious code sample, which is then output as the dynamic behavioral data.

[0012] By employing the aforementioned technical solutions, malicious code samples are introduced into a target adaptive sandbox environment built on virtualization technology. This allows for the secure execution of malicious code within an isolated virtual environment, preventing damage to the host machine. By selecting a target virtual machine image compatible with the malicious code sample and adjusting system parameters based on the sample's characteristics, the execution state of the malicious code in a real environment can be simulated, improving the effectiveness of dynamic analysis. Capturing the malicious code's calls to operating system API functions within the virtual execution environment, and obtaining call parameters and return results based on interception hooks, allows for detailed recording of the malicious code's dynamic execution flow and data interaction. Generating multiple intermediate behavior log files reflecting different execution stages of the malicious code completely preserves its dynamic execution traces, providing a data foundation for subsequent comprehensive analysis. Comprehensive analysis of these intermediate behavior log files extracts key behavioral features of the malicious code, such as process creation, file reading and writing, registry operations, and network communication, comprehensively characterizing the malicious behavior patterns. Constructing dynamic behavioral feature vectors based on these key behavioral features abstracts the dynamic execution of the malicious code into a structured data representation, facilitating subsequent feature matching and similarity analysis.

[0013] Optionally, the system parameters include installed software and patch levels. The step of selecting a target virtual machine image compatible with the malicious code sample in the target adaptive sandbox environment and adjusting the system parameters of the target virtual machine image according to the characteristics of the malicious code sample specifically includes: determining the target operating system platform of the malicious code sample based on its file attribute information, and selecting a base image corresponding to the target operating system platform from the virtual machine image library as the target virtual machine image; analyzing the import table information of the malicious code sample, identifying the dynamic link library files that the malicious code sample depends on, and installing installation software matching the version of the dynamic link library files in the target virtual machine image; performing a security scan on the target virtual machine image to identify system vulnerability data and missing patch data present in the target virtual machine image; and adjusting the patch level of the target virtual machine image according to the system vulnerability data and the missing patch data.

[0014] By employing the above technical solutions and analyzing the file attribute information of malicious code samples, the target operating system platform can be determined. A base image corresponding to the target platform can then be selected as the target virtual machine image, ensuring the malicious code can run normally in the target environment. Identifying the dynamic link library files that the malicious code sample depends on and installing software with versions matching these dynamic link library files in the target virtual machine image satisfies the malicious code's dependency requirements on specific software environments, improving the success rate of dynamic analysis. Performing a security scan on the target virtual machine image identifies existing system vulnerabilities and missing patches. Adjusting the patch level of the target virtual machine image based on vulnerability data and patch missing information can construct a vulnerable system environment similar to the real environment, inducing malicious code to trigger more malicious behaviors and improving the depth and comprehensiveness of dynamic analysis.

[0015] Optionally, the step of matching and querying the static features and dynamic behavior data with an external threat database to obtain a comprehensive tracing result associated with the malicious code sample specifically includes: extracting multiple key data from the static features and dynamic behavior data; using the key data as a query index to compare with the external threat database to obtain intelligence information, and determining whether a historical attack event record associated with the key data is matched in the external threat database; if a historical attack event record associated with the key data is matched in the external threat database, then an attack chain graph corresponding to the malicious code sample is constructed based on the historical attack event record; if no historical attack event record associated with the key data is matched in the external threat database, then the malicious code sample is marked as an unknown attack event, and basic tracing information corresponding to the malicious code sample is queried through external channels based on the key data; and the attack chain graph or the basic tracing information is integrated with the intelligence information to obtain the comprehensive tracing result.

[0016] By employing the aforementioned technical solutions, multiple key data points are extracted from static features and dynamic behavioral data as query indexes. These are then compared with external threat databases to quickly retrieve intelligence information related to malware samples, expanding our understanding of malware. By determining whether historical attack event records associated with the key data are matched in the external threat database, we can ascertain whether the malware sample represents a known attack type. If relevant historical attack event records are matched, an attack chain graph corresponding to the malware sample can be constructed based on these records. This visually demonstrates the role and association of malware in attack activities, revealing its importance in the entire attack. For unknown malware samples, marking them as unknown attack events and querying external channels based on key data allows us to obtain basic source information, providing direction for subsequent in-depth analysis. Integrating the attack chain graph or basic source information with intelligence information to form a comprehensive source tracing result can comprehensively depict the threat source and attack intent of malware samples from multiple dimensions, providing intelligence support for security incident emergency response.

[0017] Optionally, if it is determined that the malicious code sample exhibits sandbox escape behavior, then defense against the sandbox escape behavior is implemented, specifically including: dynamically modifying sandbox environment parameters in the target adaptive sandbox environment, the dynamic modification of sandbox environment parameters including randomly generating the number of virtual CPU cores, modifying the simulated value of virtual disk capacity, and forging registry entries of commonly used software; monitoring whether the malicious code sample exhibits environment probing behavior during execution; if environment probing behavior is detected in the malicious code sample, comparing whether the system information obtained by the malicious code sample is consistent with the sandbox environment parameters to determine whether the malicious code sample has a sandbox escape risk; if it is determined that the malicious code sample has a sandbox escape risk, restoring the sandbox environment to its initial state for defense, and marking the escape attempt behavior as a high-risk behavior in the dynamic behavior data.

[0018] By employing the aforementioned technical solutions, the environmental parameters of the target adaptive sandbox environment are dynamically modified. This includes randomly generating the number of virtual CPU cores, modifying the simulated virtual disk capacity, and forging registry entries for commonly used software. This obscures the criteria by which malicious code judges the real sandbox environment, increasing the difficulty for it to identify it. Monitoring the environment probing behavior of malicious code samples during execution, and comparing the system information obtained by the malicious code with the randomly generated sandbox environment parameters, can determine whether the malicious code poses a sandbox escape risk. Once a sandbox escape risk is confirmed, the sandbox environment is immediately restored to its initial state for defense, blocking escape attempts and maintaining the isolation and effectiveness of the analysis environment. Simultaneously, marking escape attempts as high-risk behaviors and embedding them into dynamic behavioral data provides crucial information for subsequent threat assessments, prompting analysts to focus on the malicious code's anti-analysis capabilities and potential destructive power.

[0019] Secondly, embodiments of this application provide an intelligent malicious code analysis system, which includes: one or more processors and a memory; the memory is coupled to the one or more processors, and the memory is used to store computer program code, the computer program code including computer instructions, and the one or more processors call the computer instructions to cause the intelligent malicious code analysis system to perform the method described in the first aspect and any possible implementation thereof.

[0020] Thirdly, embodiments of this application provide a computer-readable storage medium including instructions that, when executed on an intelligent malicious code analysis system, cause the intelligent malicious code analysis system to perform the method described in the first aspect and any possible implementation thereof.

[0021] Fourthly, embodiments of this application provide a computer program product containing instructions that, when the computer program product is run on an intelligent malicious code analysis system, cause the intelligent malicious code analysis system to execute the method described in the first aspect and any possible implementation thereof.

[0022] In summary, one or more technical solutions provided in this application have at least the following technical effects or advantages: 1. By combining packer detection with automatic unpacking, static analysis, dynamic analysis, adaptive sandboxing, and threat intelligence matching, this method addresses the shortcomings of traditional malware detection methods in terms of concealment, variability, and source tracing capabilities. Through the fusion of static risk scoring, dynamic behavior analysis, and comprehensive source tracing results, a comprehensive analysis report is generated, significantly improving detection accuracy, source tracing depth, and the ability to respond to advanced threats. Ultimately, it provides a powerful intelligent protection mechanism for critical infrastructure and data security. Attached Figure Description

[0023] Figure 1 This is a flowchart illustrating an intelligent malware analysis method disclosed in an embodiment of this application; Figure 2 This is another flowchart illustrating an intelligent malware analysis method disclosed in an embodiment of this application; Figure 3 This is a schematic diagram of the structure of an intelligent malicious code analysis system provided in an embodiment of this application.

[0024] Explanation of reference numerals in the attached drawings: 301, Central Processing Unit; 302, Read-Only Memory; 303, Random Access Memory; 304, Bus; 305, Input / Output Interface; 306, Input Section; 307, Output Section; 308, Storage Section; 309, Communication Section; 310, Driver; 311, Removable Media. Detailed Implementation

[0025] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0026] In the description of the embodiments of this application, the words "for example" or "for instance" are used to indicate examples, illustrations, or explanations. Any embodiment or design that is described as "for example" or "for instance" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design options. Rather, the use of the words "for example" or "for instance" is intended to present the relevant concepts in a specific manner.

[0027] In the description of the embodiments of this application, the term "multiple" means two or more. For example, multiple systems means two or more systems, and multiple screen terminals means two or more screen terminals. Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the indicated technical features. Thus, a feature defined with "first" or "second" may explicitly or implicitly include one or more of that feature. The terms "comprising," "including," "having," and variations thereof all mean "including but not limited to," unless otherwise specifically emphasized.

[0028] This application provides an intelligent malware analysis method, referring to... Figure 1 , Figure 1 This is a flowchart illustrating an intelligent malware analysis method provided in an embodiment of this application. The method is applied to a system that can execute programs. The method includes steps S101 to S106, as follows: Step S101: Obtain the malicious code sample to be analyzed, and perform packing detection and automatic unpacking on the malicious code sample to obtain the original code data.

[0029] In step S101, the malicious code sample refers to a program file suspected of containing malicious functionality, which is the object of analysis. This could be an executable file, a dynamic link library, or a script file. Packing detection refers to the process of identifying whether a malicious code sample has been compressed or encrypted to evade static analysis; this process is called packing. Automatic unpacking refers to the process of decompressing or decrypting the packed malicious code sample in memory using specific techniques to restore its original unencrypted code. The original code data represents the program binary code obtained after automatic unpacking, which can be directly disassembled and analyzed.

[0030] Specifically, the system first receives a malicious code sample to be analyzed. The system then performs a packer detection on the sample file. Detection methods may include scanning the file for signatures of known packers or analyzing the entropy values ​​of file sections; high entropy values ​​usually indicate that the data has been compressed or encrypted. If the sample is detected as packed, the system will activate the automatic unpacking module. This module executes the malicious code sample in a controlled environment and monitors its memory changes. When the sample completes self-decompression in memory and is about to jump to its actual program entry point (OEP), the system captures a snapshot of the process memory at this moment and dumps the relevant code and data from memory, thereby generating a complete, unpacked original code data for subsequent analysis.

[0031] In one possible implementation, the malicious code sample is subjected to packing detection and automatic unpacking to obtain the original code data, specifically including steps S1011-S1015, as follows: Step S1011: Calculate the hash value of the malicious code sample and deduplicate the malicious code sample by comparing the hash value with the existing sample library.

[0032] In step S1011, hash value calculation refers to applying one or more cryptographic hash functions, such as MD5 or SHA256, to the complete file content of the malicious code sample to generate a fixed-length digital fingerprint that uniquely identifies the file; this fingerprint is the hash value. The existing sample library refers to a database that stores a large number of previously analyzed file samples, their hash values, and analysis results. Hash value comparison refers to the process of comparing the hash value of a newly acquired malicious code sample with all hash values ​​stored in the existing sample library. Deduplication is used to represent an optimization process; if the hash value of a new sample already exists in the sample library, it means that the sample has already been analyzed, and the system will not repeat the analysis, thus saving computational resources.

[0033] Specifically, upon receiving a malware sample to be analyzed, the system first performs a hash value calculation. The system reads all the binary data of the sample file and inputs it into one or more standard hash algorithm modules, such as the SHA256 algorithm module, to generate a unique hash value for the sample. Subsequently, the system uses this newly generated hash value as a query key to perform an exact match search in the existing sample database. If an identical hash value is found in the database, it indicates a duplicate sample, and the system can directly retrieve historical analysis results and terminate the current analysis process. If no match is found, it indicates a completely new sample, and the system marks it as awaiting analysis and continues with subsequent steps.

[0034] Step S1012: Perform file format identification on the deduplicated malicious code sample to determine the file type of the malicious code sample.

[0035] In step S1012, file format identification refers to a technique that accurately determines the file type by analyzing the internal binary structure of the file, especially specific markers in the file header. This method is more reliable than relying on file extensions. The file type indicates the specific format of the malicious code sample, such as whether it is a PE executable file on a Windows platform, an ELF file on a Linux platform, a PDF document, or a Java JAR file.

[0036] Specifically, for malicious code samples that pass the deduplication check, the system will perform file format identification. The system will read the first few bytes of the file; this data usually contains file signature information known as the "magic number." For example, the system will check if the file begins with the ASCII characters "MZ." If so, it initially determines that the file type is a Windows PE file. If the file begins with "\x7FELF," it is determined to be a Linux ELF file. The system internally maintains a magic number signature library for common file types. By comparing the sample with this library, the file type of the malicious code sample can be accurately determined. Determining the file type is fundamental to subsequent analysis because the packing methods and analysis methods for different file types vary significantly.

[0037] Step S1013: Based on file type, use a machine learning-based intelligent packer detection model to detect malicious code samples.

[0038] In step S1013, the machine learning-based intelligent packer detection model refers to an algorithm model built by learning and training on a large number of packed and unpacked samples. This model can extract various features from the samples and intelligently determine whether the samples are packed based on these features, and can even identify unknown packer tools. Packer detection is used to indicate whether malicious code samples have undergone protective processing such as compression, encryption, or obfuscation.

[0039] Specifically, the system first selects an appropriate feature extraction scheme based on the file type determined in the previous step. Taking PE files as an example, the system extracts a series of features that can reflect signs of packing. These features may include the entropy distribution of file sections, the anomalies of section names, the size of the import function table, the consistency of file header information, and the existence of writable and executable memory segments. Then, the system organizes these extracted features into a numerical vector and inputs it into a pre-trained machine learning-based intelligent packing detection model. This model, such as a gradient boosting decision tree or a deep neural network model, calculates the input feature vector and finally outputs a judgment result, clearly indicating whether the malicious code sample has been protected by packing.

[0040] Step S1014: If a malicious code sample is detected to be protected by a packer, the corresponding unpacking engine is selected according to the identified packing method to unpack the malicious code sample and obtain the unpacked original code data.

[0041] In step S1014, the packing method indicates the type or name of the specific packing tool used by the malicious code sample, such as UPX, ASPack, or Themida. The unpacking engine refers to a software module or tool specifically designed for reverse engineering a particular packing method; it can automatically remove packing protection. Unpacking processing refers to the process of running the corresponding unpacking engine to perform decompression and decryption operations on the packed malicious code sample. The unpacked raw code data represents the program code and data recovered after unpacking processing, which can be directly disassembled and statically analyzed.

[0042] Specifically, this step is only performed when the detection result in step S1013 is "protected by a packer". The system will select the corresponding unpacking engine from its tool library based on the packer identification result given by the packer detection model. For example, if the identified packer is UPX, the system will call the official UPX unpacker or a compatible unpacker module. If a more complex commercial protection packer is identified, the system may launch an unpacking engine based on dynamic simulation. The selected unpacking engine will perform unpacking processing on the malicious code sample. This process may involve simulating the sample's execution in a controlled environment, monitoring its self-decryption and decompression behavior in memory, and completely dumping the code and data from memory the instant it reverts to its original form. Ultimately, this process successfully generates the unprotected original code data.

[0043] Step S1015: If a malicious code sample is detected that it has not been protected by a packer, the file data of the malicious code sample is output as the original code data.

[0044] In step S1015, the file data of the malicious code sample represents the original binary content of the malicious code sample without any modification. Here, "original code data" refers to the input data used in subsequent analysis processes; because the sample itself is not packed, its original file data is code data that can be directly analyzed.

[0045] Specifically, this step is an execution path mutually exclusive with step S1014. The system will execute this step when the detection result of step S1013 is "not protected by a packer." In this case, the system determines that the malicious code sample itself exists in an unprotected form. Therefore, the system does not need to perform any unpacking processing and directly outputs the entire file data of the received malicious code sample. This unmodified file data will be directly named "Original Code Data" and passed to the subsequent static analysis module, i.e., step S102.

[0046] Step S102: Perform static analysis on the original code data to obtain the static characteristics of the malicious code sample and code instructions with potential behavioral risks. The code instructions are call instructions that directly or indirectly call the operating system API.

[0047] In step S102, static analysis refers to the technique of analyzing the structure, instructions, and data flow of program code without actually running the code. Static features represent various information extracted through static analysis that reflects code attributes and potential functions, such as suspicious strings contained in a file, a list of imported sensitive functions, or network addresses. Code instructions with potential behavioral risks refer to critical instructions that may lead to malicious behavior during program execution; these instructions themselves or their subsequent instruction sequences trigger interactions with the operating system. Operating system APIs refer to the set of functional interfaces provided by the operating system for applications to use; applications call these APIs to perform functions such as file operations, network communication, or registry modification. Call instructions are used to represent instructions in the processor instruction set used to jump to another code address for execution, such as the CALL instruction in the x86 architecture.

[0048] Specifically, the system uses a disassembler engine to parse the raw code data obtained in step S101 instruction by instruction, converting it from machine code into human-readable assembly code. During this process, the system performs comprehensive static analysis. On one hand, the system extracts the static features of the sample, including parsing its file header format to obtain the import function table and scanning its data segments to discover hard-coded IP addresses, domain names, special file paths, or encryption keys. On the other hand, the system focuses on identifying code instructions with potential behavioral risks. The system traverses all code to locate those instructions that directly or indirectly call operating system APIs. For example, the system marks all CALL instructions pointing to sensitive APIs such as CreateFileW, Socket, and RegSetValueEx, as these instructions are fundamental to malicious behaviors such as file creation, network connection, and registry writing. Finally, the system compiles a set of static features and a list marking all dangerous API call instructions.

[0049] Step S103: Generate static code anchor point identifiers based on the static addresses of code instructions in the original code data, and inject monitoring points into the operating system APIs within the preset adaptive sandbox environment based on the static code anchor point identifiers to obtain the target adaptive sandbox environment.

[0050] In step S103, the static address represents the fixed offset or relative virtual address of the code instruction in the original code data file. The static code anchor identifier is a unique and stable identifier created for each identified code instruction with potential behavioral risks, associated with the instruction's static address. The preset adaptive sandbox environment is a pre-configured, isolated virtual execution environment that simulates a real operating system and can dynamically adjust its monitoring strategy according to analysis needs. Monitoring point injection refers to the process of implanting custom monitoring code into the operating system API functions of the sandbox environment. The target adaptive sandbox environment represents the final sandbox environment, modified by monitoring point injection, capable of accurately monitoring specific malicious code samples.

[0051] Specifically, based on the list of code instructions with potential behavioral risks identified in step S102, the system generates a static code anchor identifier for each calling instruction. This identifier can be the relative virtual address (RVA) of the instruction within its code segment, and this address is fixed. Next, the system prepares a preset adaptive sandbox environment. Then, the system performs a monitoring point injection operation: it traverses all operating system APIs associated with the marked calling instructions, such as CreateFileW, and finds the entry point of the CreateFileW function in the corresponding system library file within the sandbox environment, such as kernel32.dll. The system modifies the code at this function entry point to redirect its execution flow to a system preset hook handler. This hook handler is designed to record the current call information before executing the original API function and to associate the static code anchor identifier that triggered the call by querying the call stack. After the system performs this injection operation on all APIs that need to be monitored, the preset sandbox environment is transformed into a target adaptive sandbox environment tailored to the current malicious code sample.

[0052] In one possible implementation, based on static code anchor point identifiers, monitoring points are injected into the operating system APIs within a preset adaptive sandbox environment to obtain the target adaptive sandbox environment. Specifically, this includes steps S1031-S1034, as follows: Step S1031: Traverse the import table of the malicious code sample and extract all imported operating system API functions.

[0053] In step S1031, the import table of the malicious code sample refers to a specific data structure embedded within the executable file format. It details all external functions that the program needs to call from the operating system or other dynamic link libraries during runtime. Extraction represents a parsing process, that is, reading and collecting all referenced function names from this data structure. Operating system API functions represent functions provided by the operating system for applications to call to perform specific system-level tasks, such as the file operation function CreateFileW or the network communication function socket.

[0054] Specifically, the system first parses the file structure of the raw code data obtained in the previous steps. Taking a Windows PE file as an example, the system locates the PE header of the file and then finds the import directory table based on the header information. The system traverses this table, which organizes the imported functions according to different dynamic link libraries, such as kernel32.dll or user32.dll. For each library, the system reads its corresponding import name table or import address table, extracts the names of all operating system API functions declared as needed by the malware sample, and compiles these function names into a list for subsequent monitoring point injection preparation.

[0055] Step S1032: For each operating system API function, set an intercept hook associated with the operating system API function at the entry point of the corresponding API function in the preset adaptive sandbox environment.

[0056] In step S1032, the entry point of the API function represents the starting execution address of the function in memory. When the program calls the function, the CPU's execution flow jumps to this address. An interception hook is a technical mechanism that intercepts calls to a function by inserting a piece of custom code at the function's entry point, thereby enabling the monitoring, modification, or prevention of the call.

[0057] Specifically, for each operating system API function extracted in the previous step, the system locates the actual memory address of that API function—its entry point—within the operating system kernel or related system libraries in the preset adaptive sandbox environment. Then, the system prepares an intercept hook for this API function. This preparation includes allocating a new memory space in the sandbox memory to store a system-generated jump code for monitoring. The goal of this jump code is to gain control over the function call without disrupting the original function call flow.

[0058] Step S1033: Register the static code anchor point identifier associated with the operating system API function as parameter information into the intercept hook to form the target API function injected with the monitoring point.

[0059] In step S1033, the static code anchor identifier refers to a marker extracted from malicious code during the static analysis phase that uniquely identifies a specific code location or feature, such as the memory address of an instruction that initiates an API call. Parameter information represents data passed to a function or module; here, it specifically refers to passing the static code anchor identifier as data to the intercept hook. Registering to the intercept hook refers to the process of associating and binding the static code anchor identifier with the corresponding intercept hook, so that when the hook is triggered, it knows which static code location caused the call. The target API function with the injected monitoring point represents the modified API function, which now contains an intercept hook capable of context-aware monitoring based on the static anchor.

[0060] Specifically, the system queries the associated static code anchor identifiers for each operating system API function for which an intercept hook is to be set. An API function may be called from multiple different locations within malicious code, thus potentially associating with multiple static code anchor identifiers. The system stores this identifier information in a data structure specifically created for the intercept hook of that API. This process is equivalent to registering parameter information with the intercept hook. Thus, when malicious code runs in the sandbox and calls the API, triggering the intercept hook, the monitoring code within the hook can access these registered static code anchor identifiers, thereby precisely associating the current dynamic behavior with a specific line or segment of code within the malicious code, forming a monitoring point with contextual information.

[0061] Step S1034: Based on the preset adaptive sandbox environment, replace and update the target API function to obtain the target adaptive sandbox environment.

[0062] In step S1034, replacement update represents a memory modification operation, i.e., overwriting the original instruction sequence with a new instruction sequence. The target API function refers to the modified function version that has been bound to the intercept hook and static anchor information in step S1033 and is ready to replace the original API. The target adaptive sandbox environment represents the final sandbox environment after all API monitoring point injection operations have been completed; it has been customized for the specific malicious code sample to be analyzed.

[0063] Specifically, after completing the preparation work for all target API functions, the system will perform the final injection operation. For each operating system API function in the list, the system will modify its entry point code in the memory of the preset adaptive sandbox environment. Typically, the system will replace the first few bytes of the function with an unconditional jump instruction, which points to the starting address of the corresponding intercept hook created in step S1032. The original overwritten instruction will be stored inside the intercept hook so that the original API function can be restored and executed after the monitoring logic has finished executing. Once all the API functions to be monitored have completed this replacement and update operation, the entire preset adaptive sandbox environment is transformed into a target adaptive sandbox environment tailored to the current malicious code sample, ready to receive and execute the malicious code sample.

[0064] Step S104: Execute the malicious code sample in the target adaptive sandbox environment for dynamic analysis, generate dynamic behavior data, and detect whether the malicious code sample has sandbox escape behavior during the dynamic analysis process.

[0065] In step S104, execution in the target adaptive sandbox environment refers to loading the malware sample to be analyzed into the isolated environment with customized monitoring points generated in the previous step and running it. Dynamic analysis refers to the technique of understanding the function and intent of a program by actually running it and observing its behavior. Dynamic behavioral data refers to various behavioral records generated by the program during its operation, such as which files were created, which websites were visited, and which registry entries were modified. Sandbox escape behavior refers to various techniques used by malware to identify whether it is running in a sandbox environment and accordingly change its behavior or terminate its operation to evade analysis.

[0066] Specifically, the system loads the raw code data obtained in step S101 into the target adaptive sandbox environment generated in step S103 and initiates its execution. During the execution of the malicious code, whenever it calls an operating system API that has been injected with monitoring points, the execution flow first enters the system's preset hook handler. This handler records detailed information about the API call, including the function name, the passed parameters, and the associated static code anchor identifier. This information together constitutes dynamic behavior data. Simultaneously, throughout the entire dynamic analysis process, the system continuously detects whether sandbox escape behavior exists. For example, the system monitors whether the malicious code attempts to query specific hardware IDs, checks for the existence of virtual machine-specific driver files, or uses time-difference attacks to determine the authenticity of the execution environment. Once such behavior is detected, the system immediately marks it.

[0067] like Figure 2As shown, in one possible implementation, a malicious code sample is executed in the target adaptive sandbox environment for dynamic analysis to generate dynamic behavior data, specifically including steps S201-S210, as follows: Step S201: Introduce the malicious code sample into the target adaptive sandbox environment. The target adaptive sandbox environment is built based on virtualization technology and contains multiple virtual machine images with different configurations to simulate a real application execution environment.

[0068] In step S201, the malicious code sample refers to the executable file or script to be analyzed. The target adaptive sandbox environment represents a customized, isolated execution environment for dynamic analysis. Virtualization technology is a method for creating and managing virtual machines, allowing multiple independent instances of operating systems to run on a single physical hardware. A virtual machine image represents a template file containing a complete operating system and pre-installed software, which can be used by virtualization technology to quickly create new virtual machines. A real application execution environment refers to the computer environment actually used by a regular user, such as a Windows 10 system with office software and a browser installed.

[0069] Specifically, the system will initiate a dynamic analysis process, using the malicious code sample to be analyzed as input for this task, and introducing it into the management framework of the target adaptive sandbox environment. This sandbox environment is a comprehensive analysis platform built on virtualization technology. It maintains a resource library containing multiple virtual machine images with different configurations. These images reproduce diverse real application execution environments by simulating different operating system versions, language environments, and installing different commonly used applications.

[0070] Step S202: Based on the file attribute information of the malicious code sample, determine the target operating system platform of the malicious code sample, and select the base image corresponding to the target operating system platform from the virtual machine image library as the target virtual machine image.

[0071] In step S202, file attribute information refers to metadata embedded within the executable file, such as PE header information, which describes the file type, target platform architecture, etc. The target operating system platform indicates the specific operating system environment targeted by the malicious code during runtime, such as 32-bit Windows 7 or 64-bit Windows 10. The virtual machine image library refers to the collection of various virtual machine images mentioned in step S201. The base image represents a relatively clean, uncustomized standard virtual machine image conforming to a specific operating system platform. The target virtual machine image refers to the specific image selected from the image library, prepared for subsequent customization and analysis tasks.

[0072] Specifically, the system first parses the file format of the malicious code sample to read its file attribute information. For example, for a Windows executable file, the system checks the Machine field in its PE header to determine whether it was compiled for a 32-bit or 64-bit platform, and combines this with other flags to determine the approximate operating system version required. Based on this parsed platform information, the system searches its maintained virtual machine image library for a base image that best matches the target operating system platform. Once selected, this image is designated as the target virtual machine image for this analysis task.

[0073] Step S203: Analyze the import table information of the malicious code sample, identify the dynamic link library files that the malicious code sample depends on, and install the installation software that matches the version of the dynamic link library files in the target virtual machine image.

[0074] In step S203, the import table information refers to a data structure in the executable file that records a list of external functions and their respective library files that the executable depends on at runtime. Dynamic link library files represent modules containing code and data that can be used by multiple programs simultaneously, typically ending in DLL. Installation software refers to installation packages that provide specific dynamic link library files, such as Microsoft's Visual C++ Redistributable Package.

[0075] Specifically, the system will deeply analyze the import table information of the malicious code sample to identify all the dynamic link library files necessary for its operation. In addition to the standard library files provided by the operating system, the system will pay special attention to non-standard library files provided by third-party applications. The system maintains a dependency knowledge base that maps the relationships between dynamic link library files and the specific installation software that provides those files. Based on the identified dependencies, the system will find the corresponding installation software in the software library and automatically install it in the target virtual machine image, thus ensuring that the malicious code will not encounter errors and terminate prematurely due to missing dependencies during subsequent execution.

[0076] Step S204: Perform a security scan on the target virtual machine image to identify system vulnerability data and missing patch data present in the target virtual machine image.

[0077] In step S204, a security scan refers to an automated inspection process used to discover known security vulnerabilities on the target system. The target virtual machine image refers to the virtual machine image installed as required in step S203. System vulnerability data represents a list of exploitable known software vulnerabilities discovered after the scan, typically in the form of CVE numbers. Patch missing data refers to a list of official security updates or patches discovered during the scan that are not yet installed on the target system.

[0078] Specifically, the system will initiate a comprehensive security scan of the target virtual machine image that already has the necessary dependent software installed. This scan process will invoke internally integrated or third-party vulnerability scanning tools, which will compare their extensive vulnerability signature database with the version information of the operating system and various software installed in the target virtual machine image. After the scan is complete, the tool will generate a report detailing all identified system vulnerabilities, as well as information on which critical or recommended security updates are missing.

[0079] Step S205: Adjust the patch level of the target virtual machine image based on system vulnerability data and missing patch data.

[0080] In step S205, adjusting the patch level of the target virtual machine image represents a strategic configuration operation that selectively installs or uninstalls certain security patches based on analysis requirements to set the virtual machine environment to a specific security state.

[0081] Specifically, the system comprehensively analyzes the system vulnerability data and missing patch data obtained in the previous step, and combines this with prior knowledge or threat intelligence about the malicious code sample to determine how to adjust the patch level of the target virtual machine image. This adjustment is not simply about pursuing the highest security level. Instead, if intelligence indicates that the malicious code sample tends to exploit a specific, known system vulnerability, the system will ensure that the vulnerability exists in the target virtual machine image, and may even need to uninstall any installed patches. In this way, the system precisely adjusts the patch level of the target virtual machine image to a state most conducive to triggering and observing the complete malicious code attack behavior.

[0082] Step S206: Based on the adjusted target virtual machine image, create a virtual execution environment for executing malicious code samples, and port the malicious code samples to the virtual execution environment for execution.

[0083] In step S206, the adjusted target virtual machine image refers to the final configured virtual machine template after patch level adjustments. A virtual execution environment (VEX) represents a running, independent virtual machine instance created based on this image; it is the actual execution location of the malicious code. Porting to the VEX refers to the process of copying the malicious code file into the running virtual machine and starting its execution.

[0084] Specifically, the system uses the adjusted target virtual machine image as a base and creates a brand new virtual machine instance through the virtualization management platform. This instance is the virtual execution environment used for this dynamic analysis. To ensure the repeatability of the analysis and the purity of the environment, the creation process typically utilizes snapshot or link cloning techniques, ensuring that each analysis begins in an identical initial environment. After the environment is created, the system copies the malicious code sample file to the file system of the virtual execution environment through a pre-installed agent program in the virtual machine or a file transfer channel between the host machine and the virtual machine. Subsequently, it triggers the execution of the file via remote commands, officially commencing the dynamic analysis.

[0085] Step S207: In the virtual execution environment, capture the behavior information of the malicious code sample calling the operating system API function, and obtain the call parameters and return results based on the interception hook.

[0086] In step S207, behavioral information refers to the event itself where malicious code executes an API call. The intercept hook is monitoring code injected into the API function entry point during the previous preparation phase to intercept function calls. Call parameters represent the input data passed to the function when the malicious code calls the API. The return result represents the output data or status code returned to the caller after the API function has completed execution.

[0087] Specifically, in the virtual execution environment, when a malicious code sample executes and calls any monitored operating system API function, the program's control flow is first captured by a previously set intercept hook. Within the hook code's logic, it first parses and records all parameters of the call from the current thread's stack or registers. After recording, the hook transfers control to the original API function, allowing it to perform its intended function. When the original function finishes execution and is ready to return, control returns to the hook code, at which point the hook captures and records the function's return result. The entire process is imperceptible to the malicious code.

[0088] Step S208: Based on the captured behavioral information and the obtained call parameters and return results, generate multiple intermediate behavior log files that reflect the malicious code sample at different execution stages.

[0089] In step S208, the intermediate behavior log file refers to the raw data log stored in file form, containing detailed API call records. Different execution stages represent different functional periods in the lifecycle of malicious code, such as initialization, persistence, and lateral movement.

[0090] Specifically, the system will format each complete behavioral information captured in the previous step, including the API function name called, detailed call parameters, specific return results, and context information such as the timestamp of the call, the process ID, and the thread ID, into a structured log entry. These entries will be written to one or more intermediate behavioral log files in real time or in batches. The system may divide the logs into different logical segments based on the type of behavior or abrupt changes in the time series to identify the behavior of the malicious code sample at different execution stages, facilitating subsequent contextual analysis.

[0091] Step S209: Perform comprehensive analysis on multiple intermediate behavior log files to extract key behavioral features of the malicious code sample. Key behavioral features include process creation logs, file read / write logs, registry operation logs, and network communication logs.

[0092] In step S209, the comprehensive analysis refers to the process of processing, filtering, and classifying the raw log data. Key behavioral characteristics refer to high-level behavioral descriptions extracted from a large number of low-level API calls, possessing clear malicious intent or representative functions. Process creation logs, file read / write logs, registry operation logs, and network communication logs are several typical categories of key behavioral characteristics.

[0093] Specifically, the system will perform automated post-processing analysis on all generated intermediate behavior log files. By employing preset parsing rules and behavior patterns, the system can filter and aggregate meaningful behaviors from massive API call records. For example, the system will identify all calls to functions such as CreateProcess or ShellExecute and categorize them into process creation logs; identify calls to functions such as CreateFile, WriteFile, and DeleteFile, especially operations on user documents or system files, to form file read / write logs; similarly, it will generate registry operation logs by tracing calls to functions such as RegCreateKeyEx and RegSetValueEx; and it will generate network communication logs by monitoring calls to network-related functions such as socket, connect, and send. This step transforms the raw data into high-level, understandable key behaviors.

[0094] Step S210: Based on key behavioral features, construct a dynamic behavioral feature vector of the malicious code sample and output it as dynamic behavioral data.

[0095] In step S210, the dynamic behavior feature vector represents a mathematical representation that transforms discrete key behavioral features into a numerical, fixed-length array, facilitating processing by machine learning models. The dynamic behavior data is used to represent the final, structured result of this dynamic analysis, summarizing the core behaviors of the samples.

[0096] Specifically, the system will quantify and encode the various key behavioral features extracted in the previous step to construct a dynamic behavioral feature vector. This process includes counting the frequency of various key behaviors, such as how many new processes were created, how many registry entries were modified, and how many different remote addresses were connected to; it also includes Boolean encoding of the presence or absence of certain key behaviors, such as whether a startup item was created or whether a volume shadow copy was deleted. All these quantified and encoded values ​​are arranged and combined to form a fixed-dimensional vector. This vector is a highly condensed and digital description of the dynamic behavior of the malicious code sample, serving as the final dynamic behavioral data output.

[0097] Step S105: If it is determined that a malicious code sample exhibits sandbox escape behavior, then defenses are implemented against the sandbox escape behavior.

[0098] In step S105, defending against sandbox escape behavior means that when the system detects that malicious code is attempting to escape from the sandbox, it takes proactive countermeasures to deceive the malicious code into believing that it is running on a real physical machine, thereby inducing it to continue executing subsequent malicious behaviors.

[0099] Specifically, when the detection module in step S104 reports a sandbox escape attempt, the system activates the corresponding defense mechanism. This defense is closely integrated with API monitoring. For example, if malicious code calls an API to query the system username, and the default username for the sandbox is "SandboxUser," this might trigger its alert. After detecting this API call, the system's hook handler will intercept the call and return a fake, seemingly normal username, such as "Admin" or "John-PC," instead of passing the request to the real sandbox operating system. Similarly, if malicious code attempts to check disk size to determine if it is a virtual machine with limited space, the system can intercept the relevant API call and return a fake, large disk space value. Through this proactive deception, the system effectively defends against sandbox escape behavior, ensuring that dynamic analysis can capture deeper and more realistic malicious behavior.

[0100] In one possible implementation, if it is determined that a malicious code sample exhibits sandbox escape behavior, then defense against the sandbox escape behavior is implemented, specifically including steps S1051-S1054, as follows: Step S1051: In the target adaptive sandbox environment, dynamically modify the sandbox environment parameters. The dynamic modification of the sandbox environment parameters includes randomly generating the number of virtual CPU cores, modifying the simulated value of virtual disk capacity, and forging registry entries of commonly used software. In step S1051, the target adaptive sandbox environment refers to a dynamically configurable isolated virtual environment used to execute and analyze malicious code. Dynamically modifying sandbox environment parameters means actively and non-fixedly changing various system parameters presented to the internal program by the virtual environment before or during analysis. Randomly generating the number of virtual CPU cores means setting the number of processor cores reported by the virtual machine to the operating system to a randomly selected value consistent with common physical machine configurations, such as 2, 4, 6, or 8. Modifying the virtual disk capacity simulation value means adjusting the total hard disk space reported by the virtual machine to the operating system to resemble the actual hard disk capacity of a typical user, such as 512GB or 1TB. Forging registry entries for common software means creating entries in the virtual machine's registry that mimic the traces left after installing common applications such as Microsoft Office and Adobe Reader.

[0101] Specifically, before launching the virtual execution environment for analysis, the system performs a series of deceptive anti-probe configurations. This process doesn't use a fixed template but introduces a dynamic and randomized strategy. The system randomly selects a value from a preset range that matches real-world hardware configurations to represent the number of virtual CPU cores for this analysis. Similarly, it selects a common disk size as the simulated virtual disk capacity. Furthermore, the system runs pre-built scripts to create and populate key-value pairs in the registry to forge installation information and usage traces of commonly used office software, browsers, or design software. These dynamically modified sandbox environment parameters aim to make the sandbox environment as close as possible to a real, long-used personal computer, thus misleading malicious code attempting to identify the environment by detecting typical sandbox characteristics.

[0102] Step S1052: Monitor whether the malicious code sample exhibits environment probing behavior during execution; In step S1052, monitoring refers to the continuous and proactive observation and recording of the behavior of a specific object through technical means. The execution process of a malicious code sample refers to the entire time period from when the malicious code is started and runs until the end of its lifecycle. Environment probing behavior refers to a series of specific operations performed by the malicious code, the purpose of which is to collect hardware and software information of the current operating environment to determine whether it is in an analyzed sandbox or virtualized environment.

[0103] Specifically, when a malicious code sample begins running in the configured virtual execution environment, the system's built-in monitoring module is activated simultaneously. This module, through previously deployed API interception hooks or other kernel-level monitoring technologies, closely monitors every system call and critical operation of the malicious code sample and all its created child processes. The monitoring focuses on behaviors related to querying environment information. This includes, but is not limited to, querying CPU information, checking disk space, reading specific hardware device identifiers, scanning the list of currently running processes to find processes for analysis tools or virtual machine tools, and querying specific registry keys related to virtual machine vendors. All these suspicious query actions are identified by the system and logged as potential environment probing behaviors.

[0104] Step S1053: If the malicious code sample is detected to be probing the environment, compare the system information obtained by the malicious code sample with the sandbox environment parameters to determine whether the malicious code sample has the risk of escaping from the sandbox. In step S1053, the environment probing behavior is the triggering event that initiates the judgment logic of this step. Comparison refers to a process of comparison and verification. The system information obtained by the malicious code sample refers to the result data obtained by the malicious code after performing the environment probing behavior, such as the hardware model string or the number of CPU cores it reads. Sandbox environment parameters here specifically refer to known characteristic parameters that can expose the sandbox identity, such as the MAC address prefix unique to virtual machines, specific driver file names, or hardware IDs. Sandbox escape risk is used to indicate a dangerous state where, after judgment, it is confirmed that the malicious code has identified the sandbox environment and may therefore change its behavior.

[0105] Specifically, once the system detects that a malicious code sample is performing environment probing behavior in step S1052, the analysis engine immediately enters the judgment process. The system compares the information that the malicious code attempts to query or obtain with an internally maintained knowledge base containing a large number of known sandbox environment characteristics. For example, if the malicious code attempts to read the system BIOS version information, and the obtained information contains strings such as "VMware" or "VirtualBox", the system will determine this behavior as a successful sandbox environment identification. Or, if the malicious code attempts to probe whether the underlying layer is a virtual machine monitor through specific I / O port communication, even if this behavior does not return an explicit string, this probing behavior itself is sufficient for the system to determine that it has the intention of sandbox escape. When the comparison result matches any rule in the knowledge base, the system confirms that the malicious code sample has a sandbox escape risk.

[0106] Step S1054: If it is determined that the malicious code sample has a risk of sandbox escape, the sandbox environment is restored to its initial state for defense, and the escape attempt behavior is marked as a high-risk behavior in the dynamic behavior data.

[0107] In step S1054, sandbox escape risk is a prerequisite for implementing the defensive measures in this step. Restoring the sandbox environment to its initial state means immediately terminating the current virtual machine instance and discarding all changes made during its operation, ensuring that no subsequent actions by the malicious code can occur. Defense refers to preventing the malicious code from executing its actual malicious payload or disrupting the sandbox environment through the aforementioned termination actions. Dynamic behavior data is the final summary report generated from the entire dynamic analysis process. Marking escape attempts as high-risk behavior means that the final analysis report explicitly and prominently indicates that the sample's sandbox escape attempt was detected and its risk level is rated as high.

[0108] Specifically, upon determining that a malicious code sample poses a sandbox escape risk, the system immediately takes proactive defensive measures. The analysis and control system sends a command to the virtualization management platform to force shutdown or destroy the current virtual machine instance. Since the virtual machine instance was created based on a snapshot, destroying it will not affect the original, clean virtual machine image. The purpose of this operation is to terminate the execution process before the malicious code changes its behavior due to sandbox detection, thereby effectively preventing subsequent counter-attacks such as denial of execution, displaying false behavior, or attacking the sandbox software itself. Simultaneously with terminating the analysis, the system adds a special marker to the dynamic behavior data report generated for this task, detailing the type of escape attempt detected, and automatically upgrades the overall threat rating of the sample to "high risk" to alert security analysts that this sample possesses anti-analysis capabilities and requires more advanced handling methods.

[0109] Step S106: Match and query static features and dynamic behavior data with external threat databases to obtain comprehensive source tracing results associated with malicious code samples.

[0110] In step S106, the external threat database refers to a continuously updated database that stores a large amount of known malware information and network threat intelligence, including information such as the hash values ​​of malicious files, malicious domain names, and the tactics and techniques of attacker organizations. Matching query refers to the process of comparing the data collected in this analysis with records in the external threat database to find correlations and matches. The comprehensive source tracing result represents the final analysis report that combines static, dynamic, and external threat intelligence. It not only indicates the maliciousness of the sample but may also include its malware family, related attack activities, and attacker background information.

[0111] Specifically, after completing the dynamic analysis, the system integrates all the data obtained in this analysis. This data includes static features extracted in step S102, such as the MD5 and SHA256 hash values ​​of files and suspicious strings; and dynamic behavioral data generated in step S104, such as the IP addresses the sample attempted to connect to during runtime, the filenames created, and the registry keys modified. The system uses this data as query conditions to initiate matching queries against external threat databases. For example, the system uses the file's hash value to query whether there are matching known malware records in the database, and uses the accessed IP addresses to query whether they are known command and control server addresses. The system summarizes and correlates all the queried matching information to finally generate a comprehensive source tracing result. This result clearly indicates which known malware family the malicious code sample belongs to, and provides its attack targets, propagation methods, and related security recommendations.

[0112] In one possible implementation, static feature and dynamic behavior data are matched and queried against an external threat database to obtain a comprehensive tracing result associated with the malicious code sample. Specifically, this includes steps S1061-S1065, as follows: Step S1061: Extract multiple key data from static features and dynamic behavior data.

[0113] In step S1061, static features refer to data obtained by analyzing the malicious code sample file itself without executing it, such as the file's hash value, internally contained strings, and a list of imported function libraries. Dynamic behavioral data represents a series of behavioral records generated after the malicious code sample actually runs in the sandbox environment, such as files it creates, registry keys it modifies, and network connections it initiates. Key data refers to core information fragments with high identifiability and traceability value selected from massive static and dynamic behavioral data, such as a unique mutex name, a domain name or IP address used for command and control, or a special code signing certificate.

[0114] Specifically, after completing static and dynamic behavior analysis of the malicious code sample, the system initiates a data extraction module. This module automatically filters the two generated data reports based on preset rules or algorithms. It extracts file hash values ​​such as MD5, SHA1, and SHA256 from static features, embedded URLs, IP addresses, email addresses, and PDB path strings that may expose developer information from the files. Simultaneously, it extracts from dynamic behavior data the domain names and IP addresses actually connected to by the sample during operation, the hash values ​​of downloaded or released files, the names of scheduled tasks or services created for persistence, and special named pipes used for inter-process communication. This extracted information is considered the most important clue to locating the source and intent of the malicious code, collectively forming a key data set for subsequent queries.

[0115] Step S1062: Use the key data as a query index, compare it with the external threat database to obtain intelligence information, and determine whether a historical attack event record associated with the key data is matched in the external threat database.

[0116] In step S1062, the key data is the input information for this step. The query index represents formatting the key data into entries suitable for searching in a database or search engine. An external threat database refers to a large database maintained by security vendors or the community that stores a large amount of information on known malware, attack activities, and threat organization intelligence. Intelligence information is used to represent contextual background information about a specific key data obtained from the external threat database, such as the geographical location of an IP address, the registration information of a domain name, or the popularity of a file hash. Historical attack event records refer to complete reports found in the external threat database that describe a past cyberattack activity in detail, and that include metrics matching the key data currently being queried.

[0117] Specifically, the system iterates through each key data point extracted in the previous step. It uses this data as a query index to initiate API query requests to multiple configured external threat databases. For example, the system might submit an IP address to a threat intelligence platform, which might return intelligence information such as the IP's malware rating, country of origin, and whether it's a known botnet node. The system analyzes all query results and makes a core judgment: whether the returned information contains structured, detailed reports that identify specific attack activities or threat groups. If a domain query returns not only a "malicious" label but also a report link titled "APT-C-35 group uses this domain for spear-phishing attacks," then the system determines that a historical attack event record has been matched.

[0118] Step S1063: If a historical attack event record associated with the key data is matched in the external threat database, then an attack chain graph corresponding to the malicious code sample is constructed based on the historical attack event record.

[0119] In step S1063, the historical attack event record is a prerequisite for initiating this step. Construction represents a process of modeling and organizing based on existing information. The attack chain graph corresponding to the malware sample refers to a structured, visual model that depicts the various stages and techniques used in the entire attack process, from the initial intrusion point to the final attack target. This model is tailored to the malware sample being analyzed.

[0120] Specifically, if the system successfully matches a historical attack event record associated with critical data in the external threat database, it will further parse this record. These records typically contain the tactics, techniques, and processes used by the attackers, also known as TTPs, often following standard frameworks such as MITRE ATT&CK. The system automatically extracts this TTP information, such as descriptions in historical events like "initial access via phishing emails," "performing fileless attacks using PowerShell," and "achieving persistence using WMI event subscriptions." Then, the system uses these phased attack steps as nodes and connects them according to the logical order of the attack, forming a directed graph. This graph is the attack chain graph, which clearly shows which stage of the attack process the current malware sample is likely to belong to, and what its possible preceding and subsequent steps are.

[0121] Step S1064: If no historical attack event record associated with the key data is found in the external threat database, the malicious code sample is marked as an unknown attack event, and the basic source information corresponding to the malicious code sample is queried through external channels based on the key data.

[0122] In step S1064, the failure to find a historical attack event record associated with the critical data in the external threat database is the trigger condition for executing this step. Marking a malicious code sample as an unknown attack event indicates that the system determines the current sample may be a completely new threat that has not yet been recorded and named in detail. External channels refer to public information query services other than professional, structured external threat databases. Basic source tracing information is used to represent the original registration information or related relationship data about the critical data obtained through these external channels, such as domain name registrant information or historical IP address resolution records.

[0123] Specifically, if the system queries all key data but finds no related detailed attack event reports in any external threat database, it will proceed to this processing branch. First, it will label the sample as an "unknown attack event" or "new threat" in its analysis conclusions. Next, the system will initiate a secondary attribution process. It will utilize more common external channels, such as submitting the malicious domain to a WHOIS query service to obtain its registrar, registration date, and contact email address. It will also submit the malicious IP address to a passive DNS replication service to query which other domains have historically resolved to that IP address. The raw data returned by these queries, such as the domain owner's email address or a list of related domains, while not directly depicting the full picture of the attack, provides the most basic clues, which together constitute the foundational attribution information.

[0124] Step S1065: Integrate the attack chain map or basic attribution information with intelligence information to obtain a comprehensive attribution result.

[0125] In step S1065, the attack chain map is a product of step S1063. Basic source tracing information is a product of step S1064. Intelligence information is the background information generally obtained in step S1062. Integration means summarizing, correlating, and organizing information from different sources and of different types to form a unified and comprehensive report. The comprehensive source tracing result refers to the final generated complete analytical conclusions containing the source, purpose, background, and correlation of the malicious code sample.

[0126] Specifically, the system enters the final report generation stage. It determines whether step S1063 or S1064 was executed and obtains the corresponding results. If an attack chain graph is obtained, the system uses this graph as its core content and adds all relevant intelligence information obtained in step S1062, such as IP geolocation and file reputation ratings, as supplementary information to each node of the graph or the entire report. If basic attribution information is obtained, the system formats and displays this raw information, such as WHOIS records and passive DNS data, and similarly adds the intelligence information obtained in step S1062. Finally, the system outputs a structured, comprehensive attribution result. This result, whether containing a detailed attack chain or basic clues, provides security analysts with the most comprehensive and in-depth background profile of this malware sample.

[0127] The following describes an intelligent malware analysis system according to an embodiment of the present invention from the perspective of hardware processing. Please refer to [link / reference needed]. Figure 3 This is a schematic diagram of the structure of an intelligent malicious code analysis system in an embodiment of this application.

[0128] It should be noted that, Figure 3 The structure of the intelligent malware analysis system shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of the present invention.

[0129] like Figure 3 As shown, an intelligent malware analysis system includes a Central Processing Unit (CPU) 301, which can perform various appropriate actions and processes based on programs stored in Read-Only Memory (ROM) 302 or programs loaded from storage portion 308 into Random Access Memory (RAM) 303, such as executing the methods described in the above embodiments. The RAM 303 also stores various programs and data required for system operation. The CPU 301, ROM 302, and RAM 303 are interconnected via a bus 304. An Input / Output (I / O) interface 305 is also connected to the bus 304.

[0130] The following components are connected to I / O interface 305: input section 306 including audio input devices, push-button switches, etc.; output section 307 including a liquid crystal display (LCD) and audio output devices, indicator lights, etc.; storage section 308 including a hard disk, etc.; and communication section 309 including a network interface card such as a LAN (Local Area Network) card, modem, etc. Communication section 309 performs communication processing via a network such as the Internet. Drive 310 is also connected to I / O interface 305 as needed. Removable media 311, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 310 as needed so that computer programs read from them can be installed into storage section 308 as needed.

[0131] In particular, according to embodiments of the present invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of the present invention include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing computer programs for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 309, and / or installed from removable medium 311. When the computer program is executed by central processing unit (CPU) 301, it performs the various functions defined in the present invention.

[0132] It should be noted that specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this invention, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0133] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. Each block in a flowchart or block diagram may represent a module, segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those shown in the drawings.

[0134] Specifically, the intelligent malicious code analysis system of this embodiment includes a processor and a memory. The memory stores a computer program. When the computer program is executed by the processor, it implements the intelligent malicious code analysis method provided in the above embodiment.

[0135] In another aspect, the present invention also provides a computer-readable storage medium, which may be included in the intelligent malware analysis system described in the above embodiments; or it may exist independently and not assembled into the intelligent malware analysis system. The storage medium carries one or more computer programs, which, when executed by a processor of the intelligent malware analysis system, enable the intelligent malware analysis system to implement the intelligent malware analysis method based on IoT data encryption transmission provided in the above embodiments.

Claims

1. A method for intelligent malware analysis, characterized in that, The method includes: Obtain the malicious code sample to be analyzed, and perform packing detection and automatic unpacking on the malicious code sample to obtain the original code data; Static analysis is performed on the original code data to obtain the static characteristics of the malicious code sample and code instructions with potential behavioral risks. The code instructions are call instructions that directly or indirectly call the operating system API. Based on the static address in the original code data, a static code anchor point identifier is generated, and based on the static code anchor point identifier, monitoring points are injected into the operating system API in the preset adaptive sandbox environment to obtain the target adaptive sandbox environment. The malicious code sample is executed in the target adaptive sandbox environment for dynamic analysis, generating dynamic behavior data, and during the dynamic analysis process, it is detected whether the malicious code sample exhibits sandbox escape behavior. If it is determined that the malicious code sample exhibits the sandbox escape behavior, then defenses are implemented against the sandbox escape behavior; The static features and dynamic behavior data are matched and queried with an external threat database to obtain a comprehensive source tracing result associated with the malicious code sample.

2. The method according to claim 1, characterized in that, The process of detecting and automatically unpacking the malicious code sample to obtain the original code data specifically includes: The malicious code sample is hashed, and the sample is deduplicated by comparing the hash value with an existing sample library. The file format of the deduplicated malicious code sample is identified to determine the file type of the malicious code sample. Based on the file type, a machine learning-based intelligent packer detection model is used to detect packing on the malicious code sample. If the malicious code sample is detected to be protected by a packer, then according to the identified packer method, the corresponding unpacker engine is selected to unpack the malicious code sample and obtain the unpacked original code data. If the malicious code sample is detected to be unprotected by a packer, the file data of the malicious code sample is output as the original code data.

3. The method according to claim 1, characterized in that, The step of injecting monitoring points into the operating system APIs within the preset adaptive sandbox environment based on the static code anchor point identifier to obtain the target adaptive sandbox environment specifically includes: Traverse the import table of the malicious code sample and extract all imported operating system API functions; For each of the operating system API functions, an interception hook associated with the operating system API function is set at the entry point of the corresponding API function in the preset adaptive sandbox environment; The static code anchor point identifier associated with the operating system API function is registered as parameter information into the interception hook, forming a target API function injected with the monitoring point; Based on the preset adaptive sandbox environment, the target API function is replaced and updated to obtain the target adaptive sandbox environment.

4. The method according to claim 3, characterized in that, The step of executing the malicious code sample in the target adaptive sandbox environment for dynamic analysis and generating dynamic behavior data specifically includes: The malicious code sample is introduced into a target adaptive sandbox environment, which is built based on virtualization technology and contains multiple virtual machine images with different configurations to simulate a real application execution environment. In the target adaptive sandbox environment, a target virtual machine image compatible with the malware sample is selected, and the system parameters of the target virtual machine image are adjusted according to the characteristics of the malware sample. Based on the adjusted target virtual machine image, a virtual execution environment is created for executing the malicious code sample, and the malicious code sample is ported to the virtual execution environment for execution; In the virtual execution environment, the behavior information of the malicious code sample calling operating system API functions is captured, and the call parameters and return results are obtained based on the interception hook; Based on the captured behavioral information and the obtained call parameters and return results, multiple intermediate behavior log files reflecting the malicious code sample at different execution stages are generated; A comprehensive analysis of multiple intermediate behavior log files is performed to extract key behavioral features of the malicious code sample. These key behavioral features include process creation logs, file read / write logs, registry operation logs, and network communication logs. Based on the key behavioral characteristics, a dynamic behavioral feature vector of the malicious code sample is constructed and output as the dynamic behavioral data.

5. The method according to claim 4, characterized in that, The system parameters include installed software and patch levels. The step of selecting a target virtual machine image compatible with the malware sample in the target adaptive sandbox environment and adjusting the system parameters of the target virtual machine image according to the characteristics of the malware sample specifically includes: Based on the file attribute information of the malicious code sample, the target operating system platform of the malicious code sample is determined, and a base image corresponding to the target operating system platform is selected from the virtual machine image library as the target virtual machine image; Analyze the import table information of the malicious code sample, identify the dynamic link library files that the malicious code sample depends on, and install installation software that matches the version of the dynamic link library files in the target virtual machine image; A security scan is performed on the target virtual machine image to identify system vulnerability data and missing patch data present in the target virtual machine image; Adjust the patch level of the target virtual machine image based on the system vulnerability data and the missing patch data.

6. The method according to claim 1, characterized in that, The step of matching and querying the static features and dynamic behavior data with an external threat database to obtain a comprehensive source tracing result associated with the malicious code sample specifically includes: Extract multiple key data points from the static features and the dynamic behavior data; The key data is used as a query index and compared with the external threat database to obtain intelligence information, and it is determined whether a historical attack event record associated with the key data is matched in the external threat database. If a historical attack event record associated with the key data is matched in the external threat database, an attack chain graph corresponding to the malicious code sample is constructed based on the historical attack event record. If no historical attack event record associated with the key data is found in the external threat database, the malicious code sample is marked as an unknown attack event, and the basic source tracing information corresponding to the malicious code sample is queried through external channels based on the key data. The attack chain map or the basic attribution information is integrated with the intelligence information to obtain the comprehensive attribution result.

7. The method according to claim 1, characterized in that, If it is determined that the malicious code sample exhibits sandbox escape behavior, then defense against the sandbox escape behavior is implemented, specifically including: In the target adaptive sandbox environment, the sandbox environment parameters are dynamically modified, including randomly generating the number of virtual CPU cores, modifying the simulated value of virtual disk capacity, and forging registry entries of commonly used software. Monitor whether the malicious code sample engages in environmental probing behavior during execution; If the malicious code sample is detected to be engaging in environmental probing behavior, the system information obtained by the malicious code sample is compared with the sandbox environment parameters to determine whether the malicious code sample has a risk of escaping from the sandbox. If it is determined that the malicious code sample poses a risk of sandbox escape, the sandbox environment will be restored to its initial state for defense, and the escape attempt behavior will be marked as a high-risk behavior in the dynamic behavior data.

8. An intelligent malware analysis system, characterized in that, The intelligent malicious code analysis system includes: one or more processors and a memory; the memory is coupled to the one or more processors, the memory is used to store computer program code, the computer program code including computer instructions, and the one or more processors call the computer instructions to cause the intelligent malicious code analysis system to perform the method as described in any one of claims 1-7.

9. A computer-readable storage medium comprising instructions, characterized in that, When the instruction is executed on the intelligent malicious code analysis system, the intelligent malicious code analysis system performs the method as described in any one of claims 1-7.

10. A computer program product, characterized in that, When the computer program product is run on the intelligent malicious code analysis system, the intelligent malicious code analysis system performs the method as described in any one of claims 1-7.

Images