WO2022259528A1 - 生成装置、生成方法及び生成プログラム - Google Patents

生成装置、生成方法及び生成プログラム Download PDF

Info

Publication number
WO2022259528A1
WO2022259528A1 PCT/JP2021/022320 JP2021022320W WO2022259528A1 WO 2022259528 A1 WO2022259528 A1 WO 2022259528A1 JP 2021022320 W JP2021022320 W JP 2021022320W WO 2022259528 A1 WO2022259528 A1 WO 2022259528A1
Authority
WO
WIPO (PCT)
Prior art keywords
malware
trace
activity
generation
unit
Prior art date
Application number
PCT/JP2021/022320
Other languages
English (en)
French (fr)
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/JP2021/022320 priority Critical patent/WO2022259528A1/ja
Priority to JP2023526811A priority patent/JP7563596B2/ja
Publication of WO2022259528A1 publication Critical patent/WO2022259528A1/ja

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
    • G06F21/56—Computer malware detection or handling, e.g. anti-virus arrangements

Definitions

  • the present invention relates to a generation device, a generation method, and a generation program.
  • malware infections As cyberattacks become more sophisticated and sophisticated, it is becoming difficult to detect malware infections with conventional antivirus software based on file hash values and signatures. Similarly, it is becoming difficult to detect malware infections with conventional network monitoring based on known malicious communication destinations and communication content.
  • EDR Endpoint Detection and Response
  • IoC Indicator of Compromise
  • Non-Patent Document 1 and Non-Patent Document 2 have been proposed as techniques for automatically generating IoC from malware activity traces observed on analysis systems. These technologies cluster the observed activity traces and aggregate them using regular expressions to generate general-purpose IoCs that capture the activity traces within the cluster.
  • Malware activity traces can be classified into those that are uniquely determined depending on the execution environment and those that are not uniquely determined depending on the execution environment. For the former, it is possible to create a simple IoC that uses only the minimum number of regular expressions by creating it for each terminal to be monitored. However, since the non-patent literature does not consider the characteristics of activity traces, even for activity traces that are uniquely determined depending on the execution environment, overdetection due to abstraction using regular expressions occurs. There was a problem that matching took time.
  • the present invention has been made in view of the above, and aims to provide a generation device, a generation method, and a generation program that can improve the accuracy of extracting study materials from which specifications are created.
  • the generation apparatus executes the malware multiple times while rewriting the values returned by the instructions of the malware that acquires information from the execution environment.
  • an extraction unit for extracting an activity trace that is uniquely determined depending on the execution environment, and a program code for reproducing processing related to the generation of the activity trace extracted by the extraction unit.
  • a creation unit and a generation unit that generates trace information of a terminal to be monitored by executing the program code.
  • FIG. 1 is a diagram showing an example of a trace information generation system according to this embodiment.
  • FIG. 2 is a functional block diagram showing the configuration of the trace information generating device according to this embodiment.
  • FIG. 3 is a diagram showing an example of the data structure of a malware DB.
  • FIG. 4 is a diagram illustrating an example of a data structure of a management table of an analysis log DB;
  • FIG. 5 is a diagram illustrating an example of the data structure of a log table of an analysis log DB;
  • FIG. 6 is a diagram showing an example of the data structure of the environment-dependent trace DB.
  • FIG. 7 is a flowchart (1) showing the processing procedure of the analysis unit.
  • FIG. 8 is a flowchart (2) showing the processing procedure of the analysis unit.
  • FIG. 7 is a flowchart (1) showing the processing procedure of the analysis unit.
  • FIG. 9 is a flowchart (1) showing the processing procedure of the extraction unit.
  • FIG. 10 is a flowchart (2) showing the processing procedure of the extraction unit.
  • FIG. 11 is a flow chart showing the processing procedure of the creating unit.
  • FIG. 12 is a flow chart showing the processing procedure of the generation unit of the trace information generation device and the agent of the terminal to be monitored.
  • FIG. 13 is a diagram depicting an example of IoC generated by the generation unit;
  • FIG. 14 is a flow chart showing the processing procedure of the trace information generating device according to this embodiment.
  • FIG. 15 is a diagram illustrating an example of a computer that executes a trace information generation program;
  • FIG. 1 is a diagram showing an example of a trace information generation system according to this embodiment. As shown in FIG. 1, this trace information generation system has a trace information generation device 100 and monitored terminals 50a, 50b, and 50c. Trace information generation device 100 and monitored terminals 50 a , 50 b , 50 c are interconnected via network 30 . Trace information generation device 100 is an example of a generation device.
  • the monitored terminals 50a, 50b, and 50c are shown as an example, but the trace information generation system may include other monitored terminals.
  • the monitored terminals 50 a to 50 c are collectively referred to as a monitored terminal 50 .
  • the trace information generation device 100 executes malware multiple times while rewriting values returned by APIs (Application Programming Interfaces) and system calls that acquire execution environment information, so that malware activity traces are unique depending on the execution environment. After specifying that it is a trace determined by , a program code that reproduces only the processing related to the generation of the activity trace is generated using the program code of the malware. By executing the generated program code on the monitoring target terminal 50, the trace information generating device 100 clarifies in advance the activity trace when the monitoring target terminal 50 is infected with malware, and creates an IoC dedicated to the monitoring target terminal 50. to generate
  • FIG. 2 is a functional block diagram showing the configuration of the trace information generating device according to this embodiment.
  • the trace information generation device 100 has a communication section 110 , an input section 120 , a display section 130 , a storage section 140 and a control section 150 .
  • the communication unit 110 is a communication interface that transmits and receives various information to and from the monitored terminal 50 connected via the network 30 or the like.
  • the communication unit 110 is implemented by a NIC (Network Interface Card) or the like, and performs communication between the monitoring target terminal 50 and the control unit 150 via an electric communication line such as a LAN (Local Area Network) or the Internet.
  • NIC Network Interface Card
  • the input unit 120 is an input interface that accepts various operations from the operator of the trace information generating device 100 .
  • it is composed of input devices such as a keyboard and a mouse.
  • the display unit 130 is an output device that outputs information acquired from the control unit 150, and is realized by a display device such as a liquid crystal display, a printing device such as a printer, and the like.
  • the storage unit 140 has a malware DB 141, an analysis log DB 142, an environment dependence trace DB 143, and a generation program DB 144.
  • the storage unit 140 is implemented by a semiconductor memory device such as RAM (Random Access Memory) or flash memory, or a storage device such as a hard disk or optical disk.
  • the malware DB 141 is a DB that records information about malware.
  • FIG. 3 is a diagram showing an example of the data structure of a malware DB. As shown in FIG. 3, the malware DB 141 has malware IDs, program codes, file types, and analyzed flags.
  • a malware ID is an identifier that identifies malware to be analyzed.
  • the program code is the program code body of the malware.
  • the file type indicates the file type of the malware's program code.
  • the analyzed flag is a flag value indicating whether or not the corresponding malware has been analyzed. "on” is set when the analysis is completed, and “off” is set when the analysis is not completed.
  • the analysis log DB 142 is a DB that records the results of emulating and analyzing malware. It has a management table 142a and a log table 142b.
  • FIG. 4 is a diagram showing an example of the data structure of the management table of the analysis log DB. As shown in FIG. 4, this management table 142a has analysis IDs, malware IDs, and configuration files. Analysis ID is an identifier of an analysis task. A malware ID is an identifier of malware corresponding to the malware ID set in the malware DB 141 . The setting file indicates the setting file used for analysis.
  • FIG. 5 is a diagram showing an example of the data structure of the log table of the analysis log DB.
  • the log table 142b has analysis ID, log ID, PID, TID, instruction type, operation type, address, instruction, register (ID, value), memory (address, size, value).
  • the analysis ID is the identifier of the analysis task.
  • a log ID is an identifier of a log within an analysis task.
  • PID is the identifier of the process.
  • TID is a thread identifier.
  • the instruction type is information indicating any one of assembly instruction, API, and system call.
  • the operation type is information indicating whether reading or writing was performed on a register or memory. Address indicates an execution address. In the instruction, if it is an assembly instruction, the result of disassembly is described, and if it is an API, the API name is described.
  • the instruction is related to register manipulation, the ID that identifies the register and the value are recorded. If the instruction concerns a memory operation, the memory address, size and value are recorded.
  • the environment-dependent trace DB 143 is a DB that records information about malware activity traces that are uniquely determined depending on the execution environment.
  • FIG. 6 is a diagram showing an example of the data structure of the environment-dependent trace DB. As shown in FIG. 6, the environment-dependent trace DB 143 has trace IDs, malware IDs, analysis IDs, log IDs, trace types, environment-dependent traces, and dependency commands.
  • a dependency instruction includes a log ID, type, instruction name, arguments, and type.
  • the trace ID is the identifier of the extracted activity trace.
  • Malware ID is an identifier of malware.
  • Analysis ID is an identifier of an analysis task.
  • a log ID is an identifier of a log in an analysis task. For example, the log ID is set to a log ID that identifies the first log among the logs corresponding to the activity trace.
  • An environment-dependent trace is a concrete value of an activity trace extracted from an analysis log.
  • the dependency command includes log ID, type, command name, argument, and type.
  • the log ID included in the dependency command is the identifier of the log in the analysis task and indicates the log ID in which the corresponding command was executed.
  • the type indicates the type of instruction such as API or system call.
  • the command name indicates the name of the command, and in the case of API, the API name is set.
  • Argument indicates what number argument holds the return value that affects the activity trace.
  • the type indicates the type information of the argument.
  • the trace type of the activity trace with the trace ID “E1” is “file path”, and the value is changed by the data pointed to by the “4” argument of the instruction name “GetVolumeInformationW”. shown to change.
  • the generation program DB 144 is a DB that records activity trace generation programs.
  • the activity trace generation program is a program created by the creation unit 153, which will be described later.
  • the control unit 150 has an analysis unit 151 , an extraction unit 152 , a creation unit 153 and a generation unit 154 .
  • the control unit 150 is implemented using a CPU (Central Processing Unit) or the like.
  • the analysis unit 151 dynamically analyzes the malware recorded in the malware DB 141 and records the analysis results in the analysis log DB 142.
  • the analysis unit 151 performs virtualization on a process-by-process basis, and performs analysis while emulating the functions provided by the OS (Operating System) and hardware.
  • the analysis unit 151 will explain the processing of the analysis unit 151 using FIGS. 7 and 8. FIG.
  • the analysis unit 151 of the trace information generating device 100 initializes the virtual environment according to the setting file (step S101).
  • the malware is expanded to a predetermined address in the virtual memory, the initial values of the virtual CPU are set such as the setting of the instruction pointer, the files to be installed in the virtual file system, and the processes to exist on the virtual OS.
  • Initialize virtual objects such as
  • the analysis unit 151 sets the execution start position of the program code (step S102).
  • the analysis unit 151 fetches an instruction from the address indicated by the instruction pointer (step S103).
  • the analysis unit 151 determines whether the fetched instruction is a valid instruction (step S104). If the fetched instruction is not a valid instruction (step S104, No), the analysis unit 151 proceeds to step S113 in FIG.
  • step S104 determines whether the instruction is a system call (step S105). If the instruction is not a system call (step S105, No), the analysis unit 151 proceeds to step S110.
  • step S105 if the instruction is a system call (step S105, Yes), the analysis unit 151 emulates the system call and reflects the result in the virtual environment (step S106). The analysis unit 151 records the read/write result as a log in the analysis log DB 142 (step S107).
  • the analysis unit 151 determines whether or not it is a system call that terminates execution (step S108). If the system call does not end execution (step S108, No), the analysis unit 151 proceeds to step S112.
  • step S109 determines whether there are other processes/threads. If there is no other process/thread (step S109, No), the analysis unit 151 ends the process. If there is another process/thread (step S109, Yes), the analysis unit 151 proceeds to step S112.
  • step S110 The processing of step S110 will be described.
  • the analysis unit 151 emulates the instruction with the virtual CPU and reflects the result in the virtual environment (step S110).
  • the analysis unit 151 records the read/write result as a log in the analysis log DB 142 (step S111).
  • the analysis unit 151 sets the position to be executed next to the next command of the caller (step S112), and proceeds to step S103.
  • the analysis unit 151 determines whether the execution position is the start position of the API (step S113). If the execution position is not the start position of the API (step S113, No), the analysis unit 151 ends the process.
  • the analysis unit 151 emulates the API and reflects the result in the virtual environment (step S114).
  • the analysis unit 151 records the read/write log in the analysis log DB 142 (step S115).
  • the analysis unit 151 determines whether the API is to end execution (step S116). If the API is to end execution (step S116, Yes), the analysis unit 151 proceeds to step S109 in FIG. If the API is not an API that ends execution (step S116, No), the analysis unit 151 proceeds to step S112 in FIG.
  • steps S106, S110, and S114 when emulating a system call, an instruction other than the system call, or an API, the analysis unit 151 sets the state of the virtual environment at the start of emulation, the setting file (management table 142a configuration file).
  • the analysis unit 151 emulates a "system call”, "assembly instruction”, or "API" and attempts to read the value of virtual register A with the value 10 in virtual register A, Returns the value 10.
  • the configuration file specifies that file A should be placed in file path A of the virtual file system
  • the analysis unit 151 opens the file if the file has not been deleted.
  • the analysis unit 151 emulates the API, it returns the handle of the corresponding file, and when the file has already been deleted, it returns the handle to the new file.
  • the analysis unit 151 assigns a log ID, and stores PID, TID, instruction type, operation type, address, instruction, register, and memory information. , is registered in the log table 142 b of the analysis log DB 142 .
  • the analysis unit 151 registers the activity trace information in the analysis log DB 142 in association with the log ID.
  • traces of activity are changes made to the virtual environment at the time of analysis by executing malware.
  • traces of activity include file paths of written files, registry paths of created registries, and process command lines of started processes.
  • the extraction unit 152 acquires the malware analysis log recorded in the analysis log DB 142, acquires the activity trace from the log, and executes the processing shown in FIGS. It is determined whether or not.
  • the extraction unit 152 records, in the environment-dependent trace DB 143 , a log containing the corresponding trace of activity and a log of command/API/system call having a dependency relationship.
  • FIG. 9 and 10 are flowcharts showing the processing procedure of the extraction unit.
  • the extraction unit 152 of the trace information generating device 100 acquires one malware analysis log from the analysis log DB 142 (step S201).
  • the extraction unit 152 acquires activity traces from the analysis log (step S202).
  • the extraction unit 152 determines whether or not there is one or more activity traces (step S203). If one or more activity traces do not exist (step S203, No), the extraction unit 152 ends the process.
  • step S203 determines whether or not there is an unprocessed activity trace. If there is no unprocessed activity trace (step S204, No), the extraction unit 152 ends the process.
  • step S204 if there are unprocessed activity traces (step S204, Yes), the extraction unit 152 selects one unprocessed activity trace (step S205). The extraction unit 152 sets the log containing the trace of activity as the starting point of the retrospective search (step S206).
  • the extraction unit 152 determines whether or not there are logs that can be traced back (step S207). If there is no traceable log (step S207, No), the extraction unit 152 proceeds to step S204.
  • step S207 if there are still logs that can be traced back (step S207, Yes), the extraction unit 152 proceeds to step S208 in FIG.
  • the extraction unit 152 retroactively acquires the previous log (step S208).
  • the extraction unit 152 determines whether the acquired log is a log of an instruction/API/system call for acquiring environmental information (step S209). If the acquired log is not a command/API/system call log for acquiring environment information (step S209, No), the extraction unit 152 proceeds to step S207 in FIG.
  • the extracting unit 152 extracts an emulator in which the log is recorded. The state of the virtual environment immediately before the rate is restored (step S210).
  • the extracting unit 152 executes “the case where the value returned as the emulation result is to be changed” and “the case where the value to be returned as the emulation result is not changed” once each (two or more times in total) to obtain an activity trace. is observed, the program code of the malware is executed (step S211).
  • the extraction unit 152 determines whether or not execution has been performed up to the position where the activity trace was observed (step S212). If the extraction unit 152 cannot execute up to the position where the activity trace is observed (step S212, No), the extraction unit 152 proceeds to step S207 in FIG.
  • step S212 determines whether or not the activity trace has changed only when the return value is changed (step S213). If the activity trace does not change only when the value to be returned is changed (step S213, No), the extraction unit 152 proceeds to step S207 in FIG.
  • the extraction unit 152 identifies the selected activity trace as an environment-dependent activity trace (step S214).
  • the extraction unit 152 records a log containing the activity trace found to be environment-dependent in the environment-dependent trace DB (step S215), and proceeds to step S207 in FIG.
  • the extraction unit 152 traces the logs one by one starting from the log from which the activity trace is acquired, and extracts instructions, APIs, and system calls for acquiring information from the execution environment.
  • the log check whether the activity trace value changes depending on the command, API, or system call. In order to confirm this, the state of the virtual environment immediately prior to the emulation of the command, API, or system call is restored from the information in the analysis log, and the malware program code is executed up to the position where the trace of activity was observed.
  • the extraction unit 152 performs N times each of cases where the values returned by the commands, APIs, and system calls to be checked are changed and not changed.
  • the extracting unit 152 may execute at least one case of changing and one case of not changing the command, API, or value returned by the system call to be checked (total of two times).
  • the extraction unit 152 determines that the corresponding activity trace is environment-dependent. , and it is determined that the activity trace depends on the instruction, API, or system call.
  • the extraction unit 152 records the information on the environment-dependent trace of activity in the environment-dependent trace DB 143 .
  • the extraction unit 152 extracts trace ID, malware ID, analysis ID, log ID (the log ID of the first log among logs corresponding to activity traces), trace type, environment-dependent trace, dependency command information, It is recorded in the environment dependent trace DB 143 .
  • the creation unit 153 Based on the malware DB 141, the analysis log DB 142, and the environment-dependent trace DB 143, the creation unit 153 creates a program code for generating environment-dependent activity traces.
  • FIG. 11 is a flowchart showing the processing procedure of the creating unit. As shown in FIG. 11, the creating unit 153 of the trace information generating device 100 acquires an entry related to environment-dependent activity trace information from the environment-dependent trace DB 143 (step S301).
  • the creating unit 153 acquires the analysis log related to the acquired entry from the analysis log DB 142 (step S302).
  • the creation unit 153 acquires malware related to the acquired entry from the malware DB 141 (step S303).
  • the creation unit 153 performs backward program slicing starting from the log containing the trace of activity, and extracts only the code related to the creation of the trace of activity (step S304).
  • the creating unit 153 symbolizes an instruction/API/system call whose activity trace is known to be changed by changing the returned value, and symbolically executes it up to the same position as the log where the activity trace was observed (step S305).
  • the creation unit 153 restores the state of the virtual memory and virtual CPU at the execution start point of the slice result (step S306).
  • the creation unit 153 changes the code that is not included in the route to the position where the activity trace is observed and is not included in the slice result to an instruction (NOP) that does nothing (step S307).
  • the creation unit 153 records the state of the virtual memory and the virtual CPU as the activity trace creation program in the creation program DB 144 (step S308).
  • the generation unit 154 transmits the activity trace generation program recorded in the generation program DB 144 to the monitoring target terminal 50, and causes the agent of the monitoring target terminal 50 to execute the activity trace generation program.
  • the generation unit 154 collects activity traces generated as a result of the agent executing the activity trace generation program, and generates IoC.
  • FIG. 12 is a flow chart showing the processing procedure of the generation unit of the trace information generation device and the agent of the monitored terminal.
  • the agent of the monitored terminal 50a is used for explanation.
  • the generation unit 154 of the trace information generation device 100 acquires an activity trace generation program from the generation program DB 144 (step S401).
  • the generation unit 154 transmits the activity trace generation program to the agent of the monitored terminal 50a (step S402).
  • the agent of the monitored terminal 50a receives the activity trace generation program (step S403).
  • the agent of the monitored terminal 50a deploys the activity trace generation program on the virtual environment (step S404).
  • the agent of the monitored terminal 50a executes the activity trace generation program (step S405).
  • the agent of the monitored terminal 50a transmits the activity trace, which is the result of executing the activity trace generation program, to the generation unit 154 (step S406).
  • the generation unit 154 receives the activity trace (step S407).
  • the generator 154 generates an IoC (step S408).
  • the command/API/system call for acquiring information from the virtual OS or virtual hardware reads the actual data of the monitored terminal 50a.
  • the closed processing is executed in the virtual environment.
  • the generating unit 154 uses the agent of the monitored terminal 50a to generate IoC data using the agents of the monitored terminal 50b and the monitored terminal 50c. to generate
  • FIG. 13 is a diagram showing an example of IoC generated by the generator.
  • IoC-a is an IoC generated based on the result of causing the agent of the monitored terminal 50a to execute the activity trace generation program.
  • IoC-b is an IoC generated based on the result of causing the agent of the monitored terminal 50b to execute the activity trace generation program.
  • IoC-c is an IoC generated based on the result of causing the agent of the monitored terminal 50c to execute the activity trace generation program.
  • the IoC shown in FIG. 13 shows an example of identifying activity traces when malware is executed on the monitoring target terminal 50 and outputting them as IoCs according to the OpenIOC format.
  • the Indicator Item condition tag is the comparison method during inspection, and the Content tag is the specific condition used for inspection.
  • the generation unit 154 transmits the activity trace generation program to the agent of the monitoring target terminal 50 and acquires the activity trace from the monitoring target terminal 50, but the present invention is not limited to this.
  • the generation unit 154 may execute an activity trace generation program on the trace information generation device 100 to pseudo-acquire the activity trace of the monitored terminal 50 . In this case, the activity trace generation program is not transmitted to the terminal device 50 .
  • the reason why the activity trace generation program (program code) is executed by the monitoring target terminal 50 is that the instructions (including APIs and system calls) for acquiring environment information included in the activity trace generation program are executed by each monitor. This is because the target terminal 50 does not know what kind of result it will return. Therefore, when it is known in advance what kind of result the monitored terminal 50 will return, it is not necessary to distribute the activity trace generation program to the monitored terminal 50 . In this case, the generation unit 154 can be substituted by executing the activity trace generation program and returning information assumed to be returned by the monitoring target terminal 50 .
  • Specific examples of information expected to be returned by the monitoring target terminal 50 include APIs and system calls for acquiring the MAC address of the NIC and the GUID of the HDD. Since it is uniquely determined for each monitoring target terminal 50 (for each hardware provided in the monitoring target terminal 50), the activity trace generation program created by the creation unit 153 includes only APIs and system calls for acquiring these information. If each monitoring target terminal 50 has a DB indicating which value should be returned for which API, the activity trace generation program does not need to be executed on the monitoring target terminal 50, and the generation unit 154 Processing (processing for acquiring activity traces) can be completed.
  • FIG. 14 is a flow chart showing the processing procedure of the trace information generating device according to this embodiment.
  • the analysis unit 151 of the trace information generation device 100 dynamically analyzes malware recorded in the malware DB (step S501).
  • a specific processing procedure of step S501 corresponds to the processing procedure described with reference to FIGS.
  • the extraction unit 152 of the trace information generation device 100 extracts environment-dependent activity traces based on the malware analysis log (step S502).
  • a specific processing procedure of step S502 corresponds to the processing procedure described with reference to FIGS.
  • the creation unit 153 of the trace information generation device 100 creates an activity trace generation program for generating environment-dependent activity traces (step S503).
  • a specific processing procedure of step S503 corresponds to the processing procedure described with reference to FIG.
  • the generation unit 154 of the trace information generation device 100 causes the monitored terminal to execute the activity trace generation program to generate IoC (step S504).
  • a specific processing procedure of step S504 corresponds to the processing procedure described with reference to FIG.
  • the trace information generation device 100 executes malware multiple times while rewriting the values returned by APIs and system calls that acquire information on the execution environment, so that traces of malware activity are traces that are uniquely determined depending on the execution environment. After specifying that, a program code that reproduces only the processing related to the generation of activity traces is generated using the program code of the malware.
  • the trace information generating device 100 clarifies in advance the activity trace when the monitoring target terminal 50 is infected with malware, and creates an IoC dedicated to the monitoring target terminal 50. to generate As a result, it is possible to create an IoC dedicated to the monitored terminal that detects activity traces that are uniquely determined depending on the execution environment. It is possible to perform high-speed matching while eliminating oversights and overdetections in the stages.
  • the trace information generating device 100 executes malware multiple times, and extracts, from among a plurality of traces of activity related to malware, traces of activity that do not change when the return value is not changed and which change when the return value is changed. This makes it possible to extract environment-dependent traces of activity.
  • the trace information generation device 100 reflects the results of emulating malware instructions (instructions/APIs/system calls) in the virtual environment, records a log of reading and writing data associated with the emulation, and uses the recorded log to to restore the state of the virtual environment immediately before emulating the malware instructions, and execute the malware up to the position where the trace of activity was observed.
  • malware instructions instructions/APIs/system calls
  • traces of activity that do not change when the return value is not changed and which change when the return value is changed can be identified, and the identified traces of activity can be extracted. can.
  • FIG. 15 is a diagram showing an example of a computer that executes a trace information generation program.
  • Computer 1000 has, for example, memory 1010 , CPU 1020 , hard disk drive interface 1030 , disk drive interface 1040 , serial port interface 1050 , video adapter 1060 and network interface 1070 . These units are connected by a bus 1080 .
  • the memory 1010 includes a ROM (Read Only Memory) 1011 and a RAM 1012 .
  • the ROM 1011 stores a boot program such as BIOS (Basic Input Output System).
  • BIOS Basic Input Output System
  • Hard disk drive interface 1030 is connected to hard disk drive 1031 .
  • Disk drive interface 1040 is connected to disk drive 1041 .
  • a removable storage medium such as a magnetic disk or an optical disk is inserted into the disk drive 1041, for example.
  • a mouse 1051 and a keyboard 1052 are connected to the serial port interface 1050, for example.
  • a display 1061 is connected to the video adapter 1060 .
  • the hard disk drive 1031 stores an OS 1091, application programs 1092, program modules 1093 and program data 1094, for example. Each piece of information described in the above embodiment is stored in the hard disk drive 1031 or memory 1010, for example.
  • the trace information generation program is stored in the hard disk drive 1031 as a program module 1093 in which commands to be executed by the computer 1000 are written, for example.
  • the hard disk drive 1031 stores a program module 1093 that describes each process executed by the trace information generating apparatus 100 described in the above embodiment.
  • Data used for information processing by the trace information generation program is stored as program data 1094 in the hard disk drive 1031, for example. Then, the CPU 1020 reads out the program module 1093 and the program data 1094 stored in the hard disk drive 1031 to the RAM 1012 as necessary, and executes each procedure described above.
  • program modules 1093 and program data 1094 relating to the trace information generation program are not limited to being stored in the hard disk drive 1031.
  • they may be stored in a removable storage medium and processed by the CPU 1020 via the disk drive 1041 or the like. may be read out.
  • program modules 1093 and program data 1094 related to the trace information generation program are stored in another computer connected via a network such as LAN or WAN (Wide Area Network), and read by CPU 1020 via network interface 1070. may be issued.
  • LAN or WAN Wide Area Network
  • trace information generation device 100 storage unit 141 malware DB 142 Analysis Log DB 143 Environment dependent trace DB 144 Generation program DB 150 control unit 151 analysis unit 152 extraction unit 153 creation unit 154 generation unit

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Virology (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)

Abstract

痕跡情報生成装置（１００）は、実行環境から情報を取得するマルウェアの命令が返す値を書き換えながら前記マルウェアを複数回実行することで、前記マルウェアから、前記実行環境に依存して一意に定まる活動痕跡を抽出する。痕跡情報生成装置（１００）は、抽出した活動痕跡の生成に関わる処理を再現するプログラムコードを前記マルウェアのプログラムコードを用いて作成する。痕跡情報生成装置（１００）は、前記プログラムコードを実行することで、監視対象の端末の痕跡情報を生成する。

Description

生成装置、生成方法及び生成プログラム
　本発明は、生成装置、生成方法及び生成プログラムに関する。
　サイバー攻撃の高度化・巧妙化に伴い、ファイルハッシュ値やシグネチャに基づいた従来型のアンチウイルスソフトでマルウェアへの感染を検知することは困難となってきている。同様に、既知の悪性通信先や通信内容に基づいた従来のネットワーク監視でマルウェア感染を検知することも困難となってきている。
　このため、プログラムのふるまいを監視するEDR（Endpoint　Detection　and　Response）の普及が進んでいる。EDRは、マルウェアに感染したことを高い確度で示す痕跡情報（IoC:　Indicator　of　Compromise）と監視しているプログラムのふるまいを照らし合わせることでマルウェアへの感染を検知する機能を持つ。この機能により、未知のファイルハッシュ値を持つマルウェアや正規サイトと通信するマルウェアであっても、作成したファイルのパスや起動したプロセスのコマンドライン引数といったプログラムの活動痕跡に特徴があり、IoCと合致すればEDRはプログラムをマルウェアだと判定することができる。
　IoCのカバレッジや精度がEDRとしての検知能力を左右する。このため、IoCの作成にあたっては、正規ソフトウェアを検知しないよう注意を払いつつ、マッチングに使用できる限られた計算リソースの中でより多くのマルウェアを捉えられるようにIoCを作成することが求められる。これまでに、解析システム上で観測したマルウェアの活動痕跡からIoCを自動生成する技術として非特許文献1や非特許文献2が提案されている。これらの技術では、観測された活動痕跡をクラスタリングし、正規表現を用いて集約することで、クラスタ内の活動痕跡を捉える汎用的なIoCを生成している。
Roberto　Paleari,　Lorenzo　Martignoni,　Emanuele　Passerini,　Drew　Davidson,　Matt　Fredrikson,　Jon　Giffin,　and　Somesh　Jha,　"Automatic　Generation　of　Remediation　Procedures　for　Malware　Infections",　In　Proceedings　of　the　19th　USENIX　Conference　on　Security,　2010 Yuma　Kurogome,　Yuto　Otsuki,　Yuhei　Kawakoya,　Makoto　Iwamura,　Syogo　Hayashi,　Tatsuya　Mori,　and　Koushik　Sen,　"EIGER:　Automated　IOC　Generation　for　Accurate　and　Interpretable　Endpoint　Malware　Detection",　In　Proceedings　of　the　35th　Annual　Computer　Security　Applications　Conference,　2019
　マルウェアの活動痕跡は、実行環境に依存して一意に定まるものと、実行環境に依存して一意に定まらないものに分類できる。前者については、監視対象の端末ごとに作成することで、最小限の正規表現しか用いない簡潔なIoCにすることが可能である。しかしながら、非特許文献は活動痕跡の特徴を考慮していないため、実行環境に依存して一意に定まる活動痕跡に対しても、正規表現を用いた抽象化に起因する過検知が発生する上、マッチングに時間がかかるという問題があった。
　実行環境に依存して一意に定まる活動痕跡を検知するIoCを監視対象端末ごとに作成するには、マルウェアの活動痕跡が実行環境に依存して一意に定まるものであることを特定した上で、当該活動痕跡を生成する処理が監視対象端末上で行われた場合に観測される活動痕跡を、監視対象端末を感染させることなく調査する必要がある。
　本発明は、上記に鑑みてなされたものであって、仕様書の作成元となる検討資料の抽出精度を向上させることができる生成装置、生成方法及び生成プログラムを提供することを目的とする。
　上述した課題を解決し、目的を達成するために、本発明に係る生成装置は、実行環境から情報を取得するマルウェアの命令が返す値を書き換えながら前記マルウェアを複数回実行することで、前記マルウェアから、前記実行環境に依存して一意に定まる活動痕跡を抽出する抽出部と、前記抽出部が抽出した活動痕跡の生成に関わる処理を再現するプログラムコードを前記マルウェアのプログラムコードを用いて作成する作成部と、前記プログラムコードを実行することで、監視対象の端末の痕跡情報を生成する生成部とを備える。
　実行環境に依存して一意に定まる活動痕跡を検知する監視対象端末専用のIoCを作成することができるため、一意に定まる活動痕跡が正規ソフトウェアの活動痕跡と重複しなければ、マッチングの段階における見逃しや過検知を無くした上で高速にマッチングすることが可能となる。
図１は、本実施例に係る痕跡情報生成システムの一例を示す図である。 図２は、本実施例に係る痕跡情報生成装置の構成を示す機能ブロック図である。 図３は、マルウェアＤＢのデータ構造の一例を示す図である。 図４は、解析ログＤＢの管理テーブルのデータ構造の一例を示す図である。 図５は、解析ログＤＢのログテーブルのデータ構造の一例を示す図である。 図６は、環境依存痕跡ＤＢのデータ構造の一例を示す図である。 図７は、解析部の処理手順を示すフローチャート（１）である。 図８は、解析部の処理手順を示すフローチャート（２）である。 図９は、抽出部の処理手順を示すフローチャート（１）である。 図１０は、抽出部の処理手順を示すフローチャート（２）である。 図１１は、作成部の処理手順を示すフローチャートである。 図１２は、痕跡情報生成装置の生成部と監視対象端末のエージェントの処理手順を示すフローチャートである。 図１３は、生成部が生成するIoCの一例を示す図である。 図１４は、本実施例に係る痕跡情報生成装置の処理手順を示すフローチャートである。 図１５は、痕跡情報生成プログラムを実行するコンピュータの一例を示す図である。
　以下に、本願の開示する生成装置、生成方法及び生成プログラムの実施例を図面に基づいて詳細に説明する。なお、この実施例によりこの発明が限定されるものではない。
　図１は、本実施例に係る痕跡情報生成システムの一例を示す図である。図１に示すように、この痕跡情報生成システムは、痕跡情報生成装置１００と、監視対象端末５０ａ，５０ｂ，５０ｃとを有する。痕跡情報生成装置１００と、監視対象端末５０ａ，５０ｂ，５０ｃとは、ネットワーク３０を介して相互に接続される。痕跡情報生成装置１００は、生成装置の一例である。
　本実施例では一例として、監視対象端末５０ａ，５０ｂ，５０ｃを示すが、痕跡情報生成システムには、他の監視対象端末が含まれていてもよい。監視対象端末５０ａ～５０ｃをまとめて、監視対象端末５０と表記する。
　痕跡情報生成装置１００は、実行環境の情報を取得するＡＰＩ（Application　Programming　Interface）やシステムコールが返す値を書き換えながら複数回マルウェアを実行することで、マルウェアの活動痕跡が実行環境に依存して一意に定まる痕跡であることを特定した上で、活動痕跡の生成に関わる処理のみを再現するプログラムコードを、マルウェアのプログラムコードを用いて生成する。痕跡情報生成装置１００は、生成したプログラムコードを、監視対象端末５０にて実行することで、監視対象端末５０がマルウェアに感染した場合の活動痕跡を事前に明らかにし、監視対象端末５０専用のIoCを生成する。
　図１に示した痕跡情報生成装置１００の構成の一例について説明する。図２は、本実施例に係る痕跡情報生成装置の構成を示す機能ブロック図である。図２に示すように、痕跡情報生成装置１００は、通信部１１０、入力部１２０、表示部１３０、記憶部１４０、制御部１５０を有する。
　通信部１１０は、ネットワーク３０等を介して接続された監視対象端末５０との間で、各種情報を送受信する通信インタフェースである。通信部１１０は、ＮＩＣ（Network　Interface　Card）等で実現され、ＬＡＮ（Local　Area　Network）やインターネットなどの電気通信回線を介した監視対象端末５０と制御部１５０との間の通信を行う。
　入力部１２０は、痕跡情報生成装置１００の操作者からの各種操作を受け付ける入力インタフェースである。例えば、キーボードやマウス等の入力デバイスによって構成される。
　表示部１３０は、制御部１５０から取得した情報を出力する出力デバイスであり、液晶ディスプレイなどの表示装置、プリンター等の印刷装置等によって実現される。
　記憶部１４０は、マルウェアＤＢ１４１、解析ログＤＢ１４２、環境依存痕跡ＤＢ１４３、生成プログラムＤＢ１４４を有する。記憶部１４０は、ＲＡＭ（Random　Access　Memory）、フラッシュメモリ（Flash　Memory）等の半導体メモリ素子、または、ハードディスク、光ディスク等の記憶装置によって実現される。
　マルウェアＤＢ１４１は、マルウェアに関する情報を記録するＤＢである。図３は、マルウェアＤＢのデータ構造の一例を示す図である。図３に示すように、マルウェアＤＢ１４１は、マルウェアＩＤと、プログラムコードと、ファイルタイプと、解析済みフラグとを有する。
　マルウェアＩＤは、解析対象のマルウェアを識別する識別子である。プログラムコードは、マルウェアのプログラムコード本体である。ファイルタイプは、マルウェアのプログラムコードのファイルタイプを示す。解析済みフラグは、該当するマルウェアが解析済みか否かを示すフラグ値である。解析済みの場合には「on」が設定され、解析済みでない場合には「off」となる。
　解析ログＤＢ１４２は、マルウェアをエミュレートして解析した結果を記録するＤＢである。管理テーブル１４２ａと、ログテーブル１４２ｂとを有する。
　図４は、解析ログＤＢの管理テーブルのデータ構造の一例を示す図である。図４に示すように、この管理テーブル１４２ａは、解析ＩＤ、マルウェアＩＤ、設定ファイルを有する。解析ＩＤは、解析タスクの識別子である。マルウェアＩＤは、マルウェアＤＢ１４１に設定されるマルウェアＩＤに対応するマルウェアの識別子である。設定ファイルは、解析に使用される設定ファイルを示す。
　図５は、解析ログＤＢのログテーブルのデータ構造の一例を示す図である。図５に示すように、ログテーブル１４２ｂは、解析ＩＤ、ログＩＤ、ＰＩＤ、ＴＩＤ、命令タイプ、操作タイプ、アドレス、命令、レジスタ（ＩＤ、値）、メモリ（アドレス、サイズ、値）を有する。
　解析ＩＤは、解析タスクの識別子である。ログＩＤは、解析タスク内におけるログの識別子である。ＰＩＤは、プロセスの識別子である。ＴＩＤは、スレッドの識別子である。命令タイプは、アセンブリ命令、ＡＰＩ、システムコールのいずれかを示す情報である。
　操作タイプは、レジスタもしくはメモリに対して、読み書きのどちらを実行したのかを示す情報である。アドレスは、実行アドレスを示す。命令には、アセンブリ命令であれば逆アセンブリした結果、ＡＰＩであればＡＰＩ名が記載される。
　命令がレジスタの操作に関するものである場合には、レジスタを識別するＩＤと、値が記録される。命令がメモリの操作に関するものである場合には、メモリのアドレス、サイズ、値が記録される。
　環境依存痕跡ＤＢ１４３は、実行環境に依存して一意に定まるマルウェアの活動痕跡の情報を記録するＤＢである。図６は、環境依存痕跡ＤＢのデータ構造の一例を示す図である。図６に示すように、環境依存痕跡ＤＢ１４３は、痕跡ＩＤ、マルウェアＩＤ、解析ＩＤ、ログＩＤ、痕跡タイプ、環境依存痕跡、依存関係命令を有する。依存関係命令には、ログＩＤ、タイプ、命令名、引数、型が含まれる。
　痕跡ＩＤは、抽出された活動痕跡の識別子である。マルウェアＩＤは、マルウェアの識別子である。解析ＩＤは、解析タスクの識別子である。ログＩＤは、解析タスクにおけるログの識別子である。たとえば、ログＩＤには、活動痕跡に対応するログのうち、先頭のログを識別するログＩＤが設定される。環境依存痕跡は、解析ログから抽出した活動痕跡の具体値である。
　ここで、依存関係命令には、ログＩＤ、タイプ、命令名、引数、型が含まれる。依存関係命令に含まれるログＩＤは、解析タスクにおけるログの識別子であり、該当する命令が実行されたログＩＤを示す。タイプは、ＡＰＩやシステムコールといった命令の種別を示す。命令名は、命令の名称を示し、ＡＰＩの場合は、ＡＰＩ名が設定される。引数は、何番目の引数が活動痕跡に影響のある戻り値を保持するのかを示す。型は、引数の型情報を示す。
　たとえば、図６の環境依存痕跡ＤＢ１４３では、痕跡ＩＤ「Ｅ１」の活動痕跡の痕跡タイプは「ファイルパス」であり、命令名「GetVolumeInformationW」の第「４」引数が指し示す先のデータによって、値が変わることが示されている。
　生成プログラムＤＢ１４４は、活動痕跡生成プログラムを記録するＤＢである。活動痕跡生成プログラムは、後述する作成部１５３によって作成されるプログラムである。
　図２の説明に戻る。制御部１５０は、解析部１５１、抽出部１５２、作成部１５３、生成部１５４を有する。制御部１５０は、ＣＰＵ（Central　Processing　Unit）等を用いて実現される。
　解析部１５１は、マルウェアＤＢ１４１に記録されたマルウェアを動的に解析し、解析結果を解析ログＤＢ１４２に記録する。解析部１５１は、プロセス単位の仮想化を行い、ＯＳ（Operating　System）やハードウェアが提供する機能をエミュレートしながら解析を行う。解析部１５１は、図７、図８を用いて、解析部１５１の処理を説明する。
　図７および図８は、解析部の処理手順を示すフローチャートである。図７に示すように、痕跡情報生成装置１００の解析部１５１は、設定ファイルに従って仮想環境を初期化する（ステップＳ１０１）。解析部１５１が実行する初期化では、マルウェアを仮想メモリの所定のアドレスに展開するとともに、命令ポインタの設定といった仮想ＣＰＵの初期値設定、仮想ファイルシステムに設置するファイルや仮想ＯＳ上に存在させるプロセスなどの仮想オブジェクトの初期化を行う。
　解析部１５１は、プログラムコードの実行開始位置を設定する（ステップＳ１０２）。解析部１５１は、命令ポインタの指し示すアドレスから命令をフェッチする（ステップＳ１０３）。
　解析部１５１は、フェッチした命令が有効な命令であるか否かを判定する（ステップＳ１０４）。解析部１５１は、フェッチした命令が有効な命令でない場合には（ステップＳ１０４，Ｎｏ）、図８のステップＳ１１３に移行する。
　一方、解析部１５１は、フェッチした命令が有効な命令である場合には（ステップＳ１０４，Ｙｅｓ）、命令がシステムコールであるか否かを判定する（ステップＳ１０５）。解析部１５１は、命令がシステムコールでない場合には（ステップＳ１０５，Ｎｏ）、ステップＳ１１０に移行する。
　一方、解析部１５１は、命令がシステムコールである場合には（ステップＳ１０５，Ｙｅｓ）、システムコールをエミュレートして仮想環境に結果を反映する（ステップＳ１０６）。解析部１５１は、読み書きした結果をログとして、解析ログＤＢ１４２に記録する（ステップＳ１０７）。
　解析部１５１は、実行を終了するシステムコールであるか否かを判定する（ステップＳ１０８）。解析部１５１は、実行を終了しないシステムコールの場合には（ステップＳ１０８，Ｎｏ）、ステップＳ１１２に移行する。
　一方、解析部１５１は、実行を終了するシステムコールの場合には（ステップＳ１０８，Ｙｅｓ）、プロセス／スレッドが他にもあるか否かを判定する（ステップＳ１０９）。解析部１５１は、プロセス／スレッドが他にない場合には（ステップＳ１０９，Ｎｏ）、処理を終了する。解析部１５１は、プロセス／スレッドが他ある場合には（ステップＳ１０９，Ｙｅｓ）、ステップＳ１１２に移行する。
　ステップＳ１１０の処理について説明する。解析部１５１は、仮想ＣＰＵで命令をエミュレートして仮想環境に結果を反映する（ステップＳ１１０）。解析部１５１は、読み書きした結果をログとして、解析ログＤＢ１４２に記録する（ステップＳ１１１）。解析部１５１は、次に実行する位置を呼び元の次の命令に設定し（ステップＳ１１２）、ステップＳ１０３に移行する。
　図８のステップＳ１１３の説明に移行する。解析部１５１は、実行位置がＡＰＩの開始位置であるか否かを判定する（ステップＳ１１３）。解析部１５１は、実行位置がＡＰＩの開始位置でない場合には（ステップＳ１１３，Ｎｏ）、処理を終了する。
　解析部１５１は、実行位置がＡＰＩの開始位置である場合には（ステップＳ１１３，Ｙｅｓ）、ＡＰＩをエミュレートして仮想環境に結果を反映する（ステップＳ１１４）。
　解析部１５１は、読み書きしたログを、解析ログＤＢ１４２に記録する（ステップＳ１１５）。解析部１５１は、実行を終了するＡＰＩであるか否かを判定する（ステップＳ１１６）。解析部１５１は、実行を終了するＡＰＩである場合には（ステップＳ１１６，Ｙｅｓ）、図７のステップＳ１０９に移行する。解析部１５１は、実行を終了するＡＰＩでない場合には（ステップＳ１１６，Ｎｏ）、図７のステップＳ１１２に移行する。
　ここで、解析部１５１は、ステップＳ１０６、Ｓ１１０、Ｓ１１４において、システムコール、システムコール以外の命令またはＡＰＩをエミュレートする場合、エミュレート開始時点での仮想環境の状態や、設定ファイル（管理テーブル１４２ａの設定ファイル）の内容に基づいて、処理を行う。
　たとえば、解析部１５１は、「システムコール」、「アセンブリ命令」または「ＡＰＩ」をエミュレートし、仮想レジスタＡに値１０が入った状態で、仮想レジスタＡの値を読み取ろうとした場合には、値１０を返す。解析部１５１は、設定ファイルにて仮想ファイルシステムのファイルパスＡにファイルＡを置く指定があった場合、該当ファイルが削除されていなければ該当ファイルを開く。解析部１５１が、ＡＰＩのエミュレートを行う場合、該当ファイルのハンドルを返し、既にファイルが消されている場合には新しいファイルへのハンドルを返す。
　解析部１５１は、ステップＳ１０７、Ｓ１１１、Ｓ１１５において、解析ログＤＢにログを記録する場合には、ログＩＤを割り当て、ＰＩＤ、ＴＩＤ、命令タイプ、操作タイプ、アドレス、命令、レジスタ、メモリの情報を、解析ログＤＢ１４２のログテーブル１４２ｂに登録する。
　図示を省略するが、解析部１５１は、ログＩＤと対応付けて、活動痕跡の情報を、解析ログＤＢ１４２に登録する。ここで、「活動痕跡」とは、マルウェアを実行することで解析時に仮想環境に加えられた変更である。たとえば、活動痕跡として、書き込みをしたファイルのファイルパス、作成したレジストリのレジストリパス、起動したプロセスのプロセスコマンドラインが該当する。
　続いて、抽出部１５２について説明する。抽出部１５２は、解析ログＤＢ１４２に記録されたマルウェアの解析ログを取得し、ログから活動痕跡を取得し、図９および図１０に示す処理を実行することで、活動痕跡が環境依存の活動痕跡であるか否かを判定する。抽出部１５２は、環境依存の活動痕跡について、該当する活動痕跡が載ったログ、依存関係にある命令／ＡＰＩ／システムコールのログを、環境依存痕跡ＤＢ１４３に記録する。
　図９および図１０は、抽出部の処理手順を示すフローチャートである。図９に示すように、痕跡情報生成装置１００の抽出部１５２は、解析ログＤＢ１４２から１つのマルウェアの解析ログを取得する（ステップＳ２０１）。抽出部１５２は、解析ログから活動痕跡を取得する（ステップＳ２０２）。
　抽出部１５２は、活動痕跡が１つ以上存在するか否かを判定する（ステップＳ２０３）。抽出部１５２は、活動痕跡が１つ以上存在しない場合には（ステップＳ２０３，Ｎｏ）、処理を終了する。
　一方、抽出部１５２は、活動痕跡が１つ以上存在する場合には（ステップＳ２０３，Ｙｅｓ）、未処理の活動痕跡が存在するか否かを判定する（ステップＳ２０４）。抽出部１５２は、未処理の活動痕跡が存在しない場合には（ステップＳ２０４，Ｎｏ）、処理を終了する。
　一方、抽出部１５２は、未処理の活動痕跡が存在する場合には（ステップＳ２０４，Ｙｅｓ）、未処理の活動痕跡を１つ選択する（ステップＳ２０５）。抽出部１５２は、活動痕跡が載ったログを遡り探索の起点に設定する（ステップＳ２０６）。
　抽出部１５２は、遡れるログがまだあるか否かを判定する（ステップＳ２０７）。抽出部１５２は、遡れるログがない場合には（ステップＳ２０７，Ｎｏ）、ステップＳ２０４に移行する。
　一方、抽出部１５２は、遡れるログがまだある場合には（ステップＳ２０７，Ｙｅｓ）、図１０のステップＳ２０８に移行する。
　図１０の説明に移行する。抽出部１５２は、１つ前のログを遡って取得する（ステップＳ２０８）。抽出部１５２は、取得したログが、環境の情報を取得する命令／ＡＰＩ／システムコールのログであるか否かを判定する（ステップＳ２０９）。抽出部１５２は、取得したログが、環境の情報を取得する命令／ＡＰＩ／システムコールのログでない場合には（ステップＳ２０９，Ｎｏ）、図９のステップＳ２０７に移行する。
　一方、抽出部１５２は、取得したログが、環境の情報を取得する命令／ＡＰＩ／システムコールのログである場合には（ステップＳ２０９，Ｙｅｓ）、抽出部１５２は、当該ログが記録されたエミュレートの直前の仮想環境の状態を復元する（ステップＳ２１０）。
　抽出部１５２は、「エミュレートの結果として返す値を変更する場合」と、「エミュレートの結果として返す値を変更しない場合」とをそれぞれ１回ずつ（合計２回以上）実行し、活動痕跡が観測された位置まで、マルウェアのプログラムコードを実行する（ステップＳ２１１）。
　抽出部１５２は、活動痕跡が観測された位置まで実行できたか否かを判定する（ステップＳ２１２）。抽出部１５２は、活動痕跡が観測された位置まで実行できない場合には（ステップＳ２１２，Ｎｏ）、図９のステップＳ２０７に移行する。
　一方、抽出部１５２は、活動痕跡が観測された位置まで実行できた場合には（ステップＳ２１２，Ｙｅｓ）、返す値を変更した場合にのみ活動痕跡に変化が見られたか否かを判定する（ステップＳ２１３）。抽出部１５２は、返す値を変更した場合にのみ活動痕跡に変化が見られない場合には（ステップＳ２１３，Ｎｏ）、図９のステップＳ２０７に移行する。
　抽出部１５２は、返す値を変更した場合にのみ活動痕跡に変化が見られた場合には（ステップＳ２１３，Ｙｅｓ）、選択中の活動痕跡を環境依存の活動痕跡として特定する（ステップＳ２１４）。抽出部１５２は、環境依存であることが判明した活動痕跡について、当該活動痕跡が載ったログを環境依存痕跡ＤＢに記録し（ステップＳ２１５）、図９のステップＳ２０７に移行する。
　上記の図９、図１０で説明したように、抽出部１５２は、活動痕跡の取得元であるログを起点にログを１つずつ遡り、実行環境から情報を取得する命令やＡＰＩ、システムコールのログに到達した場合、当該命令やAPI、システムコールに依存して活動痕跡の値が変わるかを確認する。確認するため、当該命令やＡＰＩ、システムコールをエミュレーションする直前の仮想環境の状態を解析ログの情報から復元し、活動痕跡が観測された位置までマルウェアのプログラムコードを実行する。
　抽出部１５２は、活動痕跡が環境依存であるか否かを判定するため、確認する対象となる命令やＡＰＩ、システムコールが返す値を変更する場合と変更しない場合をそれぞれＮ回実行する。抽出部１５２は、少なくとも、確認する対象となる命令やＡＰＩ、システムコールが返す値を変更する場合と変更しない場合を１回ずつ（計２回）実行すればよい。
　抽出部１５２は、返す値を変更しない場合に観測される活動痕跡に変化が無く、返す値を変更した場合に観測される活動痕跡に変化があった場合には、該当する活動痕跡は環境依存の活動痕跡であり、活動痕跡は当該命令やＡＰＩ、システムコールに依存していると判定する。
　抽出部１５２は、環境に依存する活動痕跡の情報を、環境依存痕跡ＤＢ１４３に記録する。たとえば、抽出部１５２は、痕跡ＩＤ、マルウェアＩＤ、解析ＩＤ、ログＩＤ（活動痕跡に対応するログのうち、先頭のログのログＩＤ）、痕跡タイプ、環境依存痕跡、依存関係命令の情報を、環境依存痕跡ＤＢ１４３に記録する。
　続いて、作成部１５３について説明する。作成部１５３は、マルウェアＤＢ１４１、解析ログＤＢ１４２、環境依存痕跡ＤＢ１４３を基にして、環境依存の活動痕跡を生成するプログラムコードを作成する。
　図１１は、作成部の処理手順を示すフローチャートである。図１１に示すように、痕跡情報生成装置１００の作成部１５３は、環境依存痕跡ＤＢ１４３から、環境依存した活動痕跡の情報に関するエントリを取得する（ステップＳ３０１）。
　作成部１５３は、取得したエントリに関連する解析ログを解析ログＤＢ１４２から取得する（ステップＳ３０２）。作成部１５３は、取得したエントリに関連するマルウェアをマルウェアＤＢ１４１から取得する（ステップＳ３０３）。
　作成部１５３は、活動痕跡が載ったログを起点に、後方プログラムスライスを実施し、活動痕跡の生成に関連するコードのみを抽出する（ステップＳ３０４）。作成部１５３は、返す値の変更により活動痕跡が変更になることが判明している命令／ＡＰＩ／システムコールをシンボル化して、活動痕跡が観測されたログと同じ位置までシンボリック実行をする（ステップＳ３０５）。
　作成部１５３は、スライス結果の実行開始地点における仮想メモリ、仮想ＣＰＵの状態を復元する（ステップＳ３０６）。作成部１５３は、活動痕跡が観測された位置に至る経路に含まれておらず、スライス結果に含まれないコードを何もしない命令（ＮＯＰ）に変更する（ステップＳ３０７）。作成部１５３は、仮想メモリ、仮想ＣＰＵの状態を活動痕跡生成プログラムとして、生成プログラムＤＢ１４４に記録する（ステップＳ３０８）。
　続いて、生成部１５４について説明する。生成部１５４は、生成プログラムＤＢ１４４に記録された活動痕跡生成プログラムを、監視対象端末５０に送信し、監視対象端末５０のエージェントに、活動痕跡生成プログラムを実行させる。生成部１５４は、エージェントが活動痕跡生成プログラムを実行した結果生成される活動痕跡を収集し、IoCを生成する。
　図１２は、痕跡情報生成装置の生成部と監視対象端末のエージェントの処理手順を示すフローチャートである。図１２に示す例では、監視対象端末５０ａのエージェントを用いて説明を行う。図１２に示すように、痕跡情報生成装置１００の生成部１５４は、生成プログラムＤＢ１４４から活動痕跡生成プログラムを取得する（ステップＳ４０１）。
　生成部１５４は、活動痕跡生成プログラムを監視対象端末５０ａのエージェントに送信する（ステップＳ４０２）。監視対象端末５０ａのエージェントは、活動痕跡生成プログラムを受信する（ステップＳ４０３）。
　監視対象端末５０ａのエージェントは、仮想環境上に活動痕跡生成プログラムを展開する（ステップＳ４０４）。監視対象端末５０ａのエージェントは、活動痕跡生成プログラムを実行する（ステップＳ４０５）。
　監視対象端末５０ａのエージェントは、活動痕跡生成プログラムの実行結果となる活動痕跡を生成部１５４に送信する（ステップＳ４０６）。生成部１５４は、活動痕跡を受信する（ステップＳ４０７）。生成部１５４は、IoCを生成する（ステップＳ４０８）。
　なお、監視対象端末５０ａのエージェントが、活動痕跡生成プログラムを実行する場合、仮想ＯＳや仮想ハードウェアから情報を取得する命令／ＡＰＩ／システムコールについては、監視対象端末５０ａの実データを読み取るが、監視対象端末の記憶部に書き込む場合には、仮想環境に閉じた処理を実行させる。
　図１２で説明した処理では、生成部１５４は、監視対象端末５０ａのエージェントを用いて説明を行ったが、同様にして、監視対象端末５０ｂのエージェント、監視対象端末５０ｃのエージェントを用いて、IoCを生成する。
　図１３は、生成部が生成するIoCの一例を示す図である。IoC－ａは、監視対象端末５０ａのエージェントに、活動痕跡生成プログラムを実行させた結果を基にして生成されたIoCである。IoC－ｂは、監視対象端末５０ｂのエージェントに、活動痕跡生成プログラムを実行させた結果を基にして生成されたIoCである。IoC－ｃは、監視対象端末５０ｃのエージェントに、活動痕跡生成プログラムを実行させた結果を基にして生成されたIoCである。
　図１３に示すIoCは、監視対象端末５０上でマルウェアが実行された場合の活動痕跡を特定し、それぞれOpenIOCフォーマットに則ったIoCとして出力した場合の例を示している。IndicatorItem　conditionタグが検査時の比較方法、Contentタグが検査に用いる具体的な条件である。
　なお、上記の説明では、生成部１５４が、活動痕跡生成プログラムを監視対象端末５０のエージェントに送信して、監視対象端末５０から活動痕跡を取得していたがこれに限定されるものではない。生成部１５４が痕跡情報生成装置１００上で、活動痕跡生成プログラムを実行して、疑似的に監視対象端末５０の活動痕跡を取得してもよい。この場合、活動痕跡生成プログラムは、端末対象装置５０には送信されない。
　上記のように、活動痕跡生成プログラム（プログラムコード）を監視対象端末５０で実行させるのは、活動痕跡生成プログラム中に含まれる環境情報を取得する命令（APIやシステムコールも含む）が、各監視対象端末５０でどういう結果を返すのかが分からないからである。このため、監視対象端末５０がどういう結果を返すのかが事前に判明している場合については、活動痕跡生成プログラムを監視対象端末５０に配布しなくてもよい。この場合、生成部１５４が、活動痕跡生成プログラムを実行して、監視対象端末５０で返すと想定される情報を返すことで代用可能である。
　監視対象端末５０で返すと想定される情報の具体例としては、NICのMACアドレス、HDDのGUIDを取得するAPIやシステムコールが該当する。監視対象端末５０ごと（監視対象端末５０に備わっているハードウェアごと）に、一意に定まるため、作成部１５３で作成した活動痕跡生成プログラムにこれらの情報を取得するAPIやシステムコールしか含まれておらず、各監視対象端末５０についてどのAPIに対してどの値を返せばよいかのＤＢを有していれば、その活動痕跡生成プログラムは監視対象端末５０で実行することなく、生成部１５４で処理（活動痕跡を取得する処理）を完結させることができる。
　次に、本実施例に係る痕跡情報生成装置１００の処理手順の一例について説明する。図１４は、本実施例に係る痕跡情報生成装置の処理手順を示すフローチャートである。図１４に示すように、痕跡情報生成装置１００の解析部１５１は、マルウェアＤＢに記録されたマルウェアを動的に解析する（ステップＳ５０１）。ステップＳ５０１の具体的な処理手順は、図７、図８で説明した処理手順に対応する。
　痕跡情報生成装置１００の抽出部１５２は、マルウェアの解析ログを基にして、環境依存の活動痕跡を抽出する（ステップＳ５０２）。ステップＳ５０２の具体的な処理手順は、図９、図１０で説明した処理手順に対応する。
　痕跡情報生成装置１００の作成部１５３は、環境依存の活動痕跡を生成する活動痕跡生成プログラムを作成する（ステップＳ５０３）。ステップＳ５０３の具体的な処理手順は、図１１で説明した処理手順に対応する。
　痕跡情報生成装置１００の生成部１５４は、監視対象端末で、活動痕跡生成プログラムを実行させ、IoCを生成する（ステップＳ５０４）。ステップＳ５０４の具体的な処理手順を、図１２で説明した処理手順に対応する。
　次に、本実施例に係る痕跡情報生成装置１００の効果について説明する。痕跡情報生成装置１００は、実行環境の情報を取得するＡＰＩやシステムコールが返す値を書き換えながら複数回マルウェアを実行することで、マルウェアの活動痕跡が実行環境に依存して一意に定まる痕跡であることを特定した上で、活動痕跡の生成に関わる処理のみを再現するプログラムコードを、マルウェアのプログラムコードを用いて生成する。痕跡情報生成装置１００は、生成したプログラムコードを、監視対象端末５０にて実行することで、監視対象端末５０がマルウェアに感染した場合の活動痕跡を事前に明らかにし、監視対象端末５０専用のIoCを生成する。これによって、実行環境に依存して一意に定まる活動痕跡を検知する監視対象端末専用のIoCを作成することができるため、一意に定まる活動痕跡が正規ソフトウェアの活動痕跡と重複しなければ、マッチングの段階における見逃しや過検知を無くした上で高速にマッチングすることが可能となる。
　痕跡情報生成装置１００は、マルウェアを複数回実行し、マルウェアに関する複数の活動痕跡のうち、返す値を変更しない場合に変化せず、かつ、返す値を変更した場合に変化する活動痕跡を抽出することで、環境依存の活動痕跡を抽出することができる。
　痕跡情報生成装置１００は、マルウェアの命令（命令／ＡＰＩ／システムコール）をエミュレートした結果を仮想環境に反映し、エミュレートに伴うデータの読み書きのログを記録し、記録されたログを基にして、マルウェアの命令をエミュレートする直前の仮想環境の状態を復元し、活動痕跡が観測された位置まで、マルウェアを実行する。これによって、マルウェアを複数回実行しても、返す値を変更しない場合に変化せず、かつ、返す値を変更した場合に変化する活動痕跡を特定して、特定した活動痕跡を抽出することができる。
　図１５は、痕跡情報生成プログラムを実行するコンピュータの一例を示す図である。コンピュータ１０００は、たとえば、メモリ１０１０と、ＣＰＵ１０２０と、ハードディスクドライブインタフェース１０３０と、ディスクドライブインタフェース１０４０と、シリアルポートインタフェース１０５０と、ビデオアダプタ１０６０と、ネットワークインタフェース１０７０とを有する。これらの各部は、バス１０８０によって接続される。
　メモリ１０１０は、ＲＯＭ（Read　Only　Memory）１０１１およびＲＡＭ１０１２を含む。ＲＯＭ１０１１は、たとえば、ＢＩＯＳ（Basic　Input　Output　System）等のブートプログラムを記憶する。ハードディスクドライブインタフェース１０３０は、ハードディスクドライブ１０３１に接続される。ディスクドライブインタフェース１０４０は、ディスクドライブ１０４１に接続される。ディスクドライブ１０４１には、たとえば、磁気ディスクや光ディスク等の着脱可能な記憶媒体が挿入される。シリアルポートインタフェース１０５０には、たとえば、マウス１０５１およびキーボード１０５２が接続される。ビデオアダプタ１０６０には、たとえば、ディスプレイ１０６１が接続される。
　ここで、ハードディスクドライブ１０３１は、たとえば、ＯＳ１０９１、アプリケーションプログラム１０９２、プログラムモジュール１０９３およびプログラムデータ１０９４を記憶する。上記実施形態で説明した各情報は、たとえばハードディスクドライブ１０３１やメモリ１０１０に記憶される。
　また、痕跡情報生成プログラムは、たとえば、コンピュータ１０００によって実行される指令が記述されたプログラムモジュール１０９３として、ハードディスクドライブ１０３１に記憶される。具体的には、上記実施形態で説明した痕跡情報生成装置１００が実行する各処理が記述されたプログラムモジュール１０９３が、ハードディスクドライブ１０３１に記憶される。
　また、痕跡情報生成プログラムによる情報処理に用いられるデータは、プログラムデータ１０９４として、たとえば、ハードディスクドライブ１０３１に記憶される。そして、ＣＰＵ１０２０が、ハードディスクドライブ１０３１に記憶されたプログラムモジュール１０９３やプログラムデータ１０９４を必要に応じてＲＡＭ１０１２に読み出して、上述した各手順を実行する。
　なお、痕跡情報生成プログラムに係るプログラムモジュール１０９３やプログラムデータ１０９４は、ハードディスクドライブ１０３１に記憶される場合に限られず、たとえば、着脱可能な記憶媒体に記憶されて、ディスクドライブ１０４１等を介してＣＰＵ１０２０によって読み出されてもよい。あるいは、痕跡情報生成プログラムに係るプログラムモジュール１０９３やプログラムデータ１０９４は、ＬＡＮやＷＡＮ（Wide　Area　Network）等のネットワークを介して接続された他のコンピュータに記憶され、ネットワークインタフェース１０７０を介してＣＰＵ１０２０によって読み出されてもよい。
　以上、本発明者によってなされた発明を適用した実施形態について説明したが、本実施形態による本発明の開示の一部をなす記述および図面により本発明は限定されることはない。すなわち、本実施形態に基づいて当業者等によりなされる他の実施形態、実施例および運用技術等は全て本発明の範疇に含まれる。
　１００　　痕跡情報生成装置
　１４０　　記憶部
　１４１　　マルウェアＤＢ
　１４２　　解析ログＤＢ
　１４３　　環境依存痕跡ＤＢ
　１４４　　生成プログラムＤＢ
　１５０　　制御部
　１５１　　解析部
　１５２　　抽出部
　１５３　　作成部
　１５４　　生成部

Claims (6)

  1. 　実行環境から情報を取得するマルウェアの命令が返す値を書き換えながら前記マルウェアを複数回実行することで、前記マルウェアから、前記実行環境に依存して一意に定まる活動痕跡を抽出する抽出部と、
    　前記抽出部が抽出した活動痕跡の生成に関わる処理を再現するプログラムコードを前記マルウェアのプログラムコードを用いて作成する作成部と、
    　前記プログラムコードを実行することで、監視対象の端末の痕跡情報を生成する生成部と
    　を有することを特徴とする生成装置。
  2. 　前記抽出部は、実行環境を取得するＡＰＩ（Application　Programming　Interface）、システムコールまたは前記システムコール以外の命令が返す値を書き換えながらマルウェアを複数回実行することで、前記活動痕跡を抽出することを特徴とする請求項１に記載の生成装置。
  3. 　前記抽出部は、前記マルウェアを複数回実行し、前記マルウェアに関する複数の活動痕跡のうち、前記値を変更しない場合に変化せず、かつ、前記値を変更した場合に変化する活動痕跡を抽出することを特徴とする請求項１に記載の生成装置。
  4. 　仮想環境を設定し、前記マルウェアの命令をエミュレートした結果を前記仮想環境に反映し、前記エミュレートに伴うデータの読み書きのログを記録する解析部を更に有し、前記抽出部は、前記ログを基にして、前記マルウェアの命令をエミュレートする直前の仮想環境の状態を復元し、活動痕跡が観測された位置まで、前記マルウェアを実行することを特徴とする請求項３に記載の生成装置。
  5. 　実行環境から情報を取得するマルウェアの命令が返す値を書き換えながら前記マルウェアを複数回実行することで、前記マルウェアから、前記実行環境に依存して一意に定まる活動痕跡を抽出する抽出工程と、
    　前記抽出工程で抽出した活動痕跡の生成に関わる処理を再現するプログラムコードを前記マルウェアのプログラムコードを用いて作成する作成工程と、
    　前記プログラムコードを実行することで、監視対象の端末の痕跡情報を生成する生成工程と
    　を含んだことを特徴とする生成方法。
  6. 　実行環境から情報を取得するマルウェアの命令が返す値を書き換えながら前記マルウェアを複数回実行することで、前記マルウェアから、前記実行環境に依存して一意に定まる活動痕跡を抽出する抽出ステップと、
    　前記抽出工程で抽出した活動痕跡の生成に関わる処理を再現するプログラムコードを前記マルウェアのプログラムコードを用いて作成する作成ステップと、
    　前記プログラムコードを実行することで、監視対象の端末の痕跡情報を生成する生成ステップと
    　をコンピュータに実行させるための生成プログラム。
PCT/JP2021/022320 2021-06-11 2021-06-11 生成装置、生成方法及び生成プログラム WO2022259528A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
PCT/JP2021/022320 WO2022259528A1 (ja) 2021-06-11 2021-06-11 生成装置、生成方法及び生成プログラム
JP2023526811A JP7563596B2 (ja) 2021-06-11 2021-06-11 生成装置、生成方法及び生成プログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2021/022320 WO2022259528A1 (ja) 2021-06-11 2021-06-11 生成装置、生成方法及び生成プログラム

Publications (1)

Publication Number Publication Date
WO2022259528A1 true WO2022259528A1 (ja) 2022-12-15

Family

ID=84424503

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2021/022320 WO2022259528A1 (ja) 2021-06-11 2021-06-11 生成装置、生成方法及び生成プログラム

Country Status (2)

Country Link
JP (1) JP7563596B2 (ja)
WO (1) WO2022259528A1 (ja)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015186483A1 (ja) * 2014-06-05 2015-12-10 株式会社日立システムズ プログラム解析装置、プログラム解析方法及びプログラム解析システム
JP2016192139A (ja) * 2015-03-31 2016-11-10 株式会社日立アドバンストシステムズ マルウェア解析装置およびマルウェア解析方法
US20190108339A1 (en) * 2017-10-06 2019-04-11 International Business Machines Corporation Deactivating evasive malware

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015186483A1 (ja) * 2014-06-05 2015-12-10 株式会社日立システムズ プログラム解析装置、プログラム解析方法及びプログラム解析システム
JP2016192139A (ja) * 2015-03-31 2016-11-10 株式会社日立アドバンストシステムズ マルウェア解析装置およびマルウェア解析方法
US20190108339A1 (en) * 2017-10-06 2019-04-11 International Business Machines Corporation Deactivating evasive malware

Also Published As

Publication number Publication date
JP7563596B2 (ja) 2024-10-08
JPWO2022259528A1 (ja) 2022-12-15

Similar Documents

Publication Publication Date Title
EP3200115B1 (en) Specification device, specification method, and specification program
US9383934B1 (en) Bare-metal computer security appliance
Vidas et al. A5: Automated analysis of adversarial android applications
JP7392775B2 (ja) 分析システム、方法、及び、プログラム
WO2022180702A1 (ja) 解析機能付与装置、解析機能付与プログラム及び解析機能付与方法
RU2665911C2 (ru) Система и способ анализа файла на вредоносность в виртуальной машине
US20220035905A1 (en) Malware analysis through virtual machine forking
US9965631B2 (en) Apparatus and method for analyzing malicious code in multi-core environment using a program flow tracer
CN109558207B (zh) 在虚拟机中形成用于进行文件的防病毒扫描的日志的系统和方法
JP6734481B2 (ja) コールスタック取得装置、コールスタック取得方法、および、コールスタック取得プログラム
EP2985716B1 (en) Information processing device and identifying method
US20230096108A1 (en) Behavior analysis based on finite-state machine for malware detection
CN109857520B (zh) 一种虚拟机自省中的语义重构改进方法及系统
EP2988242B1 (en) Information processing device, and information processing method
CN113391874A (zh) 一种虚拟机检测对抗方法、装置、电子设备及存储介质
CN111177665A (zh) 一种新生成可执行文件的安全追溯方法
Miller et al. Insights gained from constructing a large scale dynamic analysis platform
WO2023067668A1 (ja) 解析機能付与方法、解析機能付与装置及び解析機能付与プログラム
US20140298002A1 (en) Method and device for identifying a disk boot sector virus, and storage medium
WO2022259528A1 (ja) 生成装置、生成方法及び生成プログラム
JP7568056B2 (ja) 活動痕跡抽出装置、活動痕跡抽出方法及び活動痕跡抽出プログラム
Otsuki et al. Tracing malicious injected threads using alkanet malware analyzer
WO2022195728A1 (ja) 活動痕跡抽出装置、活動痕跡抽出方法及び活動痕跡抽出プログラム
JP7501782B2 (ja) 活動痕跡抽出装置、活動痕跡抽出方法および活動痕跡抽出プログラム
WO2023067667A1 (ja) 解析機能付与方法、解析機能付与装置及び解析機能付与プログラム

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: 21945200

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2023526811

Country of ref document: JP

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21945200

Country of ref document: EP

Kind code of ref document: A1