US10853483B2 - Identification device, identification method, and identification program - Google Patents

Identification device, identification method, and identification program Download PDF

Info

Publication number
US10853483B2
US10853483B2 US15/528,875 US201515528875A US10853483B2 US 10853483 B2 US10853483 B2 US 10853483B2 US 201515528875 A US201515528875 A US 201515528875A US 10853483 B2 US10853483 B2 US 10853483B2
Authority
US
United States
Prior art keywords
malware
identification information
command server
tag
data
Prior art date
Legal status (The legal status 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 status listed.)
Active, expires
Application number
US15/528,875
Other languages
English (en)
Other versions
US20170329962A1 (en
Inventor
Tomonori IKUSE
Kazufumi AOKI
Takeo Hariu
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nippon Telegraph and Telephone Corp
Original Assignee
Nippon Telegraph and Telephone Corp
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 Nippon Telegraph and Telephone Corp filed Critical Nippon Telegraph and Telephone Corp
Assigned to NIPPON TELEGRAPH AND TELEPHONE CORPORATION reassignment NIPPON TELEGRAPH AND TELEPHONE CORPORATION ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: AOKI, Kazufumi, HARIU, TAKEO, IKUSE, Tomonori
Publication of US20170329962A1 publication Critical patent/US20170329962A1/en
Application granted granted Critical
Publication of US10853483B2 publication Critical patent/US10853483B2/en
Active legal-status Critical Current
Adjusted expiration legal-status Critical

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/52—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
    • G06F21/53—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow by executing in a restricted environment, e.g. sandbox or secure virtual machine
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • 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
    • H04W12/1208—
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/12—Detection or prevention of fraud
    • H04W12/128—Anti-malware arrangements, e.g. protection against SMS fraud or mobile malware

Definitions

  • the present invention relates to an identification device, an identification method, and an identification program.
  • malware that creates a threat such as information leakage and unauthorized access is rampant.
  • measures against such malware are to be taken, it is an ideal to prevent infection itself.
  • the way to infect some devices with malware is steadily advanced and diversified, and it is difficult to prevent all malware infections in advance. Therefore, not only measures to prevent malware infection but also measures to minimize damage after infection are required.
  • measures such as detection of infected terminals and communication cut-off using a blacklist are taken.
  • a blacklist many of malware have a feature of communicating with a command server that transmits an attacker's instruction after the infection and determines a behavior of the malware, and perform information leakage and further infection activity in response to the instruction from the command server. Therefore, if the command server is blacklisted in advance, it is possible to find an infected terminal by detecting communication with the command server and to detoxify the infected terminal by cutting off the communication with the command server.
  • these measures require generation of the blacklist beforehand.
  • Non Patent Literature 1 and Non Patent Literature 2 a method focusing on how the command server controls malware has been studied.
  • Non Patent Literature 1 a branch instruction in the program code of malware and an API call sequence executed at a branch destination are focused, and when a predetermined API is called at each branch destination by data received from the same communication destination, this communication destination is identified as a command server.
  • Non Patent Literature 2 a data transfer relationship between system calls issued in relation to data transmission/reception of malware is focused, and when arguments of the system calls and APIs are specified, the command server is identified.
  • the data received from the command server affects only the branch instruction, and is not used as arguments of the system call and API. Therefore, in the method described in Non Patent Literature 2, there is a possibility that the command server is missed when only the program code executed by malware is specified. On the other hand, in the method described in Non Patent Literature 1, because it focuses on the branch instruction, any control method can cope with it. However, because the legitimate site may sometimes affect the branch instruction, it is necessary to receive two or more types of commands that affect only the branch instruction in order to accurately detect the command server.
  • the present invention has been made to solve the conventional technological problems, and an object of the present invention is to provide an identification device, an identification method, and an identification program capable of identifying a command server even if only one type of command that affects only a branch instruction is received.
  • An identification device includes: a tracking unit that adds a tag to data received by malware upon execution of the malware, the tag capable of uniquely identifying identification information for a transmission source of the data, and that tracks propagation of the data added with the tag; a monitoring unit that acquires a tag of data referenced by a branch instruction executed by the malware, among data tracked by the tracking unit; an analyzing unit that analyzes information on an instruction of a branch destination not executed by the malware after the branch instruction; and an identifying unit that identifies identification information of a command server for issuing a command to the malware from the identification information of the transmission source corresponding to the tag acquired by the monitoring unit, based on an analysis result of the analyzing unit.
  • An identification method executed by an identification device includes: a tracking process of adding a tag to data received by malware upon execution of the malware, the tag capable of uniquely identifying identification information for a transmission source of the data, and of tracking propagation of the data added with the tag; a monitoring process of acquiring a tag of data referenced by a branch instruction executed by the malware, among data tracked in the tracking process; an analyzing process of analyzing information on an instruction of a branch destination not executed by the malware after the branch instruction; and an identifying process of identifying identification information of a command server for issuing a command to the malware from the identification information of the transmission source corresponding to the tag acquired in the monitoring process, based on an analysis result of the analyzing process.
  • An identification program for causing a computer to execute: a tracking step of adding a tag to data received by malware upon execution of the malware, the tag capable of uniquely identifying identification information for a transmission source of the data, and of tracking propagation of the data added with the tag; a monitoring step of acquiring a tag of data referenced by a branch instruction executed by the malware, among data tracked at the tracking step; an analyzing step of analyzing information on an instruction of a branch destination not executed by the malware after the branch instruction; and an identifying step of identifying identification information of a command server for issuing a command to the malware from the identification information of the transmission source corresponding to the tag acquired at the monitoring step, based on an analysis result of the analyzing step.
  • the identification device, the identification method, and the identification program disclosed in the present application can identify a command server even if only one type of command that affects only a branch instruction is received.
  • FIG. 1 is a block diagram illustrating an overview of a command server identification device according to a first embodiment.
  • FIG. 2 is a diagram illustrating an example of information stored by an identification information DB according to the first embodiment.
  • FIG. 3 is a diagram illustrating an example of information stored by an execution trace DB according to the first embodiment.
  • FIG. 4 is a diagram illustrating an example of information stored by a memory dump DB according to the first embodiment.
  • FIG. 5 is a flowchart illustrating an example of a control structure analyzed by an unexecuted area analyzing unit according to the first embodiment.
  • FIG. 6 is a flowchart illustrating a flow of processing for static analysis of an unexecuted area by the command server identification device according to the first embodiment.
  • FIG. 7 is a flowchart illustrating a flow of identification processing of a command server by the command server identification device according to the first embodiment.
  • FIG. 8 is a block diagram illustrating an overview of a command server identification device according to a second embodiment.
  • FIG. 9 is a diagram illustrating an example of information stored by a runtime state DB according to the second embodiment.
  • FIG. 10 is a flowchart illustrating a flow of processing for dynamic analysis of an unexecuted area by the command server identification device according to the second embodiment.
  • FIG. 11 is a diagram illustrating a computer that executes an identification program.
  • FIG. 1 is a block diagram illustrating an overview of the command server identification device according to a first embodiment.
  • the command server identification device 10 includes a malware execution environment unit 11 , an identification information DB (Data Base) 12 , an execution trace DB 13 , a memory dump DB 14 , an unexecuted area analyzing unit 15 , and a command server identifying unit 16 .
  • the processing of each unit will be explained below.
  • the malware execution environment unit 11 includes a malware 11 a , a guest OS (operating System) 11 b , and a virtual machine monitor 11 c , and analyzes the malware while actually running it.
  • the malware 11 a is a malicious program that poses a threat such as information leakage and unauthorized access, and is executed on the guest OS 11 b as a program to be analyzed.
  • the guest OS 11 b is an environment for dynamically analyzing the malware 11 a.
  • the virtual machine monitor 11 c includes a memory dump acquiring unit 110 , a data propagation tracking unit 111 , and an instruction monitoring unit 112 , and monitors the behavior when malware is executed.
  • the virtual machine monitor 11 c constructs a virtual machine including a virtual CPU (Central Processing Unit) and a virtual memory on the guest OS 11 b , causes the virtual machine to execute the malware 11 a , and monitors its behavior.
  • a virtual CPU Central Processing Unit
  • the memory dump acquiring unit 110 acquires a memory dump in order to monitor the behavior of the malware 11 a and registers the memory dump in the memory dump DB 14 .
  • the memory dump acquiring unit 110 acquires the content of a virtual memory provided in the virtual machine when the virtual machine executes the malware 11 a , and records the acquired content in the memory dump DB 14 .
  • the data propagation tracking unit 111 sets a tag for the data received by the malware 11 a , the tag being capable of uniquely identifying its transmission source and which the received data is, and tracks the propagation of the data during execution of the malware 11 a by taint analysis.
  • the taint analysis technology is one of methods to automate data flow analysis, and is a technology of tracking propagation of data within an analysis system by setting a tag for the data and propagating the tag according to a propagation rule.
  • the tag is attribute information added to the data, in which the origin and type of data are set.
  • the propagation rule is a condition for propagating tags, and copying and computation of the data are generally set as a condition for propagation.
  • the data propagation tracking unit 111 sets a tag that can uniquely identify an acquisition source in the received data and propagates the tag according to the copying and computation of the data.
  • the command server identification device 10 can analyze that the received data is data used as the argument of the API. It is common that the taint analysis technology is realized by using virtual computer technology, and the tag is stored in a dedicated recording area different from that of the data so as to be associated with the data.
  • the data propagation tracking unit 111 sets the tag capable of uniquely identifying the transmission source in the data received by the malware 11 a , records the tag corresponding to the identification information indicating the transmission source of the data such as IP (Internet Protocol) address, FQDN (Fully Qualified Domain Name), and URL (Uniform Resource Locator) in the identification information DB 12 , and then tracks data propagation on the virtual machine monitor 11 c .
  • the data propagation tracking unit 111 when the data is received from a plurality of transmission sources to generate new data, the data propagation tracking unit 111 generates a new tag capable of uniquely identifying the identification information for the transmission sources, adds the tag to the data, and tracks the propagation of the data added with the tag.
  • the data propagation tracking unit 111 adds a tag to a return value of the function and tracks the propagation of the data added with the tag.
  • the instruction monitoring unit 112 calls, among branch instructions executed by program codes of the malware 11 a , a branch instruction and an API that refer to the data added with the tag indicating that it is the data received by the malware 11 a , and records a call stack or the like when these are called, as logs, in the execution trace DB 13 .
  • the instruction monitoring unit 112 acquires API call executed by the malware 11 a , issue of a system call, branch instructions such as jmp instruction, jcc instruction, call instruction, and ret instruction, a call stack when an instruction is executed, and a tag of the data referenced by the branch instruction, and records the acquired data in the execution trace DB 13 . That is, the instruction monitoring unit 112 acquires the tag of the data referenced by the branch instruction executed by the malware 11 a and records the acquired tag in the execution trace DB 13 .
  • the identification information DB 12 stores the identification information of communication generated when the malware is executed and the tag set in the received data received from the communication destination indicated by the identification information in association with each other.
  • FIG. 2 is a diagram illustrating an example of information stored by the identification information DB according to the first embodiment. As illustrated in FIG. 2 , the identification information DB 12 stores the identification information and the tag added to the received data received from the communication destination indicated by the identification information in association with each other.
  • the tag corresponding to an IP address “192.168.2.150” as the identification information is “1”, and the tag corresponding to an IP address “192.168.2.140” as the identification information is “2”.
  • the identification information DB 12 recognizes the acquisition source by checking the tag set in the data.
  • the tag registered in the identification information DB 12 is set by, for example, the data propagation tracking unit 111 , but the granularity for setting the tag may be arbitrarily set according to the granularity of the identification information for the finally identified command server.
  • the data propagation tracking unit 111 may change the tag corresponding to the received data for each FQDN and URL, or may change the tag for each session in consideration of a port number.
  • the data propagation tracking unit 111 sets the tag capable of uniquely identifying the transmission source.
  • the execution trace DB 13 stores the log acquired by the instruction monitoring unit 112 .
  • FIG. 3 is a diagram illustrating an example of information stored by the execution trace DB according to the first embodiment.
  • ID IDentifier
  • the execution trace DB 13 ID (IDentifier) for identifying the log, the branch instruction executed during analysis by the malware, the execution address where the branch instruction is executed, the call stack at the time of execution, the branch destination executed, the branch destination not executed, the tag that affects the determination of the branch destination, and the API name are recorded.
  • the API name is information recorded when the branch destination is the API.
  • the tag that affects the determination of the branch destination and the branch destination not executed are information recorded only when these are present.
  • FIG. 4 is a diagram illustrating an example of information stored by the memory dump DB according to the first embodiment.
  • the memory dump DB 14 records an ID for identifying the memory dump, an execution log ID, and a dump content in association with each other.
  • the execution log ID is an ID of the log registered in the execution trace DB 13 as information indicating a location where the memory dump is acquired.
  • the dump content is a memory dump acquired by the memory dump acquiring unit 110 . Thereby, the memory dump as a target to be analyzed at the time of analyzing the unexecuted area can be identified in the memory dump DB 14 .
  • the unexecuted area analyzing unit 15 analyzes the information related to the instruction of the branch destination not executed by the malware 11 a after the branch instruction executed by the malware 11 a . Specifically, the unexecuted area analyzing unit 15 statically analyzes the program code of the branch destination not executed by the malware 11 a based on the information stored in the identification information DB 12 , the execution trace DB 13 , and the memory dump DB 14 . By analyzing the control structure that is a structure of instructions and processing at the branch destination not executed by the malware 11 a , the unexecuted area analyzing unit 15 identifies the junction between the branch destination executed by the malware 11 a and the branch destination not executed by the malware 11 a.
  • FIG. 5 is a flowchart illustrating an example of the control structure analyzed by the unexecuted area analyzing unit 15 according to the first embodiment.
  • the example illustrated in FIG. 5 represents the control structure when the processing executed by the malware 11 a is branched into a branch destination A and a branch destination B by the branch instruction for changing a branch destination by the data received from an external server and then the branches join together at a junction C.
  • the unexecuted area analyzing unit 15 identifies the range of the branch destination B executed by the malware 11 a by identifying the junction C between the branch destination B not executed by the malware 11 a and the branch destination A.
  • the unexecuted area analyzing unit 15 refers to the execution trace DB 13 , identifies the branch instruction that the received data affects the determination of a branch destination, and determines whether the malware 11 a executes each branch destination of the identified branch instruction. At this time, each branch instruction is identified in consideration of the call stack and the value of execution address (value of instruction pointer register). Then, about the identified branch instruction, when the execution log which is the log when each branch destination is executed can be checked from the execution trace DB 13 , the unexecuted area analyzing unit 15 ends the processing for the identified branch instruction assuming that there is no unexecuted area.
  • the unexecuted area analyzing unit 15 uses the memory dump recorded at the time of executing the malware 11 a to statically analyze the API called at the unexecuted branch destination and the control structure of the branch destination. For example, the unexecuted area analyzing unit 15 performs static analysis to disassemble the data of the memory dump. As a specific algorithm for disassembling, a known linear sweep algorithm or recursive algorithm is used.
  • the unexecuted area analyzing unit 15 identifies the API called at the unexecuted branch destination by checking it against information for a module loaded during dynamic analysis of the branch destination executed by the malware 11 a , its export address table, a called address, and an import address table as a target to be analyzed. However, the unexecuted area analyzing unit 15 may monitor the unexecuted area by using a known method of monitoring API calls which gives resistance to analysis interference by applying the taint analysis. Thereafter, the unexecuted area analyzing unit 15 notifies the command server identifying unit 16 of the identified API and control structure as a result of analysis.
  • the unexecuted area analyzing unit 15 identifies only the API call that can be identified, as API executed at the branch destination, and notifies the command server identifying unit 16 to that effect. Also, for the control structure, the unexecuted area analyzing unit 15 does not consider the instruction whose branch destination is unknown.
  • the command server identifying unit 16 identifies a command server based on the analysis result of the unexecuted area analyzing unit 15 and the information stored in the execution trace DB 13 and the identification information DB 12 . Specifically, the command server identifying unit 16 identifies the identification information of the command server that issues a command to the malware 11 a , from the identification information of the transmission source corresponding to the tag acquired by the instruction monitoring unit 112 based on the analysis result of the unexecuted area analyzing unit 15 .
  • the command server identifying unit 16 receives the API called in the unexecuted area, which is a branch destination not executed by the malware 11 a , and the control structure of the unexecuted area from the unexecuted area analyzing unit 15 .
  • the command server identifying unit 16 reads the execution log stored by the execution trace DB 13 and the information stored by the identification information DB 12 . Thereafter, the command server identifying unit 16 checks whether all the branch instructions that the received data affects the determination of the branch destinations are applied to next conditions.
  • the command server identifying unit 16 identifies the API called between a branch point and the junction when the junction is present beyond the branches of the branch instruction and identifies the API called before reaching the end point when the junction is not present, and determines whether a predetermined API or a predetermined API string is included in the identified API.
  • the command server identifying unit 16 identifies the command server by acquiring the tag of the data referenced at the time of branching, from the execution trace DB 13 , and then acquiring the communication destination tied to the tag from the identification information DB 12 .
  • the command server identifying unit 16 determines the transmission source of the data affected on the branch instruction as the command server.
  • the predetermined API is an API, which should be noted in malware analysis, that the malware preferably calls in general, and is separately prepared as a list, so that it is possible to check the API whether it is the predetermined API by checking it against the list.
  • the predetermined API string is an order of APIs, which should be noted in the malware analysis, that the malware executes after reception of a command from the command server.
  • an API string is set in the predetermined API string, in the order of an API for opening a file within the terminal, an API for reading data in the file, and an API for transmitting the read data to an external server.
  • an API string is set in the predetermined API string, in the order of an API for opening a file within the terminal, an API for searching for data in the file, an API for writing the data in the file, and an API for closing the file.
  • predetermined APIs and API strings can be investigated by prior malware analysis and listed.
  • the API and API string to be checked may be limited according to calculation resource operated by the API, or may be limited by the API called by the previously analyzed malware 11 a .
  • only the API called at the time of dynamic analysis for determination of the command server and API call sequence may be targets to be detected.
  • the command server identifying unit 16 may determine the transmission source corresponding to the tag of the data referenced by the branch instruction as the command server. Moreover, the command server identifying unit 16 may determine the command server based on both the called API and system call.
  • the command server identifying unit 16 identifies the command server based on the API and the system call etc. called at the branch destination executed by the malware 11 a in addition to the processing. For example, for the branch instruction where the API call and the issuing of the system call are performed at a plurality of branch destinations, when the identification information corresponding to the tag of the data referenced at the time of branching is common to that at the branch destinations, the command server identifying unit 16 identifies the identification information as identification information of the command server.
  • the command server identifying unit 16 extracts the branch instruction where the API call and the issuing of the system call are performed at the branch destinations, and acquires the tag of the data referenced when branching the processing into the branch destinations where the API call and the issuing of the system call are performed, from the execution trace DB 13 .
  • the command server identifying unit 16 acquires the communication destination that affects the branch instruction for each branch destination, and determines the communication destination that is common between the branch destinations as the command server. In other words, the command server identifying unit 16 identifies the command server by dynamically analyzing the malware 11 a , statically analyzes the branch destination not executed by the malware 11 a for each branch instruction, and determines, when the predetermined API and API string are called as a result of static analysis, the transmission source of the data that affects the branch instruction as a target to be processed, as the command server.
  • the command server identifying unit 16 can identify the command server based on the API string called by the malware 11 a.
  • the command server identifying unit 16 may identify the command server from the branch destination executed by the malware 11 a by using other known method. For example, when the predetermined API or system call is called at the branch destination executed by the malware 11 a , the command server identifying unit 16 may determine the transmission source of the data that affects the branch instruction as a target to be processed, as the command server.
  • the command server identification device 10 tracks the propagation after the tag is added to the received data at the time of execution of the malware 11 a , calls the API executed by the malware 11 a , monitors and acquires the branch instruction, the call stack at the time of executing the instruction, and the tag set in the data referenced by the branch instruction.
  • the command server identification device 10 identifies the command server in the branch instruction in which the branch destination is determined by the received data, based on API or API string called at the branch destination not executed by the malware 11 a and based on the control structure.
  • the command server identification device 10 can determine whether the communication destination can actually control the malware by checking called API or API string or the like, thus identifying the communication destination as the command server.
  • the command server identification device 10 can identify the command server, and by checking the API string at the branch destinations, its accuracy increases. That is, the command server identification device 10 analyzes also the branch destination of the unexecuted area, and can therefore identify the command server even when only one type of command instructing only switching of the program code to be executed is received.
  • the command server identified by the command server identification device 10 is registered in the blacklist for command servers in which known malicious IP addresses, URLs, etc. are listed. By registering the identification information such as the IP address of the command server in the blacklist, it is possible to block the communication with the command server, and to find and isolate the infected terminal.
  • FIG. 6 is a flowchart illustrating a flow of processing for static analysis of an unexecuted area by the command server identification device according to the first embodiment.
  • FIG. 7 is a flowchart illustrating a flow of identification processing of a command server by the command server identification device according to the first embodiment.
  • the unexecuted area analyzing unit 15 acquires a branch instruction that the received data affects the determination of the branch destination, from the execution trace DB 13 (Step S 101 ). Subsequently, the unexecuted area analyzing unit 15 determines whether all acquired branch instructions have been checked (Step S 102 ), and determines, when they have not been checked (No at Step S 102 ), whether all the branch destinations have been executed (Step S 103 ).
  • the unexecuted area analyzing unit 15 statically analyzes the unexecuted area (Step S 104 ). Subsequently, the unexecuted area analyzing unit 15 notifies the command server identifying unit 16 of the identified control structure and of the API called in the unexecuted area as a result of static analysis (Step S 105 ), and executes again Step S 102 . Meanwhile, when all the branch destinations have been executed (Yes at Step S 103 ), the unexecuted area analyzing unit 15 executes again Step S 102 . When all the acquired branch instructions have been checked (Yes at Step S 102 ), the unexecuted area analyzing unit 15 ends the processing.
  • the command server identifying unit 16 acquires an execution log from the execution trace DB 13 (Step S 201 ). Subsequently, the command server identifying unit 16 acquires an analysis result from the unexecuted area analyzing unit 15 (Step S 202 ). Then, the command server identifying unit 16 acquires a branch instruction that the received data affects the determination of the branch destination, from the execution trace DB 13 (Step S 203 ).
  • the command server identifying unit 16 determines whether all the acquired branch instructions have been checked (Step S 204 ), and executes the following processing for the branch instructions that have not been checked when they have not been checked (No at Step S 204 ). In other words, the command server identifying unit 16 acquires an API called between the branch point and the junction or before reaching the end point of the processing executed by the program, that is, acquires an API called in the unexecuted area (Step S 205 ). The command server identifying unit 16 then determines whether the predetermined API or API string has been called by the acquired API (Step S 206 ). When it has been called (Yes at Step S 206 ), the command server identifying unit 16 acquires the identification information tied to the tag of the data referenced by the branch instruction as a target to be processed from the identification information DB 12 (Step S 207 ).
  • the command server identifying unit 16 determines the communication destination indicated by the acquired identification information as the command server (Step S 208 ), and executes again Step S 204 . Meanwhile, when the predetermined API or API string has not been called by the acquired API (No at Step S 206 ), the command server identifying unit 16 executes again Step S 204 . When all the acquired branch instructions have been checked (Yes at Step S 204 ), the command server identifying unit 16 ends the processing.
  • the command server identification device 10 adds the tag capable of uniquely identifying identification information for a data transmission source to the data received by the malware 11 a , and tracks the propagation of the data added with the tag. Moreover, the command server identification device 10 acquires the tag of the data, of the tracked data, referenced by the branch instruction executed by the malware 11 a . The command server identification device 10 analyzes the information on the instruction of the branch destination not executed by the malware 11 a after the branch instruction, and identifies identification information of the command server that issues a command to the malware 11 a from the identification information for the transmission source corresponding to the acquired tag based on the analysis result.
  • the command server identification device 10 can identify the command server. In addition, the command server identification device 10 can automatically identify the command server when the communication content of malware is obfuscated or encrypted.
  • the command server identification device 10 analyzes at least one of the API and the system call called by the malware 11 a at the branch destination not executed by the malware 11 a after the branch instruction. Then, when the predetermined API is called at the branch destination not executed by the malware 11 a after the branch instruction or when the predetermined system call is called, the command server identification device 10 determines the identification information for the transmission source corresponding to the tag of the data referenced by the branch instruction as the identification information of the command server. Therefore, the command server identification device 10 can identify the command server of the malware 11 a that calls the predetermined API and system call.
  • the command server identification device 10 determines the identification information for the transmission source corresponding to the tag of the data referenced by the branch instruction as the identification information of the command server. Therefore, the command server identification device 10 can identify the command server of the malware 11 a that calls the predetermined APIs and system calls in the predetermined order.
  • the command server identification device 10 By analyzing the control structure of the branch destination not executed by the malware, the command server identification device 10 identifies a junction between the branch destination executed by the malware and the branch destination not executed by the malware, and identifies the identification information for the command server that issues the command to the malware based on the analysis result of the information on instructions from the branch instruction to the junction. Therefore, the command server identification device 10 can accurately identify the command server of the malware 11 a.
  • the command server identification device 10 acquires the content of a memory when the malware 11 a is executed, and uses the acquired content of the memory to statically analyze the information on the instruction of the branch destination not executed by the malware 11 a after the branch instruction. Therefore, the command server identification device 10 does not have to execute the malware 11 a many times in order to analyze the branch destinations, which makes it possible to reduce the processing load of the analysis.
  • the command server identification device 10 statically analyzes the unexecuted area and identifies the command server based on the API and the system call called in the unexecuted area.
  • the embodiments are not limited thereto.
  • the command server identification device 10 may analyze the API and the system call called in the unexecuted area, and the control structure of the unexecuted area.
  • the command server identification device 10 can analyze the API, the system call, and the control structure at the branch destination even in situations that the analysis is difficult only by the static analysis such as when the called party is dynamically determined by call instruction in the process of executing the instruction.
  • a command server identification device 10 a according to a second embodiment will be explained below with reference to the drawing.
  • the same reference signs are assigned to those that execute the same processing as that of the first embodiment, and explanation thereof is omitted.
  • FIG. 8 is a block diagram illustrating an overview of the command server identification device according to the second embodiment.
  • the command server identification device 10 a includes a malware execution environment unit 11 d , the identification information DB 12 , the execution trace DB 13 , a runtime state DB 17 , a runtime state recording file 18 , an unexecuted area analyzing unit 15 a , and the command server identifying unit 16 .
  • the malware execution environment unit 11 d includes the malware 11 a , the guest OS 11 b , and a virtual machine monitor 11 e , and analyzes the malware 11 a while actually running, similarly to the malware execution environment unit 11 .
  • the virtual machine monitor 11 e includes the data propagation tracking unit 111 , the instruction monitoring unit 112 , and a runtime state recording unit 113 , and monitors a runtime behavior of the malware 11 a executed by a virtual machine operating on the guest OS 11 b , similarly to the virtual machine monitor 11 c.
  • the runtime state recording unit 113 provided in the virtual machine monitor 11 e records a snapshot of the virtual machine at the time of execution of malware.
  • the runtime state recording unit 113 acquires the snapshot of the virtual machine that executes the malware 11 a , records the acquired snapshot as the runtime state recording file 18 , and records the location where the snapshot is acquired in the runtime state DB 17 .
  • the processing of acquiring snapshot by the runtime state recording unit 113 can be implemented by using a snapshot function generally provided in the virtual machine monitor 11 e .
  • the runtime state recording unit 113 stores all the data within the memory area in which the tag is stored, in the runtime state recording file 18 together with the snapshot at the time of acquiring the snapshot.
  • the snapshot can record a difference in all the states of the virtual machine including the memory content, it is possible to acquire more information than information in which the state of the virtual machine is recorded using the memory dump.
  • a combination of the snapshot of the virtual machine acquired by the data propagation tracking unit 111 and the data within the memory area in which the tag is stored is described as “snapshot”.
  • the runtime state DB 17 records the location where the snapshot acquired by the runtime state recording unit 113 is acquired.
  • FIG. 9 is a diagram illustrating an example of information stored by the runtime state DB according to the second embodiment.
  • the runtime state DB 17 stores an ID of snapshot, an execution log ID of the execution log corresponding to an instruction executed when the snapshot is acquired, and a file name in association with each other.
  • the file name is a title added to binary data of the snapshot recorded in the runtime state recording file 18 , such as snapshot acquisition date.
  • the runtime state recording file 18 is the binary data of the snapshot acquired by the runtime state recording unit 113 .
  • the runtime state recording file 18 is recorded in a predetermined storage device included in the command server identification device 10 a or a predetermined storage device included in an external device.
  • the unexecuted area analyzing unit 15 a dynamically analyzes the API and the system call called in the unexecuted area not executed by the malware 11 a , and the control structure. Specifically, the unexecuted area analyzing unit 15 a acquires the branch instruction that the received data affects the determination of the branch destination from the execution trace DB 13 , and determines whether each branch destination is executed.
  • the unexecuted area analyzing unit 15 a uses the snapshot recorded in the runtime state DB 17 , restores the state at the time of executing the branch instruction, forcibly executes the unexecuted branch destination from the restored portion, and dynamically analyzes the API and the system call called at the unexecuted branch destination, and the control structure. For example, the unexecuted area analyzing unit 15 a performs, from the restored portion, forcible execution of simply forcibly rewriting an instruction pointer register to an address of the branch destination, or forcibly executes the unexecuted branch destination by symbolic execution that symbolizes and executes the branch condition. The unexecuted area analyzing unit 15 a dynamically analyzes the API and the system call called at the branch destination, and the control structure.
  • the unexecuted area analyzing unit 15 a notifies the command server identifying unit 16 of the information on API calls, system calls, and control structures acquired so far.
  • the unexecuted area analyzing unit 15 a may generate input data based on constraint conditions with respect to the input value obtained by symbolic execution, and re-analyze the malware.
  • the command server identifying unit 16 identifies the command server based on the API and the system call called in the unexecuted area that is dynamically analyzed by the unexecuted area analyzing unit 15 a , and based on the control structure. For example, when the predetermined API and system call or the predetermined API string or the like are called in the unexecuted area, the command server identifying unit 16 determines the transmission source of the data that affects the branch instruction as a target to be processed as the command server.
  • FIG. 10 is a flowchart illustrating a flow of processing for dynamic analysis of an unexecuted area by the command server identification device according to the second embodiment.
  • the unexecuted area analyzing unit 15 a acquires a branch instruction that the received data affects the determination of the branch destination, from the execution trace DB 13 (Step S 301 ). Subsequently, the unexecuted area analyzing unit 15 a determines whether all acquired branch instructions have been checked (Step S 302 ), and determines, when they have not been checked (No at Step S 302 ), whether all the branch destinations have been executed (Step S 303 ).
  • the unexecuted area analyzing unit 15 a executes the following processing. First of all, the unexecuted area analyzing unit 15 a refers to the runtime state DB 17 , identifies the snapshot at the time of execution of the branch instruction as a target to be processed, and acquires the identified snapshot from the runtime state recording file 18 and restores the acquired snapshot (Step S 304 ). Then, the unexecuted area analyzing unit 15 a forcibly executes and dynamically analyzes the unexecuted area (Step S 305 ).
  • the unexecuted area analyzing unit 15 a notifies the command server identifying unit 16 of the identified control structure and the API called in the unexecuted area (Step S 306 ), and executes again Step S 302 . Meanwhile, when all the branch destinations have been executed (Yes at Step S 303 ), the unexecuted area analyzing unit 15 a executes again Step S 302 . When all the acquired branch instructions have been checked (Yes at Step S 302 ), the unexecuted area analyzing unit 15 a ends the processing.
  • the command server identification device 10 a records the snapshot of the virtual machine that executes the malware 11 a . Then, the command server identification device 10 a uses the snapshot to forcibly execute the branch destination not executed by the malware 11 a after the branch instruction, and dynamically analyzes the information on the instruction of the branch destination.
  • the command server identification device 10 a uses the snapshot of the virtual machine to dynamically analyze the branch destinations not executed by the malware 11 a , there are cases where it is possible to identify the command server that cannot be identified by only the content of the memory dump. As a result, the command server identification device 10 a can accurately identify the command server. However, because the command server identification device 10 a uses the snapshot of the virtual machine, the storage capacity for storing various databases and the processing burden of analysis are increased as compared with the command server identification device 10 .
  • the command server identification device 10 stores the acquired memory dump in a DB format in the memory dump DB 14 .
  • the embodiments are not limited thereto.
  • the command server identification device 10 may save the acquired memory dump in a binary format file and set the ID of the memory dump and the memory-dump acquisition date in the file name.
  • the command server identification device 10 can record the memory dump in an arbitrary method.
  • the command server identification devices 10 and 10 a use the taint analysis to track data propagation.
  • the taint analysis technology used to track data propagation has a problem such as discontinuity of data propagation.
  • the command server identification devices 10 and 10 a may use a mechanism of forced propagation such as a method of propagating a tag to a return value from the argument of the function or a method of propagating a tag to the return value of a function in the function in which a specific tag is read and to a write content within the function.
  • the components of the illustrated devices are functionally conceptual, and are not necessarily configured as physically illustrated ones.
  • the specific mode of decentralization and integration of the devices is not limited to the illustrated ones, and it may be configured by functionally or physically decentralizing or integrating all or part of the devices in an arbitrary unit according to various loads and usage conditions.
  • the data propagation tracking unit 111 and the instruction monitoring unit 112 may be integrated into one unit, or the virtual machine monitor 11 c may be separated into a virtual machine and a monitor for monitoring the virtual machine.
  • the identification information DB 12 , the execution trace DB 13 , and the memory dump DB 14 may be stored by an external device of the command server identification device 10 , and these components may be connected to the command server identification device 10 via a network.
  • Different devices have the unexecuted area analyzing unit 15 and the command server identifying unit 16 respectively, and the functions of the command server identification device 10 may be implemented by the devices connected to the network in cooperation with each other.
  • all or arbitrary part of the processing functions performed in each of the devices can be implemented by the CPU and by the program analyzed and executed by the CPU, or implemented as hardware by wired logic.
  • FIG. 11 is a diagram illustrating a computer that executes an identification program.
  • a computer 1000 includes, for example, a memory 1010 , a CPU 1020 , a hard disk drive interface 1030 , a disk drive interface 1040 , a serial port interface 1050 , a video adapter 1060 , and a network interface 1070 , which are connected to each other via a bus 1080 .
  • the memory 1010 includes ROM (Read Only Memory) 1011 and RAM (Random Access Memory) 1012 .
  • the Rom 1011 stores, for example, a boot program such as BIOS (Basic Input Output System).
  • BIOS Basic Input Output System
  • the hard disk drive interface 1030 is connected to a hard disk drive 1090 as illustrated in FIG. 11 .
  • the disk drive interface 1040 is connected to a disk drive 1041 as illustrated in FIG. 11 .
  • a removable storage medium such as a magnetic disk and an optical disk is inserted in the disk drive.
  • the serial port interface 1050 is connected to, for example, a mouse 1110 and a keyboard 1120 as illustrated in FIG. 11 .
  • the video adapter 1060 is connected to, for example, a display 1130 as illustrated in FIG. 11 .
  • the hard disk drive 1090 stores, for example, an OS 1091 , an application program 1092 , a program module 1093 , and program data 1094 .
  • the identification program is stored in, for example, the hard disk drive 1090 as a program module in which commands executed by the computer 1000 are written.
  • the various data explained in the embodiments are stored as program data in, for example, the memory 1010 and the hard disk drive 1090 .
  • the CPU 1020 loads the program module 1093 or the program data 1094 stored in the memory 1010 or the hard disk drive 1090 into the RAM 1012 as needed, and executes a tracking step, an analyzing step, and an identifying step.
  • the program module 1093 and the program data 1094 according to the identification program are not limited to the case where both are stored in the hard disk drive 1090 , and may be stored in, for example, a removable storage medium and read by the CPU 1020 via the disk drive etc.
  • the program module 1093 and the program data 1094 according to the identification program may be stored in other computer connected thereto via a network (LAN (Local Area Network) and WAN (Wide Area Network) etc.) and read by the CPU 1020 via the network interface 1070 .
  • LAN Local Area Network
  • WAN Wide Area Network

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Virology (AREA)
  • Computing Systems (AREA)
  • Debugging And Monitoring (AREA)
US15/528,875 2014-12-09 2015-12-04 Identification device, identification method, and identification program Active 2036-07-22 US10853483B2 (en)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP2014-249119 2014-12-09
JP2014249119 2014-12-09
PCT/JP2015/084215 WO2016093182A1 (ja) 2014-12-09 2015-12-04 特定装置、特定方法および特定プログラム

Publications (2)

Publication Number Publication Date
US20170329962A1 US20170329962A1 (en) 2017-11-16
US10853483B2 true US10853483B2 (en) 2020-12-01

Family

ID=56107367

Family Applications (1)

Application Number Title Priority Date Filing Date
US15/528,875 Active 2036-07-22 US10853483B2 (en) 2014-12-09 2015-12-04 Identification device, identification method, and identification program

Country Status (5)

Country Link
US (1) US10853483B2 (ja)
EP (1) EP3232359B1 (ja)
JP (1) JP6122562B2 (ja)
CN (1) CN107004088B (ja)
WO (1) WO2016093182A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11176251B1 (en) * 2018-12-21 2021-11-16 Fireeye, Inc. Determining malware via symbolic function hash analysis

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190121968A1 (en) * 2016-06-16 2019-04-25 Mitsubishi Electric Corporation Key generation source identification device, key generation source identification method, and computer readable medium
US10176325B1 (en) * 2016-06-21 2019-01-08 Symantec Corporation System and method for dynamic detection of command and control malware
US11022949B2 (en) 2016-06-24 2021-06-01 Siemens Aktiengesellschaft PLC virtual patching and automated distribution of security context
EP3293660A1 (en) * 2016-09-08 2018-03-14 Kaspersky Lab AO System and method of detecting malicious code in files
RU2637997C1 (ru) 2016-09-08 2017-12-08 Акционерное общество "Лаборатория Касперского" Система и способ обнаружения вредоносного кода в файле
JP6870386B2 (ja) * 2017-02-28 2021-05-12 沖電気工業株式会社 マルウェア不正通信対処システム及び方法
US11494216B2 (en) * 2019-08-16 2022-11-08 Google Llc Behavior-based VM resource capture for forensics
US11403392B2 (en) * 2020-01-06 2022-08-02 International Business Machines Corporation Security handling during application code branching
US12041094B2 (en) 2020-05-01 2024-07-16 Amazon Technologies, Inc. Threat sensor deployment and management
US12058148B2 (en) * 2020-05-01 2024-08-06 Amazon Technologies, Inc. Distributed threat sensor analysis and correlation

Citations (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060136720A1 (en) * 2004-12-21 2006-06-22 Microsoft Corporation Computer security management, such as in a virtual machine or hardened operating system
US20080016339A1 (en) * 2006-06-29 2008-01-17 Jayant Shukla Application Sandbox to Detect, Remove, and Prevent Malware
US20080216175A1 (en) * 2006-05-18 2008-09-04 Vmware, Inc. Computational system including mechanisms for tracking taint
US20090007100A1 (en) * 2007-06-28 2009-01-01 Microsoft Corporation Suspending a Running Operating System to Enable Security Scanning
US7870610B1 (en) * 2007-03-16 2011-01-11 The Board Of Directors Of The Leland Stanford Junior University Detection of malicious programs
US7958558B1 (en) 2006-05-18 2011-06-07 Vmware, Inc. Computational system including mechanisms for tracking propagation of information with aging
US20130024937A1 (en) * 2011-07-19 2013-01-24 Glew Andrew F Intrusion detection using taint accumulation
US20130036464A1 (en) 2011-08-04 2013-02-07 Glew Andrew F Processor operable to ensure code integrity
US20130097699A1 (en) 2011-10-18 2013-04-18 Mcafee, Inc. System and method for detecting a malicious command and control channel
US20130139262A1 (en) * 2011-11-30 2013-05-30 Daniel A. Gerrity Taint injection and tracking
CN103795679A (zh) 2012-10-26 2014-05-14 珠海市君天电子科技有限公司 一种钓鱼网站的快速检测方法及系统
WO2014098239A1 (ja) 2012-12-21 2014-06-26 日本電信電話株式会社 監視装置および監視方法
CN103914652A (zh) 2013-01-09 2014-07-09 腾讯科技（深圳）有限公司 恶意程序控制指令识别方法及装置
US20140344877A1 (en) * 2011-11-30 2014-11-20 Nippon Hoso Kyokai Reception device, program, and reception method
JP2014219741A (ja) 2013-05-01 2014-11-20 エヌ・ティ・ティ・コミュニケーションズ株式会社 指令元特定装置、指令元特定方法、及び指令元特定プログラム
WO2015137235A1 (ja) 2014-03-13 2015-09-17 日本電信電話株式会社 特定装置、特定方法および特定プログラム

Patent Citations (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060136720A1 (en) * 2004-12-21 2006-06-22 Microsoft Corporation Computer security management, such as in a virtual machine or hardened operating system
US8510827B1 (en) 2006-05-18 2013-08-13 Vmware, Inc. Taint tracking mechanism for computer security
US20140033309A1 (en) * 2006-05-18 2014-01-30 Vmware, Inc. Taint tracking mechanism for computer security
US20080216175A1 (en) * 2006-05-18 2008-09-04 Vmware, Inc. Computational system including mechanisms for tracking taint
US7958558B1 (en) 2006-05-18 2011-06-07 Vmware, Inc. Computational system including mechanisms for tracking propagation of information with aging
US20080016339A1 (en) * 2006-06-29 2008-01-17 Jayant Shukla Application Sandbox to Detect, Remove, and Prevent Malware
US7870610B1 (en) * 2007-03-16 2011-01-11 The Board Of Directors Of The Leland Stanford Junior University Detection of malicious programs
US20090007100A1 (en) * 2007-06-28 2009-01-01 Microsoft Corporation Suspending a Running Operating System to Enable Security Scanning
US20130024937A1 (en) * 2011-07-19 2013-01-24 Glew Andrew F Intrusion detection using taint accumulation
US20130036464A1 (en) 2011-08-04 2013-02-07 Glew Andrew F Processor operable to ensure code integrity
US20160277441A1 (en) 2011-09-24 2016-09-22 Elwha Llc Taint injection and tracking
US20130097699A1 (en) 2011-10-18 2013-04-18 Mcafee, Inc. System and method for detecting a malicious command and control channel
US20130139262A1 (en) * 2011-11-30 2013-05-30 Daniel A. Gerrity Taint injection and tracking
US20140344877A1 (en) * 2011-11-30 2014-11-20 Nippon Hoso Kyokai Reception device, program, and reception method
CN103795679A (zh) 2012-10-26 2014-05-14 珠海市君天电子科技有限公司 一种钓鱼网站的快速检测方法及系统
WO2014098239A1 (ja) 2012-12-21 2014-06-26 日本電信電話株式会社 監視装置および監視方法
CN103914652A (zh) 2013-01-09 2014-07-09 腾讯科技（深圳）有限公司 恶意程序控制指令识别方法及装置
JP2014219741A (ja) 2013-05-01 2014-11-20 エヌ・ティ・ティ・コミュニケーションズ株式会社 指令元特定装置、指令元特定方法、及び指令元特定プログラム
WO2015137235A1 (ja) 2014-03-13 2015-09-17 日本電信電話株式会社 特定装置、特定方法および特定プログラム
US20170019418A1 (en) 2014-03-13 2017-01-19 Nippon Telegraph And Telephone Corporation Identifying apparatus, identifying method, and identifying program

Non-Patent Citations (7)

* Cited by examiner, † Cited by third party
Title
Chia-Mei Chen et al., "Defending Malicious Attacks in Cyber Physical Systems," IEEE, pp. 13-18, 2013 (Year: 2013). *
Combined Chinese Office Action and Search Report dated Aug. 5, 2019 in Chinese Patent Application No. 201580066814.8 (with partial unedited computer generated English translation and English translation of categories of cited documents) citing documents AO and AR therein, 15 pages.
Extended European Search Report dated Apr. 4, 2018 in Patent Application No. 15867444.0 citing references AA-AG therein, 7 pages.
G. Jacob et al., "Jackstraws: Picking Command and Control Connections from Bot Traffic", In Proceedings of the 20th USENIX Conference on Security, Aug. 12, 2011, 16 pages.
International Search Report dated Mar. 1, 2016 in PCT/JP2015/084215 filed on Dec. 4, 2015.
Nathan VanHoudnos et al. "This Malware Looks Familiar: Laymen Identify Malware Run-time Similarity with Chernoff faces and Stick Figures," ACM, pp. 1-8, 2017. (Year: 2017). *
Tomonori Ikuse et al. "Identifying C&C Server by Analyzing Relation between Control Flow and Communications", IEICE Technical Report, Mar. 20, 2014, vol. 113, No. 502, 6 pages (with English Abstract).

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11176251B1 (en) * 2018-12-21 2021-11-16 Fireeye, Inc. Determining malware via symbolic function hash analysis

Also Published As

Publication number Publication date
WO2016093182A1 (ja) 2016-06-16
EP3232359A1 (en) 2017-10-18
CN107004088A (zh) 2017-08-01
JPWO2016093182A1 (ja) 2017-04-27
CN107004088B (zh) 2020-03-31
JP6122562B2 (ja) 2017-04-26
EP3232359A4 (en) 2018-05-02
EP3232359B1 (en) 2019-05-01
US20170329962A1 (en) 2017-11-16

Similar Documents

Publication Publication Date Title
US10853483B2 (en) Identification device, identification method, and identification program
US10397261B2 (en) Identifying device, identifying method and identifying program
US10382455B2 (en) Identifying apparatus, identifying method, and identifying program
US8875296B2 (en) Methods and systems for providing a framework to test the security of computing system over a network
US9507933B2 (en) Program execution apparatus and program analysis apparatus
US10412101B2 (en) Detection device, detection method, and detection program
US10701087B2 (en) Analysis apparatus, analysis method, and analysis program
WO2021243555A1 (zh) 一种快应用检测方法、装置、设备及存储介质
US10893090B2 (en) Monitoring a process on an IoT device
US11714899B2 (en) Command injection identification
CN113824748B (zh) 一种资产特征主动探测对抗方法、装置、电子设备及介质
US20170085586A1 (en) Information processing device, communication history analysis method, and medium
US20210406362A1 (en) Request control device, request control method, and request control program
JPWO2019049478A1 (ja) コールスタック取得装置、コールスタック取得方法およびコールスタック取得プログラム
Chen et al. SaTC: Shared-Keyword Aware Taint Checking for Detecting Bugs in Embedded Systems
US8429744B1 (en) Systems and methods for detecting malformed arguments in a function by hooking a generic object
US20240214417A1 (en) Analysis device, analysis method, and analysis system
CN114363006A (zh) 基于WinRM服务的防护方法及装置

Legal Events

Date Code Title Description
AS Assignment

Owner name: NIPPON TELEGRAPH AND TELEPHONE CORPORATION, JAPAN

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:IKUSE, TOMONORI;AOKI, KAZUFUMI;HARIU, TAKEO;REEL/FRAME:042475/0081

Effective date: 20170424

STPP Information on status: patent application and granting procedure in general

Free format text: DOCKETED NEW CASE - READY FOR EXAMINATION

STPP Information on status: patent application and granting procedure in general

Free format text: NON FINAL ACTION MAILED

STPP Information on status: patent application and granting procedure in general

Free format text: RESPONSE TO NON-FINAL OFFICE ACTION ENTERED AND FORWARDED TO EXAMINER

STPP Information on status: patent application and granting procedure in general

Free format text: FINAL REJECTION MAILED

STPP Information on status: patent application and granting procedure in general

Free format text: DOCKETED NEW CASE - READY FOR EXAMINATION

STPP Information on status: patent application and granting procedure in general

Free format text: RESPONSE TO NON-FINAL OFFICE ACTION ENTERED AND FORWARDED TO EXAMINER

STPP Information on status: patent application and granting procedure in general

Free format text: AWAITING TC RESP., ISSUE FEE NOT PAID

STCF Information on status: patent grant

Free format text: PATENTED CASE

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 4TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1551); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

Year of fee payment: 4