A method and device for detecting and identifying malicious sample delay code

Abstract

The application discloses a detection and identification method and device for malicious sample delay code, and relates to the technical field of malicious code detection. The method comprises the following steps: running target code, obtaining an end address and a number of running instructions; calculating an execution progress according to the number of running instructions and the number of instructions run by the target code within a specified time; finding a maximum times loop in a sub-process where the end address is located, and checking whether there is a delay call in the maximum times loop according to loop entry and exit addresses of the maximum times loop; and obtaining a detection and identification result based on the execution progress and whether there is a delay call in the maximum times loop. The application has high effectiveness, wide application range, and realizes positioning of specific addresses of all delay codes in a malicious sample file, improves actual effect of malicious code analysis, and enhances the ability of a sandbox and other dynamic environments to analyze malicious samples.

Description

Technical Field

[0001] The present invention belongs to the technical field of malicious code detection, and relates to a method for detecting and identifying a specific type of malicious code, and in particular to a method and device for detecting and identifying delayed codes of malicious samples. Background Art

[0002] Malicious code identification and detection is a crucial component of system and software security, and a research area that has seen a continuous battle between attackers and defenders in recent years, with ongoing technological advancements. Advances in malicious code analysis, particularly dynamic analysis techniques like sandboxes, have significantly improved the efficiency of malicious code feature recognition and classification.

[0003] However, to enhance the stealth and diversity of their malicious code, malware authors have begun developing techniques to counter or evade sandbox analysis. This type of malware is known as evasive malware. Evasive malware uses techniques such as anti-debugging, runtime environment detection, mimicking normal system behavior, imitating user activity patterns, and traffic obfuscation to disrupt sandbox analysis, leading to misjudgments and the ability to slip through. Specifically, the malware may exhibit no malicious behavior during analysis, deliberately mimic the behavior of normal processes, or forcefully exit or terminate itself during dynamic analysis. Therefore, the emergence and prevalence of evasive malware poses significant challenges to malware analysts.

[0004] Stalling code is a highly effective evasive technique used by many malware authors. As the name suggests, stalling code is designed to stall for time. Due to the large number of malicious samples, the analysis time available for each sample in a sandbox is very limited, typically only a few minutes. Consequently, malware authors design stalling code to delay the execution of the malicious code for periods ranging from minutes to hours. As a result, the malicious code, when running in the sandbox, will only continuously execute the stalling code, thereby appearing completely harmless, thereby deceiving the sandbox's judgment and leading analysts to incorrect conclusions.

[0005] Over time, the delay code itself has also evolved and improved. Initially and most simply, delay code utilized sleep calls, which put the program to sleep for a period of time to evade analysis by the sandbox for malicious code. Examples of this technique include the DUQU Trojan and the Kelihos botnet. However, many sandboxes now have detection and patching for sleep calls, and upon finding a useless sleep call, the sandbox simply skips it or modifies it to a NOP instruction, thus rendering the sleep ineffective.

[0006] In addition to sleep calls, malicious code authors more often use custom delay code to implement delay functions, thus improving the concealment of the malicious code itself. Malicious code authors generally choose instructions that have poor simulation effects or system calls that take longer to execute in a sandbox than on a real machine to widen the feature difference of the sandbox environment, and set a loop with a large number of times to further enhance the delay effect. For example, the custom delay code of the spyware Rombertik writes nearly 960M bytes of garbage data into memory to confuse the sandbox.

[0007] There aren't many detection methods for custom-constructed, time-stall malicious code. The HASTEN framework, proposed by Kolbitsch et al. (Kolbitsch C, Kirda E, Kruegel C. The power of procrastination: detection and mitigation of execution-stalling malicious code [C] / / Proceedings of the 18th ACM conference on Computer and communications security. 2011: 285-296.), can be considered an early exploration of identifying and remediating time-stall malicious code. HASTEN normally operates in monitoring mode. When encountering a sample with an abnormal API call, it switches to passive mode to record the addresses of executed instructions. Using these addresses, it constructs a partial control flow graph, identifies loops within it, and whitelists them. By adjusting the monitoring environment's configuration to limit detailed recording of whitelisted code areas, the impact of time-stall malicious code can be mitigated. The stall code recognition method proposed by Chou You et al. (You C, Pang J, Zhang Y, et al. An approach to detect malicious behaviors by evading stalling code [M]. Telkomnika, 2012.) focuses on identifying custom stall code with loop characteristics. First, they obtain a trace file from a sample run. Then, they identify suspicious code regions in the trace file where the loop structure has a certain size and contains time-consuming instructions, and determine them as stall code loops. Chih-Hung Lin et al. (Lin CH, Pao HK, Liao J W. Efficient dynamic malware analysis using virtual time control mechanics [J]. Computers & Security, 2018, 73: 359-373.) proposed the VTCSandbox, which uses the Virtual Time Controller (VTC) in Xen to accelerate the time inside the sandbox, thereby improving the efficiency of the sandbox when analyzing each sample. This achievement can be used to patch the anti-sandbox detection technology set around the sleep call, but malicious code may discover the existence of the sandbox by detecting the difference between the internal and external clocks of the virtual machine, or use custom constructed delay code to take targeted evasion measures against the VTCSandbox.Jeffrey Barnett (Barnett JA hierarchical temporalmemory sequence classifier for streaming data[J].2020.) proposed a new classifier called the Hierarchical Temporal Memory Sequence Classifier (HTM Sequence Classifier). This achievement originally used the HTM algorithm to remove abnormal information such as noise contained in the data when classifying the data stream. However, the author discovered an additional side effect during the analysis. That is, when analyzing data streams containing delay codes, the accuracy of the HTM classifier's analysis of the flag values ​​of the EFLAGS register is different from that of data streams that do not contain delay codes. The author believes that this difference can help identify delay codes faster and more accurately.

[0008] In contrast, custom constructed delay code is also one of the limitations of many malicious code detection systems. For example, the DRAKVUF dynamic monitoring system proposed by Lengyel et al. (Lengyel TK, Maresca S, Payne BD, et al. Scalability, fidelity and stealth in the drakvuf dynamic malware analysis system [C] / / Proceedings of the 30th Annual Computer Security Applications Conference. 2014: 386-395.) cannot detect malicious samples with a delay function; the bare metal analysis system BARECLOUD proposed by Kirat et al. (Kirat D, Vigna G, Kruegel C. Barecloud: bare-metal analysis-based evasive malware detection [C] / / 23rd {USENIX} Security Symposium ({USENIX} Security 14). 2014: 287-301.) cannot detect the presence of delay code in samples because it sacrifices monitoring capabilities in exchange for its own transparency; Peidai Xie et al. (Xie P, Lu X, Su J, et al. IPanda: A comprehensive malware iPanda, a comprehensive malware detection tool proposed by [C] / / The International Conference on Information Networking 2013 (ICOIN). IEEE, 2013: 481-486.), has a module called DEAT specifically for detecting evasive malware, but currently does not implement the detection of delayed code. Kawayoka et al. (Kawakoya Y, Iwamura M, Shioji E, et al. Api chaser: Anti-analysis resistant malware analyzer [C] / / International Workshop on Recent Advances in Intrusion Detection. Springer, 2013: 123-143.) proposed API Chaser, an API monitoring and analysis framework with anti-malware code analysis capabilities, but also did not take delayed code identification into consideration.It can be seen that the widespread use of delay codes in malicious codes poses a considerable challenge to security analysts.

[0009] Custom constructed delay codes account for a larger proportion of evasive malware and are more prevalent. Given their widespread distribution and difficulty in detection, developing a technique to precisely locate custom constructed delay codes is crucial for malware detection and behavioral signature extraction, and holds irreplaceable research value. Summary of the Invention

[0010] The present invention discloses a method and device for detecting and identifying delay codes in malicious samples, which detect and identify delay codes in malicious samples and locate the actual position of a custom constructed delay code in a delayed malicious sample. Specifically, the technical solution of the present invention takes the malicious sample to be detected as input and outputs the execution progress of the sample and a list of the delay code addresses contained therein.

[0011] The technical solution adopted in the present invention is as follows:

[0012] A method for detecting and identifying malicious sample delay codes, comprising the following steps:

[0013] Run the target code and obtain the end address and the number of instructions run;

[0014] Calculating the execution progress based on the number of instructions executed and the number of instructions executed by the target code within a specified time;

[0015] Find the maximum number of loops in the sub-process where the end address is located, and check whether there is a delayed call in the maximum number of loops based on the loop entry and exit addresses of the maximum number of loops;

[0016] Based on the execution progress and whether there is a delayed call in the maximum number of cycles, a detection and recognition result is obtained.

[0017] Furthermore, the obtaining of the end address and the number of executed instructions includes:

[0018] 1) Modify the source code of the Cuckoo sandbox based on the interface of the custom analysis sample;

[0019] 2) Set the parameter configuration for the target code to run;

[0020] 3) Based on the modified source code and the parameter configuration, write a Cuckoo custom analysis handler to obtain the end address and number of instructions generated when the target code is running in the sandbox.

[0021] Furthermore, when obtaining the end address and the number of executed instructions, library functions are not counted.

[0022] Furthermore, the calculation of the sample execution progress includes: taking the number of instructions executed by the target code within a specified time as a numerator, and taking the number of executed instructions as a denominator for calculation.

[0023] Furthermore, obtaining the detection and recognition results includes:

[0024] When the execution progress is lower than a set threshold and there are delayed calls within the maximum number of cycles, the target code is a malicious delay code;

[0025] or,

[0026] When the execution progress is not lower than the set threshold, or there is no extremely large loop in the sub-process where the end address is located, or there is no delayed call in the extremely large loop, the target code is a non-malicious delayed code.

[0027] Furthermore, the conditional jump instruction address of the maximum number of cycles is obtained, wherein the conditional jump instruction address is used to point out the patchable position of the delay code and guide the safe patching work of the delay code.

[0028] Furthermore, the detection and identification method further includes:

[0029] 1) Inside the delay loop or elsewhere in the same sub-process as the delay loop, obtain a variable associated with the delay loop and record the address of the variable;

[0030] 2) constructing a delay code address list based on the address of the variable;

[0031] 3) Output the execution progress and delay code address list.

[0032] Furthermore, the detection and identification method further includes:

[0033] 1) When detecting multiple target codes, the directory samples storing the target codes is used as input;

[0034] 2) Set the maximum number of target codes to be analyzed once;

[0035] 3) Through batch mode, malicious sample delayed code detection is performed on multiple target codes at the same time.

[0036] A storage medium stores a computer program, wherein the computer program is configured to execute any of the above methods when running.

[0037] An electronic device, characterized in that it includes a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to execute any of the above methods.

[0038] Beneficial effects of the present invention:

[0039] This method proposes a detection and identification method for custom constructed delay codes with high effectiveness and wide applicability, and realizes the function of locating the specific addresses of all delay codes in malicious sample files. Experiments show that this method can detect about 32.8% of delay samples for the malicious sample sets received by Qi'anxin Sandbox and VirusTotal in 2020, with an identification accuracy rate of about 95.4%, only a small number of false positives, and no missed reports. The screening method and identification method adopted by the present invention have higher effectiveness and a wider range of applicability compared to the existing open sandbox detection system. Not only can it effectively locate the delay code, but it can also use this as a basis to guide the sandbox to patch the delay code in the correct position, so that the malicious sample reveals more malicious behavior, improves the actual effect of malicious code analysis, and enhances the ability of dynamic environments such as sandboxes to analyze malicious samples. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] Figure 1 This is a diagram of the delayed code detection system architecture of the present invention;

[0041] Figure 2 This is a flow chart of the main information collection program of the present invention;

[0042] Figure 3 This is a flow chart of the main detection and identification program of the present invention;

[0043] Figure 4 This is a flow chart of the delayed code detection and identification method of the present invention. DETAILED DESCRIPTION

[0044] The present invention is described in further detail below with reference to the accompanying drawings.

[0045] The system architecture of the present invention is as follows Figure 1 The illustrated system consists of two parts: an information collection module based on the Cuckoo sandbox and a detection and identification module based on IDA Pro. The information collection module is implemented based on the Cuckoo sandbox's host-guest architecture. It provides a specific analysis environment for the malicious samples to be detected, collects sample information obtained on the guest machine, transfers it to the host machine, and stores it categorized by sample identifier. The detection and identification module is implemented based on IDA Pro's IDAPython scripting interface. It uses the end address and number of instructions executed for each sample obtained by the information collection module to calculate the execution progress of the malicious sample and detect the specific location of the delay code and associated characteristic variables within the malicious sample.

[0046] The main information collection program is responsible for controlling the main operation process of the information collection module, such asFigure 2 As shown, it provides parameter configuration for sample run time, sample submission quantity, and result file storage directory (results directory). The main program will construct appropriate Cuckoo task submission and start-up commands based on these user-set parameters, using the written Cuckoo custom analysis processing program to obtain valid information generated by each sample when it runs in the sandbox. In addition, the Cuckoo sandbox environment built according to the default configuration cannot obtain the sample end address and number of run instructions required for delayed code detection, so it is necessary to slightly modify the Cuckoo sandbox source code. The Cuckoo sandbox provides an interface for users to implement customized analysis samples. Based on this, corresponding analysis programs can be written and the self-written analysis program can be specified as a parameter before starting sample analysis to control the sample's running process. The method of obtaining the end address and number of run instructions in the present invention is a certain improvement over the run trace acquisition method proposed by Chou You et al. (You C, Pang J, Zhang Y, et al. An approach to detect malicious behaviors by evadingstalling code [M]. Telkomnika, 2012.). If a run trace is obtained for each sample file, a very large storage footprint will be generated, significantly reducing the efficiency of delay code recognition. However, this method only collects the instruction address at the end of the sample run and the number of instructions run once. While retaining the information required by the delay code recognition module, it reduces the program's storage footprint and shortens the running time of the delay code detection program, thereby improving detection efficiency.

[0047] The operation process of the detection and recognition main program is as follows Figure 3 As shown in the figure, it takes the directory samples where the sample files are stored as input. After setting the number of samples to be analyzed once, it starts a loop and executes the delay code detection program main_detection.py for each sample through IDA in batch mode, and finally generates a delay code address list for each sample file.

[0048] Figure 4The following diagram illustrates the execution flow of the delay code detection program, main_detection. The detection program first retrieves the number of instructions executed for each sample from the results directory to calculate the sample's execution progress. It then searches for extremely long loops within the subroutine where the end address resides. If so, it retrieves their entry and exit addresses. If the sample's execution progress falls below a specified threshold, the first characteristic of delay code is met. However, this characteristic alone is insufficient, as the sample may contain code areas requiring user activity. Therefore, the detection program will continue to run. The program will then check for delayed calls within suspicious loops with extremely long counts based on the previously retrieved loop entry and exit addresses. It will also search for variables with values ​​associated with the delay loop, either within the delay loop or elsewhere within the same subroutine as the delay loop. These variables are called delay loop signature variables. If such a variable exists, its address is also recorded, and the result is returned.

[0049] In one example, in addition to searching for the entrances and exits of suspicious loops with extremely high loop counts, the system also searches for conditional jump instruction addresses, which can be used to indicate patchable locations in the delay code for security analysts, guiding the security patching of the delay code.

[0050] To quantify the latency of malicious samples, the present invention proposes an indicator called sample execution progress, which represents the ratio of the number of instructions actually executed by the sample to the total number of instructions within a specific period of time. The numerator is the number of instructions executed by the sample within the specified time, and the denominator should originally be set to the total number of instructions (excluding library functions) when the execution is completed. However, considering that the present invention targets latency samples that cannot be completed in a short period of time, the denominator is slightly adjusted to the sum of the total number of instructions (excluding library functions) in the static sample file and the number of loops within the sample. Because the number of delay loops in delay-type samples far exceeds the number of other normal loops, it can be approximated as the total number of delay loops.

[0051] In general, the numerator of the sample execution progress is the number of running instructions obtained by the information collection module, while the denominator is the sum of the total number of instructions in the static sample file (excluding library functions) and the total number of delay loops. Since the number of running instructions itself is data obtained in one run, the sample execution progress indicator can be used to represent the proportion of the number of instructions executed by the sample in one run to the total number of instructions in the sample. In order to determine the appropriate execution progress threshold, a set of known delay samples was run under an analysis time of 120s. The test results show that as time goes on, the execution progress of the sample increases very slowly. The execution progress of more than 80% of the delay samples is concentrated in the range of 25%-35%, so the execution progress threshold is set to 35%.

[0052] In summary, the delay code in the present application should meet the following three features: the execution progress is too low, the number of times of the loop is extremely large, and there is a delay function call in the loop. Only when all the three features are met, it can be considered that the delay code is detected. The characteristic variable of the delay loop is not a feature possessed by all delay codes, only some complex delay codes meet the feature, and therefore it is not a necessary condition for identifying delay codes.

[0053] The following will give a specific embodiment in combination with the delay code detection program in the present application. It can be understood that the described embodiment is only a part of the embodiments of the present application, but not all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor are within the scope of protection of the present application.

[0054] Embodiment:

[0055] A user downloads an unknown sample named f4110f7dbf369e1b96a750a6d08ba88b.exe on a public malicious sample website. When it is run in a normal sandbox, it does not show any malicious behavior, so the user suspects that there may be delay code inside it.

[0056] The sample is put into the detection system of the present application, the running time is set to 120s and the sample execution progress threshold is set to 35%, and it is submitted to the information collection module to obtain a sample ID of 1. After a period of time, the sample ends running in the timeout situation, and a file named LastAddr.txt is generated, and the content is as follows.

[0057] Loading f4110f7dbf369e1b96a750a6d08ba88b.exe

[0058] Last Address=0x454b01

[0059] Count=42237561

[0060] The file is placed in the files folder in the directory numbered 1 on the Host machine by the custom processing program set in the present application. The information collection then renames the result file with LastAddr.txt_f4110f7dbf369e1b96a750a6d08ba88b.exe.txt as the new value, and copies it to the results directory of the Host machine.

[0061] Next, the present invention runs the main detection and identification module program. The detection program opens the sample file with IDA and uses the Last Address provided by the information collection module to find the location where the sample stopped before its execution ended. Within this sub-process, the program begins to search for all loop structures and count their loop counts. It also calculates the number of instructions contained in the entire static sample file (excluding library functions). Combining this data, it can calculate the execution progress of the sample run.

[0062] After the calculation is completed, the program finds that the execution progress is lower than the threshold of 35%, so it continues to the next step to find whether there are any delayed function calls in all the large number of cycles located before. The delayed function call detection list used by the detection program in this embodiment is shown in Table 1.

[0063] Table 1 Delay function calls currently supported by the system

[0064]

[0065]

[0066] After searching the program, it was found that there were calls to the GetTickCount function inside two loops, so the entry and exit instruction addresses and conditional jump instruction addresses of these two loops were collected.

[0067] This completes the detection process, which generates a result file named jcc_f4110f7dbf369e1b96a750a6d08ba88b.exe.txt, the contents of which are shown below.

[0068] f4110f7dbf369e1b96a750a6d08ba88b.exe

[0069] Sample Progress=29.72%

[0070] Loop Jccs=['0x454add','0x454b2c']

[0071] The resulting file contains the sample name, execution progress, and conditional jumps within the delay loop. This information guides the sandbox environment where the detected program resides to perform appropriate patching. After the patch was properly patched, the user submitted the program to the sandbox again, only to discover that the sandbox detected malicious behavior, including process injection and registry key modification.

[0072] In summary, it can be seen that the present invention can effectively detect custom constructed delay codes and correctly guide the sandbox to patch malicious samples.

Claims

1. A method for detecting and identifying delayed codes in malicious samples, comprising the following steps: Run the target code and obtain the end address and the number of instructions run; Calculating the execution progress based on the number of instructions executed and the number of instructions executed by the target code within a specified time; Find the maximum number of loops in the sub-process where the end address is located, and check whether there is a delayed call in the maximum number of loops based on the loop entry and exit addresses of the maximum number of loops; Based on the execution progress and whether there is a delayed call in the maximum number of cycles, a detection and recognition result is obtained.

2. The method according to claim 1, wherein The acquisition end address and the number of executed instructions include: 1) Modify the source code of the Cuckoo sandbox based on the interface of the custom analysis sample; 2) Set the parameter configuration for the target code to run; 3) Based on the modified source code and the parameter configuration, write a Cuckoo custom analysis handler to obtain the end address and number of instructions generated when the target code is running in the sandbox.

3. The method according to claim 1, wherein When obtaining the end address and the number of executed instructions, library functions are not counted.

4. The method according to claim 1, wherein The calculation of the sample execution progress includes: taking the number of instructions executed by the target code within a specified time as a numerator and taking the number of executed instructions as a denominator for calculation.

5. The method according to claim 1, wherein The obtaining of the detection and recognition results includes: When the execution progress is lower than a set threshold and there are delayed calls within the maximum number of cycles, the target code is a malicious delay code; or, When the execution progress is not lower than the set threshold, or there is no extremely large loop in the sub-process where the end address is located, or there is no delayed call in the extremely large loop, the target code is a non-malicious delayed code.

6. The method according to claim 1, wherein The conditional jump instruction address of the maximum number of cycles is obtained, wherein the conditional jump instruction address is used to point out the patchable position of the delay code and guide the safe patching work of the delay code.

7. The method according to claim 1, wherein The detection and identification method further includes: 1) Inside the delay loop or elsewhere in the same sub-process as the delay loop, obtain a variable associated with the delay loop and record the address of the variable; 2) constructing a delay code address list based on the address of the variable; 3) Output the execution progress and delay code address list.

8. The method according to claim 1, wherein The detection and identification method further includes: 1) When detecting multiple target codes, the directory samples storing the target codes is used as input; 2) Set the maximum number of target codes to be analyzed once; 3) Through batch mode, malicious sample delayed code detection is performed on multiple target codes at the same time.

9. A storage medium storing a computer program, wherein: The computer program is configured to execute the method according to any one of claims 1 to 8 when executed.

10. An electronic device, characterized in that: The method comprises a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to perform the method according to any one of claims 1 to 8.

Images