Generation device, generation method, and generation program

Abstract

To enable automatic generation of a signature graph in consideration of trace variations.SOLUTION: A generation device 10 is provided, comprising a graph conversion unit 11 configured to use a malware execution log to generate a first behavior graph in which subjects and targets of operations in a series of malware execution processes are represented by nodes and operations executed by the subjects of the operations on the targets of the operations are represented by edges connecting the nodes; an expression regularization unit 12 configured to convert the first behavior graph into a second behavior graph in which expression of node labels of the first behavior graph is regularized at the granularity of alphabetic and numeric character classes; and an extraction unit 13 configured to perform graph mining on the second behavior graph to generate a signature graph.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] The present invention relates to a generation device, a generation method, and a generation 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 take into account variations in traces, nor does it perform pattern generation like regular expressions.

[0014] [regular expression] One way to represent the variations in traces is to express them compactly as regular expressions.

[0015] As mentioned above, EIGER uses regular expressions, but because EIGER compares characters that are in the same position from the beginning of the string, it cannot effectively capture substrings (such as folder names) that are in the middle of a string and have different lengths.

[0016] Therefore, there is SRE (Non-Patent Document 3) as a regular expression generation method that can capture length variations. However, SRE cannot generate patterns with limited character classes. If a pattern that does not limit character classes (e.g., ".{5}") is generated even though the variations are limited to a specific character class (e.g., numbers), there is a risk of false positives. In fact, the variations of traces are often limited to specific character classes.

[0017] What is needed is a regular expression technique that can restrict character classes and capture variations including length.

[0018] Another method that can generate patterns with limited character classes is ARROW (Non-Patent Document 5). ARROW proposes a method to generate regular expressions from a set of URLs. However, URL components (substrings separated by characters such as "?", "&", "=", and " / ") are used as units of comparison, and even if only a part of a component differs between input strings, the entire component is replaced with the pattern. [Prior art documents] [Non-patent literature]

[0019]

Non-Patent Document 1

Non-Patent Document 2

Non-Patent Document 3

[0020] 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.

[0021] However, no method has yet been proposed for automatically generating signature graphs that takes into account variations in traces.

[0022] 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]

[0023] In order to solve the above-mentioned problems and achieve the object, the generation device of the present invention is characterized by 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 regularization unit that converts the first behavior graph into a second behavior graph in which the node labels of the first behavior graph are regularized at the granularity of alphabetical and numeric character classes, and an extraction unit that performs graph mining on the second behavior graph to generate a signature graph. Effect of the Invention

[0024] According to the present invention, a signature graph that takes into account variations in traces can be automatically generated. [Brief description of the drawings]

[0025] [Figure 1] FIG. 1 is a diagram illustrating an example of a configuration of a generating device according to an embodiment. [Diagram 2]FIG. 2 is a diagram illustrating an example of a data configuration of the execution log. [Diagram 3] FIG. 3 is a flowchart illustrating an example of a process executed by the graph conversion unit illustrated in FIG. [Figure 4] FIG. 4 is a diagram illustrating an example of the first behavior graph. [Diagram 5] FIG. 5 is a flowchart illustrating an example of a process executed by the regularization unit illustrated in FIG. [Figure 6] FIG. 6 is a diagram showing the processing contents of the Align subroutine. [Figure 7] FIG. 7 is a diagram showing input / output patterns in the Character Similarity (hereinafter, referred to as CharSimilarity) subroutine. [Figure 8] FIG. 8 is a diagram showing input / output patterns in the Lookup Character Compare Table (hereinafter, referred to as LookupCharCompTab) subroutine. [Figure 9] FIG. 9 is a flowchart illustrating an example of a process executed by the extraction unit illustrated in FIG. [Figure 10] FIG. 10 is a diagram showing an example of a signature graph output by the generating device shown in FIG. [Figure 11] FIG. 11 is a diagram illustrating an example of a computer that realizes the generating device by executing a program. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0026] 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.

[0027] As an embodiment, we propose a new method for generating a signature graph. In the embodiment, we describe a new method for automatically generating a signature graph that expresses trace variations as regular expressions using regular expressions with character class granularity, specifically, a new method for automatically generating a signature graph that includes regular expressions in node labels.

[0028] 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.

[0029] Here, in this embodiment, a method is realized for converting the node labels of each class into regular expressions at the granularity of character classes of alphabets and numbers. As a result, in this embodiment, regular expressions at the granularity of character classes are realized as follows. Specifically, in this embodiment, "xhde309" and "luih756" are converted into the regular expression "[a-zA-Z]{4}[0-9]{3}". Note that conventional technology (for example, Non-Patent Document 3) only converts "xhde309" and "luih756" into ".{7}".

[0030] [Generation device] A generating device according to the present embodiment will be described below. Fig. 1 is a diagram showing an example of the configuration of a generating device according to the present embodiment.

[0031] 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.

[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. 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. 2 is a diagram showing an example of the data configuration of an execution log. As shown in Fig. 2, 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. 3 is a flowchart showing an example of a process executed by the graph conversion unit 11 shown in Fig. 1.

[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. 3.

[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. 4 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. 4 based on the execution log shown in Fig. 2. Note that in the first behavior graph shown in Fig. 4, labels indicating the types of operations are omitted from the edges.

[0052] For example, as shown in FIG. 4, the graph conversion unit 11 creates nodes indicating the subject of the operation in the execution log shown in FIG. 2 (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. 4. 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. 4, ““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 node labels of the first behavior graph into a second behavior graph in which the node labels are regularized at the granularity of alphabetical and numeric character classes. The regular expression conversion unit 12 obtains a cluster set by clustering the node labels based on the edit distance between the character strings of the node labels, and converts all the character strings of the node labels included in each cluster into regular expressions.

[0057] At this time, the regular expression conversion unit 12 performs an Align subroutine (generation process) for each cluster to generate a single string representing both of the two strings in the node label, and converts the string generated in the Align subroutine into an equivalent regular expression in accordance with predetermined rules.

[0058] Here, the output of the Align subroutine and the conversion target for the regular expression may include wildcards including alphabets and numbers. The regular expression conversion unit 12 uses a predetermined rule during the Align subroutine. The rule used during the Align subroutine is a rule in which a value or character to be output according to two input characters is predetermined. The two characters are either a wildcard including alphabets and numbers, or a non-wildcard.

[0059] FIG. 5 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 labels of nodes of 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 regularization unit 12 obtains, as a cluster set CS, a result of clustering the set L of labels using the DBSCAN algorithm based on the edit distance between the character strings of the node labels (step S24).

[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. The regularization unit 12 executes the Align subroutine (p=Align(p, l)) for each label l in each cluster C (step S28). Align(p, l) generates a single string representing both of the two strings of the node labels based on the two strings. Note that Align(p, l) refers to the output obtained by inputting p and l to the Align subroutine. The same applies to Convert(p) described later.

[0065] When the loop of steps S27 to S29 ends, the regular expression conversion unit 12 converts the execution result p of the Align subroutine 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. 5, 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 edit distance is used as a distance function (metric) between data points for clustering, but the applicable method is not limited to this. For example, any function that expresses the similarity between two character strings can be used. For example, there is the Jaro-Winkler distance.

[0070] [Align subroutine] The Align subroutine shown in step S28 of Fig. 5 will now be described. The Align subroutine takes two character strings (which may include wildcards) as input, and outputs a character string that represents both of them. Here, as shown in Fig. 5, the input is two labels (character strings), and the output is a character string that represents both labels.

[0071] The Align subroutine introduces "α" and "δ" as wildcards in addition to "*" and "?" used in SRE. "*" is a symbol that represents any one character or zero characters. "?" is a symbol that represents any one character. "δ" is a symbol that represents one numeric character ("[0-9]" in regular expressions). "α" is a symbol that represents any alphabetic character ("[a-zA-Z]" in regular expressions). Wildcards can be included as output in the loop processing of the Align subroutine, and may also be included as input to the Align subroutine.

[0072] In this way, unlike SRE, the Align subroutine generates character strings including wildcards of the granularity of character classes including alphabets and numbers. With the addition of wildcards, the Align subroutine has changed the character comparison process as shown in Figures 7 and 8 compared to the conventional technology (e.g., Non-Patent Document 3).

[0073] FIG. 6 is a flowchart showing an example of the process of the Align subroutine.

[0074] The Align subroutine calculates the highest score (equation (2) in Non-Patent Document 3) from among all the correspondences between the characters of the input strings X and Y, and outputs the wildcard string R obtained from the correspondence. The Align subroutine uses dynamic programming.

[0075] The Align subroutine uses tables F, PTR, and T. Note that (table name)[i][j] represents the cell in the i-th column and j-th row of the table. Row and column numbers start from 0.

[0076] F[i][j] in table F (first table) represents the optimal score for matching between "a substring of X up to the i-th character" and "a substring of Y up to the j-th character." Table F shows the closeness of substrings including all characters up to that character in the string.

[0077] PRT[i][j] in table PTR (second table) indicates which cell (left, top, or top left) value F[i][j] is based on. By repeatedly tracing these values, the optimal character correspondence between "substring up to the i-th character of X" and "substring up to the j-th character of Y" can be found. Table PTR is a table that indicates the optimal character correspondence up to that character.

[0078] When comparing "substring up to the i-th character of X" in table T with "substring up to the j-th character of Y", it represents the number of consecutive characters that match from the right end (for example, "2" for "abc" and "edbc"). By adding a score according to the value of T (specifically, adding enc(T[i][j]) (described later)), it becomes easier for non-wildcard characters to appear consecutively in the final output result.

[0079] The enc function, as described above, is a function that represents the bonus score given when n consecutive characters match. Here, as an example, enc(n)=2n.

[0080] As shown in FIG. 6, in the Align subroutine, two character strings X and Y are input (step S41).

[0081] In the Align subroutine, N=the length of X, M=the length of Y, F=a table (first table) with (N+1) rows and (M+1) columns, PTR=a table (second table) of the same size as F, T=a table of the same size as F, and Δ=-1 (step S42).

[0082] Then, in the Align subroutine, the cell in the 0th row and the cell in the 0th column of tables F, PTR, and T are initialized with appropriate values ​​(step S43).

[0083] In the Align subroutine, the processes of steps S44 to S50 are repeatedly performed for each cell as a loop (iteration). In the Align subroutine, the processes of steps S44 to S50 are performed in order from cell [0][0] to cell [N][M].

[0084] First, in the Align subroutine, c1=the i-th character of X, and c2=the j-th character of Y (step S45). In the Align subroutine, it is determined whether c1 and c2 are equal and neither is a wildcard (step S46).

[0085] If c1 and c2 are equal and both are wild cards (step S46: Yes), then T[i][j]=T[i-1][j-1]+1 is set (step S47). On the other hand, if c1 and c2 are different or either one is a wild card (step S46: No), then T[i][j]=0 is set (step S48).

[0086] Next, in the Align subroutine, cs=CharSimilarity(c1, c2) is calculated according to the CharSimilarity subroutine (first rule) (step S49), where cs is a value indicating the similarity according to the combination of characters to be compared.

[0087] The CharSimilarity subroutine will now be described. Fig. 7 is a diagram for explaining the CharSimilarity subroutine. In the CharSimilarity subroutine, two characters (c1, c2) are input, and the value of cs is output based on the table shown in Fig. 7.

[0088] The CharSimilarity subroutine is a rule used in creating table F, in which a value indicating the similarity is associated with each combination of characters to be compared. Two characters (c1, c2) are either wildcards ("*", "?", "α", "δ") including alphabets and numbers, or non-wildcards.

[0089] In the CharSimilarity subroutine, the output cs values ​​(0, 1, 3) correspond to each combination of wildcard and wildcard, wildcard and non-wildcard, and non-wildcard and non-wildcard.

[0090] In step S49, score1, score2, and score3 are calculated.

[0091] score1, score2, and score3 are as follows. score1=F[i-1][j-1]+cs+enc(T[i][j]) score2=F[i-1][j]+Δ score3=F[i][j-1]+Δ

[0092] In step S49, the maximum of score1, score2, and score3 is assigned to the cell in the i-th column and j-th row of the F table (F[i][j]). Then, in step S49, depending on which score is the maximum, "Diagonal", "Up", or "Left" is assigned to the cell in the i-th column and j-th row of the PTR table (PTR[i][j]). Specifically, if score1 is the maximum, "Diagonal" is assigned, if score2 is the maximum, "Up" is assigned, and if score3 is the maximum, "Left" is assigned.

[0093] In the Align subroutine, when the loop (iteration) ends (step S50), R="" (empty character string) is set (step S51).

[0094] By referring to the direction information "Dial", "Up", and "Left" stored in table PTR and tracing backwards using the direction information written in table PTR, the correspondence between character strings X and Y can be found. Therefore, in the Align subroutine, the direction information of each cell in table PTR is referred to as a loop (traceback). Then, starting from [N][M] on table T, the process moves to the upper left, up, or left depending on the value of that cell, repeating this process until it reaches [0][0] (steps S52 to S54). During this process, the following step S53 is executed for each cell [i][j].

[0095] In the Align subroutine, c1=the i-th character of X, c2=the j-th character of Y, and r=LookupCharCompTab(c1, c2) is obtained according to LookupCharCompTab (second rule) (step S53). The LookupCharCompTab subroutine is a rule used when generating one character string representing both of two character strings by referring to the table PTR. The LookupCharCompTab subroutine associates the output character with the combination of two input characters.

[0096] The LookupCharCompTab subroutine will now be described with reference to FIG.

[0097] The LookupCharCompTab subroutine inputs two characters (c1, c2) and outputs the value of r based on the table shown in Fig. 8. In the table shown in Fig. 8, the character to be output corresponds to the combination of the two input characters. The two characters (c1, c2) are either wildcards including alphabets and numbers ("*", "?", "α", "δ") or non-wildcards.

[0098] In the LookupCharCompTab subroutine, the output characters r ("*", "?", "α", "δ", "x") are associated with each combination of wildcards and wildcards, wildcards and non-wildcards, and non-wildcards and non-wildcards.

[0099] Then, in step S53, the letter r is inserted at the beginning of R.

[0100] In the Align subroutine, when the loop (traceback) ends (step S54), R is output as the execution result p of the Align subroutine (step S55), and the process ends.

[0101] [Convert subroutine] The following describes the Convert subroutine in step S30 of Fig. 5. The Convert subroutine receives as input a character string X that includes a wildcard, and performs the following processes.

[0102] First, the Convert subroutine converts a string X into an equivalent regular expression r.

[0103] In the Convert subroutine, the symbol "*" is converted to ".?". The symbol "?" is converted to ".". The symbol "δ" is converted to "[0-9]". The symbol "α" is converted to "[a-zA-Z]".

[0104] In the Convert subroutine, if the same wildcard appears multiple times, it will be grouped together using ".{n}". For example, "xδδαααabc" will be converted to "x[0-9]{2}[a-zA-Z]{3}abc".

[0105] 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.

[0106] The Convert subroutine outputs the converted regular expression r.

[0107] [Extraction part] The extraction unit 13 generates a signature graph based on the second behavior graph in which the node labels are regularized. Fig. 9 is a flowchart showing an example of a process executed by the extraction unit 13 shown in Fig. 1 .

[0108] The extraction unit 13 receives a set S of second behavior graphs as an input (step S61). 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 S62).

[0109] 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 S63).

[0110] 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 S64).Then, the extraction unit 13 outputs the subgraph set SG as a signature graph (step S65).

[0111] 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.

[0112] 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.

[0113] [Signature graph example] Fig. 10 is a diagram showing an example of a signature graph output by the generation device 10 shown in Fig. 1. Note that the label of the signature graph that is actually output depends on which parts are actually common to other similar samples.

[0114] As shown in FIG. 10, the label of the node with the root label, which is the subject of the operation in the execution log, has been replaced with the regular expression ".*" in the process of step S54.

[0115] And the label of the node "C:\Temp\Ddcu49\logger.exe" which is connected to the node with the ".*" label is expressed as "C:\\Temp\\[a-zA-Z]{4}[0-9]{2}\\logger\.exe" which is the regular expression of each alphabet and number in the "Ddcu49" part.

[0116] In addition, the label of the node ""C:\Temp\Ddcu49\logger.exe" --detach" which connects to the node with the ".*" label is expressed as ""C:\\Temp\\[a-zA-Z]{4}[0-9]{2}\\logger\.exe" --detach"" which is a regular expression of each alphabet and number in the "Ddcu49" part.

[0117] Note that the node label “C:\Temp\logs.txt” that is connected to the node label “"C:\Temp\Ddcu49\logger.exe" --detach” is determined by other behavior graphs, and remains “C:\Temp\logs.txt” in the example of Fig. 10.

[0118] [Effects of the embodiment] As illustrated in FIG. 10, 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 down to the granularity of alphabetical and numeric character classes.

[0119] The generating device 10 obtains a cluster set by clustering the node labels based on the edit distance between the character strings of the node labels. For each cluster, the generating device 10 performs an Align subroutine to generate one character string representing both of the two character strings of the node labels. The generating device 10 converts the character string generated in the Align subroutine into an equivalent regular expression according to a predetermined rule, and performs graph mining to generate a signature graph.

[0120] Here, the generating device 10 uses a rule in which a value and a character to be output according to two input characters are predetermined during the Align subroutine. The two input characters are either a wildcard including alphabets and numbers or a non-wildcard. The generating device 10 executes the Align subroutine using a rule corresponding to the wildcard including alphabets and numbers and the non-wildcard.

[0121] This allows the generation device 10 to regularize the node labels down to the granularity of alphabetical and numeric character classes (Figure 5), remove variations, and then perform graph mining to extract patterns that contain variations in the traces.

[0122] Therefore, the generation device 10 can automatically generate a signature graph that expresses the variation of the trace as a regular expression down to the granularity of the character classes of the alphabet and numbers. The generation device 10 can absorb the variation of the trace with the regular expression and generate a signature graph that expresses more samples. On the analysis side, more unknown samples can be detected based on this signature graph.

[0123] 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.

[0124] [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.

[0125] 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.

[0126] 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.

[0127] [program] 11 is a diagram showing an example of a computer in which a program is executed to realize the generating device 10. The computer 1000 has, for example, a memory 1010 and a CPU 1020. The computer 1000 also has a hard disk drive interface 1030, a disk drive interface 1040, a serial port interface 1050, a video adapter 1060, and a network interface 1070. These components are connected by a bus 1080.

[0128] 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.

[0129] 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).

[0130] 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.

[0131] 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.

[0132] 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]

[0133] 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 at the granularity of alphabetic and numeric character classes; an extractor that performs graph mining on the second behavior graph to generate a signature graph; A generating device comprising:

2. the regular expression conversion unit obtains a cluster set by clustering the node labels based on an edit distance between character strings of the node labels, performs a generation process for each cluster to generate a single character string representing both of the two character strings of the node labels based on the two character strings of the node labels, and converts the character string generated in the generation process into an equivalent regular expression in accordance with a predetermined rule; The output of the generation process and the conversion target of the regular expression may include wildcards including alphabets and numbers. The generating device according to claim 1 .

3. During the generation process, a value or character output according to two input characters is determined using a predetermined rule, The two characters can be either wildcards, including letters and numbers, or non-wildcards. The generating device according to claim 2 .

4. the regular expression conversion unit creates, in the generation process, a first table indicating a closeness of a substring including all characters up to the character in the string, and a second table indicating an optimal correspondence of characters up to the character; the regular expression unit uses a first rule in which a value indicating a closeness is associated with a combination of characters to be compared when creating the first table; the regular expression conversion unit uses a second rule in which an output character corresponds to a combination of two input characters when creating the one character string based on the second table; The comparison character and the two characters are either wildcards or non-wildcards, including alphabets and numbers. The generating device according to claim 3 .

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 as 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 at the granularity of alphabetic and numeric character classes; 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 as 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 at the granularity of alphabetic and numeric character classes; performing graph mining on the second behavior graph to generate a signature graph; A generating program for causing a computer to execute the above.

Images