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

Abstract

A method and apparatus for detecting malicious codes based on heterogeneous information networks are disclosed. A method for detecting malicious software according to an embodiment includes the steps of extracting characteristics from Portable Executable (PE) files, generating a heterogeneous information network (HIN) for a relationship between the PE files and the characteristics, and And detecting whether the PE files are malicious software by using the meta path on the HIN.

Description

Malware detection method and device based on heterogeneous information network {METHOD AND APPARATUS FOR MALICIOUS DETECTION BASED ON HETEROGENEOUS INFORMATION NETWORK}

The following embodiments relate to a method and apparatus for detecting malicious codes based on heterogeneous information networks.

Methods for analyzing malicious codes in software include a fingerprint inspection method, a cyclic redundancy check (CRC) inspection method, and a heuristic inspection method.

Fingerprint scanning is one of the ways in which a security program diagnoses malicious code, just as a fingerprint is seen when identifying a person. That is, a unique character string (pattern) possessed by the malicious code is collected and stored in the database, and the malicious code is analyzed using a method in which a security program matches the pattern.

The CRC check method is a type of error detection method for verifying the reliability of data in serial transmission, and has an advantage of low error rate, but has a disadvantage of diagnosing malicious code if data is deformed even by 1 byte.

Recently, as a malicious code analysis method, an empirical technique that improves the function of the fingerprint inspection method 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 the empirical technique learns the combination of such unique API commands to determine whether or not a 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, malicious software of the traditional PC platform has become the most popular. Due to complex packaging, confusion, anti-sandboxing, virtual penetration and other technology developments, the existing methods of detecting malicious software are not satisfactory.

In the age of information networks, more and more malicious software poses a serious threat to security. Of particular importance is how to detect malicious software attacks in a timely and effective manner. With increasingly sophisticated malicious software, new defense technologies are required to detect and respond to new attacks and threats.

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

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

The characteristics may include PE header information, API call, DLL and Opcode sequence.

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

The relationship is 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 to the Opcode sequence of the PE file.

The meta path is a first meta path configured through a first matrix representing the first relationship, a second meta path configured through a second matrix representing the second relationship, and a third matrix representing the third relationship. A third meta-path configured through a third meta-path, 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 may be included.

The meta-path may further include 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. I can.

The meta path is a first meta path configured through a first matrix representing the first relationship, a second meta path configured through a second matrix representing the second relationship, and a third matrix representing the third relationship. Through 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 It may be a meta-path that is optimized and linearly combined.

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

The characteristics may include PE header information, API call, DLL and Opcode sequence.

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

The relationship is 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 to the Opcode sequence of the PE file.

The meta path is a first meta path configured through a first matrix representing the first relationship, a second meta path configured through a second matrix representing the second relationship, and a third matrix representing the third relationship. A third meta-path configured through a third meta-path, 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 may be included.

The meta-path may further include 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. I can.

The meta path is a first meta path configured through a first matrix representing the first relationship, a second meta path configured through a second matrix representing the second relationship, and a third matrix representing the third relationship. Through 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 It may be a meta-path that is optimized and linearly combined.

1 shows an apparatus for performing a malicious software detection method according to an exemplary embodiment.
FIG. 2 is a schematic block diagram of a malicious software detection apparatus shown in FIG. 1.
3 is a schematic block diagram of the controller shown in FIG. 2.
FIG. 4 is 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 of extracting characteristics by the PE file analyzer illustrated in FIG. 3.
6 is a diagram for explaining the operation of the HIN generator shown in FIG. 3.
FIG. 7 is a diagram illustrating a multi-kernel learner and classification model shown in FIG. 3.
8 is a graph for explaining an experiment result performed by a method for detecting malicious software according to an exemplary embodiment.

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

The terms used in the examples are used for illustrative purposes only and should not be interpreted as limiting. Singular expressions include plural expressions unless the context clearly indicates otherwise. In the present specification, terms such as "comprise" or "have" are intended to designate the presence of features, numbers, steps, actions, components, parts, or combinations thereof described in the specification, but one or more other features. It is to be understood that the presence or addition of elements or numbers, steps, actions, components, parts, or combinations thereof, does not preclude in advance.

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

Unless otherwise defined, all terms used herein, including technical or scientific terms, have the same meaning as commonly understood by one of ordinary skill in the art to which the embodiment belongs. Terms as defined in a commonly used dictionary should be interpreted as having a meaning consistent with the meaning in the context of the related technology, and should not be interpreted as an ideal or excessively formal meaning unless explicitly defined in this 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 the reference numerals, and redundant descriptions thereof will be omitted. In describing the embodiments, when it is determined that a detailed description of related known technologies may unnecessarily obscure the subject matter of the embodiments, the detailed description thereof will be omitted.

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

The malicious software detection device 100 not only relies on API calls, but also analyzes the relationship between them, and provides higher-level semantics (or higher-level semantics) to prevent an attacker from evading detection. Semantics) can be created to perform a new malicious software detection method. Through this, the malicious software detection device 100 may detect malicious codes in various operating systems such as Android malicious codes and Window malicious codes.

The malicious software detection device 100 builds a heterogeneous information network (HIN) through rich relationships between software and related APIs, and then performs a meta-path-based method to provide software and APIs. Can analyze semantic relevance.

The malicious software detection device 100 calculates similarity between software (eg, PE files) using each meta path, and uses MKL (Multi-kernel Learning) to construct a detection model to achieve 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 a malicious software detection apparatus 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, the instructions are the operation of each component (310 to 370 shown in FIG. 3) included in the controller 300. It may contain instructions to execute.

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 PE files received from the receiver 200 correspond to malicious software.

The controller 300 may analyze the PE files and analyze the relationship between them in more detail, including the same package name or the same property value. The controller 300 may perform a higher level of semantic analysis through relationships between APIs and PE files and various type relationships between PE files themselves.

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

The controller 300 may calculate whether or not the same APIs are used in this manner, and may calculate similarity between PE files by calculating whether usage patterns such as the same package are similar. At this time, since the paths for explaining the similarity between the same two PE files are different, the controller 300 can automatically learn the weights of different similarities as data using multi-kernel learning algorithms. .

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

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

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

The PE file analyzer 310 parses (or parses) the PE table of all executable files (PE files), and provides all PE header information, DLL names, and Opcodes in each DLL. It is possible to extract the sequence (Opcode sequence) and API functions (API functions) as features (rfeatures).

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

Then adjacency matrices between different object types are created, and commuting matrices of different meta paths can be enumerated and written.

The multi-kernel learner 350 may build a kernel of Support Vector Machines (SVM) given commuting matrices of HIN. The multi-kernel learner 350 may optimize weights of different meta paths using standard multi-kernel learning. Given the meta path weights, we can formulate a more powerful malware detection kernel by combining all commuting matrices.

The classification model 370 may also be referred to as a malicious software detector. For each newly collected unknown software, this software PE file will be first parsed through the PE file analyzer 310, then the PE header information, DLL name, Opcode sequence and API call will be extracted and further analyzed. PE files (eg, software) may be classified as either benign or malicious code by using the classification model 370 created based on these extracted characteristics.

FIG. 4 is 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 of extracting characteristics by the PE file analyzer shown in FIG. 3.

In FIGS. 4 and 5, a detailed approach to how to represent PE files using extracted features and a method of solving a classification problem based on the extracted features will be described.

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. Feature extractor 315 may 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.

Feature extractor 315 may automatically extract features, such as API calls and other related information, from PE files.

In this case, the API calls may be converted into a group of global (or global) global integer IDs representing the static execution sequence of the corresponding API calls. Similarly, PE file information, Opcode sequence, and DLL may 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 to the control flow is the start instruction of the basic block, which jumps from this basic block after the instruction finishes. The assembly code includes a number of sub-functions, and these sub-functions increase jumps between basic blocks to construct an overall program control flow graph as shown in FIG. 5A.

In the assembly instructions, it can be divided into general, jmp, jcc, call, return, and start depending on the role of the control flow graph. To extract API calls, we only keep the calling instruction node, the main function item, and the return. 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 instructions to extract an API sequence (API call sequence).

The extraction of the opcode sequence is similar to the extraction of the API sequence. Build a control flow graph for the opcode, then traverse 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, it is possible to extract an opcode sequence of PE files.

The analyzer 317 may generate matrices using the extracted features. The matrices are matrices related to the PE file, and may be matrices expressing a relationship between the PE file and the extracted features. For example, the relationship is the first relationship to 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 API sequence of the PE file. It may include a fourth relationship and a fifth relationship to 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, type, and so on. 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

To represent, the analyzer 317 is a property-value matrix

Create Where, each element

Indicates whether a pair of attributes is the same value.

■ API package

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

According to the provided functions, Windows APIs 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, universal space link library. ), Windows shell, and web services.

For example, 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 represent, the analyzer 317 is a co-package matrix

Create Where, each element

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

■ API sequence.

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

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

은 속성들의 한 쌍(a pair of properties)이 동일한 API 시퀀스를 갖는지 여부를 나타낸다.During execution of the PE file, the call sequence of API calls represents an important relationship. Google collects API call sequence (behavioral) data, and uses 2-sequences of APIs feature to represent 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 there are two PE files with the same API sequence, we think they can have some similarities. This kind of relationship

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

Create 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 the behavioral characteristics of the executing process, and can describe the malware in more detail. We use a two-sequence of Opcode features to represent the relationship between each PE file. For example, there is a PE file opcode sequence called “push → push → call” that is 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 consider them to have some similarities. This kind of relationship

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

Create Where, each element

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

A summary of the different relationships and descriptions of each element in the relationship matrix may be shown in Table 1.

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

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

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

를 갖는 그래프

이다. 여기서, 각 객체

는 특정 객체 유형

에 속하고, 각 링크

는 특정 관계

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

또는 링크 유형들의 수

인 경우, 이러한 네트워크를 HIN이라고하는 이기종 정보 네트워크라고 한다.The HIN generator 330 may construct a 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

Belong to, and each link

Is a specific relationship

Belongs to. Number of object types

Or number of link types

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

In a 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 call and PE header information, API calls within 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, the HIN generator 330 can formulate high-level semantic relationships between objects using HIN's meta-path 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 of. Its format is

It is recorded as, type

And type

Composite relationship

Defines here "

"Denotes a complex operation on a relationship. For PE files, a typical meta path 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 measurement. Symmetric meta path

Given is given, the PathSim definition for an object of the same type and y is:

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

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

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

Is the path instance between x and y,

Is the path instance between and x,

Is the path instance between y and y.

가 주어진다면,

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

Is given,

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

와 네트워크 스키마

가 주어진 경우, 메타 경로

에 대한 맞바꿈 행렬은

로 정의된다. 여기서,

은 유형

와 유형

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

는 메타 경로

에서 객체

과 객체

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

And network schema

If is given, the meta path

The replacement matrix for is

Is defined as here,

Silver type

And type

It is the adjacency matrix between.

Is the meta path

Object in

And object

Represents the number of instances of the route between.

이다. 그러면 메타 경로

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

, 즉,

이다.

를 행렬

의

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

와

의 유사도는

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

to be. Then the meta path

The swap matrix of PE files calculated using

, In other words,

to be.

Matrix

of

In the second row, the PE file

Wow

The similarity of

It is given as, which is simply the dot product of two feature vectors. More complex similarities can be defined by swap matrices based on meta paths. In other words, it does not consider only internal API calls, but calculates the similarity between two apps (eg, PE files).

FIG. 7 is a diagram illustrating a multi-kernel learner and classification model shown in FIG. 3.

Given a network schema with different types of entities and relationships, you can enumerate many meta paths. So the 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 a weight of each meta path. Meta paths

Suppose there is. The multi-kernel learner 350 is a swap matrix corresponding to meta paths

Can be calculated. here

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

이고,

을 만족한다. here,

ego,

Is satisfied.

을 가정한다. 여기서,

은 PE 파일 (여기서,

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

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

Assume here,

Is the PE file (where,

Can be considered an ID),

Is the label. Then, the multi-kernel learner 350 uses the p-norm multi-kernel learning framework having the following objective function to determine the parameters using the following objective function. You 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 allow for misclassification.

Is a nonlinear mapping of features in Hilbert's space defining the kernel. here,

to be. Then apply the representation theorem,

Can be obtained.

Can be solved using a dual formulation, non-zero

They lead to support vectors.

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

이다. 여기서 -norm

은

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

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

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

Any other set of parameters

to be. Where -norm

silver

Are used to normalize the optimization of You can empirically apply a 2-norm to your problem. After optimization, weight

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

Is used.

8 is a graph for explaining an experiment result performed by a method for detecting malicious software according to an exemplary embodiment.

The experiment was conducted 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 (false negative ratio (FNR)) was measured, and these related measurements are shown in Table 2.

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

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

In the experiment, it can be seen that the single meta-path generation model is applied and the experimental result based on the meta-path of the API sequence is 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 the PE header information attribute value 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 property values in the properties of the PE header information. These unreliable attribute values can exacerbate the experimental results.

The best experimental results were obtained by combining all meta-path configuration detection models using MKL (Multi-kernel Learning), and the actual detection rate is 98.5%, the false detection rate is 2%, and the accuracy is 98.25%. This experimental result shows 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 attributes of PE header information, remove unreliable attributes, and extract and use more important characteristics that 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 the meta paths (eg, SOAO ^T S ^T , SVPV ^T S ^T, etc.).

A new method of detecting malicious software based on a heterogeneous information network (HIN) has been described with reference to FIGS. 1 to 8. The examples analyze the PE file to extract PE header information, API calls, DLLs and opcodes as features, build a HIN for the relationship between attributes, and then describe the semantic relevance of the PE file using a meta path-based method. can do.

In order to build a detection system (for example, a classification model), embodiments may calculate similarities between PE files by applying each meta path, 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 in a computer-readable medium. The computer-readable medium may include program instructions, data files, data structures, and the like alone or in combination. The program instructions recorded on the medium may be specially designed and configured for the embodiment, or may be known and usable to 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 and DVDs, and magnetic media such as floptical disks. -A hardware device specially 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 not only machine language codes such as those produced by a compiler but also high-level language codes that can be executed by a computer using an interpreter or the like. The hardware device described above may be configured to operate as one or more software modules to perform the operation of the embodiment, and vice versa.

The software may include a computer program, code, instructions, or a combination of one or more of these, configuring the processing unit to behave as desired or processed 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 embodyed in a transmitted signal wave. The software may be distributed over networked computer systems and stored or executed in a distributed manner. Software and data may be stored on one or more computer-readable recording media.

As described above, although the embodiments have been described by the limited drawings, a person of ordinary skill 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 from the described method, and/or components such as a system, structure, device, circuit, etc. described are combined or combined in a form different from the described method, or other components Alternatively, even if substituted or substituted by an equivalent, an appropriate result can be achieved.

Therefore, other implementations, other embodiments and claims and equivalents fall within the scope of the following claims.

Claims (14)

In the malicious software detection method of a malicious software detection device,
Extracting, by the malicious software detection device, characteristics from Portable Executable (PE) files;
Generating, by the malicious software detection device, a heterogeneous information network (HIN) for a relationship between the PE files and the characteristics; And
Detecting, by the malicious software detection device, whether the PE files are malicious software using a meta path on the HIN
Including,
The above relationship is,
The first relationship to the PE file and the API call;
A second relationship to an attribute value of PE header information of a PE file;
A third relationship to the package to which the API call belongs;
A fourth relationship to the API sequence of the PE file; And
The fifth relationship to the opcode sequence of the PE file
Malicious software detection method comprising a.
The method of claim 1,
The above characteristics include PE header information, API call, DLL and Opcode sequence.
The method of claim 1,
The detecting step,
Detecting whether the PE files are malicious software by calculating similarity between the PE files using the meta path on the HIN
Malicious software detection method comprising a.
delete The method of claim 1,
The meta path is,
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;
A third meta-path constructed through a third matrix expressing the third relationship;
A fourth meta-path configured 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 is,
Malicious software detection method further comprising a meta-path 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 .
The method of claim 1,
The meta path is,
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;
A third meta-path constructed through a third matrix expressing the third relationship;
A fourth meta-path configured 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, which is a linearly combined meta-path by optimizing through multi-kernel learning.
A receiver for receiving 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
Including,
The above relationship is,
The first relationship to the PE file and the API call;
A second relationship to an attribute value of PE header information of a PE file;
A third relationship to the package to which the API call belongs;
A fourth relationship to the API sequence of the PE file; And
The fifth relationship to the opcode sequence of the PE file
Malicious software detection device comprising a.
The method of claim 8,
The characteristics of the malicious software detection device including PE header information, API call, DLL and Opcode sequence.
The method of claim 8,
The controller,
A malicious software detection device that detects whether the PE files are malicious software by calculating the similarity between the PE files using the meta path on the HIN.
delete The method of claim 8,
The meta path is,
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;
A third meta-path constructed through a third matrix expressing the third relationship;
A fourth meta-path configured 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 is,
Malicious software detection apparatus further comprising a meta-path 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 .
The method of claim 8,
The meta path is,
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;
A third meta-path constructed through a third matrix expressing the third relationship;
A fourth meta-path configured through a fourth matrix expressing the fourth relationship; And
A fifth meta-path constructed through a fifth matrix expressing the fifth relationship
A malicious software detection device that is a linearly combined meta-path by optimizing through multi-kernel learning.

Images