KR102698908B1 - Methods for quickly detecting information within incoming documents in security solutions - Google Patents

Abstract

The present specification relates to a method for pre-filtering by examining internal information of an incoming document by a server, comprising: a step of receiving an analysis target file; a step of examining the analysis target file with a static analysis engine; a step of examining the analysis target file with a filter engine based on the inspection result of the static analysis engine being normal; a step of examining whether a filter item of the analysis target file exists through the filter engine; and a step of examining the analysis target file with a dynamic analysis engine based on the existence of the filter item; wherein the analysis target file may include a format of an HWP file.

Description

{ METHODS FOR QUICKLY DETECTING INFORMATION WITHIN INCOMING DOCUMENTS IN SECURITY SOLUTIONS }

This specification relates to a method and device for quickly detecting information inside an imported document by examining the information inside the document.

Advanced Persistent Threat (APT) attacks are attacks in which attackers continuously use various forms of malware by applying advanced attack techniques to target specific targets and extract targeted information.

In particular, APT attacks are often not detected in the initial intrusion stage, and often use non-executable (Non-PE: Non-Portable Executable) files containing malicious code.

Although most non-executable files used in practice are normal files, security solutions perform inspections by applying all detection methods to all files in order to detect a small percentage of malicious documents. In particular, sandbox-based dynamic analysis methods are more accurate than static analysis methods, but they take relatively more time to analyze.

The purpose of this specification is to propose a method for applying pre-filtering before dynamic analysis of HWP files.

The technical problems to be solved by this specification are not limited to the technical problems mentioned above, and other technical problems not mentioned can be clearly understood by a person having ordinary skill in the technical field to which this specification belongs from the detailed description of the specification below.

One aspect of the present specification is a method for pre-filtering by examining internal information of an incoming document by a server, comprising: a step of receiving an analysis target file; a step of examining the analysis target file with a static analysis engine; a step of examining the analysis target file with a filter engine based on the inspection result of the static analysis engine being normal; a step of examining whether a filter item of the analysis target file exists through the filter engine; and a step of examining the analysis target file with a dynamic analysis engine based on the existence of the filter item; wherein the analysis target file may include a format of an HWP file.

In addition, the step of checking whether the filter item exists may include a step of determining that the filter item exists based on the existence of a reference value in the size of the HWP file.

Additionally, the step of checking whether the filter item exists may include a step of determining that the filter item exists based on the presence of a file inserted inside the HWP file.

Additionally, the step of determining that the filter item exists based on the presence of a file inserted inside the HWP file may include the steps of identifying BinData storage; and identifying a stream having an .OLE extension.

Additionally, the step of checking whether the filter item exists may include a step of determining that the filter item exists based on the presence of a script inserted inside the HWP file.

Additionally, the step of determining that the filter item exists based on the presence of a script inserted inside the HWP file may include the steps of identifying BinData storage; and identifying a stream having an .eps or .ps extension.

In addition, the step of checking whether the filter item exists may include a step of determining that the filter item exists based on the existence of an object related to the vulnerability within the HWP file, based on a list of objects related to the preset vulnerability.

Additionally, the list of objects associated with the above vulnerability may include flash image files with the .swf extension.

In addition, the step of checking whether the filter item exists may further include the step of reading the analysis target file as a binary; and the step of determining that the filter item exists based on the presence of shellcode related to the vulnerability in the binary.

In addition, the step of checking whether the filter item exists may further include a step of determining that the filter item exists based on the information entropy of the analysis target file exceeding a reference value.

In addition, the step of checking whether the filter item exists may further include the steps of: extracting an image of the analysis target file; extracting text from the image through OCR; and determining that the filter item exists based on the text being related to a public document.

Another aspect of the present specification is a server for inspecting and pre-filtering internal information of an imported document, comprising: a communication unit; a memory including a static analysis engine, a filter engine, and a dynamic analysis engine; and a processor functionally controlling the communication unit and the memory; wherein the processor receives an analysis target file, inspects the analysis target file with the static analysis engine, and inspects the analysis target file with the filter engine based on a normal inspection result of the static analysis engine, and inspects whether a filter item of the analysis target file exists through the filter engine, and inspects the analysis target file with the dynamic analysis engine based on the presence of the filter item, and the analysis target file may include a format of an HWP file.

According to embodiments of the present specification, filtering can be performed to sanitize HWP files.

The effects that can be obtained from this specification are not limited to the effects mentioned above, and other effects that are not mentioned will be clearly understood by a person having ordinary skill in the art to which this specification belongs from the description below.

FIG. 1 is a diagram illustrating a server or client related to this specification.
Figure 2 is an example of abnormal input that can be applied to this specification.
Figure 3 illustrates an analysis method to which the present specification can be applied.
The accompanying drawings, which are incorporated in and are intended to provide an aid to the understanding of the present specification and are a part of the detailed description, illustrate embodiments of the present specification and, together with the detailed description, serve to explain the technical features of the present specification.

Hereinafter, the embodiments disclosed in this specification will be described in detail with reference to the attached drawings. Regardless of the drawing symbols, identical or similar components will be given the same reference numerals and redundant descriptions thereof will be omitted. The suffixes "module" and "part" used for components in the following description are assigned or used interchangeably only for the convenience of writing the specification, and do not have distinct meanings or roles in themselves. In addition, when describing the embodiments disclosed in this specification, if it is determined that a specific description of a related known technology may obscure the gist of the embodiments disclosed in this specification, the detailed description thereof will be omitted. In addition, the attached drawings are only intended to facilitate easy understanding of the embodiments disclosed in this specification, and the technical ideas disclosed in this specification are not limited by the attached drawings, and should be understood to include all modifications, equivalents, and substitutes included in the spirit and technical scope of this specification.

Terms that include ordinal numbers, such as first, second, etc., may be used to describe various components, but the components are not limited by the terms. The terms are used only to distinguish one component from another.

When it is said that a component is "connected" or "connected" to another component, it should be understood that it may be directly connected or connected to that other component, but that there may be other components in between. On the other hand, when it is said that a component is "directly connected" or "directly connected" to another component, it should be understood that there are no other components in between.

Singular expressions include plural expressions unless the context clearly indicates otherwise.

In this specification, it should be understood that terms such as “comprises” or “has” are intended to specify the presence of a feature, number, step, operation, component, part or combination thereof described in the specification, but do not exclude in advance the possibility of the presence or addition of one or more other features, numbers, steps, operations, components, parts or combinations thereof.

Also, the term "part" used in the specification means a software or hardware component, and the "part" performs certain functions. However, the "part" is not limited to software or hardware. The "part" may be configured to be on an addressable storage medium and may be configured to execute one or more processors. Thus, by way of example, the "part" includes components such as software components, object-oriented software components, class components, and task components, and processes, functions, attributes, procedures, subroutines, segments of program code, drivers, firmware, microcode, circuitry, data, databases, data structures, tables, arrays, and variables. The functionality provided in the components and "parts" may be combined into a smaller number of components and "parts" or further separated into additional components and "parts."

Additionally, according to one embodiment of the present disclosure, the "unit" may be implemented as a processor and a memory. The term "processor" should be construed broadly to include a general purpose processor, a central processing unit (CPU), a microprocessor, a digital signal processor (DSP), a controller, a microcontroller, a state machine, and the like. In some environments, a "processor" may also refer to an application specific integrated circuit (ASIC), a programmable logic device (PLD), a field programmable gate array (FPGA), and the like. The term "processor" may also refer to a combination of processing devices, such as, for example, a combination of a DSP and a microprocessor, a combination of a plurality of microprocessors, a combination of one or more microprocessors in conjunction with a DSP core, or any other such configuration.

The term "memory" should be interpreted broadly to include any electronic component capable of storing electronic information. The term memory may also refer to various types of processor-readable media, such as random access memory (RAM), read-only memory (ROM), non-volatile random access memory (NVRAM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable PROM (EEPROM), flash memory, magnetic or optical data storage, registers, etc. A memory is said to be in electronic communication with the processor if the processor can read information from and/or write information to the memory. Memory integrated in a processor is in electronic communication with the processor.

As used herein, the term "non-executable file" refers to a file that does not run on its own, as opposed to an executable file or an executable file. For example, non-executable files may be, but are not limited to, document files such as PDF files, Hangul files, and Word files, image files such as JPG files, video files, JavaScript files, and HTML files.

Below, with reference to the attached drawings, an embodiment is described in detail so that a person having ordinary skill in the art to which this specification pertains can easily practice the invention. In addition, in order to clearly explain the present disclosure in the drawings, parts that are not related to the description may be omitted.

FIG. 1 is a diagram illustrating a server or client related to this specification.

In this specification, a server (or cloud server) or a client may include a control unit (100) and a communication unit (130). The control unit (100) may include a processor (110) and a memory (120). The processor (110) may execute instructions stored in the memory (120). The processor (110) may control the communication unit (130).

The processor (110) can control the operation of the server or client based on the instructions stored in the memory (120). The server or client may include one processor or may include multiple processors. When the server or client includes multiple processors, at least some of the multiple processors may be located at a physically separated distance. In addition, the server or client is not limited thereto and may be implemented in various known ways.

The communication unit (130) may include one or more modules that enable wireless communication between a server or client and a wireless communication system, between a server or client and another server or client, or between a server or client and an external server. In addition, the communication unit (110) may include one or more modules that connect the server or client to one or more networks.

The control unit (100) can control at least some of the components of the server or client in order to drive the application program stored in the memory (120). Furthermore, the control unit (100) can operate at least two or more of the components included in the server or client in combination with each other in order to drive the application program.

In this specification, a server may include a reversing engine and/or a CDR engine providing CDR services.

Reversing Engine

A reversing engine is an analysis/diagnosis engine that automates the reverse engineering process for malicious non-executable files.

For example, a reversing engine might perform the following steps:

1. File analysis: This is the step of analyzing the appearance of the non-executable file itself (e.g., properties, author, creation date, file type), and similar to general antivirus programs, it can diagnose whether the non-executable file is malicious based on information alone.

2. Static analysis: This is the step of extracting and analyzing data within a non-executable file to determine whether it is normal or malicious. Non-executable files can be diagnosed as malicious by extracting internal data according to the file structure without executing it and comparing and analyzing it. This can be suitable for macro, URL extraction analysis, etc.

3. Dynamic analysis: This is the step of executing and monitoring non-executable files and analyzing their behavior to determine whether they are malicious. It is easy to detect malicious behavior using normal functions such as macros, hyperlinks, and DDE.

4. Debugging Analysis: This is the step of analyzing vulnerabilities, exploits, etc. by executing and debugging non-executable files. It is suitable for detecting vulnerabilities in applications that use text, tables, fonts, and images within documents, including macros, hyperlinks, and DDE.

The reversing engine may include a debugging engine that can be used for debugging analysis. The debugging engine can diagnose vulnerabilities occurring in the document input, processing, and output stages by debugging the non-executable file viewing process. Here, a vulnerability refers to an error, bug, etc. that occurs when an application receives an unexpected value from the code (logic) developed by the application developer, and an attacker can perform malicious actions such as denial of service due to abnormal termination or remote code execution through the vulnerability.

Contents Disarm and Reconstruction (CDR)

CDR service is a solution that decomposes non-executable files, removes malicious or unnecessary files, and creates new files with content that is as identical to the original as possible.

That is, Contents Disarm and Reconstruction (CDR) refers to a service that disarms and reconstructs content within a document to create a safe document and provide it to customers. The target files for disarming can be any non-executable file (e.g., Word, Excel, PowerPoint, Hangul, HWP), and the target content for disarming can be active content (e.g., macros, hyperlinks, OLE objects, etc.).

Figure 2 is an example of abnormal input that can be applied to this specification.

Referring to Figure 2, if an application receives an abnormal value (for example, an input value exceeding the normal range of 2) through a non-executable file, the execution flow may change to one not intended by the developer, causing a vulnerability to be triggered. The debugging engine can automatically debug the document viewing process, set a breakpoint at a specific point related to the vulnerability, and check a specific value related to the input value to determine whether the input value is a value that causes a vulnerability or not, thereby diagnosing whether it is malicious.

In more detail, the debugging engine can start debugging by checking the non-executable file and executing an application to view it. When a module is loaded during the process of viewing the non-executable file, the debugging engine can check whether the module is the target module for analysis, and if so, can set a breakpoint at the specified address.

For example, a malicious non-executable file may have branch points that terminate the application or branch to a flow where no malicious activity occurs if certain conditions, such as the application version or operating system environment, are not met. The server can set breakpoints at branch points that have such possibilities by analyzing them in advance by analysts.

Additionally, the server can set conditions associated with that branch point that can cause the application to continue running without terminating or can lead to a flow that may result in malicious activity.

If the process stops at the breakpoint point during the execution of the application process, the server can detect whether there is a vulnerability according to the detection logic and then perform a step of saving the result in an analysis report.

The automated reversing engine included in the server can automatically perform the aforementioned steps and analyze them to diagnose and block malicious non-executable files through a diagnostic algorithm researched and developed by analysts.

Figure 3 illustrates an analysis method to which the present specification can be applied.

Referring to FIG. 3, the server may include a static analysis engine, a filter engine with filter rules applied, and a dynamic analysis engine in memory.

A static analysis engine can identify the characteristics of malicious code by analyzing the internal structure or code of a file. For example, a static analysis engine can identify malicious behavior by examining the header, section, string, binary code, etc. of a non-executable file. Since such static analysis can detect malicious code without executing the file, the server in this specification can quickly detect malicious code that can be detected through static analysis first by using a static analysis engine.

For example, a static analysis engine can identify unique signatures or malicious patterns in non-executable files. Since static analysis can operate in real time, it can be performed before a filter engine or dynamic analysis engine. In other words, static analysis can be performed earlier in the entire analysis engine process because it can obtain faster analysis results than when dynamic analysis is performed by performing analysis without executing the analysis target file.

The filter engine can check whether there are filter items inside the target file using filter rules. If a filter item is detected inside the file as a result of the inspection, the server can perform additional analysis using the dynamic analysis engine.

A dynamic analysis engine can detect malicious code by executing a target file and observing its behavior during execution. For example, the dynamic analysis engine can include the aforementioned reversing engine and/or CDR engine.

A dynamic analysis engine can execute target files to monitor for malicious behavior and analyze the behavioral patterns of malicious code.

The server receives a non-executable file as an analysis target file (S3010). For example, in order to determine the document format of the non-executable file, the server can open the non-executable file and check the identification (Signature) type in the binary code to determine the format of the document.

For example, each non-executable file has its own unique format, and the basic content of the format is the file signature. The file signature can also be used to distinguish the file format by specific bytes located at the very beginning of the file.

For example, a PDF file may have a signature of “D0 CF 11 E0 A1 B1 1A E1” and an HWP file may have a signature of “25 50 44 46”.

If the server determines that the format of the non-executable file is an HWP file, it examines the file to be analyzed using a static analysis engine (S3020).

When you unzip a CFB series file, including an HWP file, you can check the directory and file structure. At this time, the directory type is called storage, and the file type is called stream.

Table 1 below illustrates the structure of a typical HWP file.

For example, the server can identify the HWP file structure from the data stream of the HWP file through the static analysis engine, and analyze the file contents in real time to detect malicious code, suspicious patterns, etc. In more detail, the server can analyze the contents of the HWP file without directly executing them. For example, the server can identify known malicious code signatures, suspicious patterns, or vulnerabilities by examining the code, macros, scripts included in documents, embedded objects, etc. of the HWP file. If there is no abnormality in the examination result of the static analysis engine, the server examines the analysis target file with the filter engine (S3030). For example, the filter engine can examine the presence or absence of a filter item in the analysis target file based on a preset filter rule.

The document format of the non-executable file has various functions implemented to provide convenience to the user and various elements that perform the functions. The server can identify the functions that are mainly exploited by malicious code among these and apply filtering rules to examine the elements related to them. If a mechanism is applied to classify files for further analysis based on these filtering rules, further analysis can be performed only if there are filtered items in the document, and if there are no such items, file analysis can be completed quickly.

The server checks whether a filter item exists in the analysis target file using the filter engine (S3040). If the server detects a filter item in the analysis target file using the filter engine, it can perform an additional inspection using the dynamic analysis engine.

For example, the filter items of an HWP file using the server's filter rules are as follows:

1) File size

The server can check the size of the file. For example, a malicious HWP file can insert or package malicious files or scripts to bypass detection by existing security solutions. Therefore, the server can perform additional analysis if the size of the HWP file checked through the filter engine exceeds the standard value. For example, if the size of the HWP file is 1 MB or more, the server can perform additional analysis.

2) Insert object inside file

The server can check whether there is an embedded file inside the HWP file. The embedded file can be an executable file or a non-executable file such as a document file. For example, in the case of a malicious HWP file, a malicious file can be embedded inside to bypass detection by a security solution, and the malicious file can be induced to run when the HWP is opened.

To check this, for example, the server can identify a “BinData” storage through the filter engine. This storage can contain images, executables, or other forms of non-executable files. The server can check for the existence of the “BinData” storage, extract the data from the storage, and check for the existence of embedded files.

Additionally, the server can identify streams that contain embedded objects using Object Linking and Embedding (OLE) technology. For example, such streams may have a '.OLE' extension. The server can extract and analyze OLE objects from streams with an OLE extension through a filter engine to check for the presence of embedded files.

3) Script inside the file

The server can check whether there is a script embedded in the HWP file and the data. For example, for convenience when viewing an HWP document, PostScript may be inserted to express a graphic image. In the case of malicious HWP, malicious actions may be performed by inserting PostScript.

To check this, for example, the server can identify “BinData” storage through the filter engine. Also, the server can identify streams with the extension ‘.eps’ or ‘.ps’ through the filter engine. The server can analyze the PostScript code in the identified streams.

4) Inspection of objects where vulnerabilities in HWP documents are mainly exploited

The server can check whether there are objects in the HWP file that are frequently exploited by vulnerabilities through the filter engine. For example, there may be objects that are particularly vulnerable among the various objects in the HWP document. The server can list those objects, and based on this list, if those objects exist, it can perform additional analysis of the HWP file.

For example, the server can generate a list of objects in the HWP file format that frequently have known vulnerabilities and identify such objects. This list may include vulnerable Flash images (.swf files), outdated OLE objects, executable scripts, macros, etc.

5) Checking shellcode within HWP document structure

The server can check the existence of shellcode, which is a command code that is executed when a vulnerability is triggered, through the filter engine. Shellcode consists of a continuous binary data bundle. The server can select the data that is mainly exploited among the shellcodes collected by itself as filter items and perform additional analysis if they match the entire document data.

For example, the server can detect shellcode set as a filter item. To this end, the server can select shellcodes that are mainly exploited as filter items. More specifically, such shellcodes can include specific patterns or binary signatures that are usually used for malicious purposes. The server can find a part of HWP document data that matches the shellcode through the filter engine. For example, after reading an HWP file as a binary, the part matching the shellcode can be checked to see if there is a shellcode corresponding to the filter item.

For example, a filter engine might include the following shellcode as a filter item:

“33 C9 64 A1 30 00 00 00 8B 40 0C 8B 70 14 AD 96 AD 8B 58 10 8B 53 3C 03 D3 8B 52 78 03 D3 8B 72 20 03 F3 33 C9 41 AD 03 C3 81 38 47 65 74 50 75 F4 81 78 04 72 6F 63 41 75 EB 81 78 08 64 64 72 65 75 E2 8B 72 24 03 F3 66 8B 0C 4E 49 8B 72 1C 03 F3 8B 14 8E 03 D3 33 F6 8B F2 33 C9 51 68 61 72 79 41 68 4C 69 62 72 68 4C 6F 61 64 8B CC 51 53 FF D2 50 33 C9 B9 64 6C 6C 00 51 68 6C 33 32 2E 68 73 68 65 6C 8B CC 51 FF D0 50 33 C9 66 B9 6C 6C 51 68 72 74 2E 64 68 6D 73 76 63 8B CC 51 8B 54 24 20 FF D2 50 E8 8B 05 00 00 73 74 72 6C 65 6E 00 77 00 00 90 90 90 90 90 90 5C 32 5F 4D 57 41 4C 52 44 45”

The server reads the target file for analysis as a binary HWP file, and if there is shellcode in the filter item, it can perform additional analysis.

6) Measuring HWP document data entropy

HWP files usually contain various types of data, such as text, images, and graphics, and due to the combination of these various data, HWP files can have a certain level of entropy. For example, entropy is an indicator of the degree of disorder in data, and the lower the predictability of data, the higher the entropy can be.

Malicious HWP files usually obfuscate malicious code or malicious scripts to evade security solutions. Obfuscated code is harder to predict than regular text or images, which can result in higher entropy.

In more detail, HWP files have an average amount of information. For example, if it is a malicious HWP file, there may be malicious files or scripts. In this case, the existing malicious entities are obfuscated to avoid detection, so the average amount of information may be much higher than that of normal files. Therefore, the server can measure the average amount of information by applying the information entropy formula in bit units, and perform additional analysis if the average amount of information is above a certain value.

Table 2 below is an example of information entropy to which this specification can be applied.

Referring to Table 2, the information content can be inversely proportional to the probability (p) of the occurrence of the event k. The information entropy can be calculated by adding up the values obtained by multiplying the information content of each event by the probability. For example, the information content can be increased as the probability of occurrence of a certain outcome decreases, and the information content can be decreased as the probability of occurrence increases. In the case of an HWP file, since each bit represents information in the file, the information content of the file can be expressed as the sum of the information content of each bit. Therefore, the server can calculate the bit information content of the HWP file and measure the entropy through this. In more detail, the server can calculate the information content by converting the HWP file into binary data, generating data streams, and analyzing these streams to estimate the probability that each bit is 0 or 1. For example, the server can perform additional analysis through the filter engine if the entropy of the HWP file exceeds a certain level (e.g., 7 or more) to check for the presence of malicious code or malicious script.

7) Extract and inspect image text within HWP documents

HWP files are widely used in public institutions, and malicious documents disguised as government documents are sometimes used. For example, these malicious documents may contain strings related to official documents or strings on specific topics, and through this, they can attempt to trick users into executing malicious code or leaking information.

More specifically, the server can extract images from HWP documents through a filter engine, and apply OCR technology to the extracted images to identify characters in the images and convert them into text. If the text is a text pattern or a specific keyword (e.g., “North Korea’s New Year’s speech evaluation”) that is frequently used in official documents, the server can perform additional analysis.

8) Inspect text content inside HWP documents

In addition, the server can extract and inspect text data within the HWP file through the filter engine to check whether specific strings that are frequently used in official documents exist. For example, if a string such as "North Korea New Year's speech evaluation" exists within the document, the server can perform additional analysis.

If the server detects a filter item, it examines the target file for analysis with the dynamic analysis engine (S3050). The server can terminate the file examination after performing additional analysis with the dynamic analysis engine. Dynamic analysis is a method of analyzing the target file by executing it, and it takes relatively longer to analyze than static analysis, but it can obtain more accurate results.

The existing inspection method detects malicious files through a static analysis engine, and then performs dynamic analysis on all files. This is time-consuming because dynamic analysis is performed on all files. However, malicious behaviors mainly occur through specific objects, and it is inefficient for all files to require dynamic analysis.

Therefore, in this specification, the server can exclude files without malicious objects from the dynamic analysis target by applying the filter engine. This shortens the inspection time, thereby reducing the detection time of the solution. This can improve the performance of the security solution, and improve availability, which can affect the real-time communication of the main business application. Therefore, the security solution applying the filter engine in this specification can improve the continuity and security of the business at the same time.

The above-described specification can be implemented as a computer-readable code on a medium in which a program is recorded. The computer-readable medium includes all kinds of recording devices that store data that can be read by a computer system. Examples of the computer-readable medium include a hard disk drive (HDD), a solid state disk (SSD), a silicon disk drive (SDD), a ROM, a RAM, a CD-ROM, a magnetic tape, a floppy disk, an optical data storage device, and the like, and also includes those implemented in the form of a carrier wave (e.g., transmission via the Internet). Therefore, the above detailed description should not be construed as limiting in all aspects, but should be considered as illustrative. The scope of the present specification should be determined by a reasonable interpretation of the appended claims, and all changes within the equivalency range of the present specification are included in the scope of the present specification.

In addition, although the above has been described with a focus on services and embodiments, these are merely examples and do not limit the present specification, and those with ordinary knowledge in the field to which this specification pertains will recognize that various modifications and applications not exemplified above are possible without departing from the essential characteristics of the present service and embodiments. For example, each component specifically shown in the embodiments can be modified and implemented. In addition, differences related to such modifications and applications should be interpreted as being included in the scope of the present specification defined in the appended claims.

Claims (12)

In a method for pre-filtering by examining the internal information of a document that has been imported into the server,
Step of receiving the file to be analyzed;
A step of examining the above analysis target file using a static analysis engine;
A step of examining the analysis target file with a filter engine based on the inspection result of the static analysis engine being normal;
A step of checking whether a filter item exists in the analysis target file through the filter engine; and
A step of examining the analysis target file with a dynamic analysis engine based on the existence of the above filter item;
Including,
The above analysis target file contains the HWP file format,
The step of checking whether the above filter items exist is
A step of determining that the filter item exists based on the presence of an object related to the vulnerability within the HWP file, based on a list of objects related to the preset vulnerability;
A step of reading the above analysis target file as binary;
A step of determining that the filter item exists based on the existence of shellcode related to the vulnerability on the binary; and
A step of determining that the filter item exists based on the information entropy of the above analysis target file exceeding a reference value;
A pre-filtering method including:
In the first paragraph,
The step of checking whether the above filter items exist is
A step of determining that the filter item exists based on the existence of a reference value for the size of the HWP file;
A pre-filtering method including:
In the first paragraph,
The step of checking whether the above filter items exist is
A step of determining that the filter item exists based on the presence of a file inserted inside the HWP file;
A pre-filtering method including:
In the third paragraph,
The step of determining that the filter item exists based on the presence of a file inserted inside the above HWP file is
Step for identifying BinData storage; and
Step 1: Identifying a stream with an .OLE extension;
A pre-filtering method including:
In paragraph 4,
The step of checking whether the above filter items exist is
A step of determining that the filter item exists based on the presence of a script inserted inside the HWP file;
A pre-filtering method including:
In paragraph 5,
The step of determining that the filter item exists based on the presence of a script inserted inside the HWP file above is
Step for identifying BinData storage; and
Step of identifying a stream with an .eps or .ps extension;
A pre-filtering method including:
delete In the first paragraph,
The list of entities associated with the above vulnerabilities is:
A pre-filtering method comprising a flash image file having a .swf extension.
delete delete In the first paragraph,
The step of checking whether the above filter items exist is
A step of extracting an image of the above analysis target file;
A step of extracting text from the image through OCR; and
A step of determining that the filter item exists based on the above text being related to a public document;
A pre-filtering method further comprising:
For servers that inspect and pre-filter internal information of incoming documents,
Department of Communications;
Memory containing a static analysis engine, a filter engine, and a dynamic analysis engine; and
A processor functionally controlling the communication unit and the memory;
The above processor
A file to be analyzed is input, the file to be analyzed is examined by the static analysis engine, and based on the result of the static analysis engine being normal, the file to be analyzed is examined by the filter engine, and through the filter engine, the existence of a filter item in the file to be analyzed is examined, and based on the existence of the filter item, the file to be analyzed is examined by the dynamic analysis engine.
The above analysis target file includes the format of an HWP file, and to check whether the filter item exists, based on a list of objects related to preset vulnerabilities, based on the existence of an object related to the vulnerability within the HWP file, it is determined that the filter item exists, and the analysis target file is read in as a binary,
Based on the existence of shellcode related to the vulnerability on the above binary, it is determined that the above filter item exists.
A server that determines that the filter item exists based on the information entropy of the above analysis target file exceeding the reference value.