WO2024075868A1 - Procédé de notification d'entrée de fichiers malveillants lors du déplacement de fichiers dans un environnement de séparation de réseau, et dispositif associé - Google Patents

Procédé de notification d'entrée de fichiers malveillants lors du déplacement de fichiers dans un environnement de séparation de réseau, et dispositif associé Download PDF

Info

Publication number
WO2024075868A1
WO2024075868A1 PCT/KR2022/015022 KR2022015022W WO2024075868A1 WO 2024075868 A1 WO2024075868 A1 WO 2024075868A1 KR 2022015022 W KR2022015022 W KR 2022015022W WO 2024075868 A1 WO2024075868 A1 WO 2024075868A1
Authority
WO
WIPO (PCT)
Prior art keywords
target file
file
server
detoxification
result
Prior art date
Application number
PCT/KR2022/015022
Other languages
English (en)
Korean (ko)
Inventor
조성욱
Original Assignee
시큐레터 주식회사
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 시큐레터 주식회사 filed Critical 시큐레터 주식회사
Priority to PCT/KR2022/015022 priority Critical patent/WO2024075868A1/fr
Priority to KR1020227034766A priority patent/KR102503699B1/ko
Publication of WO2024075868A1 publication Critical patent/WO2024075868A1/fr

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/55—Detecting local intrusion or implementing counter-measures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/55—Detecting local intrusion or implementing counter-measures
    • G06F21/56—Computer malware detection or handling, e.g. anti-virus arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements

Definitions

  • This specification relates to a method and device for notifying that a malicious file has been introduced to a user server when a file is moved from an external network to an internal network in a separated network environment.
  • APT Advanced Persistent Threat
  • Non-PE non-portable executable files containing malicious code are often used rather than executable (portable executable, PE) files.
  • a non-executable file is the opposite of an executable file and refers to a file that does not run on its own.
  • Examples of non-executable files include document files such as Word files, Excel files, Hangul files, and PDF files, image files, video files, JavaScript files, and HTML files.
  • the reason why non-executable files containing malicious code are often used in APT attacks is because applications that run non-executable files have a certain degree of security vulnerability.
  • variant malicious code can be easily created by changing the file.
  • a document action is the act of executing an action in an application program involving a non-executable file. Since existing APT solutions operate based on document behavior, they determine whether it is malicious by observing changes in the sandbox (Virtural Machine, VM) after document behavior occurs. This takes a long time to analyze because it waits for all document actions to occur before determining whether they are malicious. Additionally, existing APT solutions such as CDR can remove malicious active content, but cannot eliminate vulnerabilities arising from essential elements of the document (e.g., body, font), creating a security gap.
  • VM Virtual Machine
  • the purpose of network separation is to prevent external intrusion and leakage of internal information by separating the internal network and external network.
  • the inter-network data transmission system can move files from an external server to an internal server through network linkage. After checking the target file for malicious code (e.g., anti-virus, APT check), if the file is a malicious file, the malicious file is generally not sent to the internal server. However, in this case, users of the internal server cannot access the external server, so they cannot receive notifications about malicious files.
  • malicious code e.g., anti-virus, APT check
  • the purpose of this specification is to propose a method and device for clearly notifying the internal server of whether the file is malicious when a file is moved in a network partition environment.
  • a method for a server to handle the inflow of malicious files in a network separation environment includes: receiving a target file from an inter-network data transmission system; inspecting the target file for malicious code; Modifying the target file according to a reading result of the target file, based on whether the target file contains malicious code; and transmitting the modified target file to the network-to-network data transmission system. It includes, and the read result may indicate the possibility or impossibility of rendering the target file harmless.
  • the modifying step includes adding a string indicating that the detoxification has been completed to the file name of the target file; may include.
  • the modifying step includes adding a string indicating that the target file contains the malicious code to the file name of the target file, based on the read result indicating the impossibility of rendering the target file harmless; may include.
  • the modifying step may further include modifying the target file as a dummy file.
  • the modifying step includes performing a reversing analysis on the target file, detecting at least one of vulnerabilities and contents in the target file, and storing the detection result; Performing detoxification on content in the target file and storing the detoxification result; and generating the readout result based on the detection result and the detoxification result; may further include.
  • a server that processes the inflow of malicious files in a network separation environment includes: a communication unit; Memory with reversing engine and CDR engine; and a processor that functionally controls the communication unit and the memory; It includes, wherein the processor receives the target file from the inter-network data transmission system through the communication unit, checks the target file for malicious code, and based on whether the target file contains malicious code, According to the file reading result, the target file is modified and the modified target file is transmitted to the network data transmission system, and the reading result may indicate the possibility or impossibility of detoxification of the target file.
  • the server when a file is moved in a network separation environment, the server can clearly inform the internal server about whether the file is malicious.
  • FIG. 1 is a block diagram showing the configuration of an electronic device related to an embodiment of the present disclosure.
  • Figure 2 is a block diagram showing the configuration of a device for blocking malicious non-executable files according to an embodiment of the present disclosure.
  • Figure 3 is a diagram illustrating normal input and abnormal input that can be applied to an embodiment of the present disclosure.
  • Figure 4 is a diagram illustrating the execution flow of an application when a normal value is input and the execution flow of an application when an abnormal value is input.
  • Figure 5 is a flowchart illustrating a method for determining document behavior that can be applied to an embodiment of the present disclosure.
  • Figure 6 is a flowchart illustrating a method for blocking non-executable files that can be applied to an embodiment of the present disclosure.
  • FIG. 7 is a flowchart specifically illustrating the detection result storage step (S6100) of FIG. 6.
  • Figure 8 is a diagram showing an example of a detection result by a reversing engine.
  • Figure 9 is a diagram showing another example of a detection result by a reversing engine.
  • FIG. 10 is a flow chart specifically illustrating the detoxification result storage step (S6200) of FIG. 6.
  • Figure 11 is a diagram showing an example of the detoxification result by the CDR engine.
  • Figure 12 is a diagram showing another example of the detoxification result by the CDR engine.
  • FIG. 13 is a flowchart specifically illustrating the read result generation step (S6300) of FIG. 6.
  • Figure 14 is a diagram illustrating a reading result screen displayed through a terminal.
  • Figure 15 is an example of a network separation system to which this specification can be applied.
  • Figure 16 is an embodiment of a server to which this specification can be applied.
  • Figure 17 is an example of target file modification to which this specification can be applied.
  • unit refers to a software or hardware component, and the “unit” performs certain roles. However, “wealth” is not limited to software or hardware.
  • the “copy” may be configured to reside on an addressable storage medium and may be configured to run on one or more processors.
  • part refers to software components, such as object-oriented software components, class components, and task components, processes, functions, properties, procedures, Includes subroutines, segments of program code, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays, and variables.
  • the functionality provided within the components and “parts” may be combined into smaller numbers of components and “parts” or may be further separated into additional components and “parts”.
  • unit may be implemented with a processor and memory.
  • processor should be interpreted broadly to include general purpose processors, central processing units (CPUs), microprocessors, digital signal processors (DSPs), controllers, microcontrollers, state machines, etc.
  • processor may refer to an application-specific integrated circuit (ASIC), programmable logic device (PLD), field programmable gate array (FPGA), etc.
  • ASIC application-specific integrated circuit
  • PLD programmable logic device
  • FPGA field programmable gate array
  • processor refers to a combination of processing devices, 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 combination with a DSP core, or any other such combination of configurations. It may also refer to
  • memory should be interpreted broadly to include any electronic component capable of storing electronic information.
  • the terms memory include 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), electrical may refer to various types of processor-readable media, such as erasable PROM (EEPROM), flash memory, magnetic or optical data storage, registers, etc.
  • RAM random access memory
  • ROM read-only memory
  • NVRAM non-volatile random access memory
  • PROM programmable read-only memory
  • EPROM erasable-programmable read-only memory
  • electrical may refer to various types of processor-readable media, such as erasable PROM (EEPROM), flash memory, magnetic or optical data storage, registers, etc.
  • EEPROM erasable PROM
  • flash memory magnetic or optical data storage, registers, etc.
  • Non-executable file' as used herein is the opposite of an executable file or executable file and refers to a file that does not execute on its own.
  • non-executable files may be document files such as PDF files, Hangul files, Word files, image files such as JPG files, video files, JavaScript files, HTML files, etc., but are not limited thereto.
  • FIG. 1 is a block diagram showing the configuration of an electronic device related to an embodiment of the present disclosure.
  • the electronic device 100 includes a wireless communication unit 110, an input unit 120, a sensing unit 140, an output unit 150, an interface unit 160, a memory 170, a control unit 180, and a power supply unit 190. ), etc. may be included.
  • the components shown in FIG. 1 are not essential for implementing the electronic device 100, so the electronic device 100 described herein may have more or fewer components than those listed above. there is.
  • the wireless communication unit 110 is used between the electronic device 100 and the wireless communication system, between the electronic device 100 and another electronic device 100, or between the electronic device 100 and an external server. It may include one or more modules that enable wireless communication. Additionally, the wireless communication unit 110 may include one or more modules that connect the electronic device 100 to one or more networks.
  • This wireless communication unit 110 may include at least one of a broadcast reception module 111, a mobile communication module 112, a wireless Internet module 113, a short-range communication module 114, and a location information module 115.
  • the input unit 120 may include a camera 121 or an image input unit for inputting an image signal, a microphone 122 or an audio input unit for inputting an audio signal, and a user input unit 123 for receiving information from a user.
  • Examples of the user input unit 123 include touch keys and push keys (mechanical keys). Voice data or image data collected by the input unit 120 may be analyzed and processed as a user's control command.
  • the sensing unit 140 may include one or more sensors for sensing at least one of information within the electronic device 100, information on the surrounding environment surrounding the electronic device 100, and user information.
  • the sensing unit 140 includes a proximity sensor 141, an illumination sensor 142, a touch sensor, an acceleration sensor, and a magnetic sensor.
  • gravity sensor G-sensor
  • gyroscope sensor motion sensor
  • RGB sensor infrared sensor
  • IR sensor fingerprint scan sensor
  • ultrasonic sensor sensor an optical sensor such as the camera 121
  • a battery gauge an environmental sensor (e.g., a barometer, a soil hygrometer, a thermometer, a radiation detection sensor, a heat detection sensor, a gas detection sensor, etc.)
  • an environmental sensor e.g., a barometer, a soil hygrometer, a thermometer, a radiation detection sensor, a heat detection sensor, a gas detection sensor, etc.
  • chemical sensors eg, electronic nose, healthcare sensor, biometric sensor, etc.
  • the electronic device 100 disclosed in this specification can utilize information sensed by two or more of the illustrated sensors by combining them.
  • the output unit 150 is used to generate output related to vision, hearing, or tactile senses.
  • the output unit 150 may include at least one of a display unit 151, an audio output unit 152, a haptip module 153, and an optical output unit 154.
  • the display unit 151 can implement a touch screen by forming a layered structure or being integrated with the touch sensor. This touch screen functions as a user input unit 123 that provides an input interface between the electronic device 100 and the user, and can simultaneously provide an output interface between the electronic device 100 and the user.
  • the interface unit 160 serves as a passageway for various types of external devices connected to the electronic device 100.
  • This interface unit 160 is provided with a wired/wireless headset port, an external charger port, a wired/wireless data port, a memory card port, and an identification module. It may include at least one of a port for connecting a connected device, an audio input/output port, a video input/output port, and an earphone port.
  • the electronic device 100 may perform appropriate control related to the connected external device.
  • the memory 170 stores data supporting various functions of the electronic device 100.
  • the memory 170 may store a plurality of application programs (application programs or applications) running on the electronic device 100, data for operating the electronic device 100, and commands. At least some of these applications may be downloaded from an external server via wireless communication. In addition, at least some of these applications will be present on the electronic device 100 from the time of shipment for the basic functions of the electronic device 100 (e.g., call incoming call function, call outgoing function, message receiving function, message sending function). You can. Meanwhile, the application program may be stored in the memory 170, installed on the electronic device 100, and driven by the control unit 180 to perform an operation or function of the electronic device.
  • control unit 180 In addition to operations related to the application program, the control unit 180 typically controls the overall operation of the electronic device 100.
  • the control unit 180 can provide or process appropriate information or functions to the user by processing signals, data, information, etc. input or output through the components discussed above, or by running an application program stored in the memory 170.
  • control unit 180 may control at least some of the components examined with FIG. 1 in order to run an application program stored in the memory 170. Furthermore, the control unit 180 may operate at least two of the components included in the electronic device 100 in combination with each other in order to run the application program.
  • the power supply unit 190 receives external power and internal power under the control of the control unit 180 and supplies power to each component included in the electronic device 100.
  • This power supply unit 190 includes a battery, and the battery may be a built-in battery or a replaceable battery.
  • At least some of the components may cooperate with each other to implement operation, control, or a control method of the electronic device 100 according to various embodiments described below. Additionally, the operation, control, or control method of the electronic device 100 may be implemented on the electronic device 100 by running at least one application program stored in the memory 170.
  • a server may include an electronic device 100, and the electronic device 100 may be collectively referred to as a terminal.
  • the terminal can communicate with an external server (or external cloud server) by being connected to a network.
  • FIG. 2 is a block diagram showing the configuration of a device for blocking malicious non-executable files according to an embodiment of the present disclosure.
  • the malicious non-executable file blocking device will be referred to as 'server'.
  • the server 200 may include a control unit 210, a result reading unit 220, and a communication unit 230.
  • the control unit 210 may include a processor 212 and a memory 214.
  • the processor 212 may execute instructions stored in the memory 214.
  • the processor 212 can control the communication unit 230.
  • Memory 214 may include cache memory. Cache memory can temporarily store original documents, which will be described later, for a certain period of time.
  • the processor 212 may control the operation of the server 200 based on instructions stored in the memory 220.
  • the server 200 may include one processor or may include multiple processors. When the server 200 includes a plurality of processors, at least some of the plurality of processors may be located physically spaced apart from each other. Additionally, the server 200 is not limited to this and may be implemented in various known ways.
  • the communication unit 230 may include one or more modules that enable wireless communication between a server and a wireless communication system, between a server and another server, or between a server and an external server (terminal). Additionally, the communication unit 230 may include one or more modules that connect servers to one or more networks.
  • the control unit 210 may control at least some of the components of the server to run the application program stored in the memory 214. Furthermore, the control unit 210 can operate at least two of the components included in the server in combination with each other to run the application program.
  • the server 200 may include a reversing engine and a CDR engine.
  • a reversing engine and a CDR engine will be described in detail.
  • the reversing engine is an analysis and diagnosis engine that automates the reverse engineering process for malicious non-executable files. This is called reverse engineering, and through this, the server 200 can learn about the principles and structure of the software by going up to the assembly level, a language that allows a computer to execute software without source code. Using this, the server 200 can know the structure of general software (eg, MS Office, PDF), malicious code behavior, and methods of exploiting vulnerabilities.
  • general software eg, MS Office, PDF
  • the reversing engine may perform a file analysis step, a static analysis step, a dynamic analysis step, and a debugging analysis step.
  • a file analysis step may perform a file analysis step, a static analysis step, a dynamic analysis step, and a debugging analysis step.
  • File analysis step This is the step of analyzing the appearance of the non-executable file itself (e.g., properties, author, creation date, file type). Similar to a general anti-virus program, it diagnoses whether it is malicious using only the information of the non-executable file itself. can do.
  • Static analysis step This is a step to extract and analyze data in non-executable files to determine whether they are normal or malicious. Non-executable files are not executed, but internal data is extracted and compared and analyzed according to the file structure to diagnose maliciousness. You can. This may be suitable for extracting and analyzing macros and extracting and analyzing URLs.
  • Dynamic analysis stage This is the stage where non-executable files are executed and monitored while their behavior is analyzed to determine whether they are malicious. This is to detect malicious behavior using the normal functions of the document, such as macros, hyperlinks, and DDE (Dynamic Data Exchange). It is easy to
  • Debugging analysis stage This is the stage of analyzing vulnerabilities, exploits, etc. by executing and debugging non-executable files. It not only detects malicious behavior using normal functions of the document such as macros, hyperlinks, DDE, etc., but also analyzes the body of the document. , it is suitable for detecting vulnerabilities in applications using tables, fonts, pictures, etc.
  • the reversing engine may include a debugging engine that can be used for debugging analysis.
  • the debugging engine can use the debugging mode during the viewing process of non-executable files to diagnose vulnerabilities that occur in the document input, processing, and output stages.
  • vulnerabilities refer to errors, bugs, etc. that occur when an application receives unexpected values from the code (logic) developed by the application developer.
  • an attacker can execute malicious document actions such as denial of service due to abnormal termination or remote code execution.
  • the debugging engine may include a debugger.
  • a debugger is a tool for reverse engineering and can refer to a program or process that can set a breakpoint at the assembly level for another target program.
  • Figure 3 is a diagram illustrating normal input and abnormal input that can be applied to an embodiment of the present disclosure.
  • FIG. 3 The top of FIG. 3 is a diagram to explain a case where an application program receives a normal value through a non-executable file, and illustrates a case where the value of the Extended Counter Register (ECX) is normal data (00000001).
  • the bottom of FIG. 3 is a diagram to explain a case where an application program receives an abnormal value through a non-executable file, and illustrates a case where the value of the ECX register is abnormal data (000000CC).
  • Figure 4 is a diagram illustrating the execution flow of an application when a normal value is input and the execution flow of an application when an abnormal value is input.
  • the application receives an abnormal value (for example, when the input value exceeds the normal range of 2) through a non-executable file, the execution flow of the application changes to an execution flow that the developer did not intend. , vulnerabilities can be triggered.
  • an abnormal value for example, when the input value exceeds the normal range of 2
  • the execution flow of the application changes to an execution flow that the developer did not intend. , vulnerabilities can be triggered.
  • the debugging engine automatically debugs the document viewing process and sets breakpoints at specific points related to vulnerabilities. Additionally, it is possible to diagnose maliciousness by checking specific values (values stored in registers or memory) related to the input value to determine whether the input value is a value that causes a vulnerability.
  • the debugging engine can determine the type of non-executable file and then start debugging by running an application to view the non-executable file.
  • the debugging engine checks whether the loaded module is the module to be analyzed. As a result of the confirmation, if the loaded module is the target of analysis, a breakpoint can be set at the specified address.
  • a malicious non-executable file may terminate the application if it does not meet certain conditions, such as the application version or operating system environment, or may have branching points that diverge to a flow in which no malicious action occurs.
  • the server 200 may be analyzed by an analyst in advance, and a breakpoint may be set at a branching point having this possibility.
  • server 200 may set conditions in association with the branch point that may continue to run the application without terminating it or lead to a flow in which malicious actions may occur.
  • the server 200 may detect vulnerabilities according to detection logic and then perform a step of storing the detection results.
  • the stored detection result may be understood as a detection result report.
  • the automated reversing engine included in the server 200 automatically performs and analyzes the above-mentioned steps, and can diagnose and block malicious non-executable files through a diagnostic algorithm researched and developed by an analyst.
  • the CDR engine provides CDR services.
  • the CDR service is a solution that disassembles non-executable files, removes malicious or unnecessary files, and creates new files by keeping the content as identical as possible to the original.
  • CDR refers to a service that disarms and reconstructs the content in a document to create a safe document and provide it to customers.
  • the file subject to detoxification may be any non-executable file. Examples of non-executable files include Word files, Excel files, PowerPoint files, Hangul files, and PDF files.
  • Content subject to detoxification may be active content. Examples of active content include macros, hyperlinks, and Object Linking and Embedding (OLE).
  • the CDR engine may perform detoxification on content in a non-executable file and store the detoxification result. The stored detoxification result may be understood as a detoxification result report.
  • the result reading unit 220 generates a reading result for the decommissioned file based on the detection result provided from the reversing engine and the decommissioning result provided from the CDR engine. And based on the reading results, the detoxified file is allowed or blocked.
  • a detoxified file refers to a file for which detoxification has been completed. The results of reading the detoxified file and/or whether the detoxified file is blocked may be transmitted to the user's terminal and output through the terminal's output unit.
  • Figure 5 is a flowchart illustrating a method for determining document behavior that can be applied to an embodiment of the present disclosure.
  • the server 200 may include a non-executable file and an application program for executing the non-executable file (eg, MS Office, Hancom Office, etc.).
  • a non-executable file e.g., MS Office, Hancom Office, etc.
  • an application program for executing the non-executable file eg, MS Office, Hancom Office, etc.
  • the server 200 executes the application process in debugging mode (S4010).
  • the server 200 may execute a document process to open a non-executable file to be analyzed for an application program in debugging mode (DEBUG_ONLY_THIS_PROCESS) using the CreateProcess API. Through this, the server 200 can receive debug events of the application process.
  • the server 200 can execute an application process by setting the “DEBUG_ONLY_THIS_PROCESS” flag using the CreateProcess API.
  • the server 200 sets a first breakpoint at a point matching document behavior based on the application process (S4020). For example, the server 200 may set a breakpoint by changing the operating (OP) code related to the process of the application program loaded in the memory 214 to “0xCC”. OP code refers to an instruction code and may be a code in which the content of work to be actually performed by the CPU is written. To this end, the server 200 can change the memory 214 using WriteProcessMemory.
  • the server 200 may have information about document actions and points at which the corresponding document actions are matched in advance.
  • the server 200 can install a breakpoint using the WriteProcessMemory API according to a predefined behavior matching breakpoint table.
  • the server 200 checks whether a non-executable file is running (S4030). More specifically, after setting a breakpoint, the server 200 checks whether other non-executable files for which analysis has been requested are being viewed. Depending on the function required by the non-executable file, the application process loads the necessary modules into the memory 214, so in order to ensure the reliability of determining the document behavior of the target non-executable file, the application program ensures that other non-executable files are not viewed. Must have status. For example, if a malicious non-executable file has been viewed, the reliability of the document behavior judgment result may be reduced.
  • the server 200 executes the non-executable file to be analyzed based on the fact that other non-executable files are not running (S4040). More specifically, the server 200 views the non-executable file that the user has requested analysis using an application program process (eg, EXCEL, WORD, PPT, etc.) appropriate for the format. For example, the server 200 can view the sample.ppt file using MS Power point.
  • an application program process eg, EXCEL, WORD, PPT, etc.
  • the server 200 determines whether a new module related to the non-executable file to be analyzed has been loaded on the memory 214 (S4050). When the non-executable file to be analyzed is executed by the application process, the server 200 checks whether a new module is loaded.
  • the server 200 can use the debugging mode to receive a debugging event when it occurs in an application process.
  • the server 200 may use the event to determine that a new module (for example, DLL memory is installed) when a LOAD DLL event occurs.
  • the server 200 may determine that a new module has been loaded into the memory 214 when the “LOAD_DLL_DEBUG_EVENT” event occurs.
  • the server 200 may load a new module suitable for the application process function into the memory 214 in order to use the necessary functions (e.g., macros, ActiveX functions, etc.) in the non-executable file to be analyzed. there is.
  • necessary functions e.g., macros, ActiveX functions, etc.
  • the server 200 sets a second breakpoint at a point matching document behavior based on the loading of the new module (S4060). If it is not determined that a new module has been loaded, the server 200 does not set a second breakpoint.
  • the server 200 monitors whether the application process is stopped at the first breakpoint and/or the second breakpoint (S4070). For example, the server 200 may check whether the application process is stopped at the breakpoint and process control is transferred to the debugger. The debugger that has taken over control can check at what breakpoint it stopped.
  • the server 200 generates document behavior information matching the first breakpoint and/or the second breakpoint based on the monitoring results (S4080). For example, the server 200 can check the address value of the breakpoint. Thereafter, the server 200 may generate information about the document action matched with the address value of the breakpoint based on the information about the corresponding document action and the point at which the corresponding document action matches, and store this information as a detection result.
  • Table 1 below is an example of document behavior matched with the address value of the stored breakpoint.
  • the server 200 may perform additional actions to obtain document actions.
  • the server 200 determines whether the viewing of the non-executable file to be analyzed has ended (S4090). For example, the server 200 may determine whether the viewing of the non-executable file to be analyzed has ended in a manner such as when a preset time has passed or when a message box (Alert) or a breakpoint has not been reached for a certain period of time. If the viewing is not terminated, the server 200 continuously monitors whether the application process is stopped at a breakpoint. Through this, the server 200 can wait for document actions to fully occur.
  • the server 200 may transmit the stored document behavior information to the terminal.
  • the terminal can communicate with the server 200 and may include a management application that can control the operation of the server.
  • the terminal can provide document behavior information to the user through a management application.
  • server 200 of the present specification may start analysis from the time the application process is executed in the stage before the sandbox is changed.
  • the analysis speed is faster than existing APT solutions.
  • Figure 6 is a flowchart illustrating a method for blocking non-executable files that can be applied to an embodiment of the present disclosure.
  • the reversing engine of the server 200 performs a reversing analysis on the input non-executable file and stores the detection results for vulnerabilities and/or malicious active content (S6100).
  • the detection result is provided to the result reading unit 220. A more detailed description of step S6100 will be described later with reference to FIGS. 7 to 9.
  • the CDR engine of the server 200 performs detoxification on the content in the input non-executable file and stores the detoxification result (S6200). At this time, step S6200 does not necessarily have to be executed after step S6100, and steps S6200 and S6100 may be performed simultaneously.
  • the detoxification result is provided to the result reading unit 220. A more detailed description of step S6200 will be described later with reference to FIGS. 10 to 12.
  • the result reading unit 220 of the server 200 generates a final reading result for the detoxified file based on the detection result provided from the reversing engine and the detoxification result provided from the CDR engine (S6300).
  • the reading results include the type of non-executable file entered, the content detected by the reversing engine (e.g. vulnerabilities, macros, hyperlinks, JavaScript), whether the detected content can be rendered harmless by the CDR engine, It may include one or more of whether the detected content has been detoxified by the CDR engine and whether the detoxified file is safe.
  • the type and/or number of information to be included in the reading result may be implemented to be changeable by the user.
  • the generated reading result may be provided to the user's terminal and may be output in the form of an audio signal and/or a video signal through an output unit of the terminal.
  • FIG. 7 is a flowchart specifically illustrating the detection result storage step (S6100) of FIG. 6.
  • Step S6110 may be understood as the document behavior determination method shown in FIG. 5.
  • the reversing engine determines whether there are results detected by the reversing analysis (S6120). For example, it determines whether there are vulnerabilities or malicious active content detected in non-executable files.
  • the CDR engine of the server 200 determines whether the detection result can be rendered harmless (S6130).
  • the determination may be made based on the type of CDR engine. This is because detoxification coverage varies depending on the type of CDR engine.
  • harmless coverage can be understood as a concept that includes one or more of a harmless file and a harmless content.
  • detoxification is not possible for content called JavaScript, but macro, Flash, object connection insertion, It is possible to detoxify content such as Active X, Embedded Document, Hyperlink, and Attachments.
  • step S6130 if the corresponding detection result cannot be detoxified in the CDR engine, a label that cannot be detoxified is recorded on the corresponding detection result (S6140).
  • step S6130 if the corresponding detection result can be detoxified in the CDR engine, a detoxification possible label is recorded in the corresponding detection result (S6150).
  • the detection result is stored (S6160).
  • the detection result may have an XML format, for example, but is not limited to the format shown.
  • the detection results by the reversing engine will be described with reference to FIGS. 8 and 9.
  • Figure 8 is a diagram showing an example of a detection result by a reversing engine.
  • the detection result is in XML format. You can see that "CVE-2017-11826.RE.300” is recorded in the “Name” item, and the value 'false' is recorded in the "isPossibelCDR” item. This means that a text vulnerability was detected in the debugging engine while running the reversing analysis, and the detected text vulnerability cannot be detoxified in the CDR engine.
  • Figure 9 is a diagram showing another example of a detection result by a reversing engine.
  • the vulnerability detection result is in XML format. And you can see that "_DownloaderMacro” is recorded in the “exploitName” item, and the value 'ture' is recorded in the "isPossibleCDR” item. This means that a malicious macro was detected in the debugging engine while running the reversing analysis, and the detected malicious macro can be rendered harmless in the CDR engine.
  • FIG. 10 is a flow chart specifically illustrating the detoxification result storage step (S6200) of FIG. 6.
  • the CDR engine determines whether content subject to detoxification exists in the input non-executable file (S6210).
  • Content subject to detoxification may be active content such as macros, hyperlinks, and object connection insertions.
  • step S6210 if content to be detoxified exists in the non-executable file, detoxification is performed on the content to be detoxified (S6220). Since content detoxification is a known technology, detailed description of it will be omitted.
  • the CDR engine determines whether content detoxification was successful (S6230).
  • step S6230 If, as a result of the determination in step S6230, the content has failed to be rendered harmless, the failure to render the content harmless is recorded in the detoxification result (S6240).
  • step S6230 If, as a result of the determination in step S6230, the content has been successfully detoxified, the successful detoxification is recorded in the detoxification results (S6250).
  • step S6210 if there is no content subject to detoxification in the non-executable file, this fact is recorded in the detoxification result (S6260).
  • Figure 11 is a diagram showing an example of the detoxification result by the CDR engine.
  • the value 'true' is recorded in the 'result' item, which means that the non-executable file is harmless.
  • the value 'SUCCESS' is recorded in the 'status' item, which means that the detoxification target content in the non-executable file was successfully detoxified.
  • CDR Process Success is recorded, which means that detoxification was successfully performed in the CDR engine.
  • the value 'NO DETECTION' is recorded in the 'status' item. And the non-executable file is also judged to be harmless, so the value 'true' is recorded in the 'result' field.
  • the detoxification result may also include 'fileType', 'inputFileName', 'inputFullPath', 'outputFileName', 'outputFullPath', 'elapsedTime', and 'cdrEntities' items.
  • the 'fileType' item is where the type of non-executable file is recorded.
  • the 'inputFileName' and 'inputFullPath' items are where the name of the non-executable file and the storage path of the non-executable file are recorded, respectively.
  • the 'outputFileName' and 'outputFullPath' items are where the name of the detoxified file and the storage path of the detoxified file are recorded, respectively.
  • the 'elapsedTime' item is where the time taken for detoxification is recorded.
  • the 'cdrEntities' item is where the properties of the data storing the detoxification results are recorded. The fact that 'Array' is written in the 'cdrEntities' field means that the detoxification results are stored in array form.
  • Figure 12 is a diagram showing another example of the detoxification result by the CDR engine.
  • the value 'false' is recorded in the 'result' item, which means that the non-executable file is not harmless.
  • the value "FAILURE” is recorded in the 'status' item, which means that detoxification failed for the content to be detoxified in the non-executable file.
  • "I/O Error Occurs” is recorded, which means that a detoxification failure error may occur due to an input/output error for the file.
  • FIG. 13 is a flowchart specifically illustrating the read result generation step (S6300) of FIG. 6.
  • the result reading unit 220 checks the detection result provided from the reversing engine (S6310) and determines whether there is a target (eg, vulnerability, malicious active content) with a label that cannot be detoxified (S6320).
  • a target eg, vulnerability, malicious active content
  • step S6320 if there is no object with a non-harmful label, the result reading unit 220 determines that there is an object with a label that can be harmless. Then, the detoxification result provided from the CDR engine is checked (S6330) to determine whether the detoxification of the object with the detoxification possible label was successful (S6340).
  • step S6340 if detoxification is successful for the object with the detoxification possible label, the result reading unit 220 generates a reading result indicating that the detoxified file is safe (S6350).
  • step S6340 if detoxification has failed for the content with the label capable of detoxification, the result reading unit 220 generates a reading result indicating that the detoxified file is dangerous (S6380).
  • the result reading unit 220 may allow or block the deactivated file based on the reading result. Specifically, if the detoxified file is read as safe, the detoxified file is allowed. Conversely, if the detoxified file is read as dangerous, the detoxified file is blocked.
  • the result reading unit 220 can provide the reading result of the detoxified file to the user's terminal and output it through the output unit.
  • Figure 14 is a diagram illustrating a reading result screen displayed through a terminal.
  • the read result screen may include the type of the input non-executable file, the detection result of the reversing engine, the detoxification result of the CDR engine, and the final read result of the detoxified file.
  • the detection results of the reversing engine may include information about the detected content and whether the detected content is malicious.
  • Examples of detected content include object vulnerabilities, text vulnerabilities, macros, hyperlinks, object link injection, and JavaScript.
  • the detoxification results of the CDR engine may include information about the detoxification target and whether detoxification was successful for the detoxification target.
  • the body vulnerability detected in the non-executable file was analyzed as malicious and was given a label that cannot be detoxified. Since detoxification is not possible in the CDR engine for detected text vulnerabilities, it can be seen that even if detoxification is successful for the detected macro, the detoxification file output from the CDR engine is read as dangerous.
  • a word file containing a hyperlink is entered as a non-executable file, you can see that the hyperlink has been detected in the reversing engine. It can be seen that the detected hyperlink was analyzed as normal, not malicious, and was given a label that could be made harmless.
  • the analysis result that the detected hyperlink is normal may be a result obtained because it is difficult to detect malicious actions using hyperlinks in the reversing engine. Therefore, by assigning a decommunicable label to the detected hyperlink, saving the detection result, and comparing the saved detection content with the decommissioning result of the CDR engine, more accurate reading results can be obtained for the decommunicated file output from the CDR engine. You can. In fact, since hyperlink detoxification was successful in the CDR engine, it can be seen that the detoxified file output from the CDR engine was read as safe.
  • Figure 15 is an example of a network separation system to which this specification can be applied.
  • the network separation system can be divided into an internal (business) network and an external (Internet) network, and data transmission between the separated networks can be performed through an inter-network data transmission system.
  • the government of the Republic of Korea is stipulating network separation guidelines for public, financial, and general companies, and since 2012, the regulations have been strengthened and made mandatory rather than recommended.
  • the solution that can transmit data between work PCs and Internet PCs is a network connection solution, and the network data transmission system can include a network connection solution.
  • files from a work PC can be transferred to an Internet PC through the Manganese data transmission system after administrator approval
  • files from an Internet PC can be transferred to a work PC through the Manganese data transmission system after administrator approval
  • the server 200 is connected to the inter-network data transmission system and can inspect and filter files passing through the inter-network data transmission system. For example, if the inter-network data transmission system requests the server 200 to scan for malicious code for a file transmitted from an external network to the inter-network data transmission system, the server 200 can check the file for malicious code. there is. If the server 200 discovers malicious code, the server 200 can block the file.
  • Figure 16 is an embodiment of a server to which this specification can be applied.
  • the server 200 is connected to an inter-network data transmission system in a network separation environment and can inspect target files being moved between networks.
  • the server 200 receives the target file from the inter-network data transmission system (S1610).
  • target files can be uploaded to a predefined directory in the inter-network data transmission system for movement to the internal network.
  • the manganese data transmission system can deliver the target file to the server 200 for malicious code inspection of the target file according to a predefined policy.
  • the server 200 checks the target file for malicious code (S1620). For example, the server 200 may inspect the target file through the operations of FIGS. 5 to 14 described above.
  • the server 200 determines whether the target file contains malicious code (S1630).
  • the server 200 modifies the target file based on the read result of the target file based on whether it contains malicious code (S1640).
  • the server 200 performs a reversing analysis on the target file, detects at least one of vulnerabilities and content in the target file, stores the detection result, and performs detoxification of the content in the target file.
  • the detoxification results can be stored and a reading result can be generated.
  • the readout results include what was detected by the reversing engine (e.g. vulnerabilities, macros, hyperlinks, JavaScript), whether the detected content can be neutralized by the CDR engine, and whether the detected content can be neutralized by the CDR engine. It may include whether or not it has been made harmless, whether the target file that has been made harmless is safe/dangerous, etc.
  • the reversing engine e.g. vulnerabilities, macros, hyperlinks, JavaScript
  • the server 200 can detoxify the target file through the CDR engine and modify the file name of the target file to notify users of the internal network that detoxification has been completed. For example, you can add the string “CDR” to the front of the file name (e.g., CDR_ INVOICE.xlsx).
  • the server 200 may modify the target file name to clearly inform internal users that the target file contains malicious code. .
  • the server 200 may additionally block the target file.
  • the server 200 can create a 0KB file (Dummyfile) to notify the internal user that the target file is blocked, and modify it to be the target file.
  • the server 200 may add the string “MALWARE” to the front end of the file name of the target file that has been modified as a dummy file.
  • the server 200 transmits the modified target file to the network data transmission system (S1650).
  • the manganese data transmission system can deliver the received modified target file to an internal user terminal, and the internal user terminal can easily determine whether the target file contains malicious code and the processing progress without having to access the server 200.
  • the server 200 may determine the target file to be a normal file and transmit it to the inter-network data transmission system.
  • the inter-network data transmission system can transmit target files directly to the internal network.
  • Figure 17 is an example of target file modification to which this specification can be applied.
  • the server 200 may deliver a modified target file to an internal user.
  • the target file may be modified as a dummy file with OKB, and a string may be added to the file name to indicate that it contains malicious code.
  • the server 200 can clearly notify the internal user server about the processing of the target file when the target file moves in a network separation environment of different bands.
  • malicious notifications can be clearly made to internal users without additional deployment of notification services (e.g., SMS, mail server 200, etc.), and in terms of management of the server 200, changing file names and capacity is easy and difficult to develop. , it is not restricted by OS area.
  • notification services e.g., SMS, mail server 200, etc.
  • the disclosed embodiments may be implemented in the form of a recording medium that stores instructions executable by a computer. Instructions may be stored in the form of program code, and when executed by a processor, may create program modules to perform operations of the disclosed embodiments.
  • the recording medium may be implemented as a computer-readable recording medium.
  • Computer-readable recording media include all types of recording media storing instructions that can be decoded by a computer. For example, there may be read only memory (ROM), random access memory (RAM), magnetic tape, magnetic disk, flash memory, optical data storage, etc.
  • ROM read only memory
  • RAM random access memory
  • magnetic tape magnetic tape
  • magnetic disk magnetic disk
  • flash memory optical data storage
  • computer-readable recording media may be provided in the form of non-transitory storage media.
  • 'non-transitory storage medium' simply means that it is a tangible device and does not contain signals (e.g. electromagnetic waves). This term refers to cases where data is semi-permanently stored in a storage medium and temporary storage media. It does not distinguish between cases where it is stored as .
  • a 'non-transitory storage medium' may include a buffer where data is temporarily stored.
  • Computer program products are commodities and can be traded between sellers and buyers.
  • the computer program product may be distributed in the form of a machine-readable recording medium (e.g. compact disc read only memory (CD-ROM)) or via an application store (e.g. Play StoreTM) or on two user devices (e.g. It may be distributed directly between smartphones (e.g. smartphones) or distributed online (e.g. downloaded or uploaded).
  • a machine-readable recording medium e.g. compact disc read only memory (CD-ROM)
  • an application store e.g. Play StoreTM
  • two user devices e.g. It may be distributed directly between smartphones (e.g. smartphones) or distributed online (e.g. downloaded or uploaded).
  • a computer program product e.g., a downloadable app
  • a machine-readable recording medium such as the memory of a manufacturer's server, an application store's server, or a relay server. It can be stored or created temporarily.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Virology (AREA)
  • Storage Device Security (AREA)

Abstract

La présente invention concerne un procédé au moyen duquel un serveur gère l'entrée de fichiers malveillants dans un environnement de séparation de réseau, le procédé consistant à : recevoir un fichier cible en provenance d'un système de transmission de données interréseau; inspecter un code malveillant du fichier cible; modifier le fichier cible en fonction des résultats de lecture du fichier cible sur la base du fait que le code malveillant est inclus dans le fichier cible; et transmettre le fichier cible modifié au système de transmission de données interréseau, les résultats de lecture pouvant indiquer la possibilité ou l'impossibilité de désinfection du fichier cible.
PCT/KR2022/015022 2022-10-06 2022-10-06 Procédé de notification d'entrée de fichiers malveillants lors du déplacement de fichiers dans un environnement de séparation de réseau, et dispositif associé WO2024075868A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
PCT/KR2022/015022 WO2024075868A1 (fr) 2022-10-06 2022-10-06 Procédé de notification d'entrée de fichiers malveillants lors du déplacement de fichiers dans un environnement de séparation de réseau, et dispositif associé
KR1020227034766A KR102503699B1 (ko) 2022-10-06 2022-10-06 네트워크 망분리 환경에서 파일 이동시 악성파일의 유입을 알리기 위한 방법 및 이를 위한 장치

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/KR2022/015022 WO2024075868A1 (fr) 2022-10-06 2022-10-06 Procédé de notification d'entrée de fichiers malveillants lors du déplacement de fichiers dans un environnement de séparation de réseau, et dispositif associé

Publications (1)

Publication Number Publication Date
WO2024075868A1 true WO2024075868A1 (fr) 2024-04-11

Family

ID=85330645

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2022/015022 WO2024075868A1 (fr) 2022-10-06 2022-10-06 Procédé de notification d'entrée de fichiers malveillants lors du déplacement de fichiers dans un environnement de séparation de réseau, et dispositif associé

Country Status (2)

Country Link
KR (1) KR102503699B1 (fr)
WO (1) WO2024075868A1 (fr)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20140034555A (ko) * 2012-09-12 2014-03-20 (주)나무소프트 파일 관리 장치 및 방법
US20150007321A1 (en) * 2005-12-12 2015-01-01 Finjan, Inc. Computer Security Method and System With Input Parameter Validation
KR102093274B1 (ko) * 2019-05-28 2020-03-25 (주)지란지교시큐리티 콘텐트 스캐닝 에이전트, 콘텐트 스캐닝 방법 및 그 방법을 수행하는 프로그램을 기록한 컴퓨터 판독 가능 기록매체

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150007321A1 (en) * 2005-12-12 2015-01-01 Finjan, Inc. Computer Security Method and System With Input Parameter Validation
KR20140034555A (ko) * 2012-09-12 2014-03-20 (주)나무소프트 파일 관리 장치 및 방법
KR102093274B1 (ko) * 2019-05-28 2020-03-25 (주)지란지교시큐리티 콘텐트 스캐닝 에이전트, 콘텐트 스캐닝 방법 및 그 방법을 수행하는 프로그램을 기록한 컴퓨터 판독 가능 기록매체

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
"OfficeScan XG Administrator’s Guide", TREND MICRO, October 2016 (2016-10-01), pages 1 - 873, Retrieved from the Internet <URL:https://docs.trendmicro.com/all/ent/officescan/v12.0/en-us/osce_12.0_ag.pdf> *
WON BYEONG-CHEOL: "CDR Intensive Analysis, The Hottest Security Item of 2020", BOANNEWS CO., LTD., 2 January 2020 (2020-01-02), pages 1 - 9, XP093155700, Retrieved from the Internet <URL:https://www.boannews.com/media/view.asp?idx=85512#> *

Also Published As

Publication number Publication date
KR102503699B1 (ko) 2023-02-24

Similar Documents

Publication Publication Date Title
WO2021060856A1 (fr) Système et procédé pour un accès au réseau sécurisé d&#39;un terminal
WO2013168913A1 (fr) Appareil et procédé de contrôle de fichiers non exécutables
US7665138B2 (en) Detecting method and architecture thereof for malicious codes
WO2010062063A2 (fr) Procédé et système pour prévenir une utilisation illicite liée à un logiciel de navigation
US7934261B1 (en) On-demand cleanup system
KR101212553B1 (ko) 악성 파일 검사 장치 및 방법
CN107408176A (zh) 恶意对象的执行剖析检测
WO2023229063A1 (fr) Procédé d&#39;amélioration de l&#39;efficacité d&#39;un espace de sauvegarde de fichier d&#39;origine, à l&#39;aide d&#39;un procédé d&#39;extraction de delta dans une opération de désarmement, et dispositif associé
WO2017126786A1 (fr) Dispositif électronique d&#39;analyse de code malveillant et procédé associé
WO2020027413A1 (fr) Dispositif et procédé pour restaurer une application supprimée par une fonction de réinitialisation de données d&#39;usine
WO2023229065A1 (fr) Procédé et dispositif de blocage d&#39;un fichier exécutable non portable malveillant par utilisation d&#39;un moteur d&#39;inversion et d&#39;un moteur cdr
WO2023090864A1 (fr) Appareil et procédé d&#39;analyse automatique de journal d&#39;événements malveillants
WO2018208032A1 (fr) Ordinateur ayant une unité informatique d&#39;utilisateur isolée
Chevalier et al. Co-processor-based behavior monitoring: Application to the detection of attacks against the system management mode
US20190236275A1 (en) Just in time memory analysis for malware detection
WO2018194196A1 (fr) Procédé et système de détection d&#39;application d&#39;obfuscation et d&#39;évaluation de la sécurité d&#39;un fichier elf
WO2024075868A1 (fr) Procédé de notification d&#39;entrée de fichiers malveillants lors du déplacement de fichiers dans un environnement de séparation de réseau, et dispositif associé
WO2023229066A1 (fr) Procédé d&#39;inversion de détermination d&#39;action de document basé sur un moteur, et dispositif associé
WO2014200201A1 (fr) Appareil de gestion de sécurité de fichier et procédé de gestion de protection de système
WO2014168406A1 (fr) Appareil et procédé permettant de diagnostiquer une attaque qui contourne des mécanismes de protection de mémoire
WO2024063184A1 (fr) Procédé et appareil pour désarmer un lien dans pdf ou hwp
WO2020013470A1 (fr) Procédé et dispositif électronique de détermination de falsification de données
WO2019177265A1 (fr) Procédé de traitement de données contre les logiciels rançonneurs, programme d&#39;exécution de ce dernier, et support d&#39;enregistrement lisible par ordinateur avec programme enregistré sur ce dernier
CN116028157A (zh) 风险识别方法、装置及电子设备
CN109522714A (zh) 一种基于外挂防护软件对目标软件进行防护的方法及系统

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22961513

Country of ref document: EP

Kind code of ref document: A1