KR20200076426A - Method and apparatus for malicious detection based on heterogeneous information network - Google Patents

Abstract

Disclosed are a method for detecting a malignant code based on a heterogeneous information network and a device thereof. According to one embodiment of the present invention, the method for detecting a malignant software comprises the steps of: extracting features from a portable executable (PE) files; generating a heterogeneous information network (HIN) for a relationship between the PE files and the features; and detecting whether the PE files are malignant software by using a meta path on the HIN.

Description

METHOD AND APPARATUS FOR MALICIOUS DETECTION BASED ON HETEROGENEOUS INFORMATION NETWORK}

The embodiments below relate to a method and apparatus for detecting malicious code based on a heterogeneous information network.

Methods for analyzing malicious code in software include a signature test method, a cyclic redundancy check (CRC) test method, and a heuristic test method.

Fingerprint inspection is one of the methods that a security program diagnoses malicious code as if looking at a fingerprint when distinguishing a person. That is, the unique character string (pattern) possessed by the malicious code is collected and stored in a database, and the malicious code is analyzed by using a method of matching the security program pattern.

The CRC test method is an error detection method for verifying the reliability of data in serial transmission, and has an advantage of low error rate, but has a disadvantage in that it can diagnose malicious code if the data is modified even if it is 1 byte.

Recently, as an analysis method of malicious code, an empirical technique that improves the function of fingerprint inspection is mainly used, which is one of the learning-based analysis methods that analyzes the behavior of malicious code or analyzes the method and learns itself. That is, in the case of malicious software, a unique combination of API commands is often used, and an empirical technique learns a combination of unique API commands as described above to determine whether malicious code is based on the API command.

With the rapid development of the Internet, various types of security threats have rapidly increased, and among them, the malicious software of the traditional PC platform has been most prevalent. Due to complex packaging, confusion, anti-sandboxing, virtual penetration and other technology developments, existing methods of detecting malicious software are not satisfactory.

In the information network era, more and more malicious software poses a serious threat to security. It is especially important to detect malicious software attacks in a timely and effective manner. For increasingly sophisticated malicious software, new defense technologies are needed to detect and respond to new attacks and threats.

Embodiments may provide a technique for analyzing a PE file, extracting characteristics, constructing a HIN for a relationship between characteristics, and then detecting whether the corresponding PE file corresponds to malicious software using a meta-path-based method.

The malicious software detection method according to an embodiment includes extracting characteristics from Portable Executable (PE) files, generating a heterogeneous information network (HIN) for the relationship between the PE files and the characteristics, and And detecting whether the PE files are malicious software using a meta path on the HIN.

The properties may include PE header information, API calls, DLL and Opcode sequences.

The detecting may include detecting whether the PE files are malicious software by calculating the similarity between the PE files using the meta path on the HIN.

The relationship includes the first relationship between the PE file and the API call, the second relationship to the attribute value of the PE header information of the PE file, the third relationship to the package to which the API call belongs, and the fourth relationship to the API sequence of the PE file , And a fifth relationship for the Opcode sequence of the PE file.

The meta-path includes a first meta-path constructed through a first matrix expressing the first relationship, a second meta-path constructed through a second matrix expressing the second relationship, and a third matrix expressing the third relationship. A third meta-path configured through, a fourth meta-path configured through a fourth matrix expressing the fourth relationship, and a fifth meta-path configured through a fifth matrix expressing the fifth relationship.

The meta-path further includes a meta-path that is linearly combined by optimizing the first meta-path, the second meta-path, the third meta-path, the fourth meta-path, and the fifth meta-path through multi-kernel learning. Can.

The meta-path includes a first meta-path constructed through a first matrix expressing the first relationship, a second meta-path constructed through a second matrix expressing the second relationship, and a third matrix expressing the third relationship. Through a multi-kernel learning, a third meta-path constructed through, a fourth meta-path constructed through a fourth matrix expressing the fourth relationship, and a fifth meta-path constructed through a fifth matrix expressing the fifth relationship through It may be a meta-path that is optimized and linearly coupled.

A malicious software detection apparatus according to an embodiment includes a receiver that receives Portable Executable (PE) files, extracts characteristics from the PE files, and a heterogeneous information network (HIN) for the relationship between the PE files and the characteristics And a controller that detects whether the PE files are malicious software using a meta path on the HIN.

The properties may include PE header information, API calls, DLL and Opcode sequences.

The controller may detect whether the PE files are malicious software by calculating the similarity between the PE files using the meta path on the HIN.

The relationship includes the first relationship between the PE file and the API call, the second relationship to the attribute value of the PE header information of the PE file, the third relationship to the package to which the API call belongs, and the fourth relationship to the API sequence of the PE file , And a fifth relationship for the Opcode sequence of the PE file.

The meta-path includes a first meta-path constructed through a first matrix expressing the first relationship, a second meta-path constructed through a second matrix expressing the second relationship, and a third matrix expressing the third relationship. A third meta-path configured through, a fourth meta-path configured through a fourth matrix expressing the fourth relationship, and a fifth meta-path configured through a fifth matrix expressing the fifth relationship.

The meta-path further includes a meta-path that is linearly combined by optimizing the first meta-path, the second meta-path, the third meta-path, the fourth meta-path, and the fifth meta-path through multi-kernel learning. Can.

The meta-path includes a first meta-path constructed through a first matrix expressing the first relationship, a second meta-path constructed through a second matrix expressing the second relationship, and a third matrix expressing the third relationship. Through a multi-kernel learning, a third meta-path constructed through, a fourth meta-path constructed through a fourth matrix expressing the fourth relationship, and a fifth meta-path constructed through a fifth matrix expressing the fifth relationship through It may be a meta-path that is optimized and linearly coupled.

1 shows an apparatus for performing a malicious software detection method according to an embodiment.
FIG. 2 is a schematic block diagram of the malicious software detection device shown in FIG. 1.
FIG. 3 is a schematic block diagram of the controller shown in FIG. 2.
FIG. 4 shows a schematic block diagram of the PE file analyzer shown in FIG. 3.
5A and 5B are diagrams for explaining an example of an operation in which the PE file analyzer illustrated in FIG. 3 extracts characteristics.
6 is a view for explaining the operation of the HIN generator shown in FIG.
FIG. 7 is a diagram for explaining the multi-kernel learner and classification model illustrated in FIG. 3.
8 is a graph for explaining the experimental results performed by the malicious software detection method according to an embodiment.

Hereinafter, embodiments will be described in detail with reference to the accompanying drawings. However, various modifications may be made to the embodiments, and the scope of the patent application right is not limited or limited by these embodiments. It should be understood that all modifications, equivalents, or substitutes for the embodiments are included in the scope of rights.

The terms used in the examples are for illustrative purposes only and should not be construed as limiting. Singular expressions include plural expressions unless the context clearly indicates otherwise. In this specification, the terms "include" or "have" are intended to indicate the presence of features, numbers, steps, actions, components, parts or combinations thereof described in the specification, one or more other features. It should be understood that the existence or addition possibilities of fields or numbers, steps, operations, components, parts or combinations thereof are not excluded in advance.

The terms first or second may be used to describe various components, but the components should not be limited by the terms. The terms are for the purpose of distinguishing one component from another component, for example, without departing from the scope of rights according to the concept of the embodiment, the first component may be referred to as the second component, and similarly The second component may also be referred to as the first component.

Unless otherwise defined, all terms used herein, including technical or scientific terms, have the same meaning as commonly understood by a person skilled in the art to which the embodiment belongs. Terms, such as those defined in a commonly used dictionary, should be interpreted to have meanings consistent with meanings in the context of related technologies, and should not be interpreted as ideal or excessively formal meanings unless explicitly defined in the present application. Does not.

In addition, in the description with reference to the accompanying drawings, the same reference numerals are assigned to the same components regardless of reference numerals, and redundant descriptions thereof will be omitted. In describing the embodiments, when it is determined that detailed descriptions of related well-known technologies may unnecessarily obscure the subject matter of the embodiments, detailed descriptions thereof will be omitted.

1 shows an apparatus for performing a malicious software detection method according to an embodiment.

The malicious software detection apparatus 100 not only relies on API calls, but also analyzes the relationship between them and prevents an attacker who evades detection from higher-level semantics, or higher-level semantics. To create a semantic system) to detect new malicious software. Through this, the malicious software detection device 100 can detect malicious codes in various operating systems such as Android malicious codes and Window malicious codes.

The malicious software detection apparatus 100 builds a heterogeneous information network (HIN) through a rich relationship between software and related APIs, and then performs a meta-path based method to perform software and API Semantic relevance can be analyzed.

The malicious software detection apparatus 100 calculates the similarity between software (for example, PE files) using each meta-path, and uses a multi-kernel learning (MKL) to construct a detection model, and uses different similarities. By counting, the detection model was trained.

The malicious software detection apparatus 100 may obtain a relatively high detection rate and a low false detection rate.

FIG. 2 is a schematic block diagram of the malicious software detection device shown in FIG. 1.

The malicious software detection device 100 includes a receiver 200, a controller 300, and a memory 400.

The memory 400 may store instructions (or programs) executable by the controller 300. For example, instructions may be performed for each configuration (310 to 370 shown in FIG. 3) included in the controller 300. It may include instructions for executing.

The receiver 200 may receive PE files.

The controller 300 may control the overall operation of the malicious software detection device 100. The controller 300 may detect whether the PE files received from the receiver 200 correspond to malicious software.

The controller 300 may analyze PE files and analyze the relationship between them using the same package name or the same property value. The controller 300 may perform a higher level semantic analysis through various types of relationships between APIs and PE files and the PE files themselves.

The controller 300 may generate a structured heterogeneous information network (HIN) representation representing PE files and APIs to express the rich meaning of the relationships. In addition, the controller 300 may build a semantic relevance of PE files by integrating a higher level of meaning using a meta-path.

The controller 300 can calculate whether to use the same APIs in this way, as well as calculate whether the usage patterns such as the same package are similar to calculate similarity between PE files. At this time, since the paths describing the similarity between two identical PE files are different, the controller 300 can automatically learn the weights of different similarities using data using multi-kernel learning algorithms. .

The controller 300 may detect whether the PE files correspond to malicious software by using the meta path learned through the kernel learning algorithm.

FIG. 3 is a schematic block diagram of the controller shown in FIG. 2.

The controller 300 includes a PE File Analyzer (PE File Analyzer) 310, a HIN Constructor (330), a Multi Kernel Learner (350), and a Classification Model (370).

The PE file analyzer 310 parses (or parses) the PE tables of all executable files (PE files), so that all PE header information inside each DLL, DLL names, and Opcode The sequence (Opcode sequence) and API functions (API functions) can be extracted as features (rfeatures).

The HIN generator 330 may configure HIN based on the extracted characteristics. The HIN generator 330 may first establish a connection between PE files and the extracted API call, and define a relationship type between these API calls and a connection between PE files and PE file information.

Adjacency matrices between different object types can then be generated, and commuting matrices of different metapaths can be enumerated and written.

The multi-kernel learner 350 may build a kernel of SVM (Support Vector Machines) given HIN commuting matrices. The multi-kernel learner 350 may use standard multi-kernel learning to optimize weights of different meta paths. Given a meta-path weight, all commuting matrices can be combined to formulate a more powerful malware detection kernel.

The classification model 370 may also be referred to as a malicious software detector. For each newly collected unknown software, the PE file parser 310 will first parse this software PE file, then extract the PE header information, DLL name, Opcode sequence, and API calls and further analyze. Using the classification model 370 created based on these extracted characteristics, a PE file (eg, software) may be classified as either benign or malicious code.

FIG. 4 shows a schematic block diagram of the PE file analyzer shown in FIG. 3, and FIGS. 5A and 5B are diagrams for explaining an example of an operation in which the PE file analyzer shown in FIG. 3 extracts characteristics.

4 and 5 describe a detailed approach on how to express PE files using extracted characteristics and a method of solving a classification problem based on the extracted characteristics.

The PE file analyzer 310 may include a decompiler (313), a feature extractor (315), and an analyzer (317). The decompiler 313 may pre-process PE files and decompile the pre-processed PE files. The feature extractor 315 can automatically extract features, such as API calls and other related information, from PE files.

The PE file analyzer 310 may include a decompiler (313), a feature extractor (315), and an analyzer (317). The decompiler 313 may pre-process PE files and decompile the pre-processed PE files.

The feature extractor 315 can automatically extract features, such as API calls and other related information, from PE files.

In this case, API calls may be converted into a group of global (or global) integer IDs representing a static execution sequence of the corresponding API call. Similarly, PE file information, Opcode sequences, and DLLs can also be converted into corresponding global integer IDs.

When extracting the API sequence, the feature extractor 315 must first generate a control flows graph. A control flow is a sequence of program statements by a run path consisting of a single assembler instruction. Each function is a basic block and is a collection of consecutive assembly instructions. The entry for the control flow is the start instruction of the basic block, and jumps from this basic block after the instruction ends. The assembly code includes several sub-functions, and these sub-functions increase the jump between basic blocks to construct the entire program control flow graph as shown in Fig. 5A.

In the assembly instructions, depending on the role of the control flow graph, it can be divided into general, jmp, jcc, call, return, and start. It keeps only the call instruction node, key function item and return to extract the API call. In this way, the feature extractor 315 obtains a simplified diagram of the control flow graph as shown in FIG. 5B. Finally, the feature extractor 315 searches the simplified control flow graph according to the order of the instructions to extract the API sequence (API call sequence).

The extraction of opcode sequences is similar to the extraction of API sequences. Build a control flow graph for the opcode, then navigate through the flow graph to extract all possible execution sequences. Since the feature extractor 315 searches only for a loop according to a self-loop included in a sub-function, an opcode sequence of PE files can be extracted.

The analyzer 317 may generate matrices using the extracted characteristics. The matrices are matrices for the PE file, and may be matrices expressing the relationship between the PE file and the extracted characteristics. For example, the relationship is the first relationship for the PE file and the API call, the second relationship for the attribute value of the PE header information in the PE file, the third relationship for the package to which the API call belongs, and the API sequence for the PE file. The fourth relationship may include a fifth relationship for the Opcode sequence of the PE file.

■ PE header information

을 표현하기 위해, 분석기(317)는 속성값 행렬(property-value matrix)

을 생성한다. 여기서, 각 요소

는 속성들의 쌍(pair)이 같은 값인지를 나타낸다.PE header information includes important information such as name, size, offset, and type. The above-described information is called a property, and these values are called a property value. Two PE files with the same attribute value have similarities. This kind of relationship

In order to represent, the analyzer 317 has a property-value matrix.

Produces Where each element

Indicates whether the pair of properties is the same value.

■ API Package

API calls can be used to indicate the behavior of a PE file, and the relationship between API calls can imply information that is important for detecting malicious software. All API calls in PE files belong to the same or different dynamic link library (DLL). We found that API calls belonging to the same DLL always show the same intent. It is said that APIs in the same DLL belong to the same package.

According to the provided function, the Windows API can be classified into 7 categories. The seven categories are basic services (kernel32.dll, advapi32.dll, etc.), graphical device interface, graphical user interface (user32.dll), common dialog links library, and universal space link library. ), Windows shell, web services.

For example, the API calls in the "advapi32.DLL" DLL are related to registry calls. API calls appear jointly in the same package and represent a strong relationship between the two.

를 나타내기 위해, 분석기(317)는 공통 패키지 행렬(co-package matrix)

을 생성한다. 여기서, 각 요소

는 API 호출들의 한 쌍이 같은 패키지에 있는지를 나타낸다. 예를 들어, 동일한 패키지 "advapi32.DLL"에서 두 개의 서로 다른 API 인 "RegDeleteKeyA"와 "RegQueryValueExA"가 두 개의 PE 파일들에서 호출된다. 이 두 API 간의 관계를 나타내는 행렬의 값은 1일 수 있다.This kind of relationship

To indicate, the analyzer 317 is a common package matrix (co-package matrix)

Produces Where each element

Indicates whether a pair of API calls are in the same package. For example, two different APIs, "RegDeleteKeyA" and "RegQueryValueExA" in the same package "advapi32.DLL" are called from two PE files. A matrix value representing a relationship between the two APIs may be 1.

■ API sequence.

를 나타내기 위해, 분석기(317)는 API 시퀀스 행렬(API-sequence matrix)

을 생성한다. 여기서, 각 요소

은 속성들의 한 쌍(a pair of properties)이 동일한 API 시퀀스를 갖는지 여부를 나타낸다.During PE file execution, the call sequence of API calls represents an important relationship. Google collects API call sequence (behavior) data and uses 2-sequences of the APIs feature to indicate the relationship between each PE file. For example, the PE file call API sequence is "RegCloseKey → NtClose → GetProcessHeap" and is defined by two properties: "RegCloseKey → NtClose" and "NtClose → GetProcessHeap", and this feature type is recorded as an API sequence. So if you have two PE files with the same API sequence, we think they can have some similarities. This kind of relationship

To indicate, the analyzer 317 is an API sequence matrix (API-sequence matrix)

Produces Where each element

Indicates whether a pair of properties has the same API sequence.

■ Opcode sequence.

를 표현하기 위해, 분석기(317)는 Op-sequence 행렬

을 생성한다. 여기서, 각 요소

는 속성들의 한 쌍이 동일한 Op-sequence를 갖는지 여부를 나타낸다.In malware analysis, the opcode feature can take into account behavioral characteristics of the execution process and describe the malware in more detail. A 2-sequence of Opcode properties is used to indicate the relationship between each PE file. For example, there is a PE file Opcode sequence called “push →push →call” defined by two properties: “push →push” and “push →call”. This characteristic type is recorded as Op-sequence. So if you have two PE files with the same op-sequence, you can assume that they have some similarities. This kind of relationship

To represent, the analyzer 317 is an Op-sequence matrix

Produces Where each element

Indicates whether a pair of attributes have the same op-sequence.

Table 1 shows a summary of descriptions of the different relationships and each element in the relationship matrix.

6 is a view for explaining the operation of the HIN generator shown in FIG.

In FIG. 6, a method of representing PE files using HIN using the characteristics extracted above to better analyze the rich relationship types of the API is described.

및 객체 유형 매핑 함수(object type mapping function)

를 갖는 그래프

이다. 여기서, 각 객체

는 특정 객체 유형

에 속하고, 각 링크

는 특정 관계

에 속한다. 객체 유형들의 수

또는 링크 유형들의 수

인 경우, 이러한 네트워크를 HIN이라고하는 이기종 정보 네트워크라고 한다.The HIN generator 330 may configure HIN based on matrices. HIN is a link type mapping function

And object type mapping function

Graph with

to be. Where each object

Is a specific object type

Each link belongs to

Is a specific relationship

Belongs to Number of object types

Or number of link types

In this case, such a network is called a heterogeneous information network called HIN.

In the system for detecting malicious software, there are five object types. The five object types include PE file, PE header information, Opcode sequence, API call and API sequence. There are four types of relationships. The four relationship types include a PE file containing API calls and PE header information, API calls in the same package, and a PE file with the same API sequence, and a PE file with the same Opcode sequence. Since different object types and different relationship types constitute a rich network of similar relationships, HIN generator 330 can formulate high-level semantic relationships between objects using HIN's metapath approach.

는 네트워크 스키마(network schema)

의 그래프 상의 경로이다. 그 형식은

와 같이 기록되는데, 유형

와 유형

간의 복합 관계(composite relationship)

를 정의한다. 여기서 "

"는 관계(relation)에 대한 복합 연산(complex operation)을 나타낸다. PE 파일의 경우, 일반적인 메타 경로는

이다. 이것은 HIN 내 동일한 API를 통해 두 개의 서로 다른 PE 파일을 연결할 수 있음을 의미한다. HIN 생성기(330)는 PathSim 방법(PathSim method)을 사용하여 메타 경로를 통해 객체들의 유사성을 계산할 수 있다.Meta path

Is the network schema

Is the path on the graph. The format

It is recorded as, type

And type

Composite relationship

Define here "

"Represents a complex operation for a relation. In the case of PE files, a typical metapath is

to be. This means that you can link two different PE files through the same API in HIN. The HIN generator 330 may calculate the similarity of objects through the meta path using the PathSim method.

가 주어지면, 동일한 유형의 객체 와 y에 대한 PathSim 정의(PathSim definition)는 다음과 같다.The PathSim method is a meta-path-based similarity measure. Symmetric meta path

If is given, PathSim definition for the same type of object and y is as follows.

는 x와 y 사이의 경로 인스턴스(path instance)이고,

는 와 x 사이의 경로 인스턴스이고,

는 y와 y 사이의 경로 인스턴스(path instance)이다.here,

Is a path instance between x and y,

Is the path instance between and x,

Is a path instance between y and y.

가 주어진다면,

는 두 부분으로 정의될 수 있다. (1) 메타 경로를 따르는 그들 사이의 경로 수로 정의된 연결성이고 (2) 가시성의 균형이다. 가시성은 그들 사이의 경로 인스턴스들의 수로 정의된다. 경로 인스턴스의 가중치로 경로 인스턴스의 멀티플 발생을 계산할 수 있다. 경로 인스턴스의 가중치는 경로 인스턴스 내 모든 경로들의 가중치 곱이다.This is a meta path

Given,

Can be defined in two parts. (1) connectivity defined by the number of paths between them along the meta path, and (2) balance of visibility. Visibility is defined as the number of path instances between them. Multiple occurrences of the route instance may be calculated by the weight of the route instance. The weight of the path instance is the weight product of all paths in the path instance.

와 네트워크 스키마

가 주어진 경우, 메타 경로

에 대한 맞바꿈 행렬은

로 정의된다. 여기서,

은 유형

와 유형

사이의 인접 행렬(adjacency matrix)이다.

는 메타 경로

에서 객체

과 객체

사이의 경로 인스턴스의 수를 나타낸다.network

And network schema

If given, meta path

The inversion matrix for

Is defined as here,

Silver type

And type

Is the adjacency matrix between.

Meta path

In object

And objects

Indicates the number of path instances between.

이다. 그러면 메타 경로

을 사용하여 계산된 PE 파일들의 맞바꿈 행렬은

, 즉,

이다.

를 행렬

의

번째 로우로 나타내면, PE 파일

와

의 유사도는

로 주어 지는데, 이는 단순히 두 특징 벡터의 내적(dot product)이다. 보다 복잡한 유사성은 메타 경로를 기반으로 한 맞바꿈 행렬에 의해 정의될 수 있다. 즉, 내부 API 호출만 고려하지 않고, 두 앱(예를 들어, PE 파일들) 간의 유사성을 계산한다.For example, the adjacency matrix between PE files and API calls

to be. Meta path

The inversion matrix of PE files calculated using

, In other words,

to be.

Matrix

of

In the first row, PE file

Wow

The similarity of

Is given, which is simply the dot product of two feature vectors. More complex similarities can be defined by an inversion matrix based on metapaths. That is, without considering only the internal API call, the similarity between the two apps (for example, PE files) is calculated.

FIG. 7 is a diagram for explaining the multi-kernel learner and classification model illustrated in FIG. 3.

Given a network schema with relationships with different types of entities, many meta paths can be enumerated. Therefore, an intuitive way is to combine different meta paths.

가 있다고 가정한다. 다중 커널 학습기(350)는 개의 메타 경로에 대응하는 맞바꿈 행렬

을 계산할 수 있다. 여기서

는 커널로 간주된다. 맞바꿈 행렬이 PSD(positive semi-definite)이 아닌 경우, 맞바꿈 행렬의 음의 고유값들(negative eigenvalues)을 제거한다. 다음과 같이, 다중 커널 학습기(350)는 커널들의 선형 결합을 사용하여 새 커널을 형성할 수 있다When classifying PE files, the multi-kernel learner 350 may automatically integrate different similarities using a multi-kernel learning algorithm and determine the weight of each metapath. Meta paths

Suppose there is. The multi-kernel learner 350 has an inversion matrix corresponding to the meta paths of the dogs.

Can be calculated. here

Is considered a kernel. When the inversion matrix is not PSD (positive semi-definite), the negative eigenvalues of the inversion matrix are removed. As described below, the multi-kernel learner 350 may form a new kernel using linear combination of kernels.

이고,

을 만족한다. here,

ego,

Satisfies

을 가정한다. 여기서,

은 PE 파일 (여기서,

을 ID로 간주할 수 있음)이고,

은 라벨(label)이다. 그런 다음 다중 커널 학습기(350)는 다음과 같은 목적 함수(objective function)를 갖는 p-norm 다중 커널 학습 프레임워크(-norm Multi-kernel Learning framework)를 사용하여 다음과 같은 목적 함수를 사용하여 파라미터들을 학습할 수 있다.Set of labeled data to learn the weight of each metapath

Suppose here,

PE file (where

Can be considered as ID),

Is a label. The multi-kernel learner 350 then uses the p-norm multi-kernel learning framework with the following objective function to set parameters using the following objective function: I can learn.

를 학습한다. 각 데이터

에 대해, 슬랙 파라미터

는 오분류(misclassification)를 혀용하기 위해 도입되었다.

는 커널을 정의하는 Hilbert 공간에서의 특징들(features)의 비선형 맵핑이다. 여기서,

이다. 그런 다음 표현 정리(representation theorem)를 적용하면,

을 얻을 수 있다.

는 이중 공식(dual formulation)을 사용하여 해결할 수 있으며, 0이 아닌

들은 지원 벡터들(support vector)로 이어진다.Here, the parameter vector for each kernel

To learn. Each data

About, slack parameter

Was introduced to take advantage of the misclassification.

Is a non-linear mapping of features in the Hilbert space that defines the kernel. here,

to be. Then apply the representation theorem,

Can get

Can be solved using a dual formulation, nonzero

These lead to support vectors.

이외의 다른 매개 변수 집합은

이다. 여기서 -norm

은

들의 최적화를 정규화하는 데 사용된다. 경험적으로 문제에 2- 놈(2-norm)을 적용할 수 있다. 최적화 후, 가중치

는 커널들로 사용되는 메타 경로들의 중요성을 나타내기 위해 최적화된다. 새로운 PE 파일 x가 오는 경우, PE 파일이 악의적인지 여부를 평가하는 데

이 사용된다.In a multi-kernel learning framework,

A set of parameters other than

to be. Where -norm

silver

Used to normalize their optimization. Empirically, you can apply a 2-norm to a problem. After optimization, weight

Is optimized to indicate the importance of metapaths used by kernels. When a new PE file x comes, it is used to evaluate whether the PE file is malicious

Is used.

8 is a graph for explaining the experimental results performed by the malicious software detection method according to an embodiment.

The experiment was performed by selecting 1000 malicious samples and 1000 benign samples. Malicious samples included Worm, Backdoor, Trojan, and Rootkit, and positive samples included viewers, games, browsers, etc. Became. To evaluate the performance of the proposed method, accuracy, true positive ratio (TPR), true negative ratio (TNR), false positive ratio (FPR), false negative The ratio (FNR (false negative ratio)) was measured, and the relevant measurements are shown in Table 2.

In this set of experiments, a classification model (or detection model) was constructed by randomly dividing the malicious and positive samples into 5 subsets and 4 subsets (800 of which are positive samples, and the remaining 800 are malicious samples). The remaining 1 subset was used for model testing (200 of which were classified as positive and 200 as malignant).

After extracting the characteristics from the experimental set and creating a relationship between them, five meta-paths were constructed using SVM (Support Vector Machine) and the detection performance was compared. In addition, all metapaths (SS ^T , SVS ^T , SPS ^T , SAS ^T , SOS ^T ) were used to experiment by applying multi-kernel learning. The results of these experiments are shown in Table 3 and FIG. 8.

In the experiment, we can apply the single meta-path generation model and confirm that the experimental results based on the meta-path of the API sequence are the best. This corresponds to a true detection rate of 95.5% and a false detection rate of 3.5%.

Conversely, the experimental results based on the meta-path of PE header information attribute values are low. This corresponds to a true detection rate of 84.5% and a false detection rate of 16.5%. It can be seen that there are many untrusted attribute values in the attributes of PE header information. These unreliable attribute values can exacerbate experimental results.

Using MKL (Multi-kernel Learning), all meta-path configuration detection models were combined to obtain the best experimental results. The actual detection rate was 98.5%, the false detection rate was 2%, and the accuracy was 98.25%. The results of this experiment show that the performance of the proposed method is effective.

Based on the above-described experimental results, the malicious software detection method according to the embodiment may filter and use attributes of PE header information, remove unreliable attributes, and extract and use more important characteristics to improve classification model performance. In addition, the malicious software detection method according to the embodiment may extend the length of the meta-path and further increase the connection between meta-paths (eg, SOAO ^T S ^T , SVPV ^T S ^T, etc.).

1 to 8, a new malicious software detection method based on a heterogeneous information network (HIN) has been described. Embodiments analyze PE files, extract PE header information, API calls, DLLs, and opcodes as features, build HINs for relationships between attributes, and then use meta-path-based methods to describe the semantic relevance of the PE files can do.

To build a detection system (e.g., a classification model), embodiments can calculate the similarity between PE files by applying each metapath, and aggregate different similarities using multi-kernel learning.

The method according to the embodiment may be implemented in the form of program instructions that can be executed through various computer means and recorded on a computer-readable medium. The computer-readable medium may include program instructions, data files, data structures, or the like alone or in combination. The program instructions recorded on the medium may be specially designed and configured for the embodiments or may be known and usable by those skilled in computer software. Examples of computer-readable recording media include magnetic media such as hard disks, floppy disks, and magnetic tapes, optical media such as CD-ROMs, DVDs, and magnetic media such as floptical disks. Includes hardware devices specifically configured to store and execute program instructions such as magneto-optical media, and ROM, RAM, flash memory, and the like. Examples of program instructions include high-level language code that can be executed by a computer using an interpreter, etc., as well as machine language codes produced by a compiler. The hardware device described above may be configured to operate as one or more software modules to perform the operations of the embodiments, and vice versa.

The software may include a computer program, code, instruction, or a combination of one or more of these, and configure the processing device to operate as desired, or process independently or collectively You can command the device. Software and/or data may be interpreted by a processing device, or to provide instructions or data to a processing device, of any type of machine, component, physical device, virtual equipment, computer storage medium or device. , Or may be permanently or temporarily embodied in the transmitted signal wave. The software may be distributed on networked computer systems and stored or executed in a distributed manner. Software and data may be stored in one or more computer-readable recording media.

As described above, although the embodiments have been described by the limited drawings, those skilled in the art can apply various technical modifications and variations based on the above. For example, the described techniques are performed in a different order than the described method, and/or the components of the described system, structure, device, circuit, etc. are combined or combined in a different form from the described method, or other components Alternatively, proper results can be achieved even if replaced or substituted by equivalents.

Therefore, other implementations, other embodiments, and equivalents to the claims are also within the scope of the following claims.

Claims (14)

Extracting features from Portable Executable (PE) files;
Generating a heterogeneous information network (HIN) for the relationship between the PE files and the characteristics; And
Detecting whether the PE files are malicious software by using the meta path on the HIN
Malicious software detection method comprising a.
According to claim 1,
The features include PE header information, API calls (calls), DLL and Opcode sequences.
According to claim 1,
The detecting step,
Detecting whether the PE files are malicious software by calculating the similarity between the PE files using the meta path on the HIN
Malicious software detection method comprising a.
According to claim 1,
The relationship is
A first relationship for PE files and API calls;
A second relationship to attribute values of PE header information of PE files;
A third relationship to the package to which the API call belongs;
A fourth relationship to the API sequence of the PE file; And
Fifth Relationship to Opcode Sequences in PE Files
Malicious software detection method comprising a.
According to claim 4,
The meta path,
A first meta-path constructed through a first matrix representing the first relationship;
A second meta-path constructed through a second matrix representing the second relationship;
A third meta-path constructed through a third matrix representing the third relationship;
A fourth meta-path constructed through a fourth matrix expressing the fourth relationship; And
A fifth meta-path constructed through a fifth matrix expressing the fifth relationship
Malicious software detection method comprising a.
The method of claim 5,
The meta path,
Malicious software detection method further comprising a linearly combined meta-path by optimizing the first meta-path, the second meta-path, the third meta-path, the fourth meta-path, and the fifth meta-path through multi-kernel learning .
According to claim 4,
The meta path,
A first meta-path constructed through a first matrix representing the first relationship;
A second meta-path constructed through a second matrix representing the second relationship;
A third meta-path constructed through a third matrix representing the third relationship;
A fourth meta-path constructed through a fourth matrix expressing the fourth relationship; And
A fifth meta-path constructed through a fifth matrix expressing the fifth relationship
Is a meta-path that is linearly combined by optimizing through multi-kernel learning.
A receiver that receives Portable Executable (PE) files; And
A controller that extracts characteristics from the PE files, creates a heterogeneous information network (HIN) for the relationship between the PE files and the characteristics, and detects whether the PE files are malicious software using a meta path on the HIN
Malicious software detection device comprising a.
The method of claim 8,
The above features are PE header information, API call (call), DLL and Opcode sequence, malicious software detection device.
The method of claim 8,
The controller,
Malicious software detection device for detecting whether the PE files are malicious software by calculating the similarity between the PE files using the meta path on the HIN.
The method of claim 8,
The relationship is
A first relationship for PE files and API calls;
A second relationship to attribute values of PE header information of PE files;
A third relationship to the package to which the API call belongs;
A fourth relationship to the API sequence of the PE file; And
Fifth Relationship to Opcode Sequences in PE Files
Malicious software detection device comprising a.
The method of claim 11,
The meta path,
A first meta-path constructed through a first matrix representing the first relationship;
A second meta-path constructed through a second matrix representing the second relationship;
A third meta-path constructed through a third matrix representing the third relationship;
A fourth meta-path constructed through a fourth matrix expressing the fourth relationship; And
A fifth meta-path constructed through a fifth matrix expressing the fifth relationship
Malicious software detection device comprising a.
The method of claim 12,
The meta path,
Malicious software detection device further comprising a linearly combined metapath by optimizing the first metapath, the second metapath, the third metapath, the fourth metapath, and the fifth metapath through multi-kernel learning .
The method of claim 11,
The meta path,
A first meta-path constructed through a first matrix representing the first relationship;
A second meta-path constructed through a second matrix representing the second relationship;
A third meta-path constructed through a third matrix representing the third relationship;
A fourth meta-path constructed through a fourth matrix expressing the fourth relationship; And
A fifth meta-path constructed through a fifth matrix expressing the fifth relationship
Malicious software detection device, which is a meta-path that combines and optimizes through multi-kernel learning.

Images