JP2010262609A - Efficient technique for dynamic analysis of malware - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a high-precision malware detection technique capable of reducing the rate of malware detection errors and reducing the processing load on a system. <P>SOLUTION: Analysis information obtained from static analysis is reflected also on a module of dynamic analysis and thereby the static analysis is associated with the dynamic analysis. A determination is made as to whether or not a program to be analyzed is a malware. Further, a determination is made as to whether not the program is a malware, by detecting the behavior of the program to unmap its own file image, and detecting the behavior of the program to register itself as a service. <P>COPYRIGHT: (C)2011,JPO&INPIT

Description

The present invention relates to a program, an information device, and a malware determination method.

Malware (software) refers to software and files that contain malicious code. Computer viruses, Trojan horses, bots, worms, spyware, and other programs that invade and attack remote computers, programs that infect or destroy other computers, and harmful information that leaks information to the outside Include behavior.

Malware static analysis refers to a method of determining whether or not malware is inspected before execution of a program to be analyzed. In a Windows (registered trademark; hereinafter abbreviated) program, there is information that can be acquired by inspecting a program file even before the program is executed. Information that can be acquired before execution includes the file size of the program itself, whether the program has an electronic signature, the hash value of the execution program file, and the like. Each program has information that can be understood before execution as a database, and in static analysis, this database is inspected to determine whether it is malware or not.

The dynamic analysis of malware refers to a method of determining whether or not the program is malware by inspecting its behavior after executing the analysis target program. Behaviors that are determined to be malware-like behavior include starting to send a large amount of emails, stopping firewall and OS (Operating System) security functions, deleting system files, intruding into other processes and executing code, etc. It is. By analyzing whether these behaviors are performed, it is determined whether or not the program is malware.

In the conventional malware detection method, static analysis (paragraph 0003) and dynamic analysis (paragraph 0004) are implemented as separate modules, and each module operates independently. Or, even if there is information exchange between both modules of static analysis and dynamic analysis, for example, a limited method is adopted in which dynamic analysis is not executed at all for some trusted programs. Note that the “trusted program” in this section (paragraph 0005) refers to a file classified as non-malware based on the judgment of static analysis alone.

Patent publication 2009-500706 Patent application 2008-518975

In the conventional method, when determining whether or not a file is malware, static analysis and dynamic analysis are performed by independent modules. Because the information that is the criterion is limited, False Positive (a state in which a normal program that does not need to be detected as malware is mistakenly determined as malware) or False Negative (a state in which malware to be detected is missed) As a result of such a false detection, the utility and availability as a security countermeasure program were lacking.

Alternatively, in claims 12 and 24 according to Patent Document 1, a mask is set that restricts the operation of an object that is determined to be malware or non-malware, and the malware moves when a movement other than the action defined by the mask is performed. Judge as. As the basis for malware determination or mask setting, object size, file name, header information, and the like are listed. One of the problems with this method is that a server is required. In addition, although malware is determined by performing a mask, all the behaviors described as masks (paragraph 0088) are basic behaviors that can be seen in ordinary programs as well as malware. Lack of decisive power. For the above reasons, the present invention is merely an approach for policy control, and the accuracy is insufficient as a technique for analyzing or detecting malware.

In order to solve the above problem, the invention according to claim 1 is a control means for efficiently determining whether or not the analysis target software is malware by effectively linking a computer with static analysis and dynamic analysis. To function as.

Further, the inventions according to claim 2 and claim 3 are (7) a behavior in which a program attempts to unmap its own file image for the purpose of compensating for the lack of detection methods in the prior art and preventing detection omissions. And (8) The program functions as a new dynamic analysis method that captures the behavior of registering itself as a service.

The information obtained by the static analysis is fed back to the dynamic analysis including the paragraph 0010 and the background art (paragraph 0004) by the method of the paragraph 0009, thereby improving the malware detection accuracy and improving the efficiency of the detection procedure.

The present invention is characterized by efficient malware detection by reducing the rate of malware false detection and reducing the load on the implementation system. This leads to the prevention of malware attacks and the prevention of the spread of damage. Therefore, it is possible to provide the user of the program including the present invention with a sufficient function as a malware countermeasure focusing on security system construction.

It is a block diagram which shows the dynamic link between the program and the function called. It is a block diagram which shows the process which maps a program to memory space. It is a flowchart which shows the determination processing of the file type by static analysis. It is a flowchart which shows the procedure which reflects the determination information of the file type acquired by static analysis in dynamic analysis, and performs a malware detection process. It is a flowchart which shows the operation | movement process of the security countermeasure program which took in the technique of the efficient malware detection by cooperation of a static analysis and a dynamic analysis.

(A) Static analysis for determining whether the program has an electronic signature (b) Static analysis for determining whether the program is an installer (c) Judging whether the program uses a packer Static analysis (d) Static analysis to determine "The program uses a commercial packer such as copy protection" (e) Static analysis to determine "The program is a self-extracting archive" (1) "Function Dynamic analysis that captures the behavior that was called in a different way than usual (2) Dynamic analysis that captures the behavior that "created a copy of itself and tried to execute it" (3) "does not have a GUI Dynamic analysis that captures the behavior of a program that has executed a system utility or batch file (4) Dynamic analysis that captures a behavior that "tried to acquire debugging privileges" (5) Dynamic analysis that captures the “tried” behavior (6) Dynamic analysis that captures the “tried to open another process” behavior (7) Dynamic analysis that captures the “tried to unmap your own file image” behavior (8) Dynamic analysis that captures the behavior of "attempting to register itself as a service"

Hereinafter, an embodiment of the present invention will be described based on a malware detection procedure in which static analysis and dynamic analysis are linked. The embodiment is not limited to the following.

When a user executes a program, the analysis module first performs a static analysis on the executed program. This static analysis checks for malware before running the program. If it cannot be determined as malware at this stage, the program is executed to perform dynamic analysis.

The type of program is also determined simultaneously with the determination of whether or not it is malware during the static analysis in paragraph 0016. The following (a) to (e) are used as judgment materials for this type of program.
(A) Is the program digitally signed? (B) Is the program an installer? (C) Is the program using a packer? (D) Is the program using a commercial packer such as copy protection? (E) The program. Is self-extracting archive

The type of program determined in paragraph 0017 is used as a clue, and based on the type of program acquired as a result of the analysis, dynamic analysis that captures the following behaviors (1) to (6) is performed on the target program: .
(1) The function was called in a different way than usual (2) Created a copy of itself and tried to execute it (3) A program without a GUI executed a system utility or batch file ( 4) Attempt to acquire debugging authority (5) Attempt to load driver (6) Attempt to open another process

Paragraphs 0018 (1) to (6) are behaviors frequently performed by malware. However, since a normal program may perform the same operation, it is possible to reduce the rate of false detection by switching between valid / invalid detection by dynamic analysis for each type of program. Specifically, when it is determined in the static analysis (paragraph 0017) that “(a) there is an electronic signature”, (2), (3), (4) among the detections by the dynamic analysis (paragraph 0018). ), (5) and (6) are not detected. When it is determined that “(b) the program is an installer”, the behaviors (2), (3), (4), and (5) are not detected. When it is determined that “(c) the program uses a packer”, (1) is not detected. Thus, by reflecting the type of program obtained by static analysis in dynamic analysis, new detection methods (paragraphs 0010) (7) and (8) can be introduced while reducing false detections.

Here, the basis for detecting / not detecting paragraph 0019 will be described. (1) is a function that focuses on dynamic library linking provided by the OS. A normal program uses a function of dynamic linking provided by the OS, but a program called a packer may incorporate a part of this function by itself. In this case, since detection by the method (1) is difficult, it is excluded from detection. (2), (3), (4), (5), and (6) are behaviors such as “suspicious” and “suspicious” although this operation cannot be identified as malware. In addition, since the electronic signature and installer may perform the operations (2), (3), (4), (5), and (6), they are excluded in this way.

The function of feeding back each detection method and the result of the static analysis to the dynamic analysis is the main method of the present invention. Regarding switching of the detection function, which detection function is enabled / disabled when detecting which type of program in the static analysis, a part of the method is given in paragraph 0019, and the program type determination method and paragraph 0010 are Details of the combination of detection methods by dynamic analysis included will be described in the embodiment.

Depending on the results of (a) to (e) obtained by static analysis, any detection method (1) to (8) may be invalidated.

In the following (paragraphs 0024 to 0029), a method for determining the type of program by static analysis will be described. The type of program can be specified by analyzing a PE (Portable Executable) header included in the program file.

(A) If the program has an electronic signature or is Windows, the OS-provided WinVerifyTrust function is used.

(B) The program is an installer or the installer includes a specific character string in the data section. For example, in the case of InstallShield, a character string “InstallShieldMSI” is embedded in the data section. Thus, the installer can be detected by holding the character string embedded for each installer as a database and checking whether the data section of the detection target program includes the character string in the database.

(C) The program uses a section name to detect whether a packer is being used. Packers use section names that are not often used in regular programs. Such characteristic sections are used for packer detection.

Instead of the packer detection in paragraph 0026, detection by a specific byte sequence included in the PE header or data section may be used. To do this, the characteristic byte sequence of the packer is stored in a database, and it is used for detection by checking whether the data section of the detection target program contains a character string in the database.

Instead of the packer detection in paragraph 0026, detection based on the ratio of 0x00 included in the code section may be used. When the ratio is less than a certain ratio, it can be determined that the packer is used. For example, a number such as 3% can be used for the “certain ratio”.

Instead of the packer detection in paragraph 0026, detection by the name of a linked DLL (Dynamic Link Library) or function may be used. Normal programs use many functions, but packers often use only specific functions. If the DLL or function used by the program to be inspected is composed only of functions that are frequently used by such packers, it is determined that the packer is a packer. The fifth uses the location of the start address of the program. A normal program contains a start address in the first code section. If there is a start address at a location outside of that, it is determined that there is a high possibility of being a packer.

(C) The program may determine whether the packer is used by combining the detection methods in paragraphs 0026 to 0029 as a method for realizing whether the packer is used.

(D) The program detects whether a commercial packer such as copy protection is used or not by basically the same method as the packer detection in paragraph 0026. Further, commercial packers such as copy protection may determine whether a specific section name is used or whether a specific character string or byte string is included.

(E) The program detects a self-extracting archive or a self-extracting archive in the same manner as the packer detection in paragraphs 0026 to 0029.
Judgment is made based on whether a specific section name is used or whether a specific character string or byte string is included.

The flow of file type determination by static analysis is shown in FIG.

The detection method by dynamic analysis will be described below (paragraphs 0035 to 0042). It is determined as malware based on the behaviors (1) to (8) detected at the time of program execution.

(1) A program in which a function is called in a different way from a normal one usually links a library provided by the OS dynamically and calls a function in the library. At that time, the program needs to specify which function in which file to link. This designation is performed by a method determined by the OS. In Windows, this dynamic link is realized by creating a table called IAT (Import Address Table). In FIG. 1, the program “program.exe” is kernel32. Indicates the association of dynamically linking dll and calling the CreateFileA function. When such an OS standard method is used, it becomes easy to analyze a program. Therefore, malware often calls a function using a method that is not an OS standard. Therefore, if a function that is not in the IAT is called, it can be determined that the function call is illegal by malware.

(2) Make a copy of itself, and the running program that tried to execute it outputs its own program as a file, and if it tries to execute it further, it is judged as malware.

(3) A program that does not have a GUI (Graphical User Interface) does not have a window for executing a system utility or batch file, and does not have a task tray icon. A system utility such as exe was executed. Or the batch file was executed.

(4) The program that attempted to acquire debugging authority attempted to acquire authority necessary for debugging. In Windows, the authority is adjusted by the ZwAdjustPrivilesToken function. It specifies what kind of authority is adjusted as an argument of the function, and if the specification includes SeDebugprivilege, it is detected that an attempt to acquire debugging authority is made.

(5) It can be determined that the driver is trying to load and execute the driver, and it is malware.
A driver is a program that runs in a more privileged kernel. Malware tries to execute malicious code with higher privileges.

(6) In the case of Windows trying to open another process, when malware infects another process, first, a function called OpenProcess is called. This function specifies which process is used for which process. The authority includes, for example, PROCESS_VM_WRITE authority. When a process is opened with this authority, arbitrary data can be written to the memory space of the target process. An operation that attempts to open another process with such write authority is detected as a malware operation.

(7) When a program that attempts to unmap its own file image is executed, the execution code of the program is loaded into the memory space of the process. In the case of Windows, this loading is realized by performing a process of mapping a program file to a memory. For example, in the case of FIG. exe and kernel32. dll is mapped into the process memory space. As a result, program. The program code in exe can be executed.
One of the behaviors of malware is to delete its own program files and erase infected traces. Windows cannot delete a program file if the program file is mapped to memory as in the above example.
Therefore, the malware is program. exe, that is, the program file is deleted after unmapping (unmapping) itself. If you are trying to unmap yourself like this, it's determined to be malware.

(8) If it is trying to register itself as a service that attempts to register itself as a service, it is determined as malware. Programs registered in the service are often used for malware because they are automatically executed without any explicit instruction from the user.

The flow from static analysis to dynamic analysis to notifying the user of malware detection will be described below.

First, before executing the program, the type of program to be analyzed is specified (FIG. 3).
This identifies whether the program has an electronic signature, an installer, or a packer.
Next, prepare to monitor the behavior of the program. This hooks the function to be monitored and enables dynamic analysis each time the monitored function is called. When this monitoring preparation is completed, the program is executed.
When the program is actually executed, “detection by dynamic analysis” is executed every time the function to be monitored is called, and it is determined whether it is malware or not (FIG. 4). This determination is performed immediately before the monitoring target function is called.
In the detection by the dynamic analysis, the processes shown in paragraphs 0018 and 0019 are performed.
When a malware-like operation is detected, the user is notified of attack detection, and the detected function is returned to the original state without executing the detected function (FIG. 4).
By performing malware determination before calling a function in this way, it is possible to prevent malware attacks in advance.

FIG. 5 shows a program execution example when the detection method based on the linkage of the static analysis and the dynamic analysis is introduced into a program for the purpose of security countermeasures. The described embodiment shows an example, and the present invention is not limited to this. The configuration and operation in the execution example can be changed as appropriate.

Claims (4)

Computer
A control means for efficiently determining whether or not the analysis target file is malware by linking static analysis and dynamic analysis by reflecting the analysis information obtained by static analysis to the dynamic analysis module,
Program to function as. The program according to claim 1, wherein it is determined whether or not the program is malware by detecting a behavior of a program that attempts to unmap its own file image. The program according to claim 1, wherein it is determined whether or not the program is malware by detecting a behavior of a program that attempts to register itself as a service. A program intended for malware detection and security measures including one or more of claims 1, 2, and 3.

Images