Generation device, generation method, and generation program
Patent Information
- Application Number
- JP2023128713
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2023-08-07
- Publication Date
- 2025-02-20
AI Technical Summary
【0019】 本発明によれば、痕跡のバリエーションを考慮したシグネチャグラフを自動で生成することができる。
Smart Images

Figure 2025024535000001_ABST
Abstract
Description
[Technical field]
[0001] The present invention relates to a generating device, a generating method, and a generating program. [Background technology]
[0002] [IOC(Indicator Of Compromise)] One of the widely used methods to protect PC terminals on corporate networks from cyber attacks is Endpoint Detection & Response (EDR). With EDR, an agent installed on the terminal performs constant monitoring and detection uses IOCs that represent the traces left by malware. Traces are specific identifiers that appear on the system when malware is active, such as process names and names of files created.
[0003] When an agent detects something, it sends out an alert, which is then manually checked and responded to by analysts at a security operations center (SOC).
[0004] Current IOCs are expressed as a single indicator rule (e.g. create file “C:\Temp\mal.exe”) or a logical combination (AND or OR) of multiple rules. Individual rules can match regular expressions as well as simple string matches.
[0005] [Detection rules] It is desirable for detection rules to not falsely detect benign programs, but not overlook malware. This is because a large number of false positives increases the cost of human response, and overlooking malware leads to the expansion of damage from attacks. However, the current IOCs have a large number of false positives, and there is a need to improve their accuracy.
[0006] [Variations of traces] Malware with similar characteristics is referred to by the same family name. One of the challenges in creating detection rules is that even samples belonging to the same family may have similar traces that differ from sample to sample or from execution to execution. This is called trace variation.
[0007] To avoid detection, malware developers, for example, change the name of a file generated by the malware in the source code, or implement the malware so that the file name is dynamically determined at execution time.
[0008] If such traces are used as they are in the detection rules, they will only detect a very limited range of samples, resulting in low detection power. Even if a detection rule is created excluding such traces, it will still produce false positives if the other traces are not sufficiently distinctive.
[0009] To detect such malware with high accuracy, it is necessary to capture the invariant parts of the varying traces.
[0010] EIGER (Non-Patent Document 1) is a technology that automatically generates an IOC that represents a family from the execution logs of multiple malware samples and benign samples that belong to the same family. This method generates an IOC by grouping similar traces together and converting them into regular expressions.
[0011] On the other hand, there is also a method that expresses the characteristics of malware as a graph with traces as nodes and sets them as detection rules, rather than expressing them as a logical combination of traces like the current IOC method. Here, such a graph is called a signature graph.
[0012] HOLMES (Non-Patent Document 2) is one of the methods for automatically generating signature graphs. The input is a set of graphs created from multiple malicious samples of the same family and execution logs of benign samples. Using techniques such as graph mining, it outputs a set of subgraphs that "match many malicious samples but not many benign samples."
[0013] However, HOLMES does not consider variations in traces and does not generate patterns such as regular expressions.
Prior Art Documents
Non-Patent Documents
[0014]
Non-Patent Document 1
Non-Patent Document 2
Non-Patent Document 3
[0015] Signature graphs can express a wider variety of information than current IOCs, and therefore may be able to detect malware more accurately. Specifically, when multiple processes leave different traces during malware execution, current IOCs cannot express which process left which trace, but signature graphs can.
[0016] However, no method has yet been proposed for automatically generating signature graphs that takes into account variations in traces.
[0017] The present invention has been made in consideration of the above, and aims to provide a generation device, a generation method, and a generation program that can automatically generate a signature graph that takes into account variations in traces. [Means for solving the problem]
[0018] In order to solve the above-mentioned problems and achieve the object, the generation device of the present invention is characterized in having a graph conversion unit that uses the execution log of malware to create a first behavior graph in which the subject and target of an operation in a series of execution processes of the malware are represented as nodes, and the operations performed by the subject of the operation on the target of the operation are represented by edges connecting the nodes, a regular expression unit that converts the first behavior graph into a second behavior graph in which the node labels of the first behavior graph are regularized, and an extraction unit that performs graph mining on the second behavior graph to generate a signature graph. Effect of the Invention
[0019] According to the present invention, a signature graph that takes into account variations in traces can be automatically generated. [Brief description of the drawings]
[0020] [Figure 1] FIG. 1 is a diagram showing an example of clustering a path string. [Diagram 2] FIG. 2 is a diagram illustrating an example of a configuration of a generating device according to an embodiment. [Diagram 3] FIG. 3 is a diagram illustrating an example of a data configuration of the execution log. [Figure 4] FIG. 4 is a flowchart illustrating an example of a process executed by the graph conversion unit illustrated in FIG. [Diagram 5] FIG. 5 is a diagram illustrating an example of the first behavior graph. [Figure 6] FIG. 6 is a flowchart illustrating an example of a process executed by the regularization unit illustrated in FIG. [Figure 7] FIG. 7 is a flowchart showing the processing procedure of the Distance subroutine. [Figure 8] FIG. 8 is a flowchart illustrating an example of a process executed by the extraction unit illustrated in FIG. [Figure 9] FIG. 9 is a diagram showing an example of a signature graph output by the generating device shown in FIG. [Figure 10] FIG. 10 is a diagram illustrating an example of a computer that realizes the generating device by executing a program. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0021] Hereinafter, an embodiment of the present invention will be described in detail with reference to the drawings. Note that the present invention is not limited to this embodiment. In addition, in the description of the drawings, the same parts are indicated by the same reference numerals.
[0022] As an embodiment, a new method for generating a signature graph is proposed. In the embodiment, a new method for automatically generating a signature graph that expresses trace variations as regular expressions, specifically, a new method for automatically generating a signature graph that includes regular expressions in node labels, is described.
[0023] In this embodiment, when generating a signature graph, clustering of node labels is performed, the node labels of each class are converted into regular expressions, and variations are removed before performing graph mining, thereby making it possible to extract patterns that contain variations in traces.
[0024] In this embodiment, the distance function used for clustering the node labels is an edit distance algorithm modified to take into account the path separator ( / ).
[0025] In an embodiment, components separated by a path separator character are treated as one character regardless of length to calculate distance. This allows the embodiment to prevent long folder or file names from affecting the distance too much. In addition, the embodiment prevents two consecutive components of one path from accidentally nearly matching a single component of another path, resulting in a short distance, as shown in Figure 1.
[0026] FIG. 1 is a diagram showing an example of clustering path strings A, B, and C.
[0027] The distance between path string A and path string B is shorter in the normal edit distance, but the file names are not similar and the folders they reside in are different. On the other hand, although path string B and path string C have different file names, they reside in the same folder, and it is thought that the distance between path string B and path string C should be closer than the distance between path string A and path string B. However, in the normal edit distance, the distance between path string B and path string C is greater than the distance between path string A and path string B.
[0028] In the distance measure in this embodiment, an edit distance algorithm modified to take into account the path separator ( / ) is used, so that the distance can be determined in accordance with the above recognition. In other words, in the distance measure in this embodiment, the distance between path string B and path string C is closer than the distance between path string A and path string B, and path string B and path string C are more likely to be included in the same cluster.
[0029] [Generation device] A generating device according to the present embodiment will be described below. Fig. 2 is a diagram showing an example of the configuration of a generating device according to the present embodiment.
[0030] A generating device 10 according to an embodiment automatically generates a signature graph that takes into account variations in a trace. The generating device 10 generates one or more signature graphs that represent one family.
[0031] The signature graph generated by the generation device 10 can be used directly for real-time malware detection.
[0032] An example of a detection method will be described. In the detection device 20, the monitoring logs of the terminal to be monitored are collected, and a behavior graph of the monitoring logs is constructed. As shown in FIG. 2, the detection device 20 acquires the signature graphs generated by the generation device 10. Then, when any one of the signature graphs of a certain family among the signature graphs generated by the generation device 10 appears as a subgraph of the monitoring log of the terminal to be monitored, the detection device 20 determines that the malware that has infected the terminal to be monitored is malware of that family.
[0033] The generating device 10 according to the embodiment is realized, for example, by loading a predetermined program into a computer or the like including a ROM (Read Only Memory), a RAM (Random Access Memory), a CPU (Central Processing Unit), etc., and executing the predetermined program by the CPU. The generating device 10 also has a communication interface for transmitting and receiving various information to and from other devices connected via a network, etc.
[0034] The generation device 10 receives an execution log, which is a monitoring log of a monitored terminal, as input, and automatically generates and outputs a signature graph that takes into account variations in traces. The generation device 10 includes a graph conversion unit 11 that converts the execution log into a first behavior graph, a regular expression conversion unit 12 that converts the node labels of the first behavior graph into a second behavior graph in which the node labels are regularized, and an extraction unit 13 that generates a signature graph based on the second behavior graph.
[0035] [Execution log] Fig. 3 is a diagram showing an example of the data configuration of an execution log. As shown in Fig. 3, the execution log, which is input data, includes one or more execution logs. The execution log, which is input data, is a collection of execution logs obtained from samples belonging to a certain sample collection.
[0036] This sample set is the union of the set of malware (called positive samples) for which we are trying to create a signature graph, and the set of benign programs (called negative samples). Each execution log shows the PID (process ID, identification information of the process that is the subject of the operation) of the caller of the execution process, the type of operation of the PID, the target of the operation, etc.
[0037] The types of operations include, for example, reading and writing files, creating and terminating processes, operations related to code injection into other processes (e.g., CreateRemoteThread, etc.), sending and receiving to sockets, etc. In the case of Windows OS, the types of operations also include reading and writing to the registry.
[0038] The target of the operation is, for example, the file path if the target of the operation is a file, the key-value path if the target of the operation is a registry, the process ID if the target of the operation is a process, the destination IP address if the target of the operation is a socket, and the target process ID for code injection-related APIs.
[0039] However, for example, when the target of an operation is a resource that is operated using a handle, such as a registry key, the target of the operation may not be identified by the information of the call alone. If the target of an operation is a registry key, it is possible to open a key (subkey) in a deeper path by calling RegOpenKey again using the handle obtained by RegOpenKey as an argument. Therefore, when the target of an operation cannot be identified by the information of the call alone, the device that inputs the data recursively traces back past calls to obtain the information, which is then written to the execution log file.
[0040] [Graph conversion section] Next, a description will be given of the graph conversion unit 11. The graph conversion unit 11 converts each input execution log into one first behavior graph. Fig. 4 is a flowchart showing an example of a process executed by the graph conversion unit 11 shown in Fig. 2.
[0041] For example, the graph conversion unit 11 creates a first behavior graph in which the subject and target of an operation in a series of execution processes of the malware shown in the execution log are represented as nodes, and the operation performed by the subject of the operation on the target of the operation is represented as edges connecting the nodes. However, the first process created by executing the malware is represented as the root node, and a unique label (e.g., root) is given to it. This label is common to all samples. Details of the processing by the graph conversion unit 11 will be explained using FIG. 4.
[0042] For example, the graph conversion unit 11 acquires an execution log of the malware (step S11). Then, the graph conversion unit 11 prepares an empty graph G (step S12), executes the processes of steps S13 to S16 shown below for each of the execution logs acquired in step S11, and then returns the graph G (step S17).
[0043] For example, if there are no nodes in graph G corresponding to the subject of the operation and the target of the operation indicated in the malware execution log obtained in step S11, the graph conversion unit 11 creates nodes corresponding to the subject of the operation and the target of the operation (step S13).
[0044] Next, the graph conversion unit 11 judges whether the operation of interest in the execution log is a read access or a receive (step S14), and if it is judged that the operation of interest is a read access or a receive (step S14: Yes), the graph conversion unit 11 proceeds to step S15. Then, if an edge labeled with the type of the operation from the target node of the operation to the subject node of the operation does not yet exist in the graph G, the graph conversion unit 11 adds it to the graph G (step S15).
[0045] On the other hand, when the graph conversion unit 11 determines that the operation of interest in the execution log is neither a read access nor a reception of the target of the operation (step S14: No), the graph conversion unit 11 proceeds to step S16. Then, if an edge labeled with the type of the operation from the node of the subject of the operation to the node of the target of the operation does not yet exist in the graph G, the graph conversion unit 11 adds it to the graph G (step S16).
[0046] In this way, the graph conversion unit 11 can create a behavior graph that corresponds to the execution log of the malware.
[0047] In the creation of the first behavior graph, the graph conversion unit 11 expresses processes, files, and sockets as nodes, and expresses their specific behaviors as edges between the nodes, in the same way as the provenance graph of POIROT (see Non-Patent Document 2). In the case of the Windows OS, the graph conversion unit 11 also expresses the registry as a node.
[0048] In addition, the above processes are identified by PIDs, but the PID of a terminated process is reused for a new process, so the graph conversion unit 11 assigns a different node to such a new process.
[0049] The graph conversion unit 11 distinguishes the above registries and files by paths, and distinguishes the above sockets by IP addresses.
[0050] Furthermore, when the type of operation is read access or receive, the graph conversion unit 11 sets the edge direction to the direction from the target node of the operation to the subject node of the operation, and in other cases, sets the edge direction to the opposite direction.
[0051] Fig. 5 is a diagram showing an example of a first behavior graph. For example, the graph conversion unit 11 creates the first behavior graph shown in Fig. 5 based on the execution log shown in Fig. 3. Note that in the first behavior graph shown in Fig. 5, the description of node labels indicating the types of operations is omitted from the edges.
[0052] For example, as shown in FIG. 5, the graph conversion unit 11 creates nodes indicating the subject of the operation in the execution log shown in FIG. 3 (for example, the root node which is the first process) and the target of the operation by the subject of the operation (for example, the file C:\Temp\logger.exe, the registry HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run\logger, the process (ProcessID=20) "C:\Temp\logger.exe" --detach, and the file C:\Temp\log).
[0053] Also, nodes are created that indicate the subject of the operation (for example, C:\Temp\Ddcu49\logger.exe) and the target of the operation by the subject of the operation (root) in the execution log shown in Fig. 5. Then, the graph conversion unit 11 connects the node of the subject of the operation and the node of the target of the operation by the subject of the operation with an edge.
[0054] In addition, since the target of the root operation in the execution log shown in FIG. 5, ““C:\Temp\Ddcu49\logger.exe” --detach”, is the creation of a process of “C:\Temp\Ddcu49\logger.exe”, the graph conversion unit 11 connects the root node and the ““C:\Temp\Ddcu49\logger.exe” --detach” node with an edge.
[0055] Furthermore, the PID is not included in the node (process node) of the subject of the operation in the final first behavior graph created by the graph conversion unit 11. This allows the detection device 20 to match an arbitrary process node when matching the behavior graph of the monitoring log with the first behavior graph.
[0056] [Regular expression section] The regular expression conversion unit 12 converts the first behavior graph into a second behavior graph in which the node labels of the first behavior graph are regularized.
[0057] Specifically, when a path separator character is present in the character string of a node label of the first behavior graph, the regular expression conversion unit 12 regards each component separated by the path separator character as one character and calculates the first edit distance. At this time, the regular expression conversion unit 12 calculates the edit distance between each component as the second edit distance, and uses the calculated second edit distance as a substitution cost to be used when calculating the first edit distance. In this way, the regular expression conversion unit 12 calculates the first edit distance to be used for clustering by performing a two-stage edit distance calculation.
[0058] Then, the regular expression conversion unit 12 obtains a cluster set by clustering the node labels of the first behavior graph based on the first edit distance, and converts all the character strings of the node labels included in each cluster into regular expressions. At this time, the regular expression conversion unit 12 generates a character string representing both of the two character strings based on the two character strings of the node labels for each cluster, and converts the generated character string into a regular expression according to a predetermined rule.
[0059] FIG. 6 is a flowchart showing an example of a process executed by the regularization unit 12 shown in FIG.
[0060] The regular expression unit 12 receives as an input a set S of first behavior graphs converted by the graph conversion unit 11 (step S21). The regular expression unit 12 executes steps S22 to S35 shown below for each node type T of the first behavior graph acquired in step S21, and then returns an output S (a set of second behavior graphs) (step S36).
[0061] The regularization unit 12 first extracts, for each node type T in the set S of first behavior graphs acquired in step S21, all node labels of nodes of node type T included in graphs belonging to the set S of first behavior graphs that do not appear in multiple graphs as a set L of node labels (step S23).
[0062] The regular expression unit 12 obtains a cluster set CS as a result of clustering the set L of node labels using a density-based spatial clustering of applications with noise (DBSCAN) algorithm (step S24). The regular expression unit 12 uses a Distance subroutine (described later) as a distance function used in clustering.
[0063] The regularization unit 12 repeatedly performs the following steps S25 to S34 for each cluster C in CS. First, any one of the labels in each cluster C is set as p (step S26).
[0064] Then, the regularization unit 12 repeatedly performs the following steps S27 to S29 for each label l in each cluster C. For each label l in each cluster C, the regularization unit 12 acquires, as p, an execution result of executing a CSR (Contiguous Substrings Rewarded) algorithm (Non-Patent Document 3) using p and l as inputs for the label l in each cluster C (step S28). The CSR algorithm is an algorithm that takes two character strings p and l as inputs and outputs a character string that represents both p and l. In this CSR algorithm, the symbol "*" and the symbol "?" can be included in the input character string as wildcards that can be generated in the processing of steps S27 to S29.
[0065] When the loop of steps S27 to S29 ends, the regular expression conversion unit 12 converts the execution result p of the CSR algorithm into a regular expression r (r=Convert(p)) (step S30).
[0066] The regular expression conversion unit 12 repeatedly performs the following steps S31 to S33 for each label l in C. For each label l in C, the regular expression conversion unit 12 replaces the label with a regular expression r for all nodes of node type T included in the graph belonging to S that have the label l (step S32).
[0067] In FIG. 6, the case where the DBSCAN algorithm is used for clustering has been described as an example, but the present invention is not limited to this.
[0068] For example, in the embodiment, any other algorithm may be used as the clustering, as long as it does not require the number of clusters to be specified, can determine outliers (data points that do not belong to any cluster), and outputs a set of multiple disjoint subsets. For example, in the embodiment, X-means or OPTICS may be used as the clustering.
[0069] In the embodiment, the CSR algorithm of SRE (Simplified Regular Expression) (Non-Patent Document 3) is used for regular expression conversion, but the present invention is not limited to this. In the embodiment, any method for generating a regular expression that expresses all three or more character strings can be applied for regular expression conversion.
[0070] [Distance subroutine] In this embodiment, the Distance subroutine is used as the distance function used in the clustering (step S24). The Distance subroutine used as the distance function in step S24 will now be described. Fig. 7 is a flowchart showing the processing procedure of the Distance subroutine.
[0071] In the Distance subroutine, two character strings X and Y are input (step S41), and a real number between 0 and 1, which represents the standardized edit distance D, is output (step S46).
[0072] In the Distance subroutine, it is determined whether the character strings X and Y are both file paths or both registry paths (step S42).
[0073] In the Distance subroutine, if the character strings X and Y are both file paths or both registry paths (step S42: Yes), the results (arrays) of dividing X and Y using the path separator character are set as LX and LY, respectively (step S43).
[0074] A specific description will be given with reference to Figure 1. For example, path string A "C: / superstar.exe" is separated by the path separator character ( / ) into two components A1 "C:" and A2 "superstar.exe". Path string B "C: / super / tar.exe" is separated by the path separator character into three components B1 "C:", B2 "super", and B3 "tar.exe". Path string C "C: / super / 7zip.exe" is separated by the path separator character into three components C1 "C:", C2 "super", and C3 "7zip.exe".
[0075] In the Distance subroutine, each element (called a word) of the array is regarded as one character, and the standardized edit distance D (first edit distance) between LX and LY is calculated (step S44).
[0076] For example, for path string A, a two-character string LA is defined, with component A1 as the first character and component A2 as the second character. For path string B, a three-character string LB is defined, with component B1 as the first character, B2 as the second character, and component B3 as the third character. For path string C, a three-character string LC is defined, with component C1 as the first character, C2 as the second character, and component C3 as the third character. Then, the standard edit distance (first edit distance) between strings LA, LB, and LC is calculated.
[0077] Here, the standardized edit distance refers to the edit distance scaled to a value between 0 and 1, and is the value obtained by dividing the edit distance by the longer of the lengths of the two input strings. The edit distance can specify the edit cost as a parameter. Specifically, it is the substitution cost, the insertion cost, or the deletion cost. The edit distance is defined as the minimum value of the total cost of the edit operations (character substitution, insertion, or deletion) required to make one input string match the other.
[0078] Furthermore, in step S44, the replacement cost is set to the Word Distance (second edit distance) between the word to be replaced and the word after replacement, the insertion cost is set to 1, and the deletion cost is set to 1. Here, the second edit distance is a value based on the edit distance between each component calculated using the Word Distance subroutine, as described later.
[0079] 1, the standardized edit distance D (e.g., 0.17) between path string B and path string C, which is composed of the same three characters, becomes closer than the standardized edit distance D (e.g., 0.49) between path string B and path string A, which is composed of two characters. This makes it easier for path string B and path string C to be included in the same cluster.
[0080] On the other hand, in the Distance subroutine, if neither character string X nor Y is a file path and neither is a registry path (step S42: No), the standardized edit distance D between character string X and character string Y is calculated (step S45).
[0081] Then, in the Distance subroutine, the standardized edit distance D calculated in step S44 or step S45 is output (step S46), and the process ends.
[0082] This Distance subroutine is based on the standardized edit distance. The Distance subroutine used in this embodiment is characterized in that each portion separated by a path separator character is regarded as one character.
[0083] [Word Distance subroutine processing] A description will now be given of the processing of the Word Distance subroutine shown in step S44 of Fig. 7. The Word Distance subroutine receives two character strings X and Y as input, and outputs a real number between 0 and 1, inclusive, which indicates the distance.
[0084] In step S44, the output of Word Distance is the standardized edit distance (second edit distance) between character string X and character string Y calculated using the following parameters: Replacement cost: 1 Insertion cost: 1 Removal cost: 1
[0085] For example, if the node labels are the path strings A, B, and C in FIG. 1, the components A1, A2, B1 to B3, and C1 to C3 separated by the path separator characters become inputs to the Word Distance subroutine.
[0086] In the Word Distance subroutine, the characters in each combination of components A1, A2, B1-B3, and C1-C3 are compared to calculate the standardized edit distance. Then, the standardized edit distances calculated for each combination are used as the replacement cost in step S44. For example, the standardized edit distances for each combination of components A1, A2 and components B1-B3 are calculated, and these are used as the replacement costs when calculating the standard edit distance between strings LA and LB.
[0087] [Convert subroutine] A description will now be given of the Convert subroutine shown in step S30 of Fig. 6. The Convert subroutine receives as input a character string X including a wildcard, and performs the following processing.
[0088] First, the Convert subroutine converts a string X into an equivalent regular expression r.
[0089] In a string, the symbol "*" represents any one character or zero characters, and the symbol "?" represents any one character. To convert to a regular expression r, specifically, in a string X, the symbol "*" becomes ".?", and the symbol "?" becomes ".".
[0090] In the Convert subroutine, if there are multiple consecutive wildcards, they are grouped together using the Convert subroutine ".{n}" or ".{n,m}". For example, the Convert subroutine converts "x??***c??" to "x.{2,5}c.{2}".
[0091] Then, in the Convert subroutine, any non-wildcard characters that require escaping are escaped. For example, "." is converted to "\." Which characters require escaping depends on the implementation of the regular expression engine that performs the regular expression matching when detected.
[0092] The Convert subroutine outputs the converted regular expression r.
[0093] [Extraction part] The extraction unit 13 generates a signature graph based on the second behavior graph in which the node labels are regularized. Fig. 8 is a flowchart showing an example of a process executed by the extraction unit 13 shown in Fig. 2 .
[0094] The extraction unit 13 receives a set S of second behavior graphs as an input (step S51). The extraction unit 13 extracts behavior graphs P corresponding to positive samples from the set S and behavior graphs N corresponding to negative samples from the set S (step S52).
[0095] The extraction unit 13 performs graph mining, SubdueCL (Non-Patent Document 4), with the behavior graph P as positive examples and the behavior graph N as negative examples to generate a subgraph set SG of the extracted results (step S53).
[0096] For each subgraph g in the subgraph set SG, if g includes a node with a (root) label, the extraction unit 13 replaces the label with the regular expression ".*" (step S54). Then, the extraction unit 13 outputs the subgraph set SG as a signature graph (step S55).
[0097] In this way, the extraction unit 13 extracts some subgraphs that frequently appear in positive samples and rarely appear in negative samples in the set S of the second behavior graphs that is the input.
[0098] The extraction unit 13 uses a graph mining technique called SubdueCL as an extraction method. It takes two graph sets, positive examples and negative examples, as input. The output is a subgraph that appears frequently in the positive examples and rarely in the negative examples. By inputting the graphs of positive samples as positive examples and the graphs of negative samples as negative examples, it is possible to create a subgraph that matches only samples from the positive family as much as possible.
[0099] [Signature graph example] Fig. 9 is a diagram showing an example of a signature graph output by the generation device 10. The label of the signature graph that is actually output depends on which parts are actually common to other similar samples. As shown in Fig. 9, the label of the root label node, which is the subject of the operation in the execution log, is replaced with the regular expression ".*" in the process of step S54.
[0100] And the label of the node "C:\Temp\Ddcu49\logger.exe" connected to the node with the ".*" label is expressed as "C:\\Temp\\.{6}\\logger\.exe" with the "Ddcu49" part converted to the regular expression ".{6}".
[0101] In addition, the node label ""C:\Temp\Ddcu49\logger.exe" --detach" which connects to a node with the ".*" label is expressed as ""C:\\Temp\\.{6}\\logger\.exe" --detach" with the "Ddcu49" part converted to the regular expression ".{6}".
[0102] Note that the node label “C:\Temp\logs.txt” that connects to the node label “"C:\Temp\.{6}\logger\.exe" --detach” is determined by other behavior graphs, and in the example in Figure 9, it remains “C:\Temp\logs.txt”.
[0103] [Effects of the embodiment] As illustrated in FIG. 9, the generating device 10 according to the embodiment can automatically generate a signature graph in which the variations of the traces are expressed as regular expressions.
[0104] When generating a signature graph, the generation device 10 converts each input execution log into a behavior graph, converts the node labels into regular expressions (Figure 6), removes variations, and then performs graph mining to extract patterns that contain variations in the traces.
[0105] The generating device 10 uses an edit distance algorithm (Distance subroutine) modified to take into account the path separator ( / ) as a distance function for clustering. The edit distance algorithm (Distance subroutine) used by the generating device 10 calculates the first edit distance by treating a component separated by a path separator character as "one character" regardless of its length.
[0106] This allows the generating device 10 to prevent long folder or file names from unduly affecting the distance, and in some embodiments, prevents two consecutive components of one path from nearly matching a single component of another path by chance, resulting in a short distance, as shown in FIG.
[0107] Furthermore, the edit distance algorithm (Distance subroutine) used by the generating device 10 uses the second edit distance between each component as a replacement cost of the first edit distance. This allows, for example, calculation so that the distance between path strings in which folders are the same or similar is closer than the edit distance between path strings in which folders are not similar.
[0108] Therefore, the generation device 10 can automatically generate a signature graph that expresses the variation of the trace as a regular expression. The generation device 10 can generate a signature graph that absorbs the variation of the trace with the regular expression and expresses more samples. The analysis side (for example, the detection device 20) can detect more unknown samples based on this signature graph.
[0109] Furthermore, with the generation device 10, rather than creating a signature graph for each similar sample with variations in traces, it is possible to represent many samples with a single signature graph, thereby reducing the computational load of detection and improving ease of understanding for analysts.
[0110] [System configuration of the embodiment] Each component of the generation device 10 is a functional concept, and does not necessarily have to be physically configured as shown in the figure. In other words, the specific form of distribution and integration of the functions of the generation device 10 is not limited to that shown in the figure, and all or part of it can be functionally or physically distributed or integrated in any unit depending on various loads, usage conditions, etc.
[0111] Further, all or any part of each process performed in the generating device 10 may be realized by a CPU, a GPU (Graphics Processing Unit), and a program analyzed and executed by the CPU and the GPU. Further, each process performed in the generating device 10 may be realized as hardware using wired logic.
[0112] Furthermore, among the processes described in the embodiments, all or part of the processes described as being performed automatically can be performed manually. Alternatively, all or part of the processes described as being performed manually can be performed automatically by a known method. In addition, the process procedures, control procedures, specific names, and information including various data and parameters described above and shown in the drawings can be changed as appropriate unless otherwise specified.
[0113] [program] 10 is a diagram showing an example of a computer in which a program is executed to realize generating device 10. Computer 1000 has, for example, memory 1010 and CPU 1020. Computer 1000 also has hard disk drive interface 1030, disk drive interface 1040, serial port interface 1050, video adapter 1060, and network interface 1070. Each of these components is connected by bus 1080.
[0114] The memory 1010 includes a ROM 1011 and a RAM 1012. The ROM 1011 stores a boot program such as a BIOS (Basic Input Output System). The hard disk drive interface 1030 is connected to a hard disk drive 1090. The disk drive interface 1040 is connected to a disk drive 1100. A removable storage medium such as a magnetic disk or an optical disk is inserted into the disk drive 1100. The serial port interface 1050 is connected to a mouse 1110 and a keyboard 1120, for example. The video adapter 1060 is connected to a display 1130, for example.
[0115] The hard disk drive 1090 stores, for example, an OS (Operating System) 1091, an application program 1092, a program module 1093, and program data 1094. That is, a program that defines each process of the generating device 10 is implemented as a program module 1093 in which code executable by the computer 1000 is written. The program module 1093 is stored, for example, in the hard disk drive 1090. For example, a program module 1093 for executing the same process as the functional configuration of the generating device 10 is stored in the hard disk drive 1090. The hard disk drive 1090 may be replaced with an SSD (Solid State Drive).
[0116] Furthermore, setting data used in the processing of the above-described embodiment is stored as program data 1094, for example, in memory 1010 or hard disk drive 1090. Then, CPU 1020 reads out program module 1093 or program data 1094 stored in memory 1010 or hard disk drive 1090 into RAM 1012 as necessary, and executes the program.
[0117] Note that the program module 1093 and the program data 1094 are not limited to being stored in the hard disk drive 1090, but may be stored in, for example, a removable storage medium and read by the CPU 1020 via the disk drive 1100 or the like. Alternatively, the program module 1093 and the program data 1094 may be stored in another computer connected via a network (such as a local area network (LAN) or wide area network (WAN)). The program module 1093 and the program data 1094 may then be read by the CPU 1020 from the other computer via the network interface 1070.
[0118] Although the embodiment of the invention made by the present inventor has been described above, the present invention is not limited by the description and drawings that form a part of the disclosure of the present invention according to the present embodiment. In other words, other embodiments, examples, operation techniques, etc. made by those skilled in the art based on the present embodiment are all included in the scope of the present invention. [Explanation of symbols]
[0119] 10 Generator 11 Graph conversion section 12 Regular expression section 13 Extraction part
Claims
1. a graph conversion unit that uses an execution log of the malware to create a first behavior graph in which a subject and a target of an operation in a series of execution processes of the malware are represented as nodes, and operations performed by the subject of the operation on the target of the operation are represented by edges connecting the nodes; a regularization unit that converts the first behavior graph into a second behavior graph in which node labels of the first behavior graph are regularized; an extractor that performs graph mining on the second behavior graph to generate a signature graph; A generating device comprising:
2. the regularization unit, when a path separator character is present in the character string of the node label, calculates a first edit distance by regarding each component separated by the path separator character as one character; The generating device according to claim 1 , characterized in that the regular expression conversion unit obtains a cluster set by clustering the node labels based on the first edit distance, and for each cluster, converts all character strings of the node labels included in the cluster into regular expressions.
3. The generating device according to claim 2 , characterized in that the regular expression conversion unit calculates an edit distance between each component as a second edit distance, and uses the calculated second edit distance as a substitution cost when calculating the first edit distance.
4. The generating device according to claim 2, characterized in that the regular expression conversion unit generates, for each cluster, a string representing both of the two strings of the node label based on the two strings, and converts the generated string into a regular expression in accordance with a predetermined rule.
5. The generation device described in claim 1, characterized in that the extraction unit performs graph mining on the set of second behavior graphs, extracts subgraphs that appear more frequently in behavior graphs corresponding to positive samples that are malware than in behavior graphs corresponding to negative samples that are benign programs, and outputs the extracted set of subgraphs as the signature graph.
6. A generation method implemented by a generation device, comprising: creating a first behavior graph using an execution log of the malware, in which a subject and a target of an operation in a series of execution processes of the malware are represented as nodes, and operations performed by the subject of the operation on the target of the operation are represented by edges connecting the nodes; converting the first behavior graph into a second behavior graph in which node labels of the first behavior graph are regularized; performing graph mining on the second behavior graph to generate a signature graph; A generating method comprising:
7. creating a first behavior graph using an execution log of the malware, in which a subject and a target of an operation in a series of execution processes of the malware are represented as nodes, and operations performed by the subject of the operation on the target of the operation are represented by edges connecting the nodes; converting the first behavior graph into a second behavior graph in which node labels of the first behavior graph are regularized; performing graph mining on the second behavior graph to generate a signature graph; A generating program for causing a computer to execute the above.